[Xen-devel] x86/vMSI-X emulation issue

["Jan Beulich" <JBeulich@xxxxxxxx>]

All,

so I've just learned that Windows (at least some versions and some
of their code paths) use REP MOVSD to read/write the MSI-X table.
The way at least msixtbl_write() works is not compatible with this
(msixtbl_read() also seems affected, albeit to a lesser degree), and
apparently it just worked by accident until the XSA-120 and 128-131
and follow-up changes - most notably commit ad28e42bd1 ("x86/MSI:
track host and guest masking separately"), as without the call to
guest_mask_msi_irq() interrupts won't ever get unmasked.

The problem with emulating REP MOVSD is that msixtbl_write()
intentionally returns X86EMUL_UNHANDLEABLE on all writes to
words 0, 1, and 2. When in the process of emulating multiple
writes, we therefore hand the entire batch of 3 or 4 writes to qemu,
and the hypervisor doesn't get to see any other than the initial
iteration.

Now I see a couple of possible solutions, but none of them look
really neat, hence I'm seeking a second opinion (including, of
course, further alternative ideas):

1) Introduce another X86EMUL_* like status that's not really to be
    used by the emulator itself, but only by the two vMSI-X functions
    to indicate to their caller that prior to forwarding the request it
    should be chopped to a single repetition.

2) Do aforementioned chopping automatically on seeing
    X86EMUL_UNHANDLEABLE, on the basis that the .check
    handler had indicated that the full range was acceptable. That
    would at once cover other similarly undesirable cases like the
    vLAPIC code returning this error. However, any stdvga like
    emulated device would clearly not want such to happen, and
    would instead prefer the entire batch to get forwarded in one
    go (stdvga itself sits on a different path). Otoh, with the
    devices we have currently, this would seem to be the least
    intrusive solution.

3) Have emulation backends provide some kind of (static) flag
    indicating which forwarding behavior they would like.

4) Expose the full ioreq to the emulation backends, so they can
    fiddle with the request to their liking.

Thanks, Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel