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

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

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.

-boris



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