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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan


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