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

Re: [Xen-users] PCI Passthrough - Write-back to unknown field



On Thu, Jul 27, 2017 at 10:36:04AM +0300, Ivan Radevici wrote:
> Hi all!
> 
> 
> I'm trying to passthrough a NI PCI-6025E card from Xen version 4.8.0 (Ubuntu
> 4.8.0-1ubuntu2.2) to HVM Windows 2000. The pass through itself is done
> accordingly to documentation. Guest OS determines the card as unknown PCI
> device. Installing the driver allows to recognize device as Data Acquisition
> Device / PCI-6028E in Windows Device Manager and in NI software. However,
> running tests from NI test panels fails with "The device is not responding
> to the selected base address" (in fact it seems to be "overFlowError" with
> detailed description "Because of system and/or bus-bandwidth limitations,
> the driver could not read data from the device fast enough to keep up with
> the device throughput; the onboard device memory reported an overflow
> error"). QEMU log file contains an error "Write-back to unknown field 0x08
> (partially) inhibited (0x000000), If the device doesn't work, try enabling
> permissive mode (unsafe) and if it helps report the problem to xen-devel".
> Adding permissive=1 to the pci section of the domain configuration file
> makes the error from the QEMU log disappear, but the card itself still can
> not pass the test in the guest system.
> 
> 
> I don't have a deep knowledge in device passthroughing, but as far as I
> understand passthrough means that everything from the virtual machine is
> just passed to the real one. This leads to a conclusion that the main
> trouble is to pass the device to the guest, once device is seen by the guest
> everything should be fine. Am I understanding something wrong?
> 
> The device shows in xl pci-assignable-list in Dom0
> Relevant part from xl dmesg
> 
> 
> (XEN) Initing memory sharing.
> (XEN) Intel VT-d iommu 1 supported page sizes: 4kB.
> (XEN) Intel VT-d iommu 0 supported page sizes: 4kB.
> (XEN) Intel VT-d iommu 2 supported page sizes: 4kB.
> (XEN) Intel VT-d Snoop Control not enabled.
> (XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
> (XEN) Intel VT-d Queued Invalidation not enabled.
> (XEN) Intel VT-d Interrupt Remapping not enabled.
> (XEN) Intel VT-d Posted Interrupt not enabled.
> (XEN) Intel VT-d Shared EPT tables not enabled.
> (XEN) I/O virtualisation enabled
> (XEN)  - Dom0 mode: Relaxed
> (XEN) Interrupt remapping disabled
> 
> 
> Can you help me to solve/debug this issue, please? Any ideas, guesses or
> suggestions are welcome.

I would say that your card generates data faster that what the DomU
can extract, so the buffer gets full.

Have you tried pinning the DomU with the card to specific physical
CPUs, and making sure that no other VM is allowed to run there?

For example, provided your box has 4 physical CPUs, and you would like
to give 2 cpus to Dom0 and 2 cpus to the DomU:

xl vcpu-pin Dom0 0 0
xl vcpu-pin Dom0 1 1

xl vcpu-pin DomU 0 2
xl vcpu-pin DomU 1 3

Note that you should create both Dom0 and DomU with only two vcpus.

Roger.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
https://lists.xen.org/xen-users

 


Rackspace

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