Re: [Xen-devel] [PATCH v5 05/13] pvh/acpi: Handle ACPI accesses for PVH guests

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 20/12/2016 15:41, Jan Beulich wrote:
>>>> On 20.12.16 at 16:29, <boris.ostrovsky@xxxxxxxxxx> wrote:
>> On 12/20/2016 09:47 AM, Jan Beulich wrote:
>>>>>> On 20.12.16 at 15:35, <boris.ostrovsky@xxxxxxxxxx> wrote:
>>>> On 12/20/2016 06:50 AM, Jan Beulich wrote:
>>>>>> +    else
>>>>>> +    {
>>>>>> +        uint32_t v = *val;
>>>>>> +
>>>>>> +        /* Status register is write-1-to-clear by guests */
>>>>>> +        switch ( port & 3 )
>>>>>> +        {
>>>>>> +        case 0:
>>>>>> +            *sts &= ~(v & 0xff);
>>>>>> +            *sts &= *mask_sts;
>>>>> I can understand the first &=, but why would a read have this second
>>>>> (side) effect? I could see some sort of need for such only when you
>>>>> were setting any flags.
>>>> This is a write, not a read.
>>> Oh, right. But the question remains about that unexpected side
>>> effect.
>> It indeed doesn't do anything for the case of guest access. It is
>> guarding against setting unauthorized bits by domctl (introduced by the
>> next patch). And I can move it into that case.
>>
>> However, as discussed in the thread about 06/13 patch, we may currently
>> not need to provide domctl access to anything but VCPU map. So the
>> question is whether domctl interface to GPE0/PM1a is needed at all. I
>> think it's a useful interface with very little extra code required and
>> the toolstack can use it, for example, to inject events into guests. But
>> I don't have a specific use case.
> To be honest, I'd keep out anything we don't really need.

I have two specific use-cases.  1) DIMM Hotplug, and 2) Windows
tablet/desktop mode switch, both of which I think will just require a
toolstack entity to be able to raise an SCI.

However, I am happy for you to ignore these case for now (as they
haven't yet been fully designed and thought through), on the assumption
that if we do need to add anything, it will happily sit alongside the
VCPU code.

~Andrew

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