| Message ID | 20200131174930.31045-6-liuwe@microsoft.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | More Hyper-V infrastructures | expand |
(Note to self) On Fri, Jan 31, 2020 at 05:49:24PM +0000, Wei Liu wrote: [...] > +static uint64_t generate_guest_id(void) > +{ > + union hv_guest_os_id id; > + id.raw = 0; > + id.vendor = HV_XEN_VENDOR_ID; > + id.major = xen_major_version(); > + id.minor = xen_minor_version(); > + > + return id.raw; > +}
> -----Original Message----- > From: Wei Liu <wl@xen.org> > Sent: 31 January 2020 17:57 > To: Xen Development List <xen-devel@lists.xenproject.org> > Cc: Durrant, Paul <pdurrant@amazon.co.uk>; Michael Kelley > <mikelley@microsoft.com>; Wei Liu <liuwe@microsoft.com>; Wei Liu > <wl@xen.org>; Jan Beulich <jbeulich@suse.com>; Andrew Cooper > <andrew.cooper3@citrix.com>; Roger Pau Monné <roger.pau@citrix.com> > Subject: Re: [PATCH v6 05/11] x86/hyperv: setup hypercall page > > (Note to self) > > On Fri, Jan 31, 2020 at 05:49:24PM +0000, Wei Liu wrote: > [...] > > +static uint64_t generate_guest_id(void) > > +{ > > + union hv_guest_os_id id; > > + > > id.raw = 0; Or just use a C99 initializer to set things up. A bit neater IMO. Paul > > > + id.vendor = HV_XEN_VENDOR_ID; > > + id.major = xen_major_version(); > > + id.minor = xen_minor_version(); > > + > > + return id.raw; > > +}
On 03.02.2020 11:39, Durrant, Paul wrote: >> -----Original Message----- >> From: Wei Liu <wl@xen.org> >> Sent: 31 January 2020 17:57 >> To: Xen Development List <xen-devel@lists.xenproject.org> >> Cc: Durrant, Paul <pdurrant@amazon.co.uk>; Michael Kelley >> <mikelley@microsoft.com>; Wei Liu <liuwe@microsoft.com>; Wei Liu >> <wl@xen.org>; Jan Beulich <jbeulich@suse.com>; Andrew Cooper >> <andrew.cooper3@citrix.com>; Roger Pau Monné <roger.pau@citrix.com> >> Subject: Re: [PATCH v6 05/11] x86/hyperv: setup hypercall page >> >> (Note to self) >> >> On Fri, Jan 31, 2020 at 05:49:24PM +0000, Wei Liu wrote: >> [...] >>> +static uint64_t generate_guest_id(void) >>> +{ >>> + union hv_guest_os_id id; >>> + >> >> id.raw = 0; > > Or just use a C99 initializer to set things up. A bit neater IMO. If you mean this for ... >>> + id.vendor = HV_XEN_VENDOR_ID; >>> + id.major = xen_major_version(); >>> + id.minor = xen_minor_version(); ... these three fields, then this won't work with rather old gcc we still permit to be used. Using { .raw = 0 } would work afaict. Jan
> -----Original Message----- > From: Jan Beulich <jbeulich@suse.com> > Sent: 03 February 2020 11:06 > To: Durrant, Paul <pdurrant@amazon.co.uk> > Cc: Wei Liu <wl@xen.org>; Xen Development List <xen- > devel@lists.xenproject.org>; Michael Kelley <mikelley@microsoft.com>; Wei > Liu <liuwe@microsoft.com>; Andrew Cooper <andrew.cooper3@citrix.com>; > Roger Pau Monné <roger.pau@citrix.com> > Subject: Re: [PATCH v6 05/11] x86/hyperv: setup hypercall page > > On 03.02.2020 11:39, Durrant, Paul wrote: > >> -----Original Message----- > >> From: Wei Liu <wl@xen.org> > >> Sent: 31 January 2020 17:57 > >> To: Xen Development List <xen-devel@lists.xenproject.org> > >> Cc: Durrant, Paul <pdurrant@amazon.co.uk>; Michael Kelley > >> <mikelley@microsoft.com>; Wei Liu <liuwe@microsoft.com>; Wei Liu > >> <wl@xen.org>; Jan Beulich <jbeulich@suse.com>; Andrew Cooper > >> <andrew.cooper3@citrix.com>; Roger Pau Monné <roger.pau@citrix.com> > >> Subject: Re: [PATCH v6 05/11] x86/hyperv: setup hypercall page > >> > >> (Note to self) > >> > >> On Fri, Jan 31, 2020 at 05:49:24PM +0000, Wei Liu wrote: > >> [...] > >>> +static uint64_t generate_guest_id(void) > >>> +{ > >>> + union hv_guest_os_id id; > >>> + > >> > >> id.raw = 0; > > > > Or just use a C99 initializer to set things up. A bit neater IMO. > > If you mean this for ... > > >>> + id.vendor = HV_XEN_VENDOR_ID; > >>> + id.major = xen_major_version(); > >>> + id.minor = xen_minor_version(); > > ... these three fields, then this won't work with rather old gcc > we still permit to be used. Using { .raw = 0 } would work afaict. > Not even { .vendor = HV_XEN_VENDOR_ID } ? Paul > Jan
On 03.02.2020 12:21, Durrant, Paul wrote: >> -----Original Message----- >> From: Jan Beulich <jbeulich@suse.com> >> Sent: 03 February 2020 11:06 >> To: Durrant, Paul <pdurrant@amazon.co.uk> >> Cc: Wei Liu <wl@xen.org>; Xen Development List <xen- >> devel@lists.xenproject.org>; Michael Kelley <mikelley@microsoft.com>; Wei >> Liu <liuwe@microsoft.com>; Andrew Cooper <andrew.cooper3@citrix.com>; >> Roger Pau Monné <roger.pau@citrix.com> >> Subject: Re: [PATCH v6 05/11] x86/hyperv: setup hypercall page >> >> On 03.02.2020 11:39, Durrant, Paul wrote: >>>> -----Original Message----- >>>> From: Wei Liu <wl@xen.org> >>>> Sent: 31 January 2020 17:57 >>>> To: Xen Development List <xen-devel@lists.xenproject.org> >>>> Cc: Durrant, Paul <pdurrant@amazon.co.uk>; Michael Kelley >>>> <mikelley@microsoft.com>; Wei Liu <liuwe@microsoft.com>; Wei Liu >>>> <wl@xen.org>; Jan Beulich <jbeulich@suse.com>; Andrew Cooper >>>> <andrew.cooper3@citrix.com>; Roger Pau Monné <roger.pau@citrix.com> >>>> Subject: Re: [PATCH v6 05/11] x86/hyperv: setup hypercall page >>>> >>>> (Note to self) >>>> >>>> On Fri, Jan 31, 2020 at 05:49:24PM +0000, Wei Liu wrote: >>>> [...] >>>>> +static uint64_t generate_guest_id(void) >>>>> +{ >>>>> + union hv_guest_os_id id; >>>>> + >>>> >>>> id.raw = 0; >>> >>> Or just use a C99 initializer to set things up. A bit neater IMO. >> >> If you mean this for ... >> >>>>> + id.vendor = HV_XEN_VENDOR_ID; >>>>> + id.major = xen_major_version(); >>>>> + id.minor = xen_minor_version(); >> >> ... these three fields, then this won't work with rather old gcc >> we still permit to be used. Using { .raw = 0 } would work afaict. >> > > Not even { .vendor = HV_XEN_VENDOR_ID } ? No, because of it being part of an unnamed (struct) member of the union. Jan
> -----Original Message----- > From: Jan Beulich <jbeulich@suse.com> > Sent: 03 February 2020 11:34 > To: Durrant, Paul <pdurrant@amazon.co.uk> > Cc: Wei Liu <wl@xen.org>; Xen Development List <xen- > devel@lists.xenproject.org>; Michael Kelley <mikelley@microsoft.com>; Wei > Liu <liuwe@microsoft.com>; Andrew Cooper <andrew.cooper3@citrix.com>; > Roger Pau Monné <roger.pau@citrix.com> > Subject: Re: [PATCH v6 05/11] x86/hyperv: setup hypercall page > > On 03.02.2020 12:21, Durrant, Paul wrote: > >> -----Original Message----- > >> From: Jan Beulich <jbeulich@suse.com> > >> Sent: 03 February 2020 11:06 > >> To: Durrant, Paul <pdurrant@amazon.co.uk> > >> Cc: Wei Liu <wl@xen.org>; Xen Development List <xen- > >> devel@lists.xenproject.org>; Michael Kelley <mikelley@microsoft.com>; > Wei > >> Liu <liuwe@microsoft.com>; Andrew Cooper <andrew.cooper3@citrix.com>; > >> Roger Pau Monné <roger.pau@citrix.com> > >> Subject: Re: [PATCH v6 05/11] x86/hyperv: setup hypercall page > >> > >> On 03.02.2020 11:39, Durrant, Paul wrote: > >>>> -----Original Message----- > >>>> From: Wei Liu <wl@xen.org> > >>>> Sent: 31 January 2020 17:57 > >>>> To: Xen Development List <xen-devel@lists.xenproject.org> > >>>> Cc: Durrant, Paul <pdurrant@amazon.co.uk>; Michael Kelley > >>>> <mikelley@microsoft.com>; Wei Liu <liuwe@microsoft.com>; Wei Liu > >>>> <wl@xen.org>; Jan Beulich <jbeulich@suse.com>; Andrew Cooper > >>>> <andrew.cooper3@citrix.com>; Roger Pau Monné <roger.pau@citrix.com> > >>>> Subject: Re: [PATCH v6 05/11] x86/hyperv: setup hypercall page > >>>> > >>>> (Note to self) > >>>> > >>>> On Fri, Jan 31, 2020 at 05:49:24PM +0000, Wei Liu wrote: > >>>> [...] > >>>>> +static uint64_t generate_guest_id(void) > >>>>> +{ > >>>>> + union hv_guest_os_id id; > >>>>> + > >>>> > >>>> id.raw = 0; > >>> > >>> Or just use a C99 initializer to set things up. A bit neater IMO. > >> > >> If you mean this for ... > >> > >>>>> + id.vendor = HV_XEN_VENDOR_ID; > >>>>> + id.major = xen_major_version(); > >>>>> + id.minor = xen_minor_version(); > >> > >> ... these three fields, then this won't work with rather old gcc > >> we still permit to be used. Using { .raw = 0 } would work afaict. > >> > > > > Not even { .vendor = HV_XEN_VENDOR_ID } ? > > No, because of it being part of an unnamed (struct) member of > the union. Ok... shame. Presumably an empty initializer - {} - would be ok? Paul > > Jan
On 03.02.2020 12:37, Durrant, Paul wrote: >> -----Original Message----- >> From: Jan Beulich <jbeulich@suse.com> >> Sent: 03 February 2020 11:34 >> To: Durrant, Paul <pdurrant@amazon.co.uk> >> Cc: Wei Liu <wl@xen.org>; Xen Development List <xen- >> devel@lists.xenproject.org>; Michael Kelley <mikelley@microsoft.com>; Wei >> Liu <liuwe@microsoft.com>; Andrew Cooper <andrew.cooper3@citrix.com>; >> Roger Pau Monné <roger.pau@citrix.com> >> Subject: Re: [PATCH v6 05/11] x86/hyperv: setup hypercall page >> >> On 03.02.2020 12:21, Durrant, Paul wrote: >>>> -----Original Message----- >>>> From: Jan Beulich <jbeulich@suse.com> >>>> Sent: 03 February 2020 11:06 >>>> To: Durrant, Paul <pdurrant@amazon.co.uk> >>>> Cc: Wei Liu <wl@xen.org>; Xen Development List <xen- >>>> devel@lists.xenproject.org>; Michael Kelley <mikelley@microsoft.com>; >> Wei >>>> Liu <liuwe@microsoft.com>; Andrew Cooper <andrew.cooper3@citrix.com>; >>>> Roger Pau Monné <roger.pau@citrix.com> >>>> Subject: Re: [PATCH v6 05/11] x86/hyperv: setup hypercall page >>>> >>>> On 03.02.2020 11:39, Durrant, Paul wrote: >>>>>> -----Original Message----- >>>>>> From: Wei Liu <wl@xen.org> >>>>>> Sent: 31 January 2020 17:57 >>>>>> To: Xen Development List <xen-devel@lists.xenproject.org> >>>>>> Cc: Durrant, Paul <pdurrant@amazon.co.uk>; Michael Kelley >>>>>> <mikelley@microsoft.com>; Wei Liu <liuwe@microsoft.com>; Wei Liu >>>>>> <wl@xen.org>; Jan Beulich <jbeulich@suse.com>; Andrew Cooper >>>>>> <andrew.cooper3@citrix.com>; Roger Pau Monné <roger.pau@citrix.com> >>>>>> Subject: Re: [PATCH v6 05/11] x86/hyperv: setup hypercall page >>>>>> >>>>>> (Note to self) >>>>>> >>>>>> On Fri, Jan 31, 2020 at 05:49:24PM +0000, Wei Liu wrote: >>>>>> [...] >>>>>>> +static uint64_t generate_guest_id(void) >>>>>>> +{ >>>>>>> + union hv_guest_os_id id; >>>>>>> + >>>>>> >>>>>> id.raw = 0; >>>>> >>>>> Or just use a C99 initializer to set things up. A bit neater IMO. >>>> >>>> If you mean this for ... >>>> >>>>>>> + id.vendor = HV_XEN_VENDOR_ID; >>>>>>> + id.major = xen_major_version(); >>>>>>> + id.minor = xen_minor_version(); >>>> >>>> ... these three fields, then this won't work with rather old gcc >>>> we still permit to be used. Using { .raw = 0 } would work afaict. >>>> >>> >>> Not even { .vendor = HV_XEN_VENDOR_ID } ? >> >> No, because of it being part of an unnamed (struct) member of >> the union. > > Ok... shame. Presumably an empty initializer - {} - would be ok? I think so, yes. I understand you'd like this better than { .raw = 0 } ? Jan
> -----Original Message----- > From: Jan Beulich <jbeulich@suse.com> > Sent: 03 February 2020 11:39 > To: Durrant, Paul <pdurrant@amazon.co.uk> > Cc: Wei Liu <wl@xen.org>; Xen Development List <xen- > devel@lists.xenproject.org>; Michael Kelley <mikelley@microsoft.com>; Wei > Liu <liuwe@microsoft.com>; Andrew Cooper <andrew.cooper3@citrix.com>; > Roger Pau Monné <roger.pau@citrix.com> > Subject: Re: [PATCH v6 05/11] x86/hyperv: setup hypercall page > > On 03.02.2020 12:37, Durrant, Paul wrote: > >> -----Original Message----- > >> From: Jan Beulich <jbeulich@suse.com> > >> Sent: 03 February 2020 11:34 > >> To: Durrant, Paul <pdurrant@amazon.co.uk> > >> Cc: Wei Liu <wl@xen.org>; Xen Development List <xen- > >> devel@lists.xenproject.org>; Michael Kelley <mikelley@microsoft.com>; > Wei > >> Liu <liuwe@microsoft.com>; Andrew Cooper <andrew.cooper3@citrix.com>; > >> Roger Pau Monné <roger.pau@citrix.com> > >> Subject: Re: [PATCH v6 05/11] x86/hyperv: setup hypercall page > >> > >> On 03.02.2020 12:21, Durrant, Paul wrote: > >>>> -----Original Message----- > >>>> From: Jan Beulich <jbeulich@suse.com> > >>>> Sent: 03 February 2020 11:06 > >>>> To: Durrant, Paul <pdurrant@amazon.co.uk> > >>>> Cc: Wei Liu <wl@xen.org>; Xen Development List <xen- > >>>> devel@lists.xenproject.org>; Michael Kelley <mikelley@microsoft.com>; > >> Wei > >>>> Liu <liuwe@microsoft.com>; Andrew Cooper <andrew.cooper3@citrix.com>; > >>>> Roger Pau Monné <roger.pau@citrix.com> > >>>> Subject: Re: [PATCH v6 05/11] x86/hyperv: setup hypercall page > >>>> > >>>> On 03.02.2020 11:39, Durrant, Paul wrote: > >>>>>> -----Original Message----- > >>>>>> From: Wei Liu <wl@xen.org> > >>>>>> Sent: 31 January 2020 17:57 > >>>>>> To: Xen Development List <xen-devel@lists.xenproject.org> > >>>>>> Cc: Durrant, Paul <pdurrant@amazon.co.uk>; Michael Kelley > >>>>>> <mikelley@microsoft.com>; Wei Liu <liuwe@microsoft.com>; Wei Liu > >>>>>> <wl@xen.org>; Jan Beulich <jbeulich@suse.com>; Andrew Cooper > >>>>>> <andrew.cooper3@citrix.com>; Roger Pau Monné <roger.pau@citrix.com> > >>>>>> Subject: Re: [PATCH v6 05/11] x86/hyperv: setup hypercall page > >>>>>> > >>>>>> (Note to self) > >>>>>> > >>>>>> On Fri, Jan 31, 2020 at 05:49:24PM +0000, Wei Liu wrote: > >>>>>> [...] > >>>>>>> +static uint64_t generate_guest_id(void) > >>>>>>> +{ > >>>>>>> + union hv_guest_os_id id; > >>>>>>> + > >>>>>> > >>>>>> id.raw = 0; > >>>>> > >>>>> Or just use a C99 initializer to set things up. A bit neater IMO. > >>>> > >>>> If you mean this for ... > >>>> > >>>>>>> + id.vendor = HV_XEN_VENDOR_ID; > >>>>>>> + id.major = xen_major_version(); > >>>>>>> + id.minor = xen_minor_version(); > >>>> > >>>> ... these three fields, then this won't work with rather old gcc > >>>> we still permit to be used. Using { .raw = 0 } would work afaict. > >>>> > >>> > >>> Not even { .vendor = HV_XEN_VENDOR_ID } ? > >> > >> No, because of it being part of an unnamed (struct) member of > >> the union. > > > > Ok... shame. Presumably an empty initializer - {} - would be ok? > > I think so, yes. I understand you'd like this better than > { .raw = 0 } ? > Yes. In general, using a c99 initializer to explicitly set something to 0 seems a bit redundant to me. Paul > Jan
On Mon, Feb 03, 2020 at 11:41:57AM +0000, Durrant, Paul wrote: > > -----Original Message----- > > From: Jan Beulich <jbeulich@suse.com> > > Sent: 03 February 2020 11:39 > > To: Durrant, Paul <pdurrant@amazon.co.uk> > > Cc: Wei Liu <wl@xen.org>; Xen Development List <xen- > > devel@lists.xenproject.org>; Michael Kelley <mikelley@microsoft.com>; Wei > > Liu <liuwe@microsoft.com>; Andrew Cooper <andrew.cooper3@citrix.com>; > > Roger Pau Monné <roger.pau@citrix.com> > > Subject: Re: [PATCH v6 05/11] x86/hyperv: setup hypercall page > > > > On 03.02.2020 12:37, Durrant, Paul wrote: > > >> -----Original Message----- > > >> From: Jan Beulich <jbeulich@suse.com> > > >> Sent: 03 February 2020 11:34 > > >> To: Durrant, Paul <pdurrant@amazon.co.uk> > > >> Cc: Wei Liu <wl@xen.org>; Xen Development List <xen- > > >> devel@lists.xenproject.org>; Michael Kelley <mikelley@microsoft.com>; > > Wei > > >> Liu <liuwe@microsoft.com>; Andrew Cooper <andrew.cooper3@citrix.com>; > > >> Roger Pau Monné <roger.pau@citrix.com> > > >> Subject: Re: [PATCH v6 05/11] x86/hyperv: setup hypercall page > > >> > > >> On 03.02.2020 12:21, Durrant, Paul wrote: > > >>>> -----Original Message----- > > >>>> From: Jan Beulich <jbeulich@suse.com> > > >>>> Sent: 03 February 2020 11:06 > > >>>> To: Durrant, Paul <pdurrant@amazon.co.uk> > > >>>> Cc: Wei Liu <wl@xen.org>; Xen Development List <xen- > > >>>> devel@lists.xenproject.org>; Michael Kelley <mikelley@microsoft.com>; > > >> Wei > > >>>> Liu <liuwe@microsoft.com>; Andrew Cooper <andrew.cooper3@citrix.com>; > > >>>> Roger Pau Monné <roger.pau@citrix.com> > > >>>> Subject: Re: [PATCH v6 05/11] x86/hyperv: setup hypercall page > > >>>> > > >>>> On 03.02.2020 11:39, Durrant, Paul wrote: > > >>>>>> -----Original Message----- > > >>>>>> From: Wei Liu <wl@xen.org> > > >>>>>> Sent: 31 January 2020 17:57 > > >>>>>> To: Xen Development List <xen-devel@lists.xenproject.org> > > >>>>>> Cc: Durrant, Paul <pdurrant@amazon.co.uk>; Michael Kelley > > >>>>>> <mikelley@microsoft.com>; Wei Liu <liuwe@microsoft.com>; Wei Liu > > >>>>>> <wl@xen.org>; Jan Beulich <jbeulich@suse.com>; Andrew Cooper > > >>>>>> <andrew.cooper3@citrix.com>; Roger Pau Monné <roger.pau@citrix.com> > > >>>>>> Subject: Re: [PATCH v6 05/11] x86/hyperv: setup hypercall page > > >>>>>> > > >>>>>> (Note to self) > > >>>>>> > > >>>>>> On Fri, Jan 31, 2020 at 05:49:24PM +0000, Wei Liu wrote: > > >>>>>> [...] > > >>>>>>> +static uint64_t generate_guest_id(void) > > >>>>>>> +{ > > >>>>>>> + union hv_guest_os_id id; > > >>>>>>> + > > >>>>>> > > >>>>>> id.raw = 0; > > >>>>> > > >>>>> Or just use a C99 initializer to set things up. A bit neater IMO. > > >>>> > > >>>> If you mean this for ... > > >>>> > > >>>>>>> + id.vendor = HV_XEN_VENDOR_ID; > > >>>>>>> + id.major = xen_major_version(); > > >>>>>>> + id.minor = xen_minor_version(); > > >>>> > > >>>> ... these three fields, then this won't work with rather old gcc > > >>>> we still permit to be used. Using { .raw = 0 } would work afaict. > > >>>> > > >>> > > >>> Not even { .vendor = HV_XEN_VENDOR_ID } ? > > >> > > >> No, because of it being part of an unnamed (struct) member of > > >> the union. > > > > > > Ok... shame. Presumably an empty initializer - {} - would be ok? > > > > I think so, yes. I understand you'd like this better than > > { .raw = 0 } ? > > > > Yes. In general, using a c99 initializer to explicitly set something > to 0 seems a bit redundant to me. Alright. I have changed it to union hv_guest_os_id id = {}; in my local branch. Wei. > > Paul > > > Jan
On 31.01.2020 18:49, Wei Liu wrote: > +static void __init setup_hypercall_page(void) > +{ > + union hv_x64_msr_hypercall_contents hypercall_msr; > + union hv_guest_os_id guest_id; > + unsigned long mfn; > + > + BUILD_BUG_ON(HV_HYP_PAGE_SHIFT != PAGE_SHIFT); > + > + rdmsrl(HV_X64_MSR_GUEST_OS_ID, guest_id.raw); > + if ( !guest_id.raw ) > + { > + guest_id.raw = generate_guest_id(); > + wrmsrl(HV_X64_MSR_GUEST_OS_ID, guest_id.raw); > + } > + > + rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); > + if ( !hypercall_msr.enable ) > + { > + mfn = HV_HCALL_MFN; > + hypercall_msr.enable = 1; > + hypercall_msr.guest_physical_address = mfn; > + wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); > + } else { > + mfn = hypercall_msr.guest_physical_address; > + } Nit: Style. Preferably omit the braces from "else" altogether. Jan
On Mon, Feb 03, 2020 at 02:21:14PM +0100, Jan Beulich wrote: > On 31.01.2020 18:49, Wei Liu wrote: > > +static void __init setup_hypercall_page(void) > > +{ > > + union hv_x64_msr_hypercall_contents hypercall_msr; > > + union hv_guest_os_id guest_id; > > + unsigned long mfn; > > + > > + BUILD_BUG_ON(HV_HYP_PAGE_SHIFT != PAGE_SHIFT); > > + > > + rdmsrl(HV_X64_MSR_GUEST_OS_ID, guest_id.raw); > > + if ( !guest_id.raw ) > > + { > > + guest_id.raw = generate_guest_id(); > > + wrmsrl(HV_X64_MSR_GUEST_OS_ID, guest_id.raw); > > + } > > + > > + rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); > > + if ( !hypercall_msr.enable ) > > + { > > + mfn = HV_HCALL_MFN; > > + hypercall_msr.enable = 1; > > + hypercall_msr.guest_physical_address = mfn; > > + wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); > > + } else { > > + mfn = hypercall_msr.guest_physical_address; > > + } > > Nit: Style. Preferably omit the braces from "else" altogether. Fixed. Wei.
On Fri, Jan 31, 2020 at 05:49:24PM +0000, Wei Liu wrote: > Hyper-V uses a technique called overlay page for its hypercall page. It > will insert a backing page to the guest when the hypercall functionality > is enabled. That means we can use a page that is not backed by real > memory for hypercall page. > > Use the top-most addressable page for that purpose. Adjust e820 map > accordingly. Can you add this is done to avoid page shattering and to make sure Xen isn't overwriting any MMIO area which might be present at lower addresses? > > We also need to register Xen's guest OS ID to Hyper-V. Use 0x3 as the > vendor ID. Fix the comment in hyperv-tlfs.h while at it. > > Signed-off-by: Wei Liu <liuwe@microsoft.com> > --- > v6: > 1. Use hv_guest_os_id > 2. Use new e820_fixup hook > 3. Add a BUILD_BUG_ON > > v5: > 1. use hypervisor_reserve_top_pages > 2. add a macro for hypercall page mfn > 3. address other misc comments > > v4: > 1. Use fixmap > 2. Follow routines listed in TLFS > --- > xen/arch/x86/guest/hyperv/hyperv.c | 69 +++++++++++++++++++++++-- > xen/include/asm-x86/guest/hyperv-tlfs.h | 5 +- > xen/include/asm-x86/guest/hyperv.h | 3 ++ > 3 files changed, 72 insertions(+), 5 deletions(-) > > diff --git a/xen/arch/x86/guest/hyperv/hyperv.c b/xen/arch/x86/guest/hyperv/hyperv.c > index 8d38313d7a..7c2a96d70e 100644 > --- a/xen/arch/x86/guest/hyperv/hyperv.c > +++ b/xen/arch/x86/guest/hyperv/hyperv.c > @@ -19,15 +19,27 @@ > * Copyright (c) 2019 Microsoft. > */ > #include <xen/init.h> > +#include <xen/version.h> > > +#include <asm/fixmap.h> > #include <asm/guest.h> > #include <asm/guest/hyperv-tlfs.h> > +#include <asm/processor.h> > > struct ms_hyperv_info __read_mostly ms_hyperv; > > -static const struct hypervisor_ops ops = { > - .name = "Hyper-V", > -}; > +static uint64_t generate_guest_id(void) > +{ > + union hv_guest_os_id id; > + > + id.vendor = HV_XEN_VENDOR_ID; > + id.major = xen_major_version(); > + id.minor = xen_minor_version(); > + > + return id.raw; > +} > + > +static const struct hypervisor_ops ops; > > const struct hypervisor_ops *__init hyperv_probe(void) > { > @@ -72,6 +84,57 @@ const struct hypervisor_ops *__init hyperv_probe(void) > return &ops; > } > > +static void __init setup_hypercall_page(void) > +{ > + union hv_x64_msr_hypercall_contents hypercall_msr; > + union hv_guest_os_id guest_id; > + unsigned long mfn; > + > + BUILD_BUG_ON(HV_HYP_PAGE_SHIFT != PAGE_SHIFT); > + > + rdmsrl(HV_X64_MSR_GUEST_OS_ID, guest_id.raw); > + if ( !guest_id.raw ) > + { > + guest_id.raw = generate_guest_id(); > + wrmsrl(HV_X64_MSR_GUEST_OS_ID, guest_id.raw); > + } > + > + rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); > + if ( !hypercall_msr.enable ) > + { > + mfn = HV_HCALL_MFN; > + hypercall_msr.enable = 1; > + hypercall_msr.guest_physical_address = mfn; > + wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); > + } else { > + mfn = hypercall_msr.guest_physical_address; > + } > + > + rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); > + BUG_ON(!hypercall_msr.enable); > + > + set_fixmap_x(FIX_X_HYPERV_HCALL, mfn << PAGE_SHIFT); > +} > + > +static void __init setup(void) > +{ > + setup_hypercall_page(); > +} > + > +static void __init e820_fixup(struct e820map *e820) > +{ > + uint64_t s = HV_HCALL_MFN << PAGE_SHIFT; > + > + if ( !e820_add_range(e820, s, s + PAGE_SIZE, E820_RESERVED) ) I think end should be s + PAGE_SIZE - 1, or else it expands across two pages? Thanks, Roger.
On Mon, Feb 03, 2020 at 04:01:54PM +0100, Roger Pau Monné wrote: > On Fri, Jan 31, 2020 at 05:49:24PM +0000, Wei Liu wrote: > > Hyper-V uses a technique called overlay page for its hypercall page. It > > will insert a backing page to the guest when the hypercall functionality > > is enabled. That means we can use a page that is not backed by real > > memory for hypercall page. > > > > Use the top-most addressable page for that purpose. Adjust e820 map > > accordingly. > > Can you add this is done to avoid page shattering and to make sure > Xen isn't overwriting any MMIO area which might be present at lower > addresses? NP. > > > + > > +static void __init e820_fixup(struct e820map *e820) > > +{ > > + uint64_t s = HV_HCALL_MFN << PAGE_SHIFT; > > + > > + if ( !e820_add_range(e820, s, s + PAGE_SIZE, E820_RESERVED) ) > > I think end should be s + PAGE_SIZE - 1, or else it expands across two > pages? No, it shouldn't. E820 entry records the size of the region, which is calculated as end-start. The one usage in pv/shim.c follows the same pattern here. Wei. > > Thanks, Roger.
On Mon, Feb 03, 2020 at 03:07:24PM +0000, Wei Liu wrote: > On Mon, Feb 03, 2020 at 04:01:54PM +0100, Roger Pau Monné wrote: > > On Fri, Jan 31, 2020 at 05:49:24PM +0000, Wei Liu wrote: > > > Hyper-V uses a technique called overlay page for its hypercall page. It > > > will insert a backing page to the guest when the hypercall functionality > > > is enabled. That means we can use a page that is not backed by real > > > memory for hypercall page. > > > > > > Use the top-most addressable page for that purpose. Adjust e820 map > > > accordingly. > > > > Can you add this is done to avoid page shattering and to make sure > > Xen isn't overwriting any MMIO area which might be present at lower > > addresses? > > NP. > > > > > > + > > > +static void __init e820_fixup(struct e820map *e820) > > > +{ > > > + uint64_t s = HV_HCALL_MFN << PAGE_SHIFT; > > > + > > > + if ( !e820_add_range(e820, s, s + PAGE_SIZE, E820_RESERVED) ) > > > > I think end should be s + PAGE_SIZE - 1, or else it expands across two > > pages? > > No, it shouldn't. > > E820 entry records the size of the region, which is calculated as > end-start. The one usage in pv/shim.c follows the same pattern here. Hm, I see. I'm not sure this is correct, I think the e820 entry should look like: addr = s; size = PAGE_SIZE - 1; As ranges on the e820 are inclusive, so if size ends up being PAGE_SIZE then the entry would expand across two pages. Anyway, this needs fixing elsewhere, and is out of the scope of this patch. Thanks, Roger.
On 03.02.2020 16:21, Roger Pau Monné wrote: > On Mon, Feb 03, 2020 at 03:07:24PM +0000, Wei Liu wrote: >> On Mon, Feb 03, 2020 at 04:01:54PM +0100, Roger Pau Monné wrote: >>> On Fri, Jan 31, 2020 at 05:49:24PM +0000, Wei Liu wrote: >>>> Hyper-V uses a technique called overlay page for its hypercall page. It >>>> will insert a backing page to the guest when the hypercall functionality >>>> is enabled. That means we can use a page that is not backed by real >>>> memory for hypercall page. >>>> >>>> Use the top-most addressable page for that purpose. Adjust e820 map >>>> accordingly. >>> >>> Can you add this is done to avoid page shattering and to make sure >>> Xen isn't overwriting any MMIO area which might be present at lower >>> addresses? >> >> NP. >> >>> >>>> + >>>> +static void __init e820_fixup(struct e820map *e820) >>>> +{ >>>> + uint64_t s = HV_HCALL_MFN << PAGE_SHIFT; >>>> + >>>> + if ( !e820_add_range(e820, s, s + PAGE_SIZE, E820_RESERVED) ) >>> >>> I think end should be s + PAGE_SIZE - 1, or else it expands across two >>> pages? >> >> No, it shouldn't. >> >> E820 entry records the size of the region, which is calculated as >> end-start. The one usage in pv/shim.c follows the same pattern here. > > Hm, I see. I'm not sure this is correct, I think the e820 entry > should look like: > > addr = s; > size = PAGE_SIZE - 1; > > As ranges on the e820 are inclusive, so if size ends up being > PAGE_SIZE then the entry would expand across two pages. Ranges can sensibly be inclusive only when specified as [start,end] tuples. (start,size) pairs make no sense for representing [start,start+size], they only make sense for [start,start+size). Otherwise, as in your example above, size taken on its own is off by one (i.e. is rather "last byte" than "size"). Modern Linux, when logging the memory map, indeed subtracts 1 from the sum of addr and size, to show an inclusive range. Jan
On Mon, Feb 03, 2020 at 04:32:52PM +0100, Jan Beulich wrote: > On 03.02.2020 16:21, Roger Pau Monné wrote: > > On Mon, Feb 03, 2020 at 03:07:24PM +0000, Wei Liu wrote: > >> On Mon, Feb 03, 2020 at 04:01:54PM +0100, Roger Pau Monné wrote: > >>> On Fri, Jan 31, 2020 at 05:49:24PM +0000, Wei Liu wrote: > >>>> Hyper-V uses a technique called overlay page for its hypercall page. It > >>>> will insert a backing page to the guest when the hypercall functionality > >>>> is enabled. That means we can use a page that is not backed by real > >>>> memory for hypercall page. > >>>> > >>>> Use the top-most addressable page for that purpose. Adjust e820 map > >>>> accordingly. > >>> > >>> Can you add this is done to avoid page shattering and to make sure > >>> Xen isn't overwriting any MMIO area which might be present at lower > >>> addresses? > >> > >> NP. > >> > >>> > >>>> + > >>>> +static void __init e820_fixup(struct e820map *e820) > >>>> +{ > >>>> + uint64_t s = HV_HCALL_MFN << PAGE_SHIFT; > >>>> + > >>>> + if ( !e820_add_range(e820, s, s + PAGE_SIZE, E820_RESERVED) ) > >>> > >>> I think end should be s + PAGE_SIZE - 1, or else it expands across two > >>> pages? > >> > >> No, it shouldn't. > >> > >> E820 entry records the size of the region, which is calculated as > >> end-start. The one usage in pv/shim.c follows the same pattern here. > > > > Hm, I see. I'm not sure this is correct, I think the e820 entry > > should look like: > > > > addr = s; > > size = PAGE_SIZE - 1; > > > > As ranges on the e820 are inclusive, so if size ends up being > > PAGE_SIZE then the entry would expand across two pages. > > Ranges can sensibly be inclusive only when specified as [start,end] > tuples. (start,size) pairs make no sense for representing > [start,start+size], they only make sense for [start,start+size). > Otherwise, as in your example above, size taken on its own is off > by one (i.e. is rather "last byte" than "size"). > > Modern Linux, when logging the memory map, indeed subtracts 1 from > the sum of addr and size, to show an inclusive range. We should perhaps do the same then. If people agree this is the way to go, I can write a patch. Wei. > > Jan
On Mon, Feb 03, 2020 at 03:42:17PM +0000, Wei Liu wrote: > On Mon, Feb 03, 2020 at 04:32:52PM +0100, Jan Beulich wrote: > > On 03.02.2020 16:21, Roger Pau Monné wrote: > > > On Mon, Feb 03, 2020 at 03:07:24PM +0000, Wei Liu wrote: > > >> On Mon, Feb 03, 2020 at 04:01:54PM +0100, Roger Pau Monné wrote: > > >>> On Fri, Jan 31, 2020 at 05:49:24PM +0000, Wei Liu wrote: > > >>>> Hyper-V uses a technique called overlay page for its hypercall page. It > > >>>> will insert a backing page to the guest when the hypercall functionality > > >>>> is enabled. That means we can use a page that is not backed by real > > >>>> memory for hypercall page. > > >>>> > > >>>> Use the top-most addressable page for that purpose. Adjust e820 map > > >>>> accordingly. > > >>> > > >>> Can you add this is done to avoid page shattering and to make sure > > >>> Xen isn't overwriting any MMIO area which might be present at lower > > >>> addresses? > > >> > > >> NP. > > >> > > >>> > > >>>> + > > >>>> +static void __init e820_fixup(struct e820map *e820) > > >>>> +{ > > >>>> + uint64_t s = HV_HCALL_MFN << PAGE_SHIFT; > > >>>> + > > >>>> + if ( !e820_add_range(e820, s, s + PAGE_SIZE, E820_RESERVED) ) > > >>> > > >>> I think end should be s + PAGE_SIZE - 1, or else it expands across two > > >>> pages? > > >> > > >> No, it shouldn't. > > >> > > >> E820 entry records the size of the region, which is calculated as > > >> end-start. The one usage in pv/shim.c follows the same pattern here. > > > > > > Hm, I see. I'm not sure this is correct, I think the e820 entry > > > should look like: > > > > > > addr = s; > > > size = PAGE_SIZE - 1; > > > > > > As ranges on the e820 are inclusive, so if size ends up being > > > PAGE_SIZE then the entry would expand across two pages. > > > > Ranges can sensibly be inclusive only when specified as [start,end] > > tuples. (start,size) pairs make no sense for representing > > [start,start+size], they only make sense for [start,start+size). > > Otherwise, as in your example above, size taken on its own is off > > by one (i.e. is rather "last byte" than "size"). > > > > Modern Linux, when logging the memory map, indeed subtracts 1 from > > the sum of addr and size, to show an inclusive range. > > We should perhaps do the same then. > > If people agree this is the way to go, I can write a patch. Oh, sorry. I got messed up by the way we print the ranges. I think it would be helpful to -1 when printing the ranges, but there's no need to do it in this series. Thanks, Roger
diff --git a/xen/arch/x86/guest/hyperv/hyperv.c b/xen/arch/x86/guest/hyperv/hyperv.c index 8d38313d7a..7c2a96d70e 100644 --- a/xen/arch/x86/guest/hyperv/hyperv.c +++ b/xen/arch/x86/guest/hyperv/hyperv.c @@ -19,15 +19,27 @@ * Copyright (c) 2019 Microsoft. */ #include <xen/init.h> +#include <xen/version.h> +#include <asm/fixmap.h> #include <asm/guest.h> #include <asm/guest/hyperv-tlfs.h> +#include <asm/processor.h> struct ms_hyperv_info __read_mostly ms_hyperv; -static const struct hypervisor_ops ops = { - .name = "Hyper-V", -}; +static uint64_t generate_guest_id(void) +{ + union hv_guest_os_id id; + + id.vendor = HV_XEN_VENDOR_ID; + id.major = xen_major_version(); + id.minor = xen_minor_version(); + + return id.raw; +} + +static const struct hypervisor_ops ops; const struct hypervisor_ops *__init hyperv_probe(void) { @@ -72,6 +84,57 @@ const struct hypervisor_ops *__init hyperv_probe(void) return &ops; } +static void __init setup_hypercall_page(void) +{ + union hv_x64_msr_hypercall_contents hypercall_msr; + union hv_guest_os_id guest_id; + unsigned long mfn; + + BUILD_BUG_ON(HV_HYP_PAGE_SHIFT != PAGE_SHIFT); + + rdmsrl(HV_X64_MSR_GUEST_OS_ID, guest_id.raw); + if ( !guest_id.raw ) + { + guest_id.raw = generate_guest_id(); + wrmsrl(HV_X64_MSR_GUEST_OS_ID, guest_id.raw); + } + + rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); + if ( !hypercall_msr.enable ) + { + mfn = HV_HCALL_MFN; + hypercall_msr.enable = 1; + hypercall_msr.guest_physical_address = mfn; + wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); + } else { + mfn = hypercall_msr.guest_physical_address; + } + + rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); + BUG_ON(!hypercall_msr.enable); + + set_fixmap_x(FIX_X_HYPERV_HCALL, mfn << PAGE_SHIFT); +} + +static void __init setup(void) +{ + setup_hypercall_page(); +} + +static void __init e820_fixup(struct e820map *e820) +{ + uint64_t s = HV_HCALL_MFN << PAGE_SHIFT; + + if ( !e820_add_range(e820, s, s + PAGE_SIZE, E820_RESERVED) ) + panic("Unable to reserve Hyper-V hypercall range\n"); +} + +static const struct hypervisor_ops ops = { + .name = "Hyper-V", + .setup = setup, + .e820_fixup = e820_fixup, +}; + /* * Local variables: * mode: C diff --git a/xen/include/asm-x86/guest/hyperv-tlfs.h b/xen/include/asm-x86/guest/hyperv-tlfs.h index 05c4044976..07db57b55f 100644 --- a/xen/include/asm-x86/guest/hyperv-tlfs.h +++ b/xen/include/asm-x86/guest/hyperv-tlfs.h @@ -318,15 +318,16 @@ struct ms_hyperv_tsc_page { * * Bit(s) * 63 - Indicates if the OS is Open Source or not; 1 is Open Source - * 62:56 - Os Type; Linux is 0x100 + * 62:56 - Os Type; Linux 0x1, FreeBSD 0x2, Xen 0x3 * 55:48 - Distro specific identification - * 47:16 - Linux kernel version number + * 47:16 - Guest OS version number * 15:0 - Distro specific identification * * */ #define HV_LINUX_VENDOR_ID 0x8100 +#define HV_XEN_VENDOR_ID 0x8300 union hv_guest_os_id { uint64_t raw; diff --git a/xen/include/asm-x86/guest/hyperv.h b/xen/include/asm-x86/guest/hyperv.h index c7a7f32bd5..1a1b47831c 100644 --- a/xen/include/asm-x86/guest/hyperv.h +++ b/xen/include/asm-x86/guest/hyperv.h @@ -21,6 +21,9 @@ #include <xen/types.h> +/* Use top-most MFN for hypercall page */ +#define HV_HCALL_MFN (((1ull << paddr_bits) - 1) >> HV_HYP_PAGE_SHIFT) + /* * The specification says: "The partition reference time is computed * by the following formula:
Hyper-V uses a technique called overlay page for its hypercall page. It will insert a backing page to the guest when the hypercall functionality is enabled. That means we can use a page that is not backed by real memory for hypercall page. Use the top-most addressable page for that purpose. Adjust e820 map accordingly. We also need to register Xen's guest OS ID to Hyper-V. Use 0x3 as the vendor ID. Fix the comment in hyperv-tlfs.h while at it. Signed-off-by: Wei Liu <liuwe@microsoft.com> --- v6: 1. Use hv_guest_os_id 2. Use new e820_fixup hook 3. Add a BUILD_BUG_ON v5: 1. use hypervisor_reserve_top_pages 2. add a macro for hypercall page mfn 3. address other misc comments v4: 1. Use fixmap 2. Follow routines listed in TLFS --- xen/arch/x86/guest/hyperv/hyperv.c | 69 +++++++++++++++++++++++-- xen/include/asm-x86/guest/hyperv-tlfs.h | 5 +- xen/include/asm-x86/guest/hyperv.h | 3 ++ 3 files changed, 72 insertions(+), 5 deletions(-)