All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>, 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
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	[thread overview]
Message-ID: <55E70132.2020806@citrix.com> (raw)
In-Reply-To: <55E6BC9F02000078000D7C83@prv-mh.provo.novell.com>

El 02/09/15 a les 10.08, Jan Beulich ha escrit:
>>>> Boris Ostrovsky <boris.ostrovsky@oracle.com> 09/02/15 2:55 AM >>>
>> On 08/27/2015 12:01 PM, Jan Beulich wrote:
>>>>>> On 13.08.15 at 20:12, <boris.ostrovsky@oracle.com> 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.

  parent reply	other threads:[~2015-09-02 14:01 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-13 18:12 [PATCH v4 0/4] 32-bit domU PVH support Boris Ostrovsky
2015-08-13 18:12 ` [PATCH v4 1/4] x86/pvh: Set 32b PVH guest mode in XEN_DOMCTL_set_address_size Boris Ostrovsky
2015-08-13 18:12 ` [PATCH v4 2/4] x86/compat: Test both PV and PVH guests for compat mode Boris Ostrovsky
2015-08-27 16:01   ` Jan Beulich
2015-09-02  0:53     ` Boris Ostrovsky
2015-09-02  8:08       ` Jan Beulich
2015-09-02 12:31         ` Boris Ostrovsky
2015-09-02 13:13           ` Jan Beulich
2015-09-02 14:01             ` Boris Ostrovsky
2015-09-02 14:16               ` Roger Pau Monné
2015-09-02 15:26               ` Jan Beulich
2015-09-02 14:01         ` Roger Pau Monné [this message]
2015-08-13 18:12 ` [PATCH v4 3/4] x86/pvh: Handle hypercalls for 32b PVH guests Boris Ostrovsky
2015-08-27 16:02   ` Jan Beulich
2015-08-13 18:12 ` [PATCH v4 4/4] libxc/x86/pvh: Allow creation of " Boris Ostrovsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55E70132.2020806@citrix.com \
    --to=roger.pau@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=elena.ufimtseva@oracle.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.