From: Alexander Graf <graf@amazon.com>
To: Peter Gonda <pgonda@google.com>, Sean Christopherson <seanjc@google.com>
Cc: <kvm@vger.kernel.org>, Paolo Bonzini <pbonzini@redhat.com>,
"Borislav Petkov" <bp@alien8.de>, <x86@kernel.org>,
Tom Lendacky <thomas.lendacky@amd.com>,
Michael Roth <michael.roth@amd.com>,
Sabin Rapan <sabrapan@amazon.com>
Subject: Re: [PATCH] KVM: x86: Allow restore of some sregs with protected state
Date: Wed, 22 Mar 2023 00:46:08 +0100 [thread overview]
Message-ID: <8dcd6141-85c9-aed5-2f50-9c9cd08d8e21@amazon.com> (raw)
In-Reply-To: <CAMkAt6ozZ5LwvRNn+hP5-ZGOyrtDMmBUR+x5iJ37xVZyQk4kBw@mail.gmail.com>
On 21.03.23 19:15, Peter Gonda wrote:
> On Tue, Mar 21, 2023 at 11:03 AM Sean Christopherson <seanjc@google.com> wrote:
>> +Peter
>>
>> On Mon, Mar 20, 2023, Alexander Graf wrote:
>>> With protected state (like SEV-ES and SEV-SNP), KVM does not have direct
>>> access to guest registers. However, we deflect modifications to CR0,
>> Please avoid pronouns in changelogs and comments.
>>
>>> CR4 and EFER to the host. We also carry the apic_base register and learn
>>> about CR8 directly from a VMCB field.
>>>
>>> That means these bits of information do exist in the host's KVM data
>>> structures. If we ever want to resume consumption of an already
>>> initialized VMSA (guest state), we will need to also restore these
>>> additional bits of KVM state.
>> For some definitions of "need". I've looked at this code multiple times in the
>> past, and even posted patches[1], but I'm still unconvinced that trapping
>> CR0, CR4, and EFER updates is necessary[2], which is partly why series to fix
>> this stalled out.
>>
>> : If KVM chugs along happily without these patches, I'd love to pivot and yank out
>> : all of the CR0/4/8 and EFER trapping/tracking, and then make KVM_GET_SREGS a nop
>> : as well.
>>
>> [1] https://lore.kernel.org/all/20210507165947.2502412-1-seanjc@google.com
>> [2] https://lore.kernel.org/all/YJla8vpwqCxqgS8C@google.com
> Yea we are using similar patches to do intra-host migration for SNP VMs.
>
> I have dropped the ball on my AI from that thread. Let me look/test this patch.
Awesome, thanks. If we can get away without any of the above states and
make sregs completely useless for protected state, I'd be even happier :)
Alex
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
prev parent reply other threads:[~2023-03-21 23:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-20 22:51 [PATCH] KVM: x86: Allow restore of some sregs with protected state Alexander Graf
2023-03-21 17:03 ` Sean Christopherson
2023-03-21 18:15 ` Peter Gonda
2023-03-21 23:46 ` Alexander Graf [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8dcd6141-85c9-aed5-2f50-9c9cd08d8e21@amazon.com \
--to=graf@amazon.com \
--cc=bp@alien8.de \
--cc=kvm@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=pbonzini@redhat.com \
--cc=pgonda@google.com \
--cc=sabrapan@amazon.com \
--cc=seanjc@google.com \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).