All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.