qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH] PCI: Introduce INTx check & mask API


From: Benjamin Herrenschmidt
Subject: Re: [Qemu-devel] [RFC PATCH] PCI: Introduce INTx check & mask API
Date: Tue, 05 Jun 2012 11:39:33 +1000

> Yep, that's what I'd suggest as well, add a blacklist to
> pci_intx_mask_supported() so this device returns false and we require an
> exclusive interrupt for it.  Thanks,

BTW, we should consider supporting an MSI-only option for guests as
well:

LSIs are a problem for virtualization, especially when we start
having things like expander racks with slots behind bridges etc, and
in some case it's better to support an MSI only setup rather than
not support the virtualizing the devices at all (or at least in
different partitions).

However, to do that, we either need to ensure the device can't be
coerced by SW to still assert the LSI and cause trouble. This can be
dealt with two ways I have in mind:

 - If we don't use any of those 4 interrupts lines at all (ie, we use no
LSI on the host bridge and they aren't shared with another bridge
etc...), we can just mask them out in the main PIC. On Power there's no
sharing between interrupt sources from different host bridges so that
would work for us

 - If the intermediary P2P bridge has a feature to block incoming LSIs
from children (I've heard that exists, is that standard ? I haven't
looked in the latest specs)

There's a third one:

 - If you trust the device own mask bit

 ... But this is fishy since many devices -will- have some kind of
backdoor via MMIO to bypass (or alter) the config space setting. In some
cases the driver can even completely replace the firmware inside the
device and do pretty much whatever it wants :-)

The main thing is how do we "represent" both in term of interface to
qemu and qemu -> kernel interface wanting such a "no LSI" setup... not
sure about that one.

Cheers,
Ben.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]