qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] pci: add standard bridge device


From: Wen Congyang
Subject: Re: [Qemu-devel] [PATCH] pci: add standard bridge device
Date: Fri, 02 Sep 2011 09:32:24 +0800
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100413 Fedora/3.0.4-2.fc13 Thunderbird/3.0.4

At 08/22/2011 02:23 PM, Avi Kivity Write:
> On 08/22/2011 06:13 AM, Wen Congyang wrote:
>> At 08/19/2011 11:26 PM, Avi Kivity Write:
>> >  On 08/18/2011 10:12 PM, Wen Congyang wrote:
>> >>  >>
>> >>  >>   The following patch can fix this problem, but I'm not sure
>> whether it
>> >>  >>   is right.
>> >>  >
>> >>  >   It's correct but insufficient, the filtering code
>> (pci_bridge_filter)
>> >>  >   needs to be updated to use the memory API.
>> >>
>> >>  I read the function pci_bridge_filter(), and the function only read
>> >>  PCI bridge's config space(command, base and limit). If base>   limit,
>> >>  it will set addr to PCI_BAR_UNMAPPED.
>> >>
>> >>  I do not find anything that needs to updated to use the memory API.
>> >
>> >  Currently it doesn't do any filtering at all.  Bridges need to
>> create a
>> >  new address space, then attach aliases of this region
>> (corresponding to
>> >  the filtered area and to the legacy vga space) to the parent bus'
>> >  address space.
>>
>> Hmm, does this problem exist before memory API is introduced?
> 
> Yes.  There was code to handle it, but I don't think it was correct.
> 
>>
>> >
>> >>  I add a scsi controller on pci bus1, and a scsi disk on this
>> controller.
>> >>  I can read and write this disk, and I do not meet any problem.
>> >>
>> >
>> >  However, filtering doesn't work.  You could put a BAR outside the
>> >  filtered area and it would be visible to the guest.
>>
>> How to put a BAR outside the filtered area and confirm whether it
>> would be
>> virible to the guest?
>>
>>
> 
> 
> You could use something like kvm-unit-tests.git to write a simple test
> that sets up a BAR (say from hw/ivshmem.c), writes and reads to see that
> it is visible, programs the bridge to filter part of the BAR out, then
> writes and reads again to verify that the correct part is filtered out.
> 

I test it with rtl8139(Because I have a such real hardware).
I add some fprintf in the callback function: rtl8139_mmio_writeb(),
rtl8139_mmio_writel(), rtl8139_mmio_writew(), rtl8139_mmio_readb(),
rtl8139_mmio_readw(), rtl8139_mmio_readl().
My test way:
1. unbind the device from rtl8139 driver
2. modify the BAR
3. reprobe the device

If the BAR is visible, the OS will access it when we reprobe the device.
If the BAR is not visible, the OS will access it.
I can not reprobe the real device if the BAR is not visible. But I can
reprobe the virtual device if the BAR is not visible.

Thanks
Wen Congyang




reply via email to

[Prev in Thread] Current Thread [Next in Thread]