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

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 12/20/2016 11:46 AM, Andrew Cooper wrote:
> 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.

And I just found these two: XEN_DOMCTL_SENDTRIGGER_POWER and
XEN_DOMCTL_SENDTRIGGER_POWER.

When we switch HVM to new interface these can be re-implemented on top
of ACPI access.

-boris

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