[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200916170839.GD10227@sjchrist-ice>
Date: Wed, 16 Sep 2020 10:08:39 -0700
From: Sean Christopherson <sean.j.christopherson@...el.com>
To: Alexander Graf <graf@...zon.com>
Cc: Aaron Lewis <aaronlewis@...gle.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Jonathan Corbet <corbet@....net>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Wanpeng Li <wanpengli@...cent.com>,
Jim Mattson <jmattson@...gle.com>,
Joerg Roedel <joro@...tes.org>,
KarimAllah Raslan <karahmed@...zon.de>,
Dan Carpenter <dan.carpenter@...cle.com>,
kvm list <kvm@...r.kernel.org>, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 1/7] KVM: x86: Deflect unknown MSR accesses to user
space
On Wed, Sep 16, 2020 at 11:31:30AM +0200, Alexander Graf wrote:
> On 03.09.20 21:27, Aaron Lewis wrote:
> > > @@ -412,6 +414,15 @@ struct kvm_run {
> > > __u64 esr_iss;
> > > __u64 fault_ipa;
> > > } arm_nisv;
> > > + /* KVM_EXIT_X86_RDMSR / KVM_EXIT_X86_WRMSR */
> > > + struct {
> > > + __u8 error; /* user -> kernel */
> > > + __u8 pad[3];
> >
> > __u8 pad[7] to maintain 8 byte alignment? unless we can get away with
> > fewer bits for 'reason' and
> > get them from 'pad'.
>
> Why would we need an 8 byte alignment here? I always thought natural u64
> alignment on x86_64 was on 4 bytes?
u64 will usually (always?) be 8 byte aligned by the compiler. "Natural"
alignment means an object is aligned to its size. E.g. an 8-byte object
can split a cache line if it's only aligned on a 4-byte boundary.
Powered by blists - more mailing lists