[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <527713984b43e372e569209f394c54520d3b3e60.camel@redhat.com>
Date: Sun, 10 Jul 2022 18:58:07 +0300
From: Maxim Levitsky <mlevitsk@...hat.com>
To: Jim Mattson <jmattson@...gle.com>,
Sean Christopherson <seanjc@...gle.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Wanpeng Li <wanpengli@...cent.com>,
Joerg Roedel <joro@...tes.org>, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org, Oliver Upton <oupton@...gle.com>,
Peter Shier <pshier@...gle.com>
Subject: Re: [PATCH v2 00/21] KVM: x86: Event/exception fixes and cleanups
On Wed, 2022-07-06 at 13:11 -0700, Jim Mattson wrote:
> On Wed, Jul 6, 2022 at 10:52 AM Sean Christopherson <seanjc@...gle.com> wrote:
>
> > Hmm, I'm not entirely convinced that Intel doesn't interpret "internal to the
> > processor" as "undocumented SMRAM fields". But I could also be misremembering
> > the SMI flows.
>
> Start using reserved SMRAM, and you will regret it when the vendor
> assigns some new bit of state to the same location.
>
This is true to some extent, but our SMRAM layout doesn't follow the
spec anyway. This is the reason I asked (I posted an RFC as a good citizen),
in the first place all of you, if you prefer SMRAM or KVM internal state.
Anyway if this is a concern, I can just save the interrupt shadow in KVM,
and migrate it, its not hard, in fact the v1 of my patches did exactly that.
Paolo, what should I do?
Best regards,
Maxim Levitsky
Powered by blists - more mailing lists