All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael Kelley (LINUX)" <mikelley@microsoft.com>
To: Borislav Petkov <bp@alien8.de>
Cc: "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>,
	"seanjc@google.com" <seanjc@google.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 v6 06/13] x86/hyperv: Change vTOM handling to use standard coco mechanisms
Date: Fri, 24 Mar 2023 19:36:02 +0000	[thread overview]
Message-ID: <BYAPR21MB16886692DF02269DE1D0C4A5D7849@BYAPR21MB1688.namprd21.prod.outlook.com> (raw)
In-Reply-To: <20230324154856.GDZB3GaHG/3L0Q1x47@fat_crate.local>

From: Borislav Petkov <bp@alien8.de> Sent: Friday, March 24, 2023 8:49 AM
> 
> On Thu, Mar 23, 2023 at 02:43:06PM +0100, Borislav Petkov wrote:
> > Ok, lemme queue 1-2,4-6 as previously mentioned.
> 
> With first six applied:
> 
> arch/x86/coco/core.c:123:7: error: use of undeclared identifier 'sev_status'
>                 if (sev_status & MSR_AMD64_SNP_VTOM)
>                     ^
> arch/x86/coco/core.c:139:7: error: use of undeclared identifier 'sev_status'
>                 if (sev_status & MSR_AMD64_SNP_VTOM)
>                     ^
> 2 errors generated.
> make[3]: *** [scripts/Makefile.build:252: arch/x86/coco/core.o] Error 1
> make[2]: *** [scripts/Makefile.build:494: arch/x86/coco] Error 2
> make[1]: *** [scripts/Makefile.build:494: arch/x86] Error 2
> make[1]: *** Waiting for unfinished jobs....
> make: *** [Makefile:2025: .] Error 2
> 
> compiler is:
> 
> Debian clang version 14.0.6-2
> Target: x86_64-pc-linux-gnu
> Thread model: posix
> InstalledDir: /usr/bin
> 
> .config is attached.
> 

OK, I see what went wrong.  I had tested with CONFIG_AMD_MEM_ENCRYPT=n
and didn't see any compile problems.  It turns out in my test, arch/x86/coco/core.c
wasn't built at all because I did not also have TDX configured, so I didn't see
any errors.  But with CONFIG_INTEL_TDX_GUEST=y, coco/core.c gets built, and
the error with undefined sev_status pops out.

The straightforward fix is somewhat ugly.  That's to put #ifdef
CONFIG_AMD_MEM_ENCRYPT around the entire CC_VENDOR_AMD
case in cc_mkenc() and in cc_mkdec().  Or put it just around the test of
sev_status.

Perhaps a cleaner way would be to have a "vendor_subtype" variable
declared in arch/x86/coco/core.c and tested instead of sev_status.
That subtype variable would be set from hv_vtom_init(), maybe via
a separate accessor function.  But didn't I recently see a patch that
makes the existing "vendor" variable no longer static?   In that case
just setting vendor_subtype without the accessor function may be
OK.

What's your preference Boris?  I can spin a v7 of the patch series
that fixes this, and that squashes the last two patches of the series
per Lorenz Pieralisi's comments.

Michael

  parent reply	other threads:[~2023-03-24 19:36 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-09  2:40 [PATCH v6 00/13] Add PCI pass-thru support to Hyper-V Confidential VMs Michael Kelley
2023-03-09  2:40 ` [PATCH v6 01/13] x86/ioremap: Add hypervisor callback for private MMIO mapping in coco VM Michael Kelley
2023-03-27 20:09   ` [tip: x86/sev] " tip-bot2 for Michael Kelley
2023-03-09  2:40 ` [PATCH v6 02/13] x86/hyperv: Reorder code to facilitate future work Michael Kelley
2023-03-09  2:40 ` [PATCH v6 03/13] Drivers: hv: Explicitly request decrypted in vmap_pfn() calls Michael Kelley
2023-03-09  2:40 ` [PATCH v6 04/13] x86/mm: Handle decryption/re-encryption of bss_decrypted consistently Michael Kelley
2023-03-27 20:09   ` [tip: x86/sev] " tip-bot2 for Michael Kelley
2023-03-09  2:40 ` [PATCH v6 05/13] init: Call mem_encrypt_init() after Hyper-V hypercall init is done Michael Kelley
2023-03-27 20:09   ` [tip: x86/sev] " tip-bot2 for Michael Kelley
2023-03-09  2:40 ` [PATCH v6 06/13] x86/hyperv: Change vTOM handling to use standard coco mechanisms Michael Kelley
2023-03-20 11:22   ` Borislav Petkov
2023-03-20 13:30     ` Michael Kelley (LINUX)
2023-03-20 18:16       ` Borislav Petkov
2023-03-20 18:50         ` Michael Kelley (LINUX)
2023-03-23 13:43           ` Borislav Petkov
2023-03-24 15:48             ` Borislav Petkov
2023-03-24 17:10               ` Dexuan Cui
2023-03-24 17:28                 ` Sathyanarayanan Kuppuswamy
2023-03-24 18:30                 ` Borislav Petkov
2023-03-24 19:36               ` Michael Kelley (LINUX) [this message]
2023-03-25  0:04                 ` Michael Kelley (LINUX)
2023-03-09  2:40 ` [PATCH v6 07/13] swiotlb: Remove bounce buffer remapping for Hyper-V Michael Kelley
2023-03-09  2:40 ` [PATCH v6 08/13] Drivers: hv: vmbus: Remove second mapping of VMBus monitor pages Michael Kelley
2023-03-09  2:40 ` [PATCH v6 09/13] Drivers: hv: vmbus: Remove second way of mapping ring buffers Michael Kelley
2023-03-09  2:40 ` [PATCH v6 10/13] hv_netvsc: Remove second mapping of send and recv buffers Michael Kelley
2023-03-09  2:40 ` [PATCH v6 11/13] Drivers: hv: Don't remap addresses that are above shared_gpa_boundary Michael Kelley
2023-03-09  2:40 ` [PATCH v6 12/13] PCI: hv: Add hypercalls to read/write MMIO space Michael Kelley
2023-03-24 14:48   ` Lorenzo Pieralisi
2023-03-24 15:13     ` Michael Kelley (LINUX)
2023-03-24 15:24       ` Lorenzo Pieralisi
2023-03-09  2:40 ` [PATCH v6 13/13] PCI: hv: Enable PCI pass-thru devices in Confidential VMs Michael Kelley
2023-03-20 11:27 ` [PATCH v6 00/13] Add PCI pass-thru support to Hyper-V " Borislav Petkov

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=BYAPR21MB16886692DF02269DE1D0C4A5D7849@BYAPR21MB1688.namprd21.prod.outlook.com \
    --to=mikelley@microsoft.com \
    --cc=Tianyu.Lan@microsoft.com \
    --cc=ak@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=bp@alien8.de \
    --cc=brijesh.singh@amd.com \
    --cc=dan.j.williams@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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.