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 i
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/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 Kiszka wrote:
>> On 2011-01-19 20:32, Blue Swirl wrote:
>>> On Wed, Jan 19, 2011 at 4:57 PM, Anthony Liguori
>>>wrote:
On 01/19/2011 07:15 AM, Markus Armbruster wr
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 (hypo
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 de
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).
N
On 2011-01-24 22:35, Blue Swirl wrote:
> On Mon, Jan 24, 2011 at 2:08 PM, Jan Kiszka 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
>>>
On Mon, Jan 24, 2011 at 2:08 PM, Jan Kiszka 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, though it
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 w
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
On Fri, Jan 21, 2011 at 6:17 PM, Jan Kiszka wrote:
> On 2011-01-21 19:04, Blue Swirl wrote:
>> On Fri, Jan 21, 2011 at 5:21 PM, Jan Kiszka wrote:
>>> On 2011-01-21 17:37, Blue Swirl wrote:
On Fri, Jan 21, 2011 at 8:46 AM, Gerd Hoffmann wrote:
> Hi,
>
>> By the way, we don't hav
On 2011-01-21 19:04, Blue Swirl wrote:
> On Fri, Jan 21, 2011 at 5:21 PM, Jan Kiszka wrote:
>> On 2011-01-21 17:37, Blue Swirl wrote:
>>> On Fri, Jan 21, 2011 at 8:46 AM, Gerd Hoffmann wrote:
Hi,
> By the way, we don't have a QEMUState but instead use globals.
/me wants t
On Fri, Jan 21, 2011 at 5:21 PM, Jan Kiszka wrote:
> On 2011-01-21 17:37, Blue Swirl wrote:
>> On Fri, Jan 21, 2011 at 8:46 AM, Gerd Hoffmann wrote:
>>> Hi,
>>>
By the way, we don't have a QEMUState but instead use globals.
>>>
>>> /me wants to underline this.
>>>
>>> IMO it is absolutely p
On 2011-01-21 17:37, Blue Swirl wrote:
> On Fri, Jan 21, 2011 at 8:46 AM, Gerd Hoffmann 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.
>> The
On Fri, Jan 21, 2011 at 8:46 AM, Gerd Hoffmann 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 that.
>
Gerd Hoffmann 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 curren
Gerd Hoffmann 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 f
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 g
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 sup
On 2011-01-20 22:40, Blue Swirl wrote:
> On Thu, Jan 20, 2011 at 9:22 PM, Jan Kiszka wrote:
>> On 2011-01-20 20:27, Blue Swirl wrote:
>>> On Thu, Jan 20, 2011 at 9: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
> wr
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 o
On Thu, Jan 20, 2011 at 9:22 PM, Jan Kiszka wrote:
> On 2011-01-20 20:27, Blue Swirl wrote:
>> On Thu, Jan 20, 2011 at 9: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
wrote:
> On 01/19/2011 07:15 AM, Markus Armb
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
>>> wrote:
>>>
On 01/19/2011 07:15 AM, Markus Armbruster wrote:
> So they interact
On 2011-01-20 20:27, Blue Swirl wrote:
> On Thu, Jan 20, 2011 at 9: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
>>> wrote:
On 01/19/2011 07:15 AM, Markus Armbruster wrote:
>
> So they interact with KVM (need k
On Thu, Jan 20, 2011 at 7:37 PM, 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
>>> wrote:
>>>
On 01/19/2011 07:15 AM, Markus Armbruster wrote:
>
>
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 for
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 expe
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
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.
On Thu, Jan 20, 2011 at 9: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
>> wrote:
>>> On 01/19/2011 07:15 AM, Markus Armbruster wrote:
So they interact with KVM (need kvm_state), and they interact with the
emul
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
On 2011-01-19 20:32, Blue Swirl wrote:
> On Wed, Jan 19, 2011 at 4: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 differ
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 '-m
On Wed, Jan 19, 2011 at 4: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
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 i
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/201
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 ne
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
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 rel
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 devic
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 f
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:54:10AM -0600, Anthony Liguori wrote:
> On 01/19/2011 07:11 AM, Markus Armbruster wrote:
> >Gerd Hoffmann 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 architectu
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 par
On 01/19/2011 07:11 AM, Markus Armbruster wrote:
Gerd Hoffmann 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
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 f
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 buses
Anthony Liguori 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:
>
>
Gerd Hoffmann 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. Ther
Anthony Liguori 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 guest-explorable topology
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
th
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
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 wr
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 hi
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-e
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 the
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 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 Kisz
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.
>>>
>>> Tha
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 b
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.
>>
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 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 w
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 w
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: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 th
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-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
Avi Kivity 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 a devi
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
>
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 kerne
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 b
On 01/11/2011 03:31 AM, Markus Armbruster wrote:
Jan Kiszka 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
Jan Kiszka 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 initializatio
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 bad/hacki
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 initia
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
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_sta
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 Kiszka
If kvmclock is used, which implies the kernel supports it, register a
kvmclock device with the sysbus. Its main purpose is to save and
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 in
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
Am 10.01.2011 21:31, Anthony Liguori wrote:
> On 01/06/2011 11:56 AM, Marcelo Tosatti wrote:
>> From: Jan Kiszka
>>
>> 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,
On 01/06/2011 11:56 AM, Marcelo Tosatti wrote:
From: Jan Kiszka
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-
83 matches
Mail list logo
