Alex Williamson wrote: > On Sat, 2012-06-09 at 18:25 +0200, Andreas Hartmann wrote: >> Alex Williamson wrote: >>> On Sat, 2012-06-09 at 11:28 +0200, Andreas Hartmann wrote: >> >> [...] >> >>>> What's the risk of this patch? Machine crash? Data loss for an active >>>> file in an application? Complete filesystem damage? The latter would be >>>> worse. >>> >>> What we're trying to prevent by testing whether devices support ACS is >>> peer-to-peer transactions that would not be translated via the IOMMU. >>> For instance, imagine if your WLAN controller behind 14.4 does a DMA >>> write to an address that happens to be within the MMIO resources of >>> device 14.2, the audio device. >> >> Why should it do that intentionally - I can't see any reason. Remains >> unintentionally. But that's already enough :-) . > > We don't know the internal design of multifunction devices. _peer-to-peer transaction_ My current idea: this transaction is done without the knowledge of the system software at all. Couldn't this happen too, even if there is no VM at all but bare metal? What would be the result in this case? >>> Instead of the transaction going up to >>> the IOMMU and resulting in a memory write, internal routing on device >>> 14.x results in that transaction being redirected to the 14.2. So >>> you're looking at potential data loss from the guest as well as >>> corrupting device state in the host. >> >> My guest does have no data. Besides that, the VM can be easily backuped >> before. >> The corrupting device state probably is limited to the devices behind >> the bridge. Correct? > > No, we're talking about the multifunction device here. A legacy PCI bus > is always susceptible to this as it's a shared bus. Another device on > the bus can claim the transaction. The IOMMU also only has visibility > to the bridge devices, all devices behind it are masked. So the > difference we're looking at is whether 14.4 is grouped with all the > other devices on 14.x or not. Bus 6 will always be grouped with device > 14.4. So then you have to consider what can happen if your guest that > owns 14.4 and bus 6 can corrupt the state of device 14.2 and how that > corrupted state could be propagated out to the host. To make it short: I applied the patch as proposed. I disabled binding / unbinding of 14.2 (Sound), started the VM, started hostapd in the VM (rt2860pci is set to do no hw crypt) and started a netperf session sending data from a client via AP to host and vice versa. At the same time, I started some sound device interaction (only output) onto the host. If there are any problems, I would have expected: - Encryption / decryption of WLAN data would have failed. I couldn't see any errors / warnings at this side. The 4 and 2 way key exchanges worked without any problem. EAP-TLS authentication has been working fine, too, apart from the already known problems. - Distortions on sound output: I couldn't hear any. - Some other malfunction, e.g. on graphics output (fglrx). I couldn't see any problem. These are tests from the point of the view of an user. Do you have any idea to intentionally activate a failure situation? Kind regards, Andreas -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
