[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 08/11] pvh/acpi: Handle ACPI accesses for PVH guests



On 15/11/16 15:56, Jan Beulich wrote:
>>>> On 15.11.16 at 16:44, <boris.ostrovsky@xxxxxxxxxx> wrote:
>> On 11/15/2016 10:17 AM, Jan Beulich wrote:
>>>> The other option was XEN_X86_EMU_ACPI. Would it be better?
>>> As that's a little too wide (and I think someone else had also
>>> disliked it for that reason), how about XEN_X86_EMU_ACPI_FF
>>> (for "fixed features"), or if that's still too wide, break things up
>>> (PM1a, PM1b, PM2, TMR, GPE0, GPE1)?
>> I think this may be a bit too fine-grained. Fixed-features would be
>> good, but is GPE block considered part of fixed features?
> See figure 4-12 in ACPI 6.1: GEP{0,1} are included there, and the
> text ahead of this makes it pretty clear that altogether they're
> being called fixed hardware register blocks. So if you consider FF
> misleading, FHRB would be another option.

Please can we also considering a naming appropriate for joint use with
HVM guests as well.

For PVH, (if enabled), Xen handles all (implemented) fixed function
registers.

For HVM, Xen already intercepts and interposes on the PM1a_STS and
PM1a_EN registers heading towards qemu, for the apparent purpose of
raising SCIs on behalf of qemu.

When we want to enable ACPI vcpu hotplug for HVM guests, Xen will have
to maintain the current intercept behaviour for qemu, but also take on
the PM1b role entirely.

~Andrew

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.