From: "Woodhouse, David" <dwmw@amazon.co.uk>
To: "seanjc@google.com" <seanjc@google.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>
Cc: "jmattson@google.com" <jmattson@google.com>,
"joro@8bytes.org" <joro@8bytes.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"vkuznets@redhat.com" <vkuznets@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"wanpengli@tencent.com" <wanpengli@tencent.com>
Subject: Re: [PATCH 5/5] KVM: x86/xen: Explicitly pad struct compat_vcpu_info to 64 bytes
Date: Wed, 10 Feb 2021 20:51:42 +0000 [thread overview]
Message-ID: <8752a59b694671d25308d644cba661c4ec128094.camel@amazon.co.uk> (raw)
In-Reply-To: <20210210182609.435200-6-seanjc@google.com>
On Wed, 2021-02-10 at 10:26 -0800, Sean Christopherson wrote:
> Add a 2 byte pad to struct compat_vcpu_info so that the sum size of its
> fields is actually 64 bytes. The effective size without the padding is
> also 64 bytes due to the compiler aligning evtchn_pending_sel to a 4-byte
> boundary, but depending on compiler alignment is subtle and unnecessary.
I think there's at least one BUILD_BUG_ON() which would have triggered
if the compiler ever did stop honouring the ELF ABI. And in fact in a
parallel universe where the ABI permits such packing, the padding would
be *wrong*, since the original Xen struct doesn't have the padding.
It *does* have an explicit uint8_t to replace evtchn_upcall_mask but it
doesn't have the following two bytes; canonically we *are* supposed to
take our chances with the ABI there. Although of course the relevant
ABI is the *32-bit* ABI in the compat case, not the 64-bit ABI. They
both align 32-bit values to 32 bits though.
uint8_t evtchn_upcall_pending;
#ifdef XEN_HAVE_PV_UPCALL_MASK
uint8_t evtchn_upcall_mask;
#else /* XEN_HAVE_PV_UPCALL_MASK */
uint8_t pad0;
#endif /* XEN_HAVE_PV_UPCALL_MASK */
xen_ulong_t evtchn_pending_sel;
struct arch_vcpu_info arch;
struct vcpu_time_info time;
}; /* 64 bytes (x86) */
So it isn't clear the additionally padding really buys us anything; if
we play this game without knowing the ABI we'd be screwed anyway. But
it doesn't hurt.
> Opportunistically replace spaces with tables in the other fields.
That part I certainly approve of.
Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.
next prev parent reply other threads:[~2021-02-10 20:53 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-10 18:26 [PATCH 0/5] KVM: x86/xen: Selftest fixes and a cleanup Sean Christopherson
2021-02-10 18:26 ` [PATCH 1/5] KVM: selftests: Ignore recently added Xen tests' build output Sean Christopherson
2021-02-10 20:52 ` [EXTERNAL] " David Woodhouse
2021-02-10 18:26 ` [PATCH 2/5] KVM: selftests: Fix size of memslots created by Xen tests Sean Christopherson
2021-02-10 20:53 ` [EXTERNAL] " David Woodhouse
2021-02-10 18:26 ` [PATCH 3/5] KVM: selftests: Fix hex vs. decimal snafu in Xen test Sean Christopherson
2021-02-10 20:54 ` Woodhouse, David
2021-02-10 18:26 ` [PATCH 4/5] KVM: sefltests: Don't bother mapping GVA for Xen shinfo test Sean Christopherson
2021-02-10 21:04 ` [EXTERNAL] " David Woodhouse
2021-02-10 18:26 ` [PATCH 5/5] KVM: x86/xen: Explicitly pad struct compat_vcpu_info to 64 bytes Sean Christopherson
2021-02-10 20:51 ` Woodhouse, David [this message]
2021-02-10 21:13 ` Sean Christopherson
2021-02-10 21:20 ` Woodhouse, David
2021-02-10 18:37 ` [PATCH 0/5] KVM: x86/xen: Selftest fixes and a cleanup Paolo Bonzini
2021-02-10 18:49 ` 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=8752a59b694671d25308d644cba661c4ec128094.camel@amazon.co.uk \
--to=dwmw@amazon.co.uk \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
/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).