On 12/30/2009 09:58 AM, Avi Kivity wrote:
On 12/30/2009 05:53 PM, Gleb Natapov wrote:
This assumes there is only one ioapic. While I don't think there's
a good reason to add more (the one we have is causing sufficient
trouble), I suggest returning an array of ioapics (or include
gsibase: [{ ioapic: object, gsibase: 0 }, { ioapic: object, gsibase:
24 }].
For the case of multiple ioapics I thought about extending the command
to get ioapic id as a parameter when time comes. gsibase is not know to
ioapic itself, so this info does not belong here.
Ok.
Here's a good example of why attacking device-info is a better general
approach.
Right now, you only support one ioapic and you only display a portion of
the device's state. In the future, it's likely that you'll want to
support multiple ioapic (okay, maybe not likely, but possible), and it's
very likely you'll want to include more state for the ioapic.
By definition, VMState contains all of the state of a device that's
guest visible. That means from a debugging perspective, you are
guaranteed to have all of the information you need for the particular
device. Also, because it's necessarily to save multiple instances of a
device with VMState, it automatically supports the ability to view
multiple instances of a device.
Regards,
Anthony Liguori
