Xen devel - Feb 2009 - [PATCH 2/3] ioemu: add libpci fixup to handle recent change in PCIUtils

Hi Yu,

What were the changes in libutils that triggered this patch?

I''ve been trying to get a domu guest to correctly use a passed through
VGA card, and noticed that some IO mappings are not as what the driver
in the guest expects to see. For example, one of the I/O range starts
from C000h. After the fixup, it was changed to C200h. I''m suspecting
this causes the guest driver not to work correctly, although there may
be other reasons. What do you think?

Thanks. :)

-Alex

Date: Sat, 24 Jan 2009 12:47:09 +0800
From: Yu Zhao <yu.zhao@intel.com>
Subject: [Xen-devel] [PATCH 2/3] ioemu: add libpci fixup to handle
       recent  change in PCIUtils
To: xen-devel@lists.xensource.com
Cc: Yu Zhao <yu.zhao@intel.com>
Message-ID: <1232772430-11079-2-git-send-email-yu.zhao@intel.com>

The following commit of PCIUtils changes what ''base_addr''
contains.
Add a fixup to make sure the pass-through works when building against
different versions of PCIUtils.

 commit 6d143c3283855c474445a3cf27c65280ed7ab1b7
 Author: Yu Zhao <yu.zhao@intel.com>
 Date:   Fri Dec 26 09:59:28 2008 +0800

   Fix base address flags when using sysfs method

   The base address flags are ignored when using sysfs method, while
   the proc and generic methods combined the flags into
''base_addr''.
   This inconsistency may fail some applications using libpci.

Signed-off-by: Yu Zhao <yu.zhao@intel.com>
---
=== deprecated ==
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, Feb 27, 2009 at 01:03:44PM +0800, Alexia Benington
wrote:
> Hi Yu,
> 
> What were the changes in libutils that triggered this patch?
> 
> I''ve been trying to get a domu guest to correctly use a passed
through
> VGA card, and noticed that some IO mappings are not as what the driver
> in the guest expects to see. For example, one of the I/O range starts
> from C000h. After the fixup, it was changed to C200h. I''m
suspecting
> this causes the guest driver not to work correctly, although there may
> be other reasons. What do you think?
The old libpci doesn''t provide BAR flags in
`pci_dev->base_addr'' when
using sysfs method. This is inconsistent with what it does when using
proc or direct I/O access method. The fix of libpci makes the BAR flags
combined into `base_addr'', which impacts applications (like Xen Qemu)
using `base_addr'' without masking the flags. That''s why the
fix triggered
the patch you mentioned.

Can you please grab some logs?

cat /sys/bus/pci/devices/xx:xx.x/resource
lspci -s xx:xx.x -vvv
Qemu log under /var/log/xen/qemu-dm-xxx

I''ll try to figure out what happened to your I/O mapping.

Thanks,
Yu

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi,

Apologies for the delay. I was trying to trace through the mappings
myself. It seems the incorrect mappings are not necessarily due to
this patch, but I''m still unable to figure out why there''s a
misalignment in the port mapping.

I''ve attached the lspci outputs for the 2 devices I was tinkering
with, although it was mostly 01:00.0. There''s also an lspci-like
output in the Windows guest for reference.

I also noticed that some of the registers are being emulated rather
than passed through. I''m wondering if this will affect the
functionality of the device in the guest.

By the way, is there any good way to step through qemu-dm instead of
looking at the log? The log helps experienced Xen developers
understand what''s wrong with the system, but its quite challenging for
a beginner, like myself, in understanding Xen implementation. If
anyone prefers, I can start another thread on this.

Thanks. :)

-Alex

On Fri, Feb 27, 2009 at 1:58 AM, Yu Zhao <yu.zhao@intel.com>
wrote:
> On Fri, Feb 27, 2009 at 01:03:44PM +0800, Alexia Benington wrote:
>> Hi Yu,
>>
>> What were the changes in libutils that triggered this patch?
>>
>> I''ve been trying to get a domu guest to correctly use a passed
through
>> VGA card, and noticed that some IO mappings are not as what the driver
>> in the guest expects to see. For example, one of the I/O range starts
>> from C000h. After the fixup, it was changed to C200h. I''m
suspecting
>> this causes the guest driver not to work correctly, although there may
>> be other reasons. What do you think?
>
> The old libpci doesn''t provide BAR flags in
`pci_dev->base_addr'' when
> using sysfs method. This is inconsistent with what it does when using
> proc or direct I/O access method. The fix of libpci makes the BAR flags
> combined into `base_addr'', which impacts applications (like Xen
Qemu)
> using `base_addr'' without masking the flags. That''s why
the fix triggered
> the patch you mentioned.
>
> Can you please grab some logs?
>
> cat /sys/bus/pci/devices/xx:xx.x/resource
> lspci -s xx:xx.x -vvv
> Qemu log under /var/log/xen/qemu-dm-xxx
>
> I''ll try to figure out what happened to your I/O mapping.
>
> Thanks,
> Yu
>





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Sat, Feb 28, 2009 at 07:12:38PM +0800, Alexia Benington
wrote:
> Hi,
> 
> Apologies for the delay. I was trying to trace through the mappings
> myself. It seems the incorrect mappings are not necessarily due to
> this patch, but I''m still unable to figure out why
there''s a
> misalignment in the port mapping.
According to the Qemu log, the I/O region of 01:00.0 has PIO address
0xc000 in the dom0, which is the host physical address (i.e. the value
in the device BAR). And the 0xc200 is guest physical address emulated
by Qemu by creating P2M mapping via hypercall. The `passthrough''
doesn''t
mean guest really can change PCI config space of device. Actually Qemu
emulates most of CSRs :-)

HPA of a BAR is not changed during device passthrough while GPA can
be any value programmed by guest firmware and OS. The 0xc200 was
allocated by guest BIOS and is size aligned (256 byte aligned).
So there is nothing wrong with it.
> I''ve attached the lspci outputs for the 2 devices I was tinkering
> with, although it was mostly 01:00.0. There''s also an lspci-like
> output in the Windows guest for reference.
> 
> I also noticed that some of the registers are being emulated rather
> than passed through. I''m wondering if this will affect the
> functionality of the device in the guest.
Yes, we can''t let guest directly access some CSRs due to architectural
and security reasons. Some devices aren''t able to work due to this.
For example, legacy IDE controller using fixed PIO address won''t work
if PIO address seen by guest is not equal to that fixed address.
But I''m not sure if it is the case of your VGA card. IIRC, someone
did successfully assign VGA card to guest. Maybe you could find some
clue by digging archive of this mailing list.

And I''ll try to find a some VGA card same as yours and do some debug.
I''ll keep you posted if I get some luck.
> By the way, is there any good way to step through qemu-dm instead of
> looking at the log? The log helps experienced Xen developers
> understand what''s wrong with the system, but its quite challenging
for
> a beginner, like myself, in understanding Xen implementation. If
> anyone prefers, I can start another thread on this.
Yes, the log is not so friendly. Any effort on improving it is appreciated!

Thanks,
Yu

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel