On Wed, Dec 30, 2009 at 05:04:53PM -0600, Anthony Liguori wrote: > 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. I included only the state I need for debugging. I don't what to see complete state. It will just clatter important info.
> > 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. > -- Gleb.