linux-kernel - Re: [PATCH v3 09/13] KVM: xen: automatically use the vcpu_info embedded in shared

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aaeb3cfe3d4cd40ced226038f3e2cb126854bcc1.camel@infradead.org>
Date:   Mon, 18 Sep 2023 17:20:35 +0100
From:   David Woodhouse <dwmw2@...radead.org>
To:     paul@....org, kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Cc:     Paul Durrant <pdurrant@...zon.com>,
        Sean Christopherson <seanjc@...gle.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org
Subject: Re: [PATCH v3 09/13] KVM: xen: automatically use the vcpu_info
 embedded in shared_info

On Mon, 2023-09-18 at 17:15 +0100, Paul Durrant wrote:
> > > +  Note that, if the guest sets an explicit vcpu_info location in guest
> > > +  memory then the VMM is expected to copy the content of the structure
> > > +  embedded in the shared_info page to the new location. It is therefore
> > > +  important that no event delivery is in progress at this time, otherwise
> > > +  events may be missed.
> > > 
> > 
> > That's difficult. It means tearing down all interrupts from passthrough
> > devices which are mapped via PIRQs, and also all IPIs.
> 
> So those don't honour event channel masking? That seems like a problem.

Oh, *mask*. Sure, it does honour masking. But... that would mean the
VMM has to keep track of which ports were *really* masked by the guest,
and which ones were just masked for the switchover. Including if the
guest does some mask/unmask activity *while* the switchover is
happening (or locking to prevent such). I still don't think that's a
kind thing to be telling the VMMs they need to do.

> > 
> > The IPI code *should* be able to fall back to just letting the VMM
> > handle the hypercall in userspace. But PIRQs are harder. I'd be happier
> > if our plan — handwavy though it may be — led to being able to use the
> > existing slow path for delivering interrupts by just *invalidating* the
> > cache. Maybe we *should* move the memcpy into the kernel, and let it
> > lock *both* the shinfo and new vcpu_info caches while it's doing the
> > copy? Given that that's the only valid transition, that shouldn't be so
> > hard, should it?
> > 
> 
> No, it just kind of oversteps the remit of the attribute... but I'll try 
> adding it and see how messy it gets.

Well, there's a reason I left all the vcpu_info address magic in
userspace in the first place. It was there in João's original patches
and I ripped it all out.

But I see your logic for wanting to put it back; I suspect moving the
memcpy too is part of the cost of that? Should work out OK, I think.

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5965 bytes)