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
Alexander Graf writes:
> On 01/29/2013 04:41 PM, Juan Quintela wrote:
>>Alex will fill this
>
> When using -device, we can not specify an IRQ line to attach to the
> device. This works for some special buses like PCI, but not in the
> generic case. We need it generically for virtio-mmio and
On 01/29/2013 04:41 PM, Juan Quintela wrote:
* Buildbot: discussed on the list (Andreas retired it)
* Replacing select(2) so that we will not hit the 1024 fd_set limit in the
future. (stefan)
Add checks for fd's bigger than 1024? multifunction devices uses lot
of fd's for device.
P
Il 29/01/2013 17:47, Anthony Liguori ha scritto:
> Paolo Bonzini writes:
>
>> Il 29/01/2013 16:41, Juan Quintela ha scritto:
>>> * Replacing select(2) so that we will not hit the 1024 fd_set limit in the
>>> future. (stefan)
>>>
>>> Add checks for fd's bigger than 1024? multifunction devices
Paolo Bonzini writes:
> Il 29/01/2013 16:41, Juan Quintela ha scritto:
>> * Replacing select(2) so that we will not hit the 1024 fd_set limit in the
>> future. (stefan)
>>
>> Add checks for fd's bigger than 1024? multifunction devices uses lot
>> of fd's for device.
>>
>> Portability?
>
Il 29/01/2013 16:41, Juan Quintela ha scritto:
> * Replacing select(2) so that we will not hit the 1024 fd_set limit in the
> future. (stefan)
>
> Add checks for fd's bigger than 1024? multifunction devices uses lot
> of fd's for device.
>
> Portability?
> Use glib? and let it use poll
* Buildbot: discussed on the list (Andreas retired it)
* Replacing select(2) so that we will not hit the 1024 fd_set limit in the
future. (stefan)
Add checks for fd's bigger than 1024? multifunction devices uses lot
of fd's for device.
Portability?
Use glib? and let it use poll under
48 matches
Mail list logo
