On Thu, Dec 30, 2010 at 11:28:20AM +0200, Avi Kivity wrote: > On 12/30/2010 09:32 AM, Sheng Yang wrote: > >> > >> I don't think it's going to work: we are not > >> in the context of the right process. Further > >> I think we should keep the option of > >> reading the PBA status from the device or host kernel open. > >> And generally having an interface > >> for functionality we don't implement is not a good idea: > >> you don't know whether you really can support the interface you promised. > > > >Well, I don't know if we want to read PBA from device directly. To me it's not a > >good idea because the real device has nothing to do with the one we show to the > >guest. > > Right. vPBA.bit = pPBA.bit | > recorded_pending_bit_from_lazy_masked_interrupt. At some level, this is correct. However both are *not* in userspace memory so an interface that assumes that pending bits in userspace are correct at all times is not going to work. There is also the spec requirement that the device clears the pending bit if the interrupt was not served but the condition that caused the event no longer applies, so that a driver can work just by polling pending bits. Personally I don't think this requirement works in real life - Seems more like a vague idea on behalf of spec authors - so hopefully guests do not use this. > > At least direct accessing the mask bits of real device would be very > >dangerous. Avi? > > Agree. > > -- > error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
