[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<SN6PR02MB4157A9D52A882A2109590708D44D2@SN6PR02MB4157.namprd02.prod.outlook.com>
Date: Wed, 23 Oct 2024 18:32:55 +0000
From: Michael Kelley <mhklinux@...look.com>
To: Nuno Das Neves <nunodasneves@...ux.microsoft.com>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>, "netdev@...r.kernel.org"
<netdev@...r.kernel.org>, "linux-pci@...r.kernel.org"
<linux-pci@...r.kernel.org>, "linux-arch@...r.kernel.org"
<linux-arch@...r.kernel.org>, "virtualization@...ts.linux.dev"
<virtualization@...ts.linux.dev>
CC: "kys@...rosoft.com" <kys@...rosoft.com>, "haiyangz@...rosoft.com"
<haiyangz@...rosoft.com>, "wei.liu@...nel.org" <wei.liu@...nel.org>,
"decui@...rosoft.com" <decui@...rosoft.com>, "catalin.marinas@....com"
<catalin.marinas@....com>, "will@...nel.org" <will@...nel.org>,
"luto@...nel.org" <luto@...nel.org>, "tglx@...utronix.de"
<tglx@...utronix.de>, "mingo@...hat.com" <mingo@...hat.com>, "bp@...en8.de"
<bp@...en8.de>, "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
"seanjc@...gle.com" <seanjc@...gle.com>, "pbonzini@...hat.com"
<pbonzini@...hat.com>, "peterz@...radead.org" <peterz@...radead.org>,
"daniel.lezcano@...aro.org" <daniel.lezcano@...aro.org>, "joro@...tes.org"
<joro@...tes.org>, "robin.murphy@....com" <robin.murphy@....com>,
"davem@...emloft.net" <davem@...emloft.net>, "edumazet@...gle.com"
<edumazet@...gle.com>, "kuba@...nel.org" <kuba@...nel.org>,
"pabeni@...hat.com" <pabeni@...hat.com>, "lpieralisi@...nel.org"
<lpieralisi@...nel.org>, "kw@...ux.com" <kw@...ux.com>, "robh@...nel.org"
<robh@...nel.org>, "bhelgaas@...gle.com" <bhelgaas@...gle.com>,
"arnd@...db.de" <arnd@...db.de>, "sgarzare@...hat.com" <sgarzare@...hat.com>,
"jinankjain@...ux.microsoft.com" <jinankjain@...ux.microsoft.com>,
"muminulrussell@...il.com" <muminulrussell@...il.com>,
"skinsburskii@...ux.microsoft.com" <skinsburskii@...ux.microsoft.com>,
"mukeshrathor@...rosoft.com" <mukeshrathor@...rosoft.com>
Subject: RE: [PATCH 0/5] Add new headers for Hyper-V Dom0
From: Nuno Das Neves <nunodasneves@...ux.microsoft.com> Sent: Tuesday, October 22, 2024 5:51 PM
>
> On 10/10/2024 11:21 AM, Michael Kelley wrote:
> >
[snip]
> > Have you considered user space code that uses
> > include/linux/hyperv.h? Which of the two schemes will it use? That code
> > needs to compile correctly on x86 and ARM64 after your changes.
> > User space code includes the separate DPDK project, and some of the
> > tools in the kernel tree under tools/hv. Anything that uses the
> > uio_hv_generic.c driver falls into this category.
> >
> Unless I misunderstand something, the uapi code isn't affected at all
> by this patch set. e.g. the code in tools/hv uses include/uapi/linux/hyperv.h,
> which doesn't include any other Hyper-V headers.
>
> I'm not aware of how the DPDK project uses the Hyper-V definitions, but if it
> is getting headers from uapi it should also be unaffected.
You are right. My mistake. User space code based on uio_hv_generic.c
maps the VMBus ring buffers into user space, and I thought that code
was pulling "struct hv_ring_buffer" from include/linux/hyperv.h file. But
DPDK and the tools/hv code each have their own completely separate
header file with the equivalent of "struct hv_ring_buffer". Duplicating
the ring buffer structure in multiple places probably isn't ideal, but the
decoupling helps in this case. ;-)
>
> > I think there's also user space code that is built for vDSO that might pull
> > in the .h files you are modifying. There are in-progress patches dealing
> > with vDSO include files, such as [1]. My general comment on vDSO
> > is to be careful in making #include file changes that it uses, but I'm
> > not knowledgeable enough on how vDSO is built to give specific
> > guidance. :-(
> >
> Hmm, interesting, looks like it does get used by userspace. The tsc page
> is mapped into userspace in vdso.vma.c, and read in vdso/gettimeofday.h.
>
> That is unexpected for me, since these things aren't in uapi. However I don't
> anticipate a problem. The definitions used haven't changed, just the headers
> they are included from.
>
Fair enough. I don't know enough about vDSO user space to add anything
helpful.
Michael
Powered by blists - more mailing lists