On Mon, Mar 27, 2023 at 05:32:01PM +0200, Jan Beulich wrote: > On 27.03.2023 12:12, Roger Pau Monné wrote: > > On Sat, Mar 25, 2023 at 03:49:22AM +0100, 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. This does include forwarding also writes > >> that did not change the value, but as tested on both Linux (6.1.12) and > >> Windows (10 pro), they don't do excessive writes of unchanged values > >> (Windows seems to clear maskbit in some cases twice, but not more). > > > > Since we passthrough all the accesses to the device model, is the > > handling in Xen still required? > > "All accesses" isn't really correct; aiui even after this change it's only > "all writes". We still "accelerate" reading from the first 3 table entries > (whether or not that's [still] useful in this shape is a separate question). > Plus we need to invoke guest_mask_msi_irq() as necessary, and I don't think > we should make ourselves dependent upon qemu communicating the necessary > info back to us, when that's necessary for the correctness of Xen's internal > interrupt handling. (That's further leaving aside the performance aspect of > handing off to qemu just for it to pass data back to us.)
The call to guest_mask_msi_irq() is a result of a guest action, I'm failing to see how that's necessary for the correctness of Xen's internal interrupt handling. In my proposed model QEMU won't be allowed direct access to the physical MSIX entry mask bits, and would instead use an hypercall to mask/unmask MSIX entries (and thus guest_mask_msi_irq() would be called as appropriate). Thanks, Roger.
