[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1909201345380.1858@nanos.tec.linutronix.de>
Date: Fri, 20 Sep 2019 13:48:05 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Paolo Bonzini <pbonzini@...hat.com>
cc: LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
Peter Zijlstra <peterz@...radead.org>,
Andy Lutomirski <luto@...nel.org>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Marc Zyngier <maz@...nel.org>, kvm@...r.kernel.org,
linux-arch@...r.kernel.org
Subject: Re: [RFC patch 14/15] workpending: Provide infrastructure for work
before entering a guest
On Thu, 19 Sep 2019, Paolo Bonzini wrote:
> > + /* Any extra architecture specific work */
> > + return arch_exit_to_guestmode_work(kvm, vcpu, ti_work);
> > +}
>
> Perhaps, in virt/kvm/kvm_main.c:
>
> int kvm_exit_to_guestmode_work(struct kvm *kvm, struct kvm_vcpu *vcpu,
> unsigned long ti_work)
> {
...
> }
>
> and in kernel/entry/common.c:
>
> int core_exit_to_guestmode_work(unsigned long ti_work)
> {
...
> }
Makes sense.
> so that kernel/entry/ is not polluted with KVM structs and APIs.
>
> Perhaps even extract the body of core_exit_to_usermode_work's while loop
> to a separate function, and call it as
>
> core_exit_to_usermode_work_once(NULL,
> ti_work & EXIT_TO_GUESTMODE_WORK);
Doh, its too obvious now that you mention it :)
> from core_exit_to_guestmode_work.
>
> In general I don't mind having these exit_to_guestmode functions in
> kvm_host.h, and only having entry-common.h export EXIT_TO_GUESTMODE_WORK
> and ARCH_EXIT_TO_GUESTMODE_WORK. Unless you had good reasons to do the
> opposite...
That was an arbitrary choice and it does not matter much where it lives.
Thanks,
tglx
Powered by blists - more mailing lists