Avi Kivity wrote: > On 10/04/2009 12:50 PM, Jan Kiszka wrote: >> Avi Kivity wrote: >> >>> On 10/04/2009 10:59 AM, Jan Kiszka wrote: >>> >>>> Hi, >>>> >>>> while preparing new IOCTLs to let user space query& set the yet >>>> unaccessible NMI states (pending and masked) I also came across the >>>> interrupt shadow masks. Unless I missed something I would say that >>>> we so >>>> far break them in the rare case that a migration happens right while >>>> any >>>> of them is asserted. So I guess I should extend my interface and stuff >>>> them in as well. >>>> >>>> Do we have more of such unaccessible states on x86 that could be >>>> included, too? Would be a good chance... >>>> >>>> >>> There's some hidden state in the cpuid mechanism. I think we expose it >>> though (just don't use it in qemu). >>> >> Do you have more details on this? >> > > Some cpuid leaves return different information based on an internal > counter. This is indicated by KVM_CPUID_FLAG_STATEFUL_FUNC. > >> The PDPTRs are hidden state that we should save/restore, though no sane >> guest relies on them. >> A quick glance at SVM makes me think that those registered are not >> exposed there. So when keeping in mind that we may only help VMX guests, >> I think i makes even less sense to "fix" this, does it? >> > > Yes. With npt the PDPTRs are essentially gone. > >>> I think we can lose information if we migrate during a SIPI >>> (sipi_vector), though that might be fixable without exposing it. >>> >> Hmm, I see. But even it it's not fixable, such an extension would be an >> in-kernel irqchip thing. >> > > Yes. > >>> We'll might also lost debug traps. >>> >>> We drop pending exceptions; normally that's fine since they'll reinject >>> themselves, but MCE will not. >>> >> So would it make sense and fix those two issues when we simply save and >> restore the pending exception? >> > > Yes. > > btw, instead of adding a new ioctl, perhaps it makes sense to define a > new KVM_VCPU_STATE structure that holds all current and future state > (with generous reserved space), instead of separating state over a dozen > ioctls. > OK, makes sense. With our without lapic state? How much "future space"? Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
