From: Yu Zhang <yu.c.zhang@linux.intel.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
Jan Beulich <JBeulich@suse.com>
Cc: xen-devel@lists.xenproject.org
Subject: Re: about fully UMIP support in Xen
Date: Wed, 19 Apr 2017 19:16:33 +0800 [thread overview]
Message-ID: <58F74711.4070307@linux.intel.com> (raw)
In-Reply-To: <4e7490e2-0304-b55c-3379-ed8bdf9733be@citrix.com>
On 4/19/2017 5:59 PM, Andrew Cooper wrote:
> On 19/04/17 10:48, Yu Zhang wrote:
>>
>> On 4/19/2017 5:18 PM, Jan Beulich wrote:
>>>>>> On 19.04.17 at 10:48, <yu.c.zhang@linux.intel.com> wrote:
>>>> I saw that commit 8c14e5f provides emulations for UMIP affected
>>>> instructions. But realized that xen does not have logic to expose UMIP
>>>> feature to guests - you have sent out one in
>>>> https://lists.xenproject.org/archives/html/xen-devel/2016-12/msg00552.html
>>>>
>>>> to emulate the cpuid leaf, but seems it was only a software solution
>>>> and
>>>> have not get merged yet.
>>>> So I wonder do you have any specific plan to fully support the
>>>> UMIP,
>>>> i.e. in Xen 4.10? :-)
>>> It would be nice, but I think there are caveats: While PV guests
>>> _shouldn't_ use any of the affected instructions, we can't blindly
>>> assume they don't. Hence we'd have to emulate them (producing
>>> to be determined data, e.g. all zeros). Luckily we don't have to
>>> care about VM86 mode, as for code running there emulating the
>>> instructions would be mandatory (as they're e.g. needed for CPU
>>> family detection, since the recommended approach to tell [iirc]
>>> 286 from 386 doesn't reliably work there).
>> Thanks, Jan.
>> You mean if UMIP is enabled in xen, and dom0 triggers affected
>> instructions, 0 should
>> be returned? Does hypervisor need to differentiate dom0 kernel and its
>> user space?
>>
>>> For HVM guests the feature is of no interest to Xen itself anyway,
>>> i.e. all we'd need is allow them to enable the CR4 bit (which my
>>> emulation patch did as a side effect, but that patch has been
>>> deferred until after Andrew manages to put in some more CPUID
>>> work; that single hunk could certainly be split out if desired).
>> By "CPUID work", I guess you changes needed in the
>> xen/tools/gen-cpuid.py,
>> not just emulating one to the guest, right?
> There are two angles here.
>
> The easy part of CPUID work is to expose it to PV and HVM guests, and
> this has yet to be done but shouldn't be hard.
>
> The more complicated part, which needs the toolstack CPUID modifications
> I want to do, is to be able to fake up UMIP to HVM guests on non-UMIP
> capable hardware.
Thanks, Andrew.
Our expectation is to get this feature into xen upstream in this year.
Considering the
xen release schedule, I guess it means to get the easy part accepted in
xen 4.10.
So I wonder, do you have plan to do this? Any assistance needed from
Intel? :)
Yu
> ~Andrew
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-04-19 11:19 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-19 8:48 about fully UMIP support in Xen Yu Zhang
2017-04-19 9:18 ` Jan Beulich
2017-04-19 9:48 ` Yu Zhang
2017-04-19 9:59 ` Andrew Cooper
2017-04-19 11:16 ` Yu Zhang [this message]
2017-04-19 11:19 ` Jan Beulich
2017-04-19 11:44 ` Yu Zhang
2017-04-19 13:34 ` Jan Beulich
2017-04-19 13:49 ` Andrew Cooper
2017-04-19 14:06 ` Jan Beulich
2017-04-19 14:17 ` Andrew Cooper
2017-04-19 14:27 ` Jan Beulich
2017-04-19 14:35 ` Andrew Cooper
2017-04-19 13:50 ` Yu Zhang
2017-04-19 13:58 ` Andrew Cooper
2017-04-19 14:07 ` Jan Beulich
2017-04-19 14:09 ` Andrew Cooper
2017-04-20 7:15 ` Yu Zhang
2017-04-20 9:47 ` Jan Beulich
2017-04-20 9:53 ` Yu Zhang
2017-04-20 10:01 ` Jan Beulich
2017-04-20 10:10 ` Yu Zhang
2017-04-20 10:23 ` Andrew Cooper
2017-04-20 10:38 ` Yu Zhang
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=58F74711.4070307@linux.intel.com \
--to=yu.c.zhang@linux.intel.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=xen-devel@lists.xenproject.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.