On 08/23/2010 07:02 PM, Anthony Liguori wrote:
On 08/23/2010 10:14 AM, Avi Kivity wrote:
On 08/23/2010 05:47 PM, Anthony Liguori wrote:
Devices can contain references to structs and objects. If a
Device contains a reference to an object, the object should be
stored in a BusState which i
On 08/23/2010 12:36 PM, Markus Armbruster wrote:
Anthony Liguori writes:
On 08/23/2010 10:10 AM, Markus Armbruster wrote:
You lost me. A few messages upthread.
What's the *practical* problem again?
CPU hotplug adds a local APIC to Sysbus but Sysbus does not allow hot plu
Anthony Liguori writes:
> On 08/23/2010 10:10 AM, Markus Armbruster wrote:
>> You lost me. A few messages upthread.
>>
>> What's the *practical* problem again?
>>
>
> CPU hotplug adds a local APIC to Sysbus but Sysbus does not allow hot plug.
>
> I believe the right short term way to fix thi
On 08/23/2010 10:10 AM, Markus Armbruster wrote:
You lost me. A few messages upthread.
What's the *practical* problem again?
CPU hotplug adds a local APIC to Sysbus but Sysbus does not allow hot plug.
I believe the right short term way to fix this is to take the local APIC
off of Sysbus
On 08/23/2010 10:14 AM, Avi Kivity wrote:
On 08/23/2010 05:47 PM, Anthony Liguori wrote:
Devices can contain references to structs and objects. If a Device
contains a reference to an object, the object should be stored in a
BusState which is a container of Devices. Therefore, the object
On 08/23/2010 05:47 PM, Anthony Liguori wrote:
Devices can contain references to structs and objects. If a Device
contains a reference to an object, the object should be stored in a
BusState which is a container of Devices. Therefore, the object
should inherit from Device.
I disagree.
You lost me. A few messages upthread.
What's the *practical* problem again?
On 08/23/2010 05:26 PM, Anthony Liguori wrote:
On 08/23/2010 09:00 AM, Avi Kivity wrote:
On 08/23/2010 04:48 PM, Anthony Liguori wrote:
The fundamental issue is: every function (minus trivial ones) in
the device models code should have a state reference. That state
reference should inherit
On 08/23/2010 09:32 AM, Avi Kivity wrote:
Is bad? The answer would depend on whether OtherState implemented
methods or not. If OtherState has no methods, it's fine. If it has
methods, it's bad.
I don't see why. As long as you can manipulate all of MyDevice's
state via MyDeviceState metho
On 08/23/2010 09:00 AM, Avi Kivity wrote:
On 08/23/2010 04:48 PM, Anthony Liguori wrote:
The fundamental issue is: every function (minus trivial ones) in
the device models code should have a state reference. That state
reference should inherit from a DeviceState. If this statement
isn't tru
On 08/23/2010 04:48 PM, Anthony Liguori wrote:
The fundamental issue is: every function (minus trivial ones) in the
device models code should have a state reference. That state
reference should inherit from a DeviceState. If this statement
isn't true, then the device has been modelled in qde
On 08/23/2010 08:42 AM, Avi Kivity wrote:
GPIO is just one way for a device to talk, same as
(*bus)_phys_memory_rw() or its netdev or its chardev or its timers.
It doesn't need to have special status within DeviceState, but it
doesn't hurt so much that I can tell.
Everything extra hurts when
On 08/23/2010 04:23 PM, Anthony Liguori wrote:
This is really a fundamental discussion. If you look closely at
qdev in it's current form, what it actually models is a device with
GPIO input and output whereas the GPIO input and output correspond
to qemu_irqs which really model pins that can b
On 08/23/2010 12:46 AM, Avi Kivity wrote:
On 08/23/2010 12:02 AM, Anthony Liguori wrote:
On 08/22/2010 03:28 PM, Avi Kivity wrote:
On 08/20/2010 09:38 PM, Anthony Liguori wrote:
While that might be useful, I don't quite see what makes CPUs so
special
that they need to be kept out of qdev. C
On 08/23/2010 12:07 AM, Anthony Liguori wrote:
On 08/22/2010 02:44 PM, Avi Kivity wrote:
No more MI diamond and all devices have DeviceStates.
Coincidentally, it matches more closely how hardware works..
Well, I agree, but I honestly lost the context. How does this relate
to the APIC an
On 08/23/2010 12:06 AM, Anthony Liguori wrote:
On 08/22/2010 03:33 PM, Avi Kivity wrote:
On 08/22/2010 11:03 PM, Anthony Liguori wrote:
On 08/22/2010 02:44 PM, Avi Kivity wrote:
No more MI diamond and all devices have DeviceStates.
Coincidentally, it matches more closely how hardware works.
On 08/23/2010 12:02 AM, Anthony Liguori wrote:
On 08/22/2010 03:28 PM, Avi Kivity wrote:
On 08/20/2010 09:38 PM, Anthony Liguori wrote:
While that might be useful, I don't quite see what makes CPUs so
special
that they need to be kept out of qdev. Could be just my ignorance, of
course.
CP
On 08/20/2010 09:38 PM, Anthony Liguori wrote:
While that might be useful, I don't quite see what makes CPUs so special
that they need to be kept out of qdev. Could be just my ignorance, of
course.
CPUs have special relationships with things like memory in QEMU. You
can argue that a device
On 08/22/2010 02:44 PM, Avi Kivity wrote:
No more MI diamond and all devices have DeviceStates.
Coincidentally, it matches more closely how hardware works..
Well, I agree, but I honestly lost the context. How does this relate
to the APIC and cpu hotplug?
I'll take the opportunity to say
On 08/22/2010 03:33 PM, Avi Kivity wrote:
On 08/22/2010 11:03 PM, Anthony Liguori wrote:
On 08/22/2010 02:44 PM, Avi Kivity wrote:
No more MI diamond and all devices have DeviceStates.
Coincidentally, it matches more closely how hardware works..
Well, I agree, but I honestly lost the con
On 08/22/2010 11:03 PM, Anthony Liguori wrote:
On 08/22/2010 02:44 PM, Avi Kivity wrote:
No more MI diamond and all devices have DeviceStates.
Coincidentally, it matches more closely how hardware works..
Well, I agree, but I honestly lost the context. How does this relate
to the APIC an
On 08/22/2010 03:28 PM, Avi Kivity wrote:
On 08/20/2010 09:38 PM, Anthony Liguori wrote:
While that might be useful, I don't quite see what makes CPUs so
special
that they need to be kept out of qdev. Could be just my ignorance, of
course.
CPUs have special relationships with things like me
On 08/22/2010 09:52 PM, Anthony Liguori wrote:
So really, I think this suggests that some devices shouldn't have
any requirement to sit on a bus. A UART16650A does not sit on bus.
It sits on a card and is wired to the ISA bus or is sometimes wired
directly to pins on a CPU on a SoC.
I don'
On 08/22/2010 02:44 PM, Avi Kivity wrote:
No more MI diamond and all devices have DeviceStates.
Coincidentally, it matches more closely how hardware works..
Well, I agree, but I honestly lost the context. How does this relate
to the APIC and cpu hotplug?
My original assertion was that t
On 08/22/2010 04:37 AM, Avi Kivity wrote:
On 08/19/2010 11:49 PM, Anthony Liguori wrote:
The bus does not need to have any connection to existence or
non-existence of real buses. In SoCs or ASICs, all devices and buses
may reside inside a chip.
Well, I think this is part of the trouble with t
On 08/19/2010 11:49 PM, Anthony Liguori wrote:
The bus does not need to have any connection to existence or
non-existence of real buses. In SoCs or ASICs, all devices and buses
may reside inside a chip.
Well, I think this is part of the trouble with the current qdev object
model. There are r
On 08/19/2010 10:33 PM, Anthony Liguori wrote:
On 06/12/2010 04:14 PM, Blue Swirl wrote:
Clean up APIC and IOAPIC. Convert both devices to qdev.
v1->v2:
Remove apic.h reorganization.
Add IOAPIC and APIC qdev conversions.
Use CPUState also in 5/7. However on 6/7 we have to again use void *
beca
On Thu, Aug 19, 2010 at 9:51 PM, Anthony Liguori wrote:
> On 08/19/2010 04:21 PM, Blue Swirl wrote:
>>>
>>> Should CPUs appear in the QEMU device tree?
>>>
>>
>> They have several properties that should be user visible.
>>
>
> Sure, but that's an argument for having some of the qdev features (like
On 08/20/2010 12:01 PM, Markus Armbruster wrote:
Anthony Liguori writes:
On 08/19/2010 04:21 PM, Blue Swirl wrote:
Should CPUs appear in the QEMU device tree?
They have several properties that should be user visible.
Sure, but that's an argument for having some
Anthony Liguori writes:
> On 08/19/2010 04:21 PM, Blue Swirl wrote:
>>> Should CPUs appear in the QEMU device tree?
>>>
>> They have several properties that should be user visible.
>>
>
> Sure, but that's an argument for having some of the qdev features
> (like variant properties) be co
On Thu, 19 Aug 2010, Anthony Liguori wrote:
> On 08/19/2010 05:52 PM, malc wrote:
> > > Yes, but the programming model was different.
> > >
> > > Look at the PIC compared to the lapic. The PIC is programmed via pio at a
> > > fixed location. There is only one PIC and it interacts with the syste
On 08/19/2010 05:52 PM, malc wrote:
Yes, but the programming model was different.
Look at the PIC compared to the lapic. The PIC is programmed via pio at a
fixed location. There is only one PIC and it interacts with the system just
like all other devices. IOW, there is no reference to CPUStat
On Thu, 19 Aug 2010, Anthony Liguori wrote:
> On 08/19/2010 04:21 PM, Blue Swirl wrote:
> > > Should CPUs appear in the QEMU device tree?
> > >
> > They have several properties that should be user visible.
> >
>
> Sure, but that's an argument for having some of the qdev features (like
>
On 08/19/2010 04:21 PM, Blue Swirl wrote:
Should CPUs appear in the QEMU device tree?
They have several properties that should be user visible.
Sure, but that's an argument for having some of the qdev features (like
variant properties) be consumable outside of qdev.
requirement t
On Thu, Aug 19, 2010 at 8:49 PM, Anthony Liguori wrote:
> On 08/19/2010 03:09 PM, Blue Swirl wrote:
>>
>> On Thu, Aug 19, 2010 at 7:33 PM, Anthony Liguori
>> wrote:
>>
>>>
>>> On 06/12/2010 04:14 PM, Blue Swirl wrote:
>>>
Clean up APIC and IOAPIC. Convert both devices to qdev.
On 08/19/2010 03:09 PM, Blue Swirl wrote:
On Thu, Aug 19, 2010 at 7:33 PM, Anthony Liguori wrote:
On 06/12/2010 04:14 PM, Blue Swirl wrote:
Clean up APIC and IOAPIC. Convert both devices to qdev.
v1->v2:
Remove apic.h reorganization.
Add IOAPIC and APIC qdev conversions.
Use CPUStat
On Thu, Aug 19, 2010 at 7:33 PM, Anthony Liguori wrote:
> On 06/12/2010 04:14 PM, Blue Swirl wrote:
>>
>> Clean up APIC and IOAPIC. Convert both devices to qdev.
>>
>> v1->v2:
>> Remove apic.h reorganization.
>> Add IOAPIC and APIC qdev conversions.
>> Use CPUState also in 5/7. However on 6/7 we h
On 06/12/2010 04:14 PM, Blue Swirl wrote:
Clean up APIC and IOAPIC. Convert both devices to qdev.
v1->v2:
Remove apic.h reorganization.
Add IOAPIC and APIC qdev conversions.
Use CPUState also in 5/7. However on 6/7 we have to again use void *
because of VMState limitations. VMState gurus, please
Clean up APIC and IOAPIC. Convert both devices to qdev.
v1->v2:
Remove apic.h reorganization.
Add IOAPIC and APIC qdev conversions.
Use CPUState also in 5/7. However on 6/7 we have to again use void *
because of VMState limitations. VMState gurus, please comment.
Blue Swirl (7):
ioapic: unexpor
39 matches
Mail list logo
