linux-kernel - Re: [PATCH v2] xen: Add support for XenServer 6.1 platform device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CACHz=ZjurD-dvVOnOCJv4q02UV4iy78J5hJ8rMh1UPAZBbfaXQ@mail.gmail.com>
Date: Fri, 7 Mar 2025 11:14:52 +0000
From: Frediano Ziglio <frediano.ziglio@...ud.com>
To: Roger Pau Monné <roger.pau@...rix.com>
Cc: Andrew Cooper <andrew.cooper3@...rix.com>, xen-devel@...ts.xenproject.org, 
	linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org, 
	Juergen Gross <jgross@...e.com>, Stefano Stabellini <sstabellini@...nel.org>, 
	Oleksandr Tyshchenko <oleksandr_tyshchenko@...m.com>, Bjorn Helgaas <bhelgaas@...gle.com>
Subject: Re: [PATCH v2] xen: Add support for XenServer 6.1 platform device

Hi,
   after all discussions on this thread and Xen-devel, can we agree
that this patch is good as it is and can be merged upstream?
Just to make it clear, it was already acked.

Regards,
   Frediano

On Fri, Feb 28, 2025 at 12:37 PM Roger Pau Monné <roger.pau@...rix.com> wrote:
>
> On Thu, Feb 27, 2025 at 03:41:54PM +0000, Andrew Cooper wrote:
> > On 27/02/2025 2:50 pm, Frediano Ziglio wrote:
> > > On XenServer on Windows machine a platform device with ID 2 instead of
> > > 1 is used.
> > >
> > > This device is mainly identical to device 1 but due to some Windows
> > > update behaviour it was decided to use a device with a different ID.
> > >
> > > This causes compatibility issues with Linux which expects, if Xen
> > > is detected, to find a Xen platform device (5853:0001) otherwise code
> > > will crash due to some missing initialization (specifically grant
> > > tables). Specifically from dmesg
> > >
> > >     RIP: 0010:gnttab_expand+0x29/0x210
> > >     Code: 90 0f 1f 44 00 00 55 31 d2 48 89 e5 41 57 41 56 41 55 41 89 fd
> > >           41 54 53 48 83 ec 10 48 8b 05 7e 9a 49 02 44 8b 35 a7 9a 49 02
> > >           <8b> 48 04 8d 44 39 ff f7 f1 45 8d 24 06 89 c3 e8 43 fe ff ff
> > >           44 39
> > >     RSP: 0000:ffffba34c01fbc88 EFLAGS: 00010086
>
> I think the back trace might be more helpful here rather than the raw
> code?
>
> Not sure if it helps, but there's a document in upstream Xen
> repository that lists the IDs:
>
> https://xenbits.xen.org/docs/unstable/man/xen-pci-device-reservations.7.html
>
> It would be good to record the information you have gathered about the
> different devices somewhere.  Maybe xen-pci-device-reservations would
> be a good place to list the intended usage of those device IDs, as
> right now it just lists the allocated ranges, but no information about
> what's the purpose of each device.
>
> > >     ...
> > >
> > > The device 2 is presented by Xapi adding device specification to
> > > Qemu command line.
> > >
> > > Signed-off-by: Frediano Ziglio <frediano.ziglio@...ud.com>
> >
> > I'm split about this.  It's just papering over the bugs that exist
> > elsewhere in the Xen initialisation code.
> >
> > But, if we're going to take this approach, then 0xc000 needs adding too,
> > which is the other device ID you might find when trying to boot Linux in
> > a VM configured using a Windows template.
>
> Won't adding 0xc000 cause issues?  As then the xenpci driver will bind
> to two devices on the same system (either 0001 or 0002, and
> additionally c000).  As it's my understanding that the device with ID
> c000 will be present in conjunction with either a device with ID 0001
> or 0002.
>
> Thanks, Roger.