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.ostrov...@oracle.com> wrote: >>> On 12/20/2016 09:47 AM, Jan Beulich wrote: >>>>>>> On 20.12.16 at 15:35, <boris.ostrov...@oracle.com> 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@lists.xen.org https://lists.xen.org/xen-devel