Re: [Xen-devel] [PATCH for-4.6] p2m/ept: Set the A bit only if PML is enabled

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 09/23/2015 04:18 PM, Wei Liu wrote:
> With the discussion still not finalised I'm a bit worried that this
> issue will block the release.
> 
> I think we have a few options here. I will list them in order of my
> preference. Please correct me if I'm talking non-sense, and feel free to
> add more options if I miss anything.
> 
> 1. Disable PML on broken chips, gate access to A bit (or AD) with PML.
> 
> In the sub-thread I had with Ross, the proposed patch already does that.
> There is no need to "disable PML in broken chips" because that feature
> is not supported by broken chips in the first place.
> 
> The downside is that the overhead of gating with `if' statement which
> makes things a tad slower for everyone. But that's not really reason to
> reject this patch because any gating method would involve similar
> overhead. 
> 
> This approach is specific to this erratum, not general enough to handle
> future errata. But in the end, if we accept this patch and later decide
> we need something more flexible, we can revert it and backport the
> proper solution if people are keen.
> 
> If people are not satisfied with gating on PML, maybe we can have
> something like
> 
>   bool vmx_domain_can_use_ad_bits(d)
>   {
>       return vmx_domain_pml_enabled(d);
>   }
> 
> for now, which should be clear enough that this is not specific to PML.
> And we can extend this check and / or replace internal of this
> function with hooks into generic framework that keys AVR41 and other
> possible errata in the future.
> 
> 2. Implement general framework to detect broken chips and apply quirks.
> 
> I take that there is no general framework at the moment, otherwise the
> patch would have used that.
> 
> I think Tim's suggestion fall into this category.  I'm not sure about
> the workload but it seems to be more intrusive than #1. This approach is
> future-proof, but nobody is working on it and we're not sure about the
> incarnation of this framework and the specific fix for this errata.

We do have a way to detect broken chips and apply quirks, don't we?  If
I understand him properly, Tim is suggesting that we:

1) Add a quirk to detect this chip

2) If that quirk is detected, then enable CR3 exiting when constructing
the VMCS, even when using EPT.  (Hand-waving a bit here from memory.)

If we have reason to believe that #1 is going to slow things down for
most processors, and #2 will work, then I would actually be in favor of
doing #3, and just following it up with 4.6.1 with the #2 fix.

 -George

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