From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH v3 2/4] x86/compat: Test both PV and PVH guests for compat mode Date: Fri, 24 Jul 2015 13:54:58 -0400 Message-ID: <55B27BF2.1080902@oracle.com> References: <1436566853-8444-1-git-send-email-boris.ostrovsky@oracle.com> <1436566853-8444-3-git-send-email-boris.ostrovsky@oracle.com> <55B111500200007800094A51@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: <55B111500200007800094A51@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 , roger.pau@citrix.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 On 07/23/2015 10:07 AM, Jan Beulich wrote: >>>> On 11.07.15 at 00:20, wrote: >> Add is_pvh_32bit_domain() macro and use it alongside is_pv_32bit_domain() >> where necessary. >> >> Since PVH guests cannot change execution mode, has_32bit_shinfo is a good >> indicator of whether the guest is PVH and 32-bit. >> >> Signed-off-by: Boris Ostrovsky > Relative to what is in the tree right now this is fine, but ... > >> @@ -771,7 +771,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); > ... won't this and ... > >> @@ -1203,7 +1204,7 @@ void arch_get_info_guest(struct vcpu *v, vcpu_guest_context_u c) >> { >> unsigned int i; >> const struct domain *d = v->domain; >> - bool_t compat = is_pv_32bit_domain(d); >> + bool_t compat = is_pv_32bit_domain(d) || is_pvh_32bit_domain(d); > ... this get in the way of what we called "no-pm" on yesterday's call? I made no effort to make this workable for "no-dm" case. This will probably need to be adjusted when that code gets in. IIRC this new code has a flag (or something along those lines) that will allow us to distinguish PVH-"classic" vs. "no-dm". > I would assume that for the transitional period both ought to be able > to co-exist. Yes, but I suspect this will not be the only place where we will need to have different code paths for the two approaches. hvm_set_cr0(), for example, doesn't allow PVH guests to switch modes. > Plus - is this in line with what the tools are doing? Aren't they > assuming !PV <=> native format context? I.e. don't you need > to treat differently v->domain == current->domain and its > opposite? Roger btw. raised a similar question on IRC earlier > today... Not sure I understand this. You mean for copying 64-bit guest's info into 32-bit dom0? -boris