qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 28/35] kvm: x86: Introduce kvmclock device to sa


From: Gleb Natapov
Subject: Re: [Qemu-devel] [PATCH 28/35] kvm: x86: Introduce kvmclock device to save/restore its state
Date: Mon, 24 Jan 2011 10:45:16 +0200

On Tue, Jan 18, 2011 at 11:09:01AM -0600, Anthony Liguori wrote:
> >>But we also need to provide a compatible interface to management tools.
> >>Exposing the device model topology as a compatible interface
> >>artificially limits us.  It's far better to provide higher level
> >>supported interfaces to give us the flexibility to change the device
> >>model as we need to.
> >How do you want to change qdev to keep the guest and management tool
> >view stable while branching off kvm sub-buses?
> 
> The qdev device model is not a stable interface.  I think that's
> been clear from the very beginning.
> 

And what was the reason it was declared not stable? May be because we
were not sure we will do it right from the start, so change will be
needed later. But changes should bring qdev closer to reflect what guest
expect device topology to look like. This will bring us to stable state
as close possible.  We need this knowledge and stability in qdev for
device path creation.  Both kind of device paths: OF and the one we use
for migration. To create OF device path we need to know topology as seen
by a guest (and guest does not care how isa bus is implemented internally
inside south bridge), to create device path used for migration we need
stability, otherwise change in qdev topology will break migration. All
this artificial buses you propose to add move us in opposite direction
and make qdev useless for anything but .... well for anything.

--
                        Gleb.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]