Re: [PATCH] KVM: s390: generate kvm hypercall functions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jul 13, 2021 at 05:59:17PM +0200, Christian Borntraeger wrote:
> On 13.07.21 17:52, Heiko Carstens wrote:
> > On Tue, Jul 13, 2021 at 05:41:33PM +0200, Christian Borntraeger wrote:
> > > On 13.07.21 16:57, Heiko Carstens wrote:
> > > [..]
> > > > +#define HYPERCALL_FMT_0
> > > > +#define HYPERCALL_FMT_1 , "0" (r2)
> > > > +#define HYPERCALL_FMT_2 , "d" (r3) HYPERCALL_FMT_1
> > > > +#define HYPERCALL_FMT_3 , "d" (r4) HYPERCALL_FMT_2
> > > > +#define HYPERCALL_FMT_4 , "d" (r5) HYPERCALL_FMT_3
> > > > +#define HYPERCALL_FMT_5 , "d" (r6) HYPERCALL_FMT_4
> > > > +#define HYPERCALL_FMT_6 , "d" (r7) HYPERCALL_FMT_5
> > > 
> > > This will result in reverse order.
> > > old:
> > > "d" (__nr), "0" (__p1), "d" (__p2), "d" (__p3), "d" (__p4), "d" (__p5), "d" (__p6)
> > > new:
> > > "d"(__nr), "d"(r7), "d"(r6), "d"(r5), "d"(r4), "d"(r3), "0"(r2)
> > > 
> > > As we do not reference the variable in the asm this should not matter,
> > > I just noticed it when comparing the result of the preprocessed files.
> > > 
> > > Assuming that we do not care this looks good.
> > 
> > Yes, it does not matter. Please let me know if should change it anyway.
> 
> No, I think this is ok.
> Shall I take it via the kvm tree or do you want to take it via the s390 tree?

I think this should go via kvm tree. It probably has to wait until next merge
window anyway(?).



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux