Re: [Xen-devel] Some Xen pci-passthrough questions

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 10/26/2017 04:48 PM, Sander Eikelenboom wrote:
> Hi Boris / Andrew,
>
> In the aftermath of the linux mmap path I have some questions regarding 
> pci-passthrough:
>
> - Is pci-passthrough in combination with an auto-ballooning dom0 supposed to 
> be a supported combination ?

I thought it is. I haven't done passthrough recently (and can't do it
right now) but I when I did I am pretty sure I was running with
auto-ballooning dom0.

Our production does passthrough but they always run with dom0's memory
limited.

>
>     I have used dom0_maxmem settings for dom0 since ages and that works fine 
> and stable, 
>     but while doing some testing around the linux mmap patch i also thought 
> to try an auto-ballooning dom0.
>
>     That ended up in a crashing PV guest with pci-passthrough and a strange 
> error on two HVM's with pci-passthrough,
>     about vcpu's (while no configurations where changed).
>
>     So if it is supported i probably have some more testing and reporting to 
> do ...
>
>
> - While adding some extra logging and enabling the logging on xen pt in qemu,
>   i wonder if it wouldn't be beneficial to have at least some basic logging 
> permanently enabled ? 
>
> - Enabling the xen pt logging in qemu spit out some things, i wonder if they 
> are normal:
>
>         qemu-system-i386: -serial pty: char device redirected to /dev/pts/16 
> (label serial0)
>         [00:05.0] xen_pt_realize: Assigning real physical device 08:00.0 to 
> devfn 0x28
>         [00:05.0] xen_pt_register_regions: IO region 0 registered 
> (size=0x00002000 base_addr=0xfe1fe000 type: 0x4)
>
>     Are these somehow expected / benign (they also occur when pci passthrough 
> is succesful) ?:
>         [00:05.0] xen_pt_config_reg_init: Offset 0x000e mismatch! 
> Emulated=0x0080, host=0x0000, syncing to 0x0080.
>         [00:05.0] xen_pt_config_reg_init: Offset 0x0010 mismatch! 
> Emulated=0x0000, host=0xfe1fe004, syncing to 0xfe1fe004.
>         [00:05.0] xen_pt_config_reg_init: Offset 0x0052 mismatch! 
> Emulated=0x0000, host=0x4803, syncing to 0x0003.
>         [00:05.0] xen_pt_config_reg_init: Offset 0x0072 mismatch! 
> Emulated=0x0000, host=0x0086, syncing to 0x0080.
>         [00:05.0] xen_pt_config_reg_init: Offset 0x00a4 mismatch! 
> Emulated=0x0000, host=0x8fc0, syncing to 0x8fc0.
>         [00:05.0] xen_pt_config_reg_init: Offset 0x00b2 mismatch! 
> Emulated=0x0000, host=0x1012, syncing to 0x1012.
>
>         [00:05.0] xen_pt_msix_init: get MSI-X table BAR base 0xfe1fe000
>         [00:05.0] xen_pt_msix_init: table_off = 0x1000, total_entries = 8
>         [00:05.0] xen_pt_msix_init: table_off = 0x1000, total_entries = 8, 
> PCI_MSIX_ENTRY_SIZE = 0x10,  msix->table_offset_adjust = 0,  msix->table_base 
> = 0xfe1fe000
>         [00:05.0] xen_pt_msix_init: Error: Can't map physical MSI-X table: 
> Invalid argument

That's mmap() of /dev/mem failing:

mmap(NULL,
             total_entries * PCI_MSIX_ENTRY_SIZE +
msix->table_offset_adjust,
             PROT_READ,
             MAP_SHARED | MAP_LOCKED,
             fd,
             msix->table_base + table_off - msix->table_offset_adjust);


Are you running with Craig Bergstrom's patch?

-boris


>         [00:05.0] xen_pt_msix_size_init: Error: Internal error: Invalid 
> xen_pt_msix_init.
>         Failed to initialize 12/15, type = 0x1, rc: -22
>         [00:05.0] xen_pt_msi_set_enable: disabling MSI.
>
>     This crash seems to indicate the above disabling of MSI isn't handled 
> well enough to prevent this from happening: 
>         *** Error in `/usr/local/lib/xen/bin/qemu-system-i386': corrupted 
> size vs. prev_size: 0x000055ce13565570 ***
>         ======= Backtrace: =========
>         /lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7f700ab7ebcb]
>         /lib/x86_64-linux-gnu/libc.so.6(+0x76f96)[0x7f700ab84f96]
>         <snip>
>
> --
> Sander


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