[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d711ca30-ff84-2efa-4b9e-d9b46f53c0a5@intel.com>
Date: Tue, 18 May 2021 10:46:38 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Andi Kleen <ak@...ux.intel.com>,
Sean Christopherson <seanjc@...gle.com>
Cc: Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>,
Andy Lutomirski <luto@...nel.org>,
Tony Luck <tony.luck@...el.com>,
Kirill Shutemov <kirill.shutemov@...ux.intel.com>,
Kuppuswamy Sathyanarayanan <knsathya@...nel.org>,
Dan Williams <dan.j.williams@...el.com>,
Raj Ashok <ashok.raj@...el.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC v2-fix 1/1] x86/tdx: Handle in-kernel MMIO
On 5/18/21 10:21 AM, Andi Kleen wrote:
> Besides instruction decoding works fine for all the existing
> hypervisors. All we really want to do is to do the same thing as KVM
> would do.
Dumb question of the day: If you want to do the same thing that KVM
does, why don't you share more code with KVM? Wouldn't you, for
instance, need to crack the same instruction opcodes?
I'd feel a lot better about this if you said:
Listen, this doesn't work for everything. But, it will run
every single driver as a TDX guest that KVM can handle as a
host. So, if the TDX code is broken, so is the KVM host code.
Powered by blists - more mailing lists