On Fri, 2013-02-01 at 08:44 +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2013-01-31 at 09:34 -0700, Alex Williamson wrote:
> > > Luckily guests do not seem to be worried as long as we use ACPI.
> >
> > Yes, in fact I just figured out last night that Windows is unhappy with
> > assigned PCI devic
> > Here's a more interesting example:
> >
> > -+-[:01]-+-00.0 NVIDIA Corporation GT218 [GeForce G210M]
> > | \-00.1 NVIDIA Corporation High Definition Audio Controller
> > \-[:00]-+-00.0 Intel Corporation Mobile 4 Series Chipset Memory
> > Controller Hub
> > +
On Fri, Feb 01, 2013 at 08:22:33AM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2013-01-31 at 12:49 +0200, Michael S. Tsirkin wrote:
>
> > OK but this appears behind a bridge. So the bridge configuration tells
> > the root complex where to send accesses to the VGA.
>
> Sort-of, again the root
On Thu, Jan 31, 2013 at 02:21:50PM -0700, Alex Williamson wrote:
> On Thu, 2013-01-31 at 23:11 +0200, Michael S. Tsirkin wrote:
> > On Thu, Jan 31, 2013 at 09:34:03AM -0700, Alex Williamson wrote:
> > >
> > > On Thu, 2013-01-31 at 12:49 +0200, Michael S. Tsirkin wrote:
> > > > On Wed, Jan 30, 2013
On Thu, 2013-01-31 at 09:34 -0700, Alex Williamson wrote:
> > Luckily guests do not seem to be worried as long as we use ACPI.
>
> Yes, in fact I just figured out last night that Windows is unhappy with
> assigned PCI devices on bus 0 that claim to be an endpoint in their PCIe
> capability rather
On Thu, 2013-01-31 at 12:49 +0200, Michael S. Tsirkin wrote:
> OK but this appears behind a bridge. So the bridge configuration tells
> the root complex where to send accesses to the VGA.
Sort-of, again the root complex isn't "sending" anything targeted here.
PCIe is point to point and any devic
On Thu, 2013-01-31 at 23:11 +0200, Michael S. Tsirkin wrote:
> On Thu, Jan 31, 2013 at 09:34:03AM -0700, Alex Williamson wrote:
> >
> > On Thu, 2013-01-31 at 12:49 +0200, Michael S. Tsirkin wrote:
> > > On Wed, Jan 30, 2013 at 04:28:30PM -0700, Alex Williamson wrote:
> > > > On Thu, 2013-01-31 at
On Thu, Jan 31, 2013 at 09:34:03AM -0700, Alex Williamson wrote:
>
> On Thu, 2013-01-31 at 12:49 +0200, Michael S. Tsirkin wrote:
> > On Wed, Jan 30, 2013 at 04:28:30PM -0700, Alex Williamson wrote:
> > > On Thu, 2013-01-31 at 10:02 +1100, Benjamin Herrenschmidt wrote:
> > > > On Thu, 2013-01-31 a
On Thu, 2013-01-31 at 12:49 +0200, Michael S. Tsirkin wrote:
> On Wed, Jan 30, 2013 at 04:28:30PM -0700, Alex Williamson wrote:
> > On Thu, 2013-01-31 at 10:02 +1100, Benjamin Herrenschmidt wrote:
> > > On Thu, 2013-01-31 at 00:49 +0200, Michael S. Tsirkin wrote:
> > > > > In practice they do (VGA
On Wed, Jan 30, 2013 at 04:28:30PM -0700, Alex Williamson wrote:
> On Thu, 2013-01-31 at 10:02 +1100, Benjamin Herrenschmidt wrote:
> > On Thu, 2013-01-31 at 00:49 +0200, Michael S. Tsirkin wrote:
> > > > In practice they do (VGA at least)
> > > >
> > > > >From a SW modelling standpoint, I don't t
On Thu, 2013-01-31 at 10:02 +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2013-01-31 at 00:49 +0200, Michael S. Tsirkin wrote:
> > > In practice they do (VGA at least)
> > >
> > > >From a SW modelling standpoint, I don't think it's worth
> > differentiating
> > > PCI and PCIE.
> > >
> > > Cheers
On Thu, 2013-01-31 at 00:49 +0200, Michael S. Tsirkin wrote:
> > In practice they do (VGA at least)
> >
> > >From a SW modelling standpoint, I don't think it's worth
> differentiating
> > PCI and PCIE.
> >
> > Cheers,
> > Ben.
>
> Interesting.
> Do you have such hardware? Could you please dump
>
On Thu, Jan 31, 2013 at 09:32:05AM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2013-01-31 at 00:20 +0200, Michael S. Tsirkin wrote:
> >
> > Well you can have a PCI bridge and a legacy device behind that.
> > I think real PCI express devices can not be mapped onto legacy address
> > ranges.
>
>
On Thu, 2013-01-31 at 00:20 +0200, Michael S. Tsirkin wrote:
>
> Well you can have a PCI bridge and a legacy device behind that.
> I think real PCI express devices can not be mapped onto legacy address
> ranges.
In practice they do (VGA at least)
>From a SW modelling standpoint, I don't think it
On Wed, Jan 30, 2013 at 03:39:34PM -0600, Anthony Liguori wrote:
> Benjamin Herrenschmidt writes:
>
> > On Wed, 2013-01-30 at 07:59 -0600, Anthony Liguori wrote:
> >> An x86 CPU has a MMIO capability that's essentially 65 bits. Whether
> >> the top bit is set determines whether it's a "PIO" tran
On Wed, 2013-01-30 at 15:39 -0600, Anthony Liguori wrote:
> Benjamin Herrenschmidt writes:
> > There also exists P2P bridges doing such substractive
> > decoding, this used to be fairly common with transparent bridges used for
> > laptop docking.
>
> I'm not sure I understand how this would work
Benjamin Herrenschmidt writes:
> On Wed, 2013-01-30 at 17:54 +0100, Andreas Färber wrote:
>>
>> That would require polymorphism since we already need to derive from
>> PCIDevice or ISADevice respectively for interfacing with the bus...
>> Modern object-oriented languages have tried to avoid mult
Benjamin Herrenschmidt writes:
> On Wed, 2013-01-30 at 07:59 -0600, Anthony Liguori wrote:
>> An x86 CPU has a MMIO capability that's essentially 65 bits. Whether
>> the top bit is set determines whether it's a "PIO" transaction or an
>> "MMIO" transaction. A large chunk of that address space i
On Wed, 2013-01-30 at 18:08 +0100, Paolo Bonzini wrote:
> > Make VGACommonState a proper QOM object and use it as the base class
> for
> > QXL, CirrusVGA, QEMUVGA (std-vga), and VMwareVGA.
>
> I think QXL should have-a VGA rather than being one. It completely
> bypasses the VGA infrastructure if
On Wed, 2013-01-30 at 17:54 +0100, Andreas Färber wrote:
>
> That would require polymorphism since we already need to derive from
> PCIDevice or ISADevice respectively for interfacing with the bus...
> Modern object-oriented languages have tried to avoid multi-inheritence
> due to arising complica
On Wed, 2013-01-30 at 07:59 -0600, Anthony Liguori wrote:
> An x86 CPU has a MMIO capability that's essentially 65 bits. Whether
> the top bit is set determines whether it's a "PIO" transaction or an
> "MMIO" transaction. A large chunk of that address space is invalid of
> course.
>
> PCI has a
On Wed, Jan 30, 2013 at 09:33:05PM +0100, Andreas Färber wrote:
> Am 30.01.2013 21:20, schrieb Michael S. Tsirkin:
> > On Wed, Jan 30, 2013 at 06:55:47PM +0100, Andreas Färber wrote:
> >> Am 30.01.2013 12:48, schrieb Peter Maydell:
> >>> On 30 January 2013 11:39, Andreas Färber wrote:
> Propo
Am 30.01.2013 21:20, schrieb Michael S. Tsirkin:
> On Wed, Jan 30, 2013 at 06:55:47PM +0100, Andreas Färber wrote:
>> Am 30.01.2013 12:48, schrieb Peter Maydell:
>>> On 30 January 2013 11:39, Andreas Färber wrote:
Proposal by hpoussin was to move _list_add() code to ISADevice:
http://lis
Am 30.01.2013 18:29, schrieb Anthony Liguori:
> Andreas Färber writes:
>
>> Am 30.01.2013 17:33, schrieb Anthony Liguori:
>>> Gerd Hoffmann writes:
>>>
> hw/qxl.c:portio_list_add(qxl_vga_port_list,
> pci_address_space_io(dev), 0x3b0);
> hw/vga.c:portio_list_add(vga_port_l
On 30 January 2013 20:08, Michael S. Tsirkin wrote:
> Anthony wrote:
>> Nope. You can use composition:
>>
>> QXLDevice is-a VGACommonState
>>
>> QXLPCI is-a PCIDevice
>>has-a QXLDevice
>
> But why like this?
> The distinction is artificial, isn't it?
I think it's the wrong way round. QXL
On Wed, Jan 30, 2013 at 06:55:47PM +0100, Andreas Färber wrote:
> Am 30.01.2013 12:48, schrieb Peter Maydell:
> > On 30 January 2013 11:39, Andreas Färber wrote:
> >> Proposal by hpoussin was to move _list_add() code to ISADevice:
> >> http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg00508.
On Wed, Jan 30, 2013 at 11:29:58AM -0600, Anthony Liguori wrote:
> Andreas Färber writes:
>
> > Am 30.01.2013 17:33, schrieb Anthony Liguori:
> >> Gerd Hoffmann writes:
> >>
> hw/qxl.c:portio_list_add(qxl_vga_port_list,
> pci_address_space_io(dev), 0x3b0);
> hw/vga.c:
Hi,
> hw/qxl.c:portio_list_add(qxl_vga_port_list,
> pci_address_space_io(dev), 0x3b0);
> hw/vga.c:portio_list_add(vga_port_list, address_space_io, 0x3b0);
That reminds me I should solve this in a more elegant way.
qxl takes over the vga io ports. The reason it does this is because
Am 30.01.2013 12:48, schrieb Peter Maydell:
> On 30 January 2013 11:39, Andreas Färber wrote:
>> Proposal by hpoussin was to move _list_add() code to ISADevice:
>> http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg00508.html
>>
>> Concerns:
>> * PCI devices (VGA, QXL) register I/O ports as w
Andreas Färber writes:
> Am 30.01.2013 17:33, schrieb Anthony Liguori:
>> Gerd Hoffmann writes:
>>
hw/qxl.c:portio_list_add(qxl_vga_port_list,
pci_address_space_io(dev), 0x3b0);
hw/vga.c:portio_list_add(vga_port_list, address_space_io, 0x3b0);
>>>
>>> That reminds me
Il 30/01/2013 17:33, Anthony Liguori ha scritto:
> Gerd Hoffmann writes:
>
>> Hi,
>>
>>> hw/qxl.c:portio_list_add(qxl_vga_port_list,
>>> pci_address_space_io(dev), 0x3b0);
>>> hw/vga.c:portio_list_add(vga_port_list, address_space_io, 0x3b0);
>>
>> That reminds me I should solve this
Am 30.01.2013 17:33, schrieb Anthony Liguori:
> Gerd Hoffmann writes:
>
>>> hw/qxl.c:portio_list_add(qxl_vga_port_list,
>>> pci_address_space_io(dev), 0x3b0);
>>> hw/vga.c:portio_list_add(vga_port_list, address_space_io, 0x3b0);
>>
>> That reminds me I should solve this in a more eleg
Gerd Hoffmann writes:
> Hi,
>
>> hw/qxl.c:portio_list_add(qxl_vga_port_list,
>> pci_address_space_io(dev), 0x3b0);
>> hw/vga.c:portio_list_add(vga_port_list, address_space_io, 0x3b0);
>
> That reminds me I should solve this in a more elegant way.
>
> qxl takes over the vga io ports.
Markus Armbruster writes:
> Peter Maydell writes:
>
>> On 30 January 2013 11:39, Andreas Färber wrote:
>>> Proposal by hpoussin was to move _list_add() code to ISADevice:
>>> http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg00508.html
>>>
>>> Concerns:
>>> * PCI devices (VGA, QXL) regist
On Wed, Jan 30, 2013 at 07:24:57AM -0600, Anthony Liguori wrote:
> "Michael S. Tsirkin" writes:
>
> > On Wed, Jan 30, 2013 at 11:48:14AM +, Peter Maydell wrote:
> >> On 30 January 2013 11:39, Andreas Färber wrote:
> >> > Proposal by hpoussin was to move _list_add() code to ISADevice:
> >> >
Andreas Färber writes:
> Am 29.01.2013 16:41, schrieb Juan Quintela:
>> * Portio port to new memory regions?
>> Andreas, could you fill?
>
> MemoryRegion's .old_portio mechanism requires workarounds for VGA on
> ppc, affecting among others the sPAPR PCI host bridge:
> http://git.qemu.org/?p=qem
"Michael S. Tsirkin" writes:
> On Wed, Jan 30, 2013 at 11:48:14AM +, Peter Maydell wrote:
>> On 30 January 2013 11:39, Andreas Färber wrote:
>> > Proposal by hpoussin was to move _list_add() code to ISADevice:
>> > http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg00508.html
>> >
>> >
Peter Maydell writes:
> On 30 January 2013 11:39, Andreas Färber wrote:
>> Proposal by hpoussin was to move _list_add() code to ISADevice:
>> http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg00508.html
>>
>> Concerns:
>> * PCI devices (VGA, QXL) register I/O ports as well
>> => above pa
On 30.01.2013, at 12:48, Peter Maydell wrote:
> On 30 January 2013 11:39, Andreas Färber wrote:
>> Proposal by hpoussin was to move _list_add() code to ISADevice:
>> http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg00508.html
>>
>> Concerns:
>> * PCI devices (VGA, QXL) register I/O ports
On Wed, Jan 30, 2013 at 11:48:14AM +, Peter Maydell wrote:
> On 30 January 2013 11:39, Andreas Färber wrote:
> > Proposal by hpoussin was to move _list_add() code to ISADevice:
> > http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg00508.html
> >
> > Concerns:
> > * PCI devices (VGA, QXL)
On 30 January 2013 11:39, Andreas Färber wrote:
> Proposal by hpoussin was to move _list_add() code to ISADevice:
> http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg00508.html
>
> Concerns:
> * PCI devices (VGA, QXL) register I/O ports as well
> => above patches add dependency on ISABus t
Am 29.01.2013 16:41, schrieb Juan Quintela:
> * Portio port to new memory regions?
> Andreas, could you fill?
MemoryRegion's .old_portio mechanism requires workarounds for VGA on
ppc, affecting among others the sPAPR PCI host bridge:
http://git.qemu.org/?p=qemu.git;a=commit;h=a3cfa18eb075c7ef783
42 matches
Mail list logo
