On Mon, Sep 09, 2013 at 01:46:49PM +0200, Paolo Bonzini wrote: > >>>>>> Yes. QEMU unmarshals information from the XSAVE region and back, so it > >>>>>> cannot support MPX or AVX-512 yet (even if KVM were). Separate bug, though. > >>>>>> > >>>>> IMO this is the main issue here, not separate bug. If we gonna let guest > >>>>> use CPU state QEMU does not support we gonna have a bad time. > >>>> > >>>> We cannot force the guest not to use a feature; all we can do is hide > >>> > >>> Of course we can't, this is correct for other features too, but this is > >>> guest's problem. > >> > >> Ok, then we agree that QEMU doesn't have a problem? The XSAVE data will > > > > Which problem exactly. The problems I see is that 1. We do not support > > MPX and AVX-512 (but this is probably not the problem you meant :)) 2. 0D > > data is not consistent with features. Guest may not expect it and do stupid > > things. > > It is not a problem to unmarshal information out of KVM_GET_XSAVE data > (and back). If the guest does stupid things, it's a bug in an > ill-behaving guest. > You know I am first in line to blame guest for everything :) (who needs guests anyway) but in this case I didn't mean that guest does something illegal. If we advertise support for some XSAVE state in 0D leaf guest is in his right to make conclusions we may not expect from that. It may check corespondent feature bit and crash if it is not present for instance. > On the other hand, I agree that passthrough of host 0xD data is bad and > will fix it. > Thanks! -- Gleb. -- 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
