From: Borislav Petkov <bp@alien8.de>
To: Sean Christopherson <seanjc@google.com>
Cc: "Michael Kelley (LINUX)" <mikelley@microsoft.com>,
Dave Hansen <dave.hansen@intel.com>,
"hpa@zytor.com" <hpa@zytor.com>,
KY Srinivasan <kys@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
"wei.liu@kernel.org" <wei.liu@kernel.org>,
Dexuan Cui <decui@microsoft.com>,
"luto@kernel.org" <luto@kernel.org>,
"peterz@infradead.org" <peterz@infradead.org>,
"davem@davemloft.net" <davem@davemloft.net>,
"edumazet@google.com" <edumazet@google.com>,
"kuba@kernel.org" <kuba@kernel.org>,
"pabeni@redhat.com" <pabeni@redhat.com>,
"lpieralisi@kernel.org" <lpieralisi@kernel.org>,
"robh@kernel.org" <robh@kernel.org>,
"kw@linux.com" <kw@linux.com>,
"bhelgaas@google.com" <bhelgaas@google.com>,
"arnd@arndb.de" <arnd@arndb.de>, "hch@lst.de" <hch@lst.de>,
"m.szyprowski@samsung.com" <m.szyprowski@samsung.com>,
"robin.murphy@arm.com" <robin.murphy@arm.com>,
"thomas.lendacky@amd.com" <thomas.lendacky@amd.com>,
"brijesh.singh@amd.com" <brijesh.singh@amd.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"mingo@redhat.com" <mingo@redhat.com>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
Tianyu Lan <Tianyu.Lan@microsoft.com>,
"kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>,
"sathyanarayanan.kuppuswamy@linux.intel.com"
<sathyanarayanan.kuppuswamy@linux.intel.com>,
"ak@linux.intel.com" <ak@linux.intel.com>,
"isaku.yamahata@intel.com" <isaku.yamahata@intel.com>,
"dan.j.williams@intel.com" <dan.j.williams@intel.com>,
"jane.chu@oracle.com" <jane.chu@oracle.com>,
"tony.luck@intel.com" <tony.luck@intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
"iommu@lists.linux.dev" <iommu@lists.linux.dev>
Subject: Re: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted
Date: Thu, 23 Feb 2023 11:45:17 +0100 [thread overview]
Message-ID: <Y/dDvTMrCm4GFsvv@zn.tnic> (raw)
In-Reply-To: <Y/a/lzOwqMjOUaYZ@google.com>
On Wed, Feb 22, 2023 at 05:21:27PM -0800, Sean Christopherson wrote:
> The MTRR mess isn't unique to coco guests, e.g. KVM explicitly "supports" VMMs
> hiding MTTRs from the guest by defaulting to WB if MTTRs aren't exposed to the
> guest. Why on earth Hyper-V suddenly needs to enlighten the guest is beyond me,
> but whatever the reason, it's not unique to coco VMs.
Well, TDX can't stomach MTRRs either, reportedly, and I hear we should
try to avoid #VEs for them too.
And this is the problem: all those guest "enlightening" efforts come up
with the weirdest stuff they need to sprinkle around arch/x86/. And if
we let that without paying attention to the big picture, that will
become an unmaintanable mess.
And I'm not proud of some of the stuff we did in arch/x86/ already and
some day they'll get on my nerves just enough...
> All I'm advocating is that for determining whether or not a device should be mapped
> private vs. shared, provide an API so that the hypervisor-specific enlightened code
> can manage that insanity without polluting common code. If we are ever fortunate
> enough to have common enumeration, e.g. through ACPI or something, the enlightened
> code can simply reroute to the common code. This is a well established pattern for
> many paravirt features, I don't see why it wouldn't work here.
Yah, that would be good. If the device can know upfront how it needs to
ioremap its address range, then that is fine - we already have
ioremap_encrypted() for example.
What I don't like is hooking conditionals into the common code to figure
out what to do depending on what we're running on.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2023-02-23 10:45 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-12 21:42 [PATCH v5 00/14] Add PCI pass-thru support to Hyper-V Confidential VMs Michael Kelley
2023-01-12 21:42 ` [PATCH v5 01/14] x86/ioapic: Gate decrypted mapping on cc_platform_has() attribute Michael Kelley
2023-01-12 21:42 ` [PATCH v5 02/14] x86/hyperv: Reorder code to facilitate future work Michael Kelley
2023-01-12 21:42 ` [PATCH v5 03/14] Drivers: hv: Explicitly request decrypted in vmap_pfn() calls Michael Kelley
2023-01-12 21:42 ` [PATCH v5 04/14] x86/mm: Handle decryption/re-encryption of bss_decrypted consistently Michael Kelley
2023-01-12 21:42 ` [PATCH v5 05/14] init: Call mem_encrypt_init() after Hyper-V hypercall init is done Michael Kelley
2023-01-12 21:42 ` [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted Michael Kelley
2023-01-20 20:15 ` Borislav Petkov
2023-01-21 4:10 ` Michael Kelley (LINUX)
2023-01-25 14:55 ` Borislav Petkov
2023-02-02 5:49 ` Michael Kelley (LINUX)
2023-02-07 12:41 ` Borislav Petkov
2023-02-07 19:01 ` Michael Kelley (LINUX)
2023-02-07 19:33 ` Borislav Petkov
2023-02-07 19:48 ` Michael Kelley (LINUX)
2023-02-07 19:54 ` Borislav Petkov
2023-02-07 19:57 ` Michael Kelley (LINUX)
2023-02-08 0:18 ` Michael Kelley (LINUX)
2023-02-08 15:09 ` Dave Hansen
2023-02-09 17:29 ` Michael Kelley (LINUX)
2023-02-08 17:23 ` Dave Hansen
2023-02-09 17:47 ` Michael Kelley (LINUX)
2023-02-10 18:41 ` Sean Christopherson
2023-02-10 18:58 ` Dave Hansen
2023-02-10 19:03 ` Borislav Petkov
2023-02-10 19:15 ` Michael Kelley (LINUX)
2023-02-10 19:36 ` Borislav Petkov
2023-02-10 19:58 ` Dave Hansen
2023-02-10 20:50 ` Sean Christopherson
2023-02-10 20:57 ` Sean Christopherson
2023-02-10 21:27 ` Michael Kelley (LINUX)
2023-02-10 23:47 ` Sean Christopherson
2023-02-14 7:45 ` Michael Kelley (LINUX)
2023-02-16 13:32 ` Borislav Petkov
2023-02-16 16:16 ` Michael Kelley (LINUX)
2023-02-16 17:06 ` Borislav Petkov
2023-02-17 6:16 ` Michael Kelley (LINUX)
2023-02-17 14:55 ` Borislav Petkov
2023-02-22 22:13 ` Sean Christopherson
2023-02-22 22:33 ` Borislav Petkov
2023-02-22 22:54 ` Sean Christopherson
2023-02-22 23:34 ` Borislav Petkov
2023-02-23 1:21 ` Sean Christopherson
2023-02-23 10:45 ` Borislav Petkov [this message]
2023-02-23 20:01 ` Michael Kelley (LINUX)
2023-02-23 20:27 ` Dave Hansen
2023-03-06 21:51 ` Borislav Petkov
2023-03-09 11:12 ` David Woodhouse
2023-03-09 11:59 ` Borislav Petkov
2023-03-09 13:00 ` David Woodhouse
2023-03-09 14:19 ` Tom Lendacky
2023-03-09 14:36 ` Jörg Rödel
2023-03-09 14:45 ` Borislav Petkov
2023-03-09 15:45 ` David Woodhouse
2023-03-09 16:34 ` Borislav Petkov
2023-03-10 10:05 ` David Woodhouse
2023-02-23 20:26 ` Dave Hansen
2023-02-23 20:41 ` Dave Hansen
2023-02-23 20:51 ` Michael Kelley (LINUX)
2023-02-23 21:07 ` Sean Christopherson
2023-02-23 21:15 ` Michael Kelley (LINUX)
2023-02-23 21:24 ` Dave Hansen
2023-01-12 21:42 ` [PATCH v5 07/14] x86/hyperv: Change vTOM handling to use standard coco mechanisms Michael Kelley
2023-01-12 21:42 ` [PATCH v5 08/14] swiotlb: Remove bounce buffer remapping for Hyper-V Michael Kelley
2023-01-12 21:42 ` [PATCH v5 09/14] Drivers: hv: vmbus: Remove second mapping of VMBus monitor pages Michael Kelley
2023-01-12 21:42 ` [PATCH v5 10/14] Drivers: hv: vmbus: Remove second way of mapping ring buffers Michael Kelley
2023-01-12 21:42 ` [PATCH v5 11/14] hv_netvsc: Remove second mapping of send and recv buffers Michael Kelley
2023-01-12 21:42 ` [PATCH v5 12/14] Drivers: hv: Don't remap addresses that are above shared_gpa_boundary Michael Kelley
2023-01-12 21:42 ` [PATCH v5 13/14] PCI: hv: Add hypercalls to read/write MMIO space Michael Kelley
2023-01-12 21:42 ` [PATCH v5 14/14] PCI: hv: Enable PCI pass-thru devices in Confidential VMs Michael Kelley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y/dDvTMrCm4GFsvv@zn.tnic \
--to=bp@alien8.de \
--cc=Tianyu.Lan@microsoft.com \
--cc=ak@linux.intel.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=brijesh.singh@amd.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=decui@microsoft.com \
--cc=edumazet@google.com \
--cc=haiyangz@microsoft.com \
--cc=hch@lst.de \
--cc=hpa@zytor.com \
--cc=iommu@lists.linux.dev \
--cc=isaku.yamahata@intel.com \
--cc=jane.chu@oracle.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kuba@kernel.org \
--cc=kw@linux.com \
--cc=kys@microsoft.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=luto@kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mikelley@microsoft.com \
--cc=mingo@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=peterz@infradead.org \
--cc=robh@kernel.org \
--cc=robin.murphy@arm.com \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=tony.luck@intel.com \
--cc=wei.liu@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®