From: David Woodhouse <dwmw2@infradead.org>
To: paul@xen.org, Sean Christopherson <seanjc@google.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v8 15/15] KVM: xen: allow vcpu_info content to be 'safely' copied
Date: Wed, 22 Nov 2023 11:25:47 +0000 [thread overview]
Message-ID: <40d2e3051fbc70308cf0b6fc5298b65bf5737012.camel@infradead.org> (raw)
In-Reply-To: <94697586-7600-420d-a91b-2829019dab7c@xen.org>
[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]
On Wed, 2023-11-22 at 10:55 +0000, Paul Durrant wrote:
>
> > > Wait, didn't we realise that this leaves the bits set in the shadow
> > > evtchn_pending_sel that get lost on migration?
> > >
>
> Indeed we did not, but that's not something that *this* patch, or even
> this series, is dealing with. We also know that setting the 'width' of
> shared_info has some issues, but again, can we keep that for other
> patches? The series is at v9 and has already suffered a fair amount of
> scope-creep.
Hrm... OK, that makes sense. This series is attempting to address the
fact that we can't do overlays on memslots without temporarily taking
away GPA ranges that we didn't mean to change. This patch is sufficient
to allow evtchn delivery to work while the memslots are being frobbed,
because userspace takes the vcpu_info away during the update.
In that case the shadow works just fine.
So yeah, if you want to handle the migration case separately then that
seems reasonable.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5965 bytes --]
prev parent reply other threads:[~2023-11-22 11:26 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-21 18:02 [PATCH v8 00/15] KVM: xen: update shared_info and vcpu_info handling Paul Durrant
2023-11-21 18:02 ` [PATCH v8 01/15] KVM: pfncache: Add a map helper function Paul Durrant
2023-11-21 18:02 ` [PATCH v8 02/15] KVM: pfncache: remove unnecessary exports Paul Durrant
2023-11-21 21:49 ` David Woodhouse
2023-11-22 8:44 ` Paul Durrant
2023-11-21 18:02 ` [PATCH v8 03/15] KVM: xen: mark guest pages dirty with the pfncache lock held Paul Durrant
2023-11-21 21:49 ` David Woodhouse
2023-11-21 18:02 ` [PATCH v8 04/15] KVM: pfncache: add a mark-dirty helper Paul Durrant
2023-11-21 18:02 ` [PATCH v8 05/15] KVM: pfncache: remove KVM_GUEST_USES_PFN usage Paul Durrant
2023-11-21 22:24 ` David Woodhouse
2023-11-27 23:36 ` Sean Christopherson
2023-11-21 18:02 ` [PATCH v8 06/15] KVM: pfncache: stop open-coding offset_in_page() Paul Durrant
2023-11-21 22:26 ` David Woodhouse
2023-11-21 18:02 ` [PATCH v8 07/15] KVM: pfncache: include page offset in uhva and use it consistently Paul Durrant
2023-11-21 22:35 ` David Woodhouse
2023-11-22 9:29 ` Paul Durrant
2023-11-22 8:54 ` Xu Yilun
2023-11-22 9:12 ` David Woodhouse
2023-11-22 14:27 ` Xu Yilun
2023-11-22 15:42 ` David Woodhouse
2023-11-22 15:52 ` Paul Durrant
2023-11-21 18:02 ` [PATCH v8 08/15] KVM: pfncache: allow a cache to be activated with a fixed (userspace) HVA Paul Durrant
2023-11-21 22:47 ` David Woodhouse
2023-11-22 10:07 ` Paul Durrant
2023-11-21 18:02 ` [PATCH v8 09/15] KVM: xen: allow shared_info to be mapped by fixed HVA Paul Durrant
2023-11-21 18:02 ` [PATCH v8 10/15] KVM: xen: allow vcpu_info " Paul Durrant
2023-11-21 18:02 ` [PATCH v8 11/15] KVM: selftests / xen: map shared_info using HVA rather than GFN Paul Durrant
2023-11-21 18:02 ` [PATCH v8 12/15] KVM: selftests / xen: re-map vcpu_info using HVA rather than GPA Paul Durrant
2023-11-21 18:02 ` [PATCH v8 13/15] KVM: xen: advertize the KVM_XEN_HVM_CONFIG_SHARED_INFO_HVA capability Paul Durrant
2023-11-21 18:02 ` [PATCH v8 14/15] KVM: xen: split up kvm_xen_set_evtchn_fast() Paul Durrant
2023-11-21 22:49 ` David Woodhouse
2023-11-21 18:02 ` [PATCH v8 15/15] KVM: xen: allow vcpu_info content to be 'safely' copied Paul Durrant
2023-11-21 22:53 ` David Woodhouse
2023-11-22 10:39 ` David Woodhouse
2023-11-22 10:55 ` Paul Durrant
2023-11-22 11:25 ` David Woodhouse [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=40d2e3051fbc70308cf0b6fc5298b65bf5737012.camel@infradead.org \
--to=dwmw2@infradead.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=paul@xen.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--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).