[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <594b0e2a-9377-1b67-be93-924cae2db7f4@redhat.com>
Date: Fri, 22 Feb 2019 13:50:20 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Sean Christopherson <sean.j.christopherson@...el.com>,
Joao Martins <joao.m.martins@...cle.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
Ankur Arora <ankur.a.arora@...cle.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Radim Krčmář <rkrcmar@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org
Subject: Re: [PATCH RFC 02/39] KVM: x86/xen: intercept xen hypercalls if
enabled
On 22/02/19 01:30, Sean Christopherson wrote:
> On Thu, Feb 21, 2019 at 08:56:06PM +0000, Joao Martins wrote:
>> The Xen addition follows the same structure as Hyper-V in kvm (what you suggest
>> here is probably applicable for both). i.e. there's some Xen specific routines
>> for vm/vcpu init/teardown, and timer handling. We would have to place some of
>> those functions into a struct that gets registered at modinit.
>
> Huh. I never really hooked at the Hyper-V code, for some reason I always
> assumed it was only related to running KVM on Hyper-V. I agree that this
> extra hurdle only makes sense if it's also applied to Hyper-V.
The difference is that Hyper-V support is more or less mandatory to run
recent Windows guests. Having a config symbol would be enough for me.
Paolo
Powered by blists - more mailing lists