On 01/18/2011 04:28 PM, Jan Kiszka wrote:
So we can either infect the whole device tree with kvm (or maybe a
more generic accelerator structure that also deals with Xen) or we need
to pull the reference inside the device's init function from some global
service (kvm_get_state).
Note
On 01/18/2011 05:50 PM, Anthony Liguori wrote:
This design is in conflict with the requirement to attach KVM-assisted
devices also to their home bus, e.g. an assigned PCI device to the PCI
bus. We don't support multi-homed qdev devices.
The bus topology reflects how I/O flows in and out of a
On 01/19/2011 06:57 PM, Anthony Liguori wrote:
On 01/19/2011 07:15 AM, Markus Armbruster wrote:
So they interact with KVM (need kvm_state), and they interact with the
emulated PCI bus. Could you elaborate on the fundamental difference
between the two interactions that makes you choose the
On 01/20/2011 11:22 PM, Jan Kiszka wrote:
On 2011-01-20 20:27, Blue Swirl wrote:
On Thu, Jan 20, 2011 at 9:33 AM, Jan Kiszkajan.kis...@siemens.com wrote:
On 2011-01-19 20:32, Blue Swirl wrote:
On Wed, Jan 19, 2011 at 4:57 PM, Anthony Liguori
aligu...@linux.vnet.ibm.com wrote:
On
On 01/25/2011 04:27 AM, Avi Kivity wrote:
It boils down to how we reasonably pass a kvm_state reference from
machine init code to a sysbus device. I'm probably biased, but I don't
see any way that does not work against the idea of confining access to
kvm_state or breaks device instantiation from
On 01/25/2011 05:06 AM, Avi Kivity wrote:
On 01/19/2011 06:57 PM, Anthony Liguori wrote:
On 01/19/2011 07:15 AM, Markus Armbruster wrote:
So they interact with KVM (need kvm_state), and they interact with the
emulated PCI bus. Could you elaborate on the fundamental difference
between the two
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
On 2011-01-21 19:49, Blue Swirl wrote:
I'd add fourth possible class:
- device, CPU and machine configuration, like nographic,
win2k_install_hack, no_hpet, smp_cpus etc. Maybe also
irqchip_in_kernel could fit here, though it obviously depends on a
host capability too.
I would count
On Mon, Jan 24, 2011 at 2:08 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-01-21 19:49, Blue Swirl wrote:
I'd add fourth possible class:
- device, CPU and machine configuration, like nographic,
win2k_install_hack, no_hpet, smp_cpus etc. Maybe also
irqchip_in_kernel could fit here,
On 2011-01-24 22:35, Blue Swirl wrote:
On Mon, Jan 24, 2011 at 2:08 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-01-21 19:49, Blue Swirl wrote:
I'd add fourth possible class:
- device, CPU and machine configuration, like nographic,
win2k_install_hack, no_hpet, smp_cpus etc. Maybe
On 01/20/11 20:39, Anthony Liguori wrote:
On 01/20/2011 02:44 AM, Gerd Hoffmann wrote:
Hi,
For (2), you cannot use bus=X,addr=Y because it makes assumptions about
the PCI topology which may change in newer -M pc's.
Why should the PCI topology for 'pc' ever change?
We'll probably get q35
Hi,
By the way, we don't have a QEMUState but instead use globals.
/me wants to underline this.
IMO it is absolutely pointless to worry about ways to pass around
kvm_state. There never ever will be a serious need for that.
We can stick with the current model of keeping global state in
Gerd Hoffmann kra...@redhat.com writes:
On 01/20/11 20:39, Anthony Liguori wrote:
On 01/20/2011 02:44 AM, Gerd Hoffmann wrote:
Hi,
For (2), you cannot use bus=X,addr=Y because it makes assumptions about
the PCI topology which may change in newer -M pc's.
Why should the PCI topology for
Gerd Hoffmann kra...@redhat.com writes:
Hi,
By the way, we don't have a QEMUState but instead use globals.
/me wants to underline this.
IMO it is absolutely pointless to worry about ways to pass around
kvm_state. There never ever will be a serious need for that.
We can stick with the
On Fri, Jan 21, 2011 at 8:46 AM, Gerd Hoffmann kra...@redhat.com wrote:
Hi,
By the way, we don't have a QEMUState but instead use globals.
/me wants to underline this.
IMO it is absolutely pointless to worry about ways to pass around kvm_state.
There never ever will be a serious need for
On 2011-01-21 17:37, Blue Swirl wrote:
On Fri, Jan 21, 2011 at 8:46 AM, Gerd Hoffmann kra...@redhat.com wrote:
Hi,
By the way, we don't have a QEMUState but instead use globals.
/me wants to underline this.
IMO it is absolutely pointless to worry about ways to pass around kvm_state.
On Fri, Jan 21, 2011 at 5:21 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-01-21 17:37, Blue Swirl wrote:
On Fri, Jan 21, 2011 at 8:46 AM, Gerd Hoffmann kra...@redhat.com wrote:
Hi,
By the way, we don't have a QEMUState but instead use globals.
/me wants to underline this.
IMO it
On 2011-01-21 19:04, Blue Swirl wrote:
On Fri, Jan 21, 2011 at 5:21 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-01-21 17:37, Blue Swirl wrote:
On Fri, Jan 21, 2011 at 8:46 AM, Gerd Hoffmann kra...@redhat.com wrote:
Hi,
By the way, we don't have a QEMUState but instead use globals.
On Fri, Jan 21, 2011 at 6:17 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-01-21 19:04, Blue Swirl wrote:
On Fri, Jan 21, 2011 at 5:21 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-01-21 17:37, Blue Swirl wrote:
On Fri, Jan 21, 2011 at 8:46 AM, Gerd Hoffmann kra...@redhat.com
Hi,
For (2), you cannot use bus=X,addr=Y because it makes assumptions about
the PCI topology which may change in newer -M pc's.
Why should the PCI topology for 'pc' ever change?
We'll probably get q35 support some day, but when this lands I expect
we'll see a new machine type 'q35', so
On 2011-01-19 20:32, Blue Swirl wrote:
On Wed, Jan 19, 2011 at 4:57 PM, Anthony Liguori
aligu...@linux.vnet.ibm.com wrote:
On 01/19/2011 07:15 AM, Markus Armbruster wrote:
So they interact with KVM (need kvm_state), and they interact with the
emulated PCI bus. Could you elaborate on the
On Thu, Jan 20, 2011 at 09:44:05AM +0100, Gerd Hoffmann wrote:
Hi,
For (2), you cannot use bus=X,addr=Y because it makes assumptions about
the PCI topology which may change in newer -M pc's.
Why should the PCI topology for 'pc' ever change?
We'll probably get q35 support some day, but
On Thu, Jan 20, 2011 at 9:33 AM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-01-19 20:32, Blue Swirl wrote:
On Wed, Jan 19, 2011 at 4:57 PM, Anthony Liguori
aligu...@linux.vnet.ibm.com wrote:
On 01/19/2011 07:15 AM, Markus Armbruster wrote:
So they interact with KVM (need kvm_state),
On 01/20/2011 03:33 AM, Jan Kiszka wrote:
On 2011-01-19 20:32, Blue Swirl wrote:
On Wed, Jan 19, 2011 at 4:57 PM, Anthony Liguori
aligu...@linux.vnet.ibm.com wrote:
On 01/19/2011 07:15 AM, Markus Armbruster wrote:
So they interact with KVM (need kvm_state), and they
On 01/20/2011 02:44 AM, Gerd Hoffmann wrote:
Hi,
For (2), you cannot use bus=X,addr=Y because it makes assumptions about
the PCI topology which may change in newer -M pc's.
Why should the PCI topology for 'pc' ever change?
We'll probably get q35 support some day, but when this lands I
On 01/20/2011 04:33 AM, Daniel P. Berrange wrote:
On Thu, Jan 20, 2011 at 09:44:05AM +0100, Gerd Hoffmann wrote:
Hi,
For (2), you cannot use bus=X,addr=Y because it makes assumptions about
the PCI topology which may change in newer -M pc's.
Why should the PCI topology
On Thu, Jan 20, 2011 at 7:37 PM, Anthony Liguori
aligu...@linux.vnet.ibm.com wrote:
On 01/20/2011 03:33 AM, Jan Kiszka wrote:
On 2011-01-19 20:32, Blue Swirl wrote:
On Wed, Jan 19, 2011 at 4:57 PM, Anthony Liguori
aligu...@linux.vnet.ibm.com wrote:
On 01/19/2011 07:15 AM, Markus
On 2011-01-20 20:27, Blue Swirl wrote:
On Thu, Jan 20, 2011 at 9:33 AM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-01-19 20:32, Blue Swirl wrote:
On Wed, Jan 19, 2011 at 4:57 PM, Anthony Liguori
aligu...@linux.vnet.ibm.com wrote:
On 01/19/2011 07:15 AM, Markus Armbruster wrote:
So
On 2011-01-20 20:37, Anthony Liguori wrote:
On 01/20/2011 03:33 AM, Jan Kiszka wrote:
On 2011-01-19 20:32, Blue Swirl wrote:
On Wed, Jan 19, 2011 at 4:57 PM, Anthony Liguori
aligu...@linux.vnet.ibm.com wrote:
On 01/19/2011 07:15 AM, Markus Armbruster wrote:
So they
On Thu, Jan 20, 2011 at 9:22 PM, Jan Kiszka jan.kis...@web.de wrote:
On 2011-01-20 20:27, Blue Swirl wrote:
On Thu, Jan 20, 2011 at 9:33 AM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-01-19 20:32, Blue Swirl wrote:
On Wed, Jan 19, 2011 at 4:57 PM, Anthony Liguori
On 2011-01-20 21:02, Blue Swirl wrote:
I think KVMState was designed to match KVM ioctl interface: all stuff
that is needed for talking to KVM or received from KVM are there. But
I think this shouldn't be a design driver.
Agreed. The nice cleanup would probably be the complete assimilation of
On 2011-01-20 22:40, Blue Swirl wrote:
On Thu, Jan 20, 2011 at 9:22 PM, Jan Kiszka jan.kis...@web.de wrote:
On 2011-01-20 20:27, Blue Swirl wrote:
On Thu, Jan 20, 2011 at 9:33 AM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-01-19 20:32, Blue Swirl wrote:
On Wed, Jan 19, 2011 at 4:57 PM,
On 01/18/11 18:09, Anthony Liguori wrote:
On 01/18/2011 10:56 AM, Jan Kiszka wrote:
The device model topology is 100% a hidden architectural detail.
This is true for the sysbus, it is obviously not the case for PCI and
similarly discoverable buses. There we have a guest-explorable topology
Anthony Liguori aligu...@linux.vnet.ibm.com writes:
On 01/18/2011 10:56 AM, Jan Kiszka wrote:
The device model topology is 100% a hidden architectural detail.
This is true for the sysbus, it is obviously not the case for PCI and
similarly discoverable buses. There we have a
Gerd Hoffmann kra...@redhat.com writes:
On 01/18/11 18:09, Anthony Liguori wrote:
On 01/18/2011 10:56 AM, Jan Kiszka wrote:
The device model topology is 100% a hidden architectural detail.
This is true for the sysbus, it is obviously not the case for PCI and
similarly discoverable buses.
Anthony Liguori aligu...@linux.vnet.ibm.com writes:
On 01/18/2011 09:43 AM, Jan Kiszka wrote:
On 2011-01-18 16:04, Anthony Liguori wrote:
On 01/18/2011 08:28 AM, Jan Kiszka wrote:
On 2011-01-12 11:31, Jan Kiszka wrote:
Am 12.01.2011 11:22, Avi Kivity wrote:
On 01/19/2011 03:48 AM, Gerd Hoffmann wrote:
On 01/18/11 18:09, Anthony Liguori wrote:
On 01/18/2011 10:56 AM, Jan Kiszka wrote:
The device model topology is 100% a hidden architectural detail.
This is true for the sysbus, it is obviously not the case for PCI and
similarly discoverable
On Wed, Jan 19, 2011 at 10:53:30AM -0600, Anthony Liguori wrote:
On 01/19/2011 03:48 AM, Gerd Hoffmann wrote:
On 01/18/11 18:09, Anthony Liguori wrote:
On 01/18/2011 10:56 AM, Jan Kiszka wrote:
The device model topology is 100% a hidden architectural detail.
This is true for the sysbus, it
On 01/19/2011 07:11 AM, Markus Armbruster wrote:
Gerd Hoffmannkra...@redhat.com writes:
On 01/18/11 18:09, Anthony Liguori wrote:
On 01/18/2011 10:56 AM, Jan Kiszka wrote:
The device model topology is 100% a hidden architectural detail.
This is true
On 01/19/2011 07:15 AM, Markus Armbruster wrote:
So they interact with KVM (need kvm_state), and they interact with the
emulated PCI bus. Could you elaborate on the fundamental difference
between the two interactions that makes you choose the (hypothetical)
KVM bus over the PCI bus as device
On Wed, Jan 19, 2011 at 10:54:10AM -0600, Anthony Liguori wrote:
On 01/19/2011 07:11 AM, Markus Armbruster wrote:
Gerd Hoffmannkra...@redhat.com writes:
On 01/18/11 18:09, Anthony Liguori wrote:
On 01/18/2011 10:56 AM, Jan Kiszka wrote:
The device model topology is 100% a hidden
On 2011-01-19 17:57, Anthony Liguori wrote:
On 01/19/2011 07:15 AM, Markus Armbruster wrote:
So they interact with KVM (need kvm_state), and they interact with the
emulated PCI bus. Could you elaborate on the fundamental difference
between the two interactions that makes you choose the
On Wed, Jan 19, 2011 at 10:53:30AM -0600, Anthony Liguori wrote:
On 01/19/2011 03:48 AM, Gerd Hoffmann wrote:
On 01/18/11 18:09, Anthony Liguori wrote:
On 01/18/2011 10:56 AM, Jan Kiszka wrote:
The device model topology is 100% a hidden architectural detail.
This is true for the sysbus, it
On 01/19/2011 11:35 AM, Daniel P. Berrange wrote:
On Wed, Jan 19, 2011 at 10:53:30AM -0600, Anthony Liguori wrote:
On 01/19/2011 03:48 AM, Gerd Hoffmann wrote:
On 01/18/11 18:09, Anthony Liguori wrote:
On 01/18/2011 10:56 AM, Jan Kiszka wrote:
The
On 01/19/2011 11:19 AM, Daniel P. Berrange wrote:
In our past experiance though, *not* specifying attributes like
these has also been pretty bad from a forward compatibility
perspective too. We're kind of damned either way, so on balance
we decided we'd specify every attribute in qdev that's
On 01/19/2011 11:01 AM, Daniel P. Berrange wrote:
The reason we specify 'bus' is that we wanted to be flexible wrt
upgrades of libvirt, without needing restarts of QEMU instances
it manages. That way we can introduce new functionality into
libvirt that relies on it having previously set 'bus'
On Wed, Jan 19, 2011 at 11:51:58AM -0600, Anthony Liguori wrote:
On 01/19/2011 11:01 AM, Daniel P. Berrange wrote:
The reason we specify 'bus' is that we wanted to be flexible wrt
upgrades of libvirt, without needing restarts of QEMU instances
it manages. That way we can introduce new
On Wed, Jan 19, 2011 at 11:42:18AM -0600, Anthony Liguori wrote:
On 01/19/2011 11:35 AM, Daniel P. Berrange wrote:
On Wed, Jan 19, 2011 at 10:53:30AM -0600, Anthony Liguori wrote:
On 01/19/2011 03:48 AM, Gerd Hoffmann wrote:
On 01/18/11 18:09, Anthony Liguori wrote:
On 01/18/2011 10:56 AM,
On 01/19/2011 12:52 PM, Daniel P. Berrange wrote:
On Wed, Jan 19, 2011 at 11:51:58AM -0600, Anthony Liguori wrote:
On 01/19/2011 11:01 AM, Daniel P. Berrange wrote:
The reason we specify 'bus' is that we wanted to be flexible wrt
upgrades of libvirt, without needing restarts of QEMU
On Wed, Jan 19, 2011 at 4:57 PM, Anthony Liguori
aligu...@linux.vnet.ibm.com wrote:
On 01/19/2011 07:15 AM, Markus Armbruster wrote:
So they interact with KVM (need kvm_state), and they interact with the
emulated PCI bus. Could you elaborate on the fundamental difference
between the two
On 2011-01-18 17:37, Anthony Liguori wrote:
On 01/18/2011 10:17 AM, Jan Kiszka wrote:
On 2011-01-18 17:04, Anthony Liguori wrote:
A KVM device should sit on a KVM specific bus that hangs off of
sysbus.
It can get to kvm_state through that bus.
That bus doesn't get instantiated through
On Tue, 2011-01-18 at 16:54 +0100, Jan Kiszka wrote:
On 2011-01-18 16:48, Anthony Liguori wrote:
On 01/18/2011 09:43 AM, Jan Kiszka wrote:
On 2011-01-18 16:04, Anthony Liguori wrote:
On 01/18/2011 08:28 AM, Jan Kiszka wrote:
On 2011-01-12 11:31, Jan Kiszka wrote:
On 2011-01-18 18:02, Alex Williamson wrote:
On Tue, 2011-01-18 at 16:54 +0100, Jan Kiszka wrote:
On 2011-01-18 16:48, Anthony Liguori wrote:
On 01/18/2011 09:43 AM, Jan Kiszka wrote:
On 2011-01-18 16:04, Anthony Liguori wrote:
On 01/18/2011 08:28 AM, Jan Kiszka wrote:
On
On 01/18/2011 10:56 AM, Jan Kiszka wrote:
The device model topology is 100% a hidden architectural detail.
This is true for the sysbus, it is obviously not the case for PCI and
similarly discoverable buses. There we have a guest-explorable topology
that is currently equivalent to the
On 2011-01-18 18:09, Anthony Liguori wrote:
On 01/18/2011 10:56 AM, Jan Kiszka wrote:
The device model topology is 100% a hidden architectural detail.
This is true for the sysbus, it is obviously not the case for PCI and
similarly discoverable buses. There we have a guest-explorable
On 01/18/2011 11:20 AM, Jan Kiszka wrote:
Which only works as along as we expose a single bus. You don't need to
be an oracle to predict that this is not a stable interface.
Today we only have a very low level factory interface--device creation
and deletion.
I think we should move to
On Tue, 2011-01-18 at 18:08 +0100, Jan Kiszka wrote:
On 2011-01-18 18:02, Alex Williamson wrote:
On Tue, 2011-01-18 at 16:54 +0100, Jan Kiszka wrote:
On 2011-01-18 16:48, Anthony Liguori wrote:
On 01/18/2011 09:43 AM, Jan Kiszka wrote:
On 2011-01-18 16:04, Anthony Liguori wrote:
On 2011-01-18 18:31, Anthony Liguori wrote:
It's automatically created as part of the CPUs or as part of the
chipset. How to enable/disable kvm assistance is a property of the CPU
and/or chipset.
If we exclude creation via command line / config files, we could also
pass the kvm_state
On 2011-01-12 11:31, Jan Kiszka wrote:
Am 12.01.2011 11:22, Avi Kivity wrote:
On 01/11/2011 03:54 PM, Anthony Liguori wrote:
Right, we should introduce a KVMBus that KVM devices are created on.
The devices can get at KVMState through the BusState.
There is no kvm bus in a PC (I looked).
On 01/18/2011 08:28 AM, Jan Kiszka wrote:
On 2011-01-12 11:31, Jan Kiszka wrote:
Am 12.01.2011 11:22, Avi Kivity wrote:
On 01/11/2011 03:54 PM, Anthony Liguori wrote:
Right, we should introduce a KVMBus that KVM devices are created on.
The devices can get at KVMState through
On 2011-01-18 16:04, Anthony Liguori wrote:
On 01/18/2011 08:28 AM, Jan Kiszka wrote:
On 2011-01-12 11:31, Jan Kiszka wrote:
Am 12.01.2011 11:22, Avi Kivity wrote:
On 01/11/2011 03:54 PM, Anthony Liguori wrote:
Right, we should introduce a KVMBus that KVM devices are
On 01/18/2011 09:43 AM, Jan Kiszka wrote:
On 2011-01-18 16:04, Anthony Liguori wrote:
On 01/18/2011 08:28 AM, Jan Kiszka wrote:
On 2011-01-12 11:31, Jan Kiszka wrote:
Am 12.01.2011 11:22, Avi Kivity wrote:
On 01/11/2011 03:54 PM, Anthony Liguori wrote:
On 01/18/2011 09:43 AM, Jan Kiszka wrote:
On 2011-01-18 16:04, Anthony Liguori wrote:
On 01/18/2011 08:28 AM, Jan Kiszka wrote:
On 2011-01-12 11:31, Jan Kiszka wrote:
Am 12.01.2011 11:22, Avi Kivity wrote:
On 01/11/2011 03:54 PM, Anthony Liguori wrote:
On 2011-01-18 16:48, Anthony Liguori wrote:
On 01/18/2011 09:43 AM, Jan Kiszka wrote:
On 2011-01-18 16:04, Anthony Liguori wrote:
On 01/18/2011 08:28 AM, Jan Kiszka wrote:
On 2011-01-12 11:31, Jan Kiszka wrote:
Am 12.01.2011 11:22, Avi Kivity wrote:
On
On 2011-01-18 16:50, Anthony Liguori wrote:
On 01/18/2011 09:43 AM, Jan Kiszka wrote:
On 2011-01-18 16:04, Anthony Liguori wrote:
On 01/18/2011 08:28 AM, Jan Kiszka wrote:
On 2011-01-12 11:31, Jan Kiszka wrote:
Am 12.01.2011 11:22, Avi Kivity wrote:
On
On 01/18/2011 10:01 AM, Jan Kiszka wrote:
On 2011-01-18 16:50, Anthony Liguori wrote:
On 01/18/2011 09:43 AM, Jan Kiszka wrote:
On 2011-01-18 16:04, Anthony Liguori wrote:
On 01/18/2011 08:28 AM, Jan Kiszka wrote:
On 2011-01-12 11:31, Jan Kiszka wrote:
On 2011-01-18 17:04, Anthony Liguori wrote:
A KVM device should sit on a KVM specific bus that hangs off of
sysbus.
It can get to kvm_state through that bus.
That bus doesn't get instantiated through qdev so requiring a pointer
argument should not be an issue.
This design is in
On 01/18/2011 10:17 AM, Jan Kiszka wrote:
On 2011-01-18 17:04, Anthony Liguori wrote:
A KVM device should sit on a KVM specific bus that hangs off of
sysbus.
It can get to kvm_state through that bus.
That bus doesn't get instantiated through qdev so requiring a pointer
argument should not
On 01/11/2011 03:54 PM, Anthony Liguori wrote:
Right, we should introduce a KVMBus that KVM devices are created on.
The devices can get at KVMState through the BusState.
There is no kvm bus in a PC (I looked). We're bending the device model
here because a device is implemented in the
Am 12.01.2011 11:22, Avi Kivity wrote:
On 01/11/2011 03:54 PM, Anthony Liguori wrote:
Right, we should introduce a KVMBus that KVM devices are created on.
The devices can get at KVMState through the BusState.
There is no kvm bus in a PC (I looked). We're bending the device model
here
Avi Kivity a...@redhat.com writes:
On 01/11/2011 03:54 PM, Anthony Liguori wrote:
Right, we should introduce a KVMBus that KVM devices are created on.
The devices can get at KVMState through the BusState.
There is no kvm bus in a PC (I looked). We're bending the device
model here because
Hi,
Actually, there is already a channel to pass pointers to qdev devices:
the pointer property hack. I'm not sure we should contribute to its user
base or take the chance for a cleanup, but we are not alone with this
requirement. Point below remains valid, though.
It is considered
Jan Kiszka jan.kis...@web.de writes:
Am 10.01.2011 22:06, Jan Kiszka wrote:
kvmclock should be created with
kvm_state as a parameter and kvm_vm_ioctl() is passed the stored
reference. Taking a global reference to kvm_state in machine_init is
not a bad thing, obviously the machine
On 01/11/2011 03:31 AM, Markus Armbruster wrote:
Jan Kiszkajan.kis...@web.de writes:
Am 10.01.2011 22:06, Jan Kiszka wrote:
kvmclock should be created with
kvm_state as a parameter and kvm_vm_ioctl() is passed the stored
reference. Taking a global reference to kvm_state in
Am 11.01.2011 09:53, Gerd Hoffmann wrote:
Hi,
Actually, there is already a channel to pass pointers to qdev devices:
the pointer property hack. I'm not sure we should contribute to its user
base or take the chance for a cleanup, but we are not alone with this
requirement. Point below
On 01/06/2011 11:56 AM, Marcelo Tosatti wrote:
From: Jan Kiszkajan.kis...@siemens.com
If kvmclock is used, which implies the kernel supports it, register a
kvmclock device with the sysbus. Its main purpose is to save and restore
the kernel state on migration, but this will also allow to
Am 10.01.2011 21:31, Anthony Liguori wrote:
On 01/06/2011 11:56 AM, Marcelo Tosatti wrote:
From: Jan Kiszkajan.kis...@siemens.com
If kvmclock is used, which implies the kernel supports it, register a
kvmclock device with the sysbus. Its main purpose is to save and restore
the kernel state on
Am 10.01.2011 22:06, Jan Kiszka wrote:
kvmclock should be created with
kvm_state as a parameter and kvm_vm_ioctl() is passed the stored
reference. Taking a global reference to kvm_state in machine_init is
not a bad thing, obviously the machine initialization function needs
access to the
On 01/10/2011 04:21 PM, Jan Kiszka wrote:
Am 10.01.2011 22:06, Jan Kiszka wrote:
kvmclock should be created with
kvm_state as a parameter and kvm_vm_ioctl() is passed the stored
reference. Taking a global reference to kvm_state in machine_init is
not a bad thing, obviously the machine
On 01/10/2011 03:06 PM, Jan Kiszka wrote:
Am 10.01.2011 21:31, Anthony Liguori wrote:
On 01/06/2011 11:56 AM, Marcelo Tosatti wrote:
From: Jan Kiszkajan.kis...@siemens.com
If kvmclock is used, which implies the kernel supports it, register a
kvmclock device with the sysbus. Its main
Am 11.01.2011 00:02, Anthony Liguori wrote:
On 01/10/2011 04:21 PM, Jan Kiszka wrote:
Am 10.01.2011 22:06, Jan Kiszka wrote:
kvmclock should be created with
kvm_state as a parameter and kvm_vm_ioctl() is passed the stored
reference. Taking a global reference to kvm_state in
Am 11.01.2011 00:04, Anthony Liguori wrote:
kvmclock should be created with
kvm_state as a parameter and kvm_vm_ioctl() is passed the stored
reference. Taking a global reference to kvm_state in machine_init is
not a bad thing, obviously the machine initialization function needs
access to
On 01/10/2011 11:21 PM, Jan Kiszka wrote:
Am 10.01.2011 22:06, Jan Kiszka wrote:
kvmclock should be created with
kvm_state as a parameter and kvm_vm_ioctl() is passed the stored
reference. Taking a global reference to kvm_state in machine_init is
not a bad thing, obviously the machine
From: Jan Kiszka jan.kis...@siemens.com
If kvmclock is used, which implies the kernel supports it, register a
kvmclock device with the sysbus. Its main purpose is to save and restore
the kernel state on migration, but this will also allow to visualize it
one day.
Signed-off-by: Jan Kiszka
84 matches
Mail list logo
