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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 15.11.16 at 20:19, <andrew.cooper3@xxxxxxxxxx> 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, Xen will have
> to maintain the current intercept behaviour for qemu, but also take on
> the PM1b role entirely.

PM1b? There's no such thing right now, and it's also not being added
by Boris' series, so I don't know what you're thinking about making it
a requirement to have (and be handled in Xen). Yes, PM1a and PM1b
are intentionally split so that two distinct parties (on raw hardware:
chips) could each take on part of the combined functionality. But, if
at all, that should have been leveraged when the implementation was
done originally (to separate Xen's and qemu's parts); I don't see how
it matters now (unless you're again referring to some future overhaul).

Jan


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