From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH v4 2/4] x86/compat: Test both PV and PVH guests for compat mode Date: Wed, 02 Sep 2015 10:01:03 -0400 Message-ID: <55E7011F.5040002@oracle.com> References: <1439489529-3633-1-git-send-email-boris.ostrovsky@oracle.com> <1439489529-3633-3-git-send-email-boris.ostrovsky@oracle.com> <55DF5082020000780009D8A3@prv-mh.provo.novell.com> <55E648A3.90104@oracle.com> <55E6BC9F02000078000D7C83@prv-mh.provo.novell.com> <55E6EC3B.1080408@oracle.com> <55E71202020000780009EFCB@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55E71202020000780009EFCB@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: elena.ufimtseva@oracle.com, wei.liu2@citrix.com, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, roger.pau@citrix.com List-Id: xen-devel@lists.xenproject.org On 09/02/2015 09:13 AM, Jan Beulich wrote: >>>> On 02.09.15 at 14:31, wrote: >> On 09/02/2015 04:08 AM, Jan Beulich wrote: >>>>>> Boris Ostrovsky 09/02/15 2:55 AM >>> >>>> On 08/27/2015 12:01 PM, Jan Beulich wrote: >>>>>>>> On 13.08.15 at 20:12, wrote: >>>>>> @@ -777,7 +777,7 @@ int arch_set_info_guest( >>>>>> >>>>>> /* The context is a compat-mode one if the target domain is >> compat-mode; >>>>>> * we expect the tools to DTRT even in compat-mode callers. */ >>>>>> - compat = is_pv_32bit_domain(d); >>>>>> + compat = is_pv_32bit_domain(d) || is_pvh_32bit_domain(d); >>>>> I continue to think that this should include a v->domain == >>>>> current->domain check (to match behavior for HVM guests >>>>> from the tool stack perspective). Having looked at patch 4, I also >>>>> can't see how the tool stack is being made expect a non-native >>>>> guest context record in the 32-bit PVH case (i.e. I'd appreciate >>>>> if you could point out where that hides). >>>> For vcpu 0 current->domain is dom0 so I am not sure how this check would >>>> work. >>>> >>>> For a 32-bit PVH guest the toolstack will place data into >>>> vcpu_guest_context_x86_32_t (in vcpu_x86_32()) and so the hypervisor, >>>> knowing that the guest is a compat one (based on the test above), will >>>> access appropriate fields. >>>> >>>> This is not how HVM guests are started --- "classic" PVH behaves very >>>> much like a PV guest, unlike what we are doing with no-dm PVH. >>> And I believe this to be wrong, and potentially getting in the way of the >> no-dm >>> work - Roger? >>> >>> As to the reference to vcpu_x86_32() - by its name alone it is already clear >>> that this is after the determination of what bit width a guest to deal with, and >>> looking at xc_dom_32_pae I still can't see why PVH guests would (intentionally >>> and legitimately) be treated like PV rather than HVM ones (not to speak of the >>> fact that I don't think 32-bit PVH is in any way limited to PAE). >> The purpose of this series is to get 32-bit guests to parity with >> classic PVH with minimal changes and then move on to no-dm. Not getting >> in the way of no-dm is obviously important but making classic behave >> like no-dm (which is, to certain extent, is what you are suggesting) is >> out of scope. > Well, okay. But are you saying then that 64-bit PVH also just > _happens_ to be treated like PV in the tool stack? Yes. They both are processed by tollstack's elf parser (and the size is determined by xc_dom_guest_type()). > IOW I'm still missing > the explicit tool stack adjustment that makes it use a guest-bit-width > context for PVH guests. > >> (I haven't considered non-PAE case, TBH) > But I'm afraid you need to. > Actually, at least for Linux, CONFIG_XEN 'depends on X86_64 || (X86_32 && X86_PAE)'. And I don't know whether there are any other OSs (i.e. FreeBSD) that are going to ever support 32-bit PVH-classic (Roger might correct me on that). -boris