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: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 28/35] kvm: x86: Introduce kvmclock device to save/restore its state
Date: Tue, 18 Jan 2011 09:48:24 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Lightning/1.0b1 Thunderbird/3.0.10

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:

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 kernel and not in
userspace.  An implementation detail is magnified beyond all proportions.

An ioapic that is implemented by kvm lives in exactly the same place
that the qemu ioapic lives in.  An assigned pci device lives on the PCI
bus, not a KVMBus.  If we need a pointer to KVMState, then we must find
it elsewhere, not through creating imaginary buses that don't exist.


Exactly.

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 that this topic is still waiting for good suggestions, specifically
from those who believe in kvm_state references :). This is not only
blocking kvmstate merge but will affect KVM irqchips as well.

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 the command line or a
config file.

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 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.

With vfio, would an assigned PCI device even need kvm_state?

Regards,

Anthony Liguori

Jan





reply via email to

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