[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XEN PATCH] xen/vpci: Fix UB in mask_write



On Mon, Nov 11, 2024 at 12:21:32PM +0000, Mykyta Poturai wrote:
> On 06.11.24 16:57, Roger Pau Monné wrote:
> > 
> > Let's try to figure out what causes msi_maxvec to be 0 in your case
> > and then we can see how to better detect this.  If msi_maxvec needs to
> > be checked it should likely be done in init_msi().
> > 
> > Regards, Roger.
> 
> Hi everyone,
> So I have done some more investigations, and I think it finally makes 
> sense. The real cause of my crashes was a long-standing bug in yet to be 
> upstreamed vpci patches where the register value and offset were swapped 
> by mistake. And this bug was hidden for a long time because mask_write 
> skipped actually doing anything, respecting vectors = 0, so I failed to 
> spot it from the get-go.
> 
> Regarding msi_maxvec there seems to be an implicit dependency between 
> CONFIG_HAS_VPCI and CONFIG_HAS_PCI_MSI. If HAS_PCI_MSI=n, then 
> pdev_msi_init gets replaced with a stub and msi_maxvec remains 0, but it 
> is still used in control_write unconditionally.

Hello,

If HAS_PCI_MSI=n then vPCI shouldn't attempt to handle the MSI(-X)
capabilities in the first place.  However that can lead to incorrect
scenarios if vPCI is used for dom0, as vPCI not supporting MSI(-X)
grants dom0 unmediated access to the capability registers, which won't
result in a functional system at least on x86.

I think the more robust solution is for vPCI to require
HAS_PCI_MSI=y.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.