Re: [Xen-devel] Restoring FPU exception state

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 18 February 2016 09:24
> To: Paul Durrant
> Cc: Andrew Cooper; David Vrabel; Feng Wu; Kevin Tian; xen-devel
> Subject: RE: Restoring FPU exception state
> 
> >>> On 18.02.16 at 09:54, <Paul.Durrant@xxxxxxxxxx> wrote:
> >>  -----Original Message-----
> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> Sent: 18 February 2016 08:50
> >> To: Paul Durrant; Kevin Tian
> >> Cc: Andrew Cooper; David Vrabel; Feng Wu; xen-devel
> >> Subject: RE: Restoring FPU exception state
> >>
> >> >>> On 18.02.16 at 09:41, <Paul.Durrant@xxxxxxxxxx> wrote:
> >> >>  -----Original Message-----
> >> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> >> Sent: 18 February 2016 08:16
> >> >> To: Kevin Tian
> >> >> Cc: Andrew Cooper; David Vrabel; Paul Durrant; Feng Wu; xen-devel
> >> >> Subject: RE: Restoring FPU exception state
> >> >>
> >> >> >>> On 18.02.16 at 07:30, <kevin.tian@xxxxxxxxx> wrote:
> >> >> > Interesting. Let me also have a check internally whether there is
> other
> >> >> > architectural alternative. BTW, not quite related. Could I think 
> >> >> > finally
> >> >> > Xen may allow user to specify OS type as a general per-domain
> control,
> >> >> > and then Xen can do free optimizations underlying based on that
> type?
> >> >> > I don't expect we want to expose raw FPU related per-domain
> control
> >> >> > since it's difficult for users to correctly set it up...
> >> >>
> >> >> So what if then, with us implying some kind of workaround here
> >> >> from the OS type, someone set the OS type to Windows, and
> >> >> subsequently MS decided to fix their issue?
> >> >
> >> > We already get full OS version information from Windows via the
> >> > VIRIDIAN_MSR_GUEST_OS_ID MSR so it would be quite straightforward
> to
> >> work
> >> > around the issue for all Windows at the moment and then make the
> check
> >> more
> >> > specific if Microsoft choose to avoid the problem by some other means.
> >>
> >> That's only if "viridian=1" in the guest config, isn't it?
> >
> > Yes, but most people are going to run with that on for HVM guests;
> 
> That view may be pretty XenServer centric.

It may be but really shouldn't be. Setting viridian on by default for HVM 
guests has been pretty safe for a long time.

> 
> > in
> > general there's no penalty for doing so unless you're running some old and
> > buggy OS. If it's turned off then there's nothing Xen can do other than
> > continue to behave as it does now.
> >
> >> Plus - how would
> >> we know MS chose to fix their apparent issue?
> >>
> >
> > Well either we'd hear about it or we can run tests on each new version of
> > Windows (it wouldn't be hard to add a specific test for this and add it
> > XenServer's automated suite).
> 
> Well, if that also covers kernel updates for existing versions of
> Windows.
> 

It should do; there's build number and service pack info in the OS id. I'd be 
disappointed if at least one of these didn't change with a kernel update.

> But taking both together, defaulting the behavior based on the
> Viridian flag is certainly an option, just that we'd need an override
> both ways nevertheless.
> 

Yes, there should definitely be some way to override the default choice.

  Paul

> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel