From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Subject: Re: [PATCH v4 2/4] x86/compat: Test both PV and PVH guests for compat mode Date: Wed, 2 Sep 2015 16:01:22 +0200 Message-ID: <55E70132.2020806@citrix.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55E6BC9F02000078000D7C83@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 , boris.ostrovsky@oracle.com 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 List-Id: xen-devel@lists.xenproject.org El 02/09/15 a les 10.08, Jan Beulich ha escrit: >>>> 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? The no-dm work doesn't use arch_set_info_guest, it uses a new function created specifically for no-dm guests with a new structure also, see: http://marc.info/?l=xen-devel&m=144017739531928 So I don't think this code is explicitly getting in the way of no-dm. Another thing to consider might be if it's worth to add this when no-dm is going in a complete different direction regarding AP startup. I certainly don't plan to add classic PVH 32bit support to FreeBSD. Roger.