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

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 11/15/2016 02:19 PM, Andrew Cooper wrote:
> 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, 

What do you mean by "when"? We *are* doing ACPI hotplug for HVM guests,
aren't we?

Or are you thinking about moving this functionality to the hypervisor?

-boris

> 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