Andreas Hartmann wrote:
> 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?
I did one more test:
- Set up a sound server (pulseaudio) on the host using the sound device
14.2 for output.
- Configure the WLAN-client to use this sound device as output device.
- The VM is the AP again, configured with rt2800pci hw encryption on or
off
Result:
Again, I didn't face any problem (until now). The machine just worked as
expected. Even after a s2ram/resume cycle (all VM's have been shut down
before).
As I don't need the USB or IDE device, the ISA-bridge or the
SMBus-Controller at all here, the patch should be reducible to
+ { 0x1002, 0x4383, pci_func_supports_acs }, // Sound
+ { 0x1002, 0x4384, pci_func_supports_acs }, // PCI-to-PCI bridge
Would this work, too?
BTW:
Isn't there a deterministic possibility to check if the MF device does
peer-to-peer transfers? It could be a external program, which tells the
user, if the hardware could be used the desired way.
Thanks,
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
