On 21/03/16 11:53, Jan Beulich wrote:
+XEN_CPUFEATURE(X2APIC,1*32+21) /*A Extended xAPIC */
>>> Does this make sense for PV?
>> It is currently visible, and we already have to leak APIC through to PV
>> guests.
> Having to leak on piece of state doesn't mean when need to leak
> more,
>>> On 18.03.16 at 19:56, wrote:
> On 18/03/16 16:57, Jan Beulich wrote:
> On 15.03.16 at 16:35, wrote:
>>> +XEN_CPUFEATURE(MTRR, 0*32+12) /*S Memory Type Range Registers */
>> I thin I've said so before - this alters current behavior
>
> Again, no it doesn't. PV DomU's don't get
On Tue, Mar 15, 2016 at 03:35:04PM +, Andrew Cooper wrote:
> Use attributes to specify whether a feature is applicable to be exposed to:
> 1) All guests
> 2) HVM guests
> 3) HVM HAP guests
>
> There is no current need for other categories (e.g. PV-only features), and
> such categories shoud
On 18/03/16 16:57, Jan Beulich wrote:
On 15.03.16 at 16:35, wrote:
>> v3:
>> * Rebase over the new namespaceing changes.
>> * Expand commit message.
>> * Correct PSE36 to being a HAP-only feature.
> As Tim has pointed out on IRC, this may need revisiting.
I am still debating how to fix th
>>> On 15.03.16 at 16:35, wrote:
> v3:
> * Rebase over the new namespaceing changes.
> * Expand commit message.
> * Correct PSE36 to being a HAP-only feature.
As Tim has pointed out on IRC, this may need revisiting.
> +XEN_CPUFEATURE(MCE, 0*32+ 7) /*A Machine Check Architecture */
Use attributes to specify whether a feature is applicable to be exposed to:
1) All guests
2) HVM guests
3) HVM HAP guests
There is no current need for other categories (e.g. PV-only features), and
such categories shoud not be introduced if possible. These categories follow
from the fact that,
