On Tue, Oct 20, 2009 at 03:29:38PM +0200, Jan Kiszka wrote: > Gleb Natapov wrote: > > On Tue, Oct 20, 2009 at 03:19:41PM +0200, Jan Kiszka wrote: > >> Alexander Graf wrote: > >>> On 20.10.2009, at 15:01, Jan Kiszka wrote: > >>> > >>>> Hi all, > >>>> > >>>> as the list of yet user-unaccessible x86 states is a bit volatile ATM, > >>>> this is an attempt to collect the precise requirements for additional > >>>> state fields. Once everyone feels the list is complete, we can decide > >>>> how to partition it into one ore more substates for the new > >>>> KVM_GET/SET_VCPU_STATE interface. > >>>> > >>>> What I read so far (or tried to patch already): > >>>> > >>>> - nmi_masked > >>>> - nmi_pending > >>>> - nmi_injected > >>>> - kvm_queued_exception (whole struct content) > >>>> - KVM_REQ_TRIPLE_FAULT (from vcpu.requests) > >>>> > >>>> Unclear points (for me) from the last discussion: > >>>> > >>>> - sipi_vector > >>>> - MCE (covered via kvm_queued_exception, or does it require more?) > >>>> > >>>> Please extend or correct the list as required. > >>> hflags. Qemu supports GIF, kvm supports GIF, but no side knows how to > >>> sync it. > >> OK. Whole hflags or just the GIF bit? > >> > >> If we allow access to all bits, can user space cause any problems > >> (beyond screwing up its guests) by passing weird patterns? > >> > > HF_NMI_MASK should be migrated too. Destination should enable IRET intercept if > > HF_NMI_MASK is set. Or we can assume that migration in the middle of NMI > > will never happen :) > > HF_NMI_MASK is redundant to the vendor-agnostic nmi_masked and would > therefore likely be masked out. > Correct. We can restore HF_NMI_MASK from nmi_masked. -- 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
