From: Sean Christopherson <seanjc@google.com>
To: Paul Durrant <paul@xen.org>
Cc: David Woodhouse <dwmw2@infradead.org>,
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 0/2] KVM: xen: update shared_info when long_mode is set
Date: Fri, 1 Dec 2023 08:46:07 -0800 [thread overview]
Message-ID: <ZWoNzzYiZtloNQiv@google.com> (raw)
In-Reply-To: <20231201104536.947-1-paul@xen.org>
On Fri, Dec 01, 2023, Paul Durrant wrote:
> From: Paul Durrant <pdurrant@amazon.com>
>
> This series is based on my v9 of my "update shared_info and vcpu_info
> handling" series [1] and fixes an issue that was latent before the
> "allow shared_info to be mapped by fixed HVA" patch of that series allowed
> a VMM to set up shared_info before the VM booted and then leave it alone.
Uh, what? If this is fixing an existing bug then it really shouldn't take a
dependency on a rather large and non-trivial series. If the bug can only manifest
as a result of said series, then the fix absolutely belongs in that series.
This change from patch 1 in particular:
-static int kvm_xen_shared_info_init(struct kvm *kvm, u64 addr, bool addr_is_gfn)
+static int kvm_xen_shared_info_init(struct kvm *kvm)
practically screams for inclusion in that series which does:
-static int kvm_xen_shared_info_init(struct kvm *kvm, gfn_t gfn)
+static int kvm_xen_shared_info_init(struct kvm *kvm, u64 addr, bool addr_is_gfn)
Why not get the code right the first time instead of fixing it up in a completely
different series?
next prev parent reply other threads:[~2023-12-01 16:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-01 10:45 [PATCH 0/2] KVM: xen: update shared_info when long_mode is set Paul Durrant
2023-12-01 10:45 ` [PATCH 1/2] KVM: xen: separate initialization of shared_info cache and content Paul Durrant
2023-12-01 10:45 ` [PATCH 2/2] KVM: xen: (re-)initialize shared_info if guest (32/64-bit) mode is set Paul Durrant
2023-12-01 15:32 ` Paul Durrant
2023-12-01 16:46 ` Sean Christopherson [this message]
2023-12-01 17:08 ` [PATCH 0/2] KVM: xen: update shared_info when long_mode " Durrant, Paul
2023-12-01 17:44 ` Sean Christopherson
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=ZWoNzzYiZtloNQiv@google.com \
--to=seanjc@google.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=dwmw2@infradead.org \
--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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.