Alex Williamson wrote:
> On Fri, 2010-06-18 at 11:16 +0200, Jan Kiszka wrote:
>> Alex Williamson wrote:
>>> On Wed, 2010-06-16 at 10:23 +0200, Markus Armbruster wrote:
Alex Williamson writes:
> On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
Alex proposed to disambiguat
On Fri, 2010-06-18 at 16:03 +0200, Markus Armbruster wrote:
> Alex Williamson writes:
> > On Wed, 2010-06-16 at 10:23 +0200, Markus Armbruster wrote:
> >> Alex Williamson writes:
> >> >
> >> > (A): /i440FX-pcihost/pci.0/e1000.05.0
> >> >
> >> > vs
> >> >
> >> > (B): /pci.0/05.0
> >> >
> >> > (rem
On Fri, 2010-06-18 at 11:16 +0200, Jan Kiszka wrote:
> Alex Williamson wrote:
> > On Wed, 2010-06-16 at 10:23 +0200, Markus Armbruster wrote:
> >> Alex Williamson writes:
> >>
> >>> On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
> >> Alex proposed to disambiguate by adding "identified pr
Markus Armbruster wrote:
> Alex Williamson writes:
>
>> On Wed, 2010-06-16 at 10:23 +0200, Markus Armbruster wrote:
>>> Alex Williamson writes:
>>>
On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
>>> Alex proposed to disambiguate by adding "identified properties of the
>>> imme
Alex Williamson writes:
> On Wed, 2010-06-16 at 10:23 +0200, Markus Armbruster wrote:
>> Alex Williamson writes:
>>
>> > On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
>> >> > > Alex proposed to disambiguate by adding "identified properties of the
>> >> > > immediate parent bus and device
Alex Williamson wrote:
> On Wed, 2010-06-16 at 10:23 +0200, Markus Armbruster wrote:
>> Alex Williamson writes:
>>
>>> On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
>> Alex proposed to disambiguate by adding "identified properties of the
>> immediate parent bus and device" to the pa
On Wed, 2010-06-16 at 10:23 +0200, Markus Armbruster wrote:
> Alex Williamson writes:
>
> > On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
> >> > > Alex proposed to disambiguate by adding "identified properties of the
> >> > > immediate parent bus and device" to the path component. For PCI
Jan Kiszka writes:
> Markus Armbruster wrote:
>> Jan Kiszka writes:
[...]
>>> The format I will propose is "global-ID|/absolute/path", no more
>>> /path/global-ID as this comes with the risk of ambiguity (ID may shadow
>>> bus-local name of a device).
>>
>> Doesn't this break existing usage?
>
Alex Williamson writes:
> On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
>> > > Alex proposed to disambiguate by adding "identified properties of the
>> > > immediate parent bus and device" to the path component. For PCI, these
>> > > are dev.fn. Likewise for any other bus where devices h
On Wed, 2010-06-16 at 02:30 +0100, Paul Brook wrote:
> Transferring the machine description on migration is a separate problem.
>
> Lets say we associate each RAM block with a device. Each ram block also has a
> name. These names distinguish between blocks attached to a given device, but
> need
> > > > > See my comment above, I'm not seeing a sufficient argument about
> > > > > why driver name matching is a false sense of security.
> > > >
> > > > I still say it should be the migration code that checks that both
> > > > vmstate structures are for the same type of device. i.e. if
> > > >
* Paul Brook (p...@codesourcery.com) wrote:
> > * Paul Brook (p...@codesourcery.com) wrote:
> > > > > I find this argument contradictory. The migration code already needs
> > > > > to check whether a device is compatible before it allows migration.
> > > > > The driver name is not sufficient to en
> * Paul Brook (p...@codesourcery.com) wrote:
> > > > I find this argument contradictory. The migration code already needs
> > > > to check whether a device is compatible before it allows migration.
> > > > The driver name is not sufficient to ensure compatibility, so I see
> > > > no benefit in i
* Paul Brook (p...@codesourcery.com) wrote:
> > > I find this argument contradictory. The migration code already needs to
> > > check whether a device is compatible before it allows migration. The
> > > driver name is not sufficient to ensure compatibility, so I see no
> > > benefit in including i
> > I find this argument contradictory. The migration code already needs to
> > check whether a device is compatible before it allows migration. The
> > driver name is not sufficient to ensure compatibility, so I see no
> > benefit in including it in the device address.
>
> See my comment above,
On Wed, 2010-06-16 at 00:01 +0100, Paul Brook wrote:
> > > I find this argument contradictory. The migration code already needs to
> > > check whether a device is compatible before it allows migration. The
> > > driver name is not sufficient to ensure compatibility, so I see no
> > > benefit in in
On Tue, 2010-06-15 at 22:55 +0100, Paul Brook wrote:
> > On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
> > > > > Alex proposed to disambiguate by adding "identified properties of the
> > > > > immediate parent bus and device" to the path component. For PCI,
> > > > > these are dev.fn. Like
> On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
> > > > Alex proposed to disambiguate by adding "identified properties of the
> > > > immediate parent bus and device" to the path component. For PCI,
> > > > these are dev.fn. Likewise for any other bus where devices have
> > > > unambigous
On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
> > > Alex proposed to disambiguate by adding "identified properties of the
> > > immediate parent bus and device" to the path component. For PCI, these
> > > are dev.fn. Likewise for any other bus where devices have unambigous
> > > bus addres
Markus Armbruster wrote:
> Jan Kiszka writes:
>
>> Markus Armbruster wrote:
>>> Jan Kiszka writes:
>>>
Markus Armbruster wrote:
> Paul Brook writes:
>
>> Alex Williamson writes:
>>
>>> On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote:
Could you expla
Markus Armbruster wrote:
> That way, we gain a useful feature, and avoid having an savevm-specific
> "device path" that isn't recognized anywhere else.
Agreed, we should find one solution for all use cases.
>>> I wasn't aware that there was any suggestion of a separate savevm-specific
> > > Every hotplug-capable bus must have a proper addressing scheme, I think
> > > this is a reasonable and achievable requirement. Then we don't need
> > > instance numbers for those buses.
> >
> > What about USB?
>
> USB has useful device addresses (physical ports).
> These aren't used by most
> > Every hotplug-capable bus must have a proper addressing scheme, I think
> > this is a reasonable and achievable requirement. Then we don't need
> > instance numbers for those buses.
>
> What about USB?
USB has useful device addresses (physical ports).
These aren't used by most of the higher-l
Jan Kiszka writes:
> Paul Brook wrote:
Alex proposed to disambiguate by adding "identified properties of the
immediate parent bus and device" to the path component. For PCI, these
are dev.fn. Likewise for any other bus where devices have unambigous
bus address. The driver n
> >> Works for serial, but fails for ISA devices not occupying an address.
> >
> > An ISA device without an IO/MMIO capabilities seems extremely unlikely.
> > What exactly would such a device do?
>
> Inject interrupts via that bus (while exposing registers in some other
> way). The m48t59 seems t
Jan Kiszka writes:
> Markus Armbruster wrote:
>> Jan Kiszka writes:
>>
>>> Markus Armbruster wrote:
Paul Brook writes:
> Alex Williamson writes:
>
>> On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote:
>>> Could you explain why you add "identified properties
Paul Brook wrote:
>> Paul Brook wrote:
>> From user POV, driver names are very handly to address a device
>> intuitively - except for the case you have tones of devices on the
>> same bus that are handled by the same driver. For that case we need
>> to augment the device name with a
> Paul Brook wrote:
> From user POV, driver names are very handly to address a device
> intuitively - except for the case you have tones of devices on the
> same bus that are handled by the same driver. For that case we need
> to augment the device name with a useful per-bus ID,
Paul Brook wrote:
From user POV, driver names are very handly to address a device
intuitively - except for the case you have tones of devices on the same
bus that are handled by the same driver. For that case we need to
augment the device name with a useful per-bus ID, derived f
> >> From user POV, driver names are very handly to address a device
> >> intuitively - except for the case you have tones of devices on the same
> >> bus that are handled by the same driver. For that case we need to
> >> augment the device name with a useful per-bus ID, derived from the bus
> >> a
Markus Armbruster wrote:
> Jan Kiszka writes:
>
>> Markus Armbruster wrote:
>>> Paul Brook writes:
>>>
Alex Williamson writes:
> On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote:
>> Could you explain why you add "identified properties of the immediate
>> parent b
Paul Brook wrote:
>>> Alex proposed to disambiguate by adding "identified properties of the
>>> immediate parent bus and device" to the path component. For PCI, these
>>> are dev.fn. Likewise for any other bus where devices have unambigous
>>> bus address. The driver name carries no information!
Jan Kiszka writes:
> Markus Armbruster wrote:
>> Paul Brook writes:
>>
>>> Alex Williamson writes:
>>>
On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote:
> Could you explain why you add "identified properties of the immediate
> parent bus and device"? They make the resul
> > Alex proposed to disambiguate by adding "identified properties of the
> > immediate parent bus and device" to the path component. For PCI, these
> > are dev.fn. Likewise for any other bus where devices have unambigous
> > bus address. The driver name carries no information!
>
> From user PO
> > In fact what you really want to do is transfer the device tree
> > (including properties), and create the machine from scratch, not load
> > state into a pre-supplied device tree.
>
> Well, I agree, but that's a lot more of an overhaul, and once again
> we're changing the problem.
I think it'
Markus Armbruster wrote:
> Paul Brook writes:
>
>> Alex Williamson writes:
>>
>>> On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote:
Could you explain why you add "identified properties of the immediate
parent bus and device"? They make the result ver much *not* a "dev
p
Paul Brook writes:
> Alex Williamson writes:
>
>> On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote:
>> > Could you explain why you add "identified properties of the immediate
>> > parent bus and device"? They make the result ver much *not* a "dev
>> > path" in the qdev sense...
>>
>>
On Mon, 2010-06-14 at 23:46 +0100, Paul Brook wrote:
> > > > Ok, I can get it down to something like:
> > > >
> > > > /i440FX-pcihost/pci.0/virtio-blk-pci,09.0
> > > >
> > > > The addr on the device is initially a little non-intuitive to me since
> > > > it's a property of the bus, but I guess it
> > > Ok, I can get it down to something like:
> > >
> > > /i440FX-pcihost/pci.0/virtio-blk-pci,09.0
> > >
> > > The addr on the device is initially a little non-intuitive to me since
> > > it's a property of the bus, but I guess it make sense if we think of
> > > that level as slot, which includ
On Mon, 2010-06-14 at 22:43 +0100, Paul Brook wrote:
> > On Mon, 2010-06-14 at 18:49 +0200, Jan Kiszka wrote:
> > > Alex Williamson wrote:
> > Ok, I can get it down to something like:
> >
> > /i440FX-pcihost/pci.0/virtio-blk-pci,09.0
> >
> > The addr on the device is initially a little non-intuit
> On Mon, 2010-06-14 at 18:49 +0200, Jan Kiszka wrote:
> > Alex Williamson wrote:
> > > On Mon, 2010-06-14 at 18:00 +0200, Jan Kiszka wrote:
> > >> And instead of introducing another hierarchy level with the bus
> > >> address, I would also prefer to add this as prefix or suffix to the
> > >> devic
On Mon, 2010-06-14 at 18:49 +0200, Jan Kiszka wrote:
> Alex Williamson wrote:
> > On Mon, 2010-06-14 at 18:00 +0200, Jan Kiszka wrote:
> >> And instead of introducing another hierarchy level with the bus address,
> >> I would also prefer to add this as prefix or suffix to the device name,
> >> e.g
Alex Williamson wrote:
> On Mon, 2010-06-14 at 18:00 +0200, Jan Kiszka wrote:
>> Alex Williamson wrote:
>>> On Mon, 2010-06-14 at 14:09 +0100, Paul Brook wrote:
>>> "/main-system-bus/pci.0,addr=09.0/virtio-blk-pci"
There's a device missing between the main system bus and the pci bus.
>>>
On Mon, 2010-06-14 at 18:00 +0200, Jan Kiszka wrote:
> Alex Williamson wrote:
> > On Mon, 2010-06-14 at 14:09 +0100, Paul Brook wrote:
> > "/main-system-bus/pci.0,addr=09.0/virtio-blk-pci"
> >> There's a device missing between the main system bus and the pci bus.
> >> Should
> >> be somethin
Alex Williamson wrote:
> On Mon, 2010-06-14 at 14:09 +0100, Paul Brook wrote:
> "/main-system-bus/pci.0,addr=09.0/virtio-blk-pci"
>> There's a device missing between the main system bus and the pci bus.
>> Should
>> be something like:
>>
>> /main-system-bus/piix4-pcihost/pci.0/_09.0
>
> Ok,
> On Mon, 2010-06-14 at 14:09 +0100, Paul Brook wrote:
> > > > > "/main-system-bus/pci.0,addr=09.0/virtio-blk-pci"
> >
> > There's a device missing between the main system bus and the pci bus.
> > Should be something like:
> >
> > /main-system-bus/piix4-pcihost/pci.0/_09.0
>
> Ok, I can easily
On Mon, 2010-06-14 at 14:09 +0100, Paul Brook wrote:
> > > > "/main-system-bus/pci.0,addr=09.0/virtio-blk-pci"
>
> There's a device missing between the main system bus and the pci bus. Should
> be something like:
>
> /main-system-bus/piix4-pcihost/pci.0/_09.0
Ok, I can easily come up with:
/S
Alex Williamson wrote:
> On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote:
>> Alex Williamson writes:
>>
>>> qdev_get_dev_path() is intended to be the canonical utility for creating
>>> a string representing the qdev hierarchy of a device. The path consists
>>> of bus and device names a
> > > "/main-system-bus/pci.0,addr=09.0/virtio-blk-pci"
There's a device missing between the main system bus and the pci bus. Should
be something like:
/main-system-bus/piix4-pcihost/pci.0/_09.0
> > Could you explain why you add "identified properties of the immediate
> > parent bus and device
On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote:
> Alex Williamson writes:
>
> > qdev_get_dev_path() is intended to be the canonical utility for creating
> > a string representing the qdev hierarchy of a device. The path consists
> > of bus and device names as well as identified prope
Alex Williamson writes:
> qdev_get_dev_path() is intended to be the canonical utility for creating
> a string representing the qdev hierarchy of a device. The path consists
> of bus and device names as well as identified properties of the immediate
> parent bus and device. This results in strin
qdev_get_dev_path() is intended to be the canonical utility for creating
a string representing the qdev hierarchy of a device. The path consists
of bus and device names as well as identified properties of the immediate
parent bus and device. This results in strings like:
"/main-system-bus/pci.0,
52 matches
Mail list logo
