On 13.03.2024 16:16, Marek Marczykowski-Górecki wrote: > QEMU needs to know whether clearing maskbit of a vector is really > clearing, or was already cleared before. Currently Xen sends only > clearing that bit to the device model, but not setting it, so QEMU > cannot detect it. Because of that, QEMU is working this around by > checking via /dev/mem, but that isn't the proper approach. > > Give all necessary information to QEMU by passing all ctrl writes, > including masking a vector. Advertise the new behavior via > XENVER_get_features, so QEMU can know it doesn't need to access /dev/mem > anymore. > > While this commit doesn't move the whole maskbit handling to QEMU (as > discussed on xen-devel as one of the possibilities), it is a necessary > first step anyway. Including telling QEMU it will get all the required > information to do so. The actual implementation would need to include: > - a hypercall for QEMU to control just maskbit (without (re)binding the > interrupt again > - a methor for QEMU to tell Xen it will actually do the work > Those are not part of this series. > > Signed-off-by: Marek Marczykowski-Górecki <marma...@invisiblethingslab.com>
Reviewed-by: Jan Beulich <jbeul...@suse.com> > --- > I did not added any control to enable/disable this new behavior (as > Roger have suggested for possible non-QEMU ioreqs). I don't see how the > new behavior could be problematic for some existing ioreq server (they > already received writes to those addresses, just not all of them), > but if that's really necessary, I can probably add a command line option > to restore previous behavior system-wide. Roger, please indicate whether you consider things to be okay to go in as is, or whether you demand this earlier concern of yours to be addressed by adding a command line option (or even finer-grained control). Jan
