Alexander Graf ag...@suse.de writes:
On 01/28/2014 05:44 PM, Aneesh Kumar K.V wrote:
We definitely don't need to emulate mtspr, because both the registers
are hypervisor resource.
This patch description doesn't cover what the patch actually does. It
changes the implementation from always
On 31.01.2014, at 11:38, Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
wrote:
Alexander Graf ag...@suse.de writes:
On 01/28/2014 05:44 PM, Aneesh Kumar K.V wrote:
We definitely don't need to emulate mtspr, because both the registers
are hypervisor resource.
This patch description
Paul Mackerras pau...@samba.org writes:
On Tue, Jan 28, 2014 at 10:14:07PM +0530, Aneesh Kumar K.V wrote:
virtual time base register is a per vm register and need to saved
and restored on vm exit and entry. Writing to VTB is not allowed
in the privileged mode.
...
+#ifdef
Alexander Graf ag...@suse.de writes:
On 01/28/2014 05:44 PM, Aneesh Kumar K.V wrote:
Writing to IC is not allowed in the privileged mode.
This is not a patch description.
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/kvm_host.h | 1 +
On 31.01.2014, at 12:25, Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
wrote:
Alexander Graf ag...@suse.de writes:
On 01/28/2014 05:44 PM, Aneesh Kumar K.V wrote:
Writing to IC is not allowed in the privileged mode.
This is not a patch description.
Signed-off-by: Aneesh Kumar
Paul Mackerras pau...@samba.org writes:
On Tue, Jan 28, 2014 at 10:14:12PM +0530, Aneesh Kumar K.V wrote:
We allow priv-mode update of this. The guest value is saved in fscr,
and the value actually used is saved in shadow_fscr. shadow_fscr
only contains values that are allowed by the host. On
Am 30.01.2014 22:47, schrieb Paolo Bonzini:
Il 30/01/2014 20:48, Eduardo Habkost ha scritto:
Is there any hope to get this into QEMU 2.0, or it is now too late? I got
almost no feedback on take 6 (submitted November 27).
It's not too late, not for me at least. I wanted to send the next
Il 30/01/2014 13:53, Christian Borntraeger ha scritto:
+static inline void kvm_async_page_present_async(struct kvm_vcpu *vcpu,
+ struct kvm_async_pf *work)
+{
+#ifndef CONFIG_KVM_ASYNC_PF_SYNC
+ kvm_arch_async_page_present(vcpu, work);
+#endif
Alexander Graf ag...@suse.de writes:
On 01/28/2014 05:44 PM, Aneesh Kumar K.V wrote:
At this point we allow all the supported facilities except EBB. So
forward the interrupt to guest as illegal instruction.
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
Il 31/01/2014 12:30, Andreas Färber ha scritto:
Further, I was under the impression that this series depends on Igor's
feature property series, which I haven't found time to rework and
haven't noticed anyone else do either. So if there's no prereqs (why
uq/master?) I'll happily start reviewing
Il 30/01/2014 20:48, Eduardo Habkost ha scritto:
As the new X86CPU subclass code is going to change lots of the code
invoving x86_def_t, let's rename the struct to match coding style first.
Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
target-i386/cpu.c | 26 +-
Il 30/01/2014 20:48, Eduardo Habkost ha scritto:
There isn't any kind of registration involved in cpu_x86_register()
anymore: it is simply looking up a CPU model name and loading the model
definition data into the X86CPU object. Rename it to x86_cpu_load_def()
to reflect what it does.
Il 30/01/2014 20:48, Eduardo Habkost ha scritto:
As eventually the x86_def_t data is going to be provided by the CPU
class, it's better to not touch it, and handle the special cases on the
X86CPU object itself.
Current behavior of the code should stay exactly the same.
Signed-off-by: Eduardo
Il 30/01/2014 20:48, Eduardo Habkost ha scritto:
As we will not have a cpu_x86_find_by_name() function anymore,
move the KVM default-vendor hack to instance_init.
Unfortunately we can't move that code to class_init because it depends
on KVM being initialized.
Signed-off-by: Eduardo Habkost
Il 30/01/2014 20:48, Eduardo Habkost ha scritto:
The compiler is already able to eliminate the kvm_arch_get_supported_cpuid()
calls in kvm_cpu_fill_host() and filter_features_for_kvm(), so we can
eliminate the CONFIG_KVM #ifdefs there.
Also, kvm_cpu_fill_host() and host_cpuid() don't need to
On 31.01.2014, at 12:40, Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
wrote:
Alexander Graf ag...@suse.de writes:
On 01/28/2014 05:44 PM, Aneesh Kumar K.V wrote:
At this point we allow all the supported facilities except EBB. So
forward the interrupt to guest as illegal instruction.
On Fri, Jan 31, 2014 at 12:30:17PM +0100, Andreas Färber wrote:
Am 30.01.2014 22:47, schrieb Paolo Bonzini:
Il 30/01/2014 20:48, Eduardo Habkost ha scritto:
Is there any hope to get this into QEMU 2.0, or it is now too late? I got
almost no feedback on take 6 (submitted November 27).
On Fri, Jan 31, 2014 at 12:42:08PM +0100, Paolo Bonzini wrote:
Il 31/01/2014 12:30, Andreas Färber ha scritto:
Further, I was under the impression that this series depends on Igor's
feature property series, which I haven't found time to rework and
haven't noticed anyone else do either. So if
On 31/01/14 12:38, Paolo Bonzini wrote:
Il 30/01/2014 13:53, Christian Borntraeger ha scritto:
+static inline void kvm_async_page_present_async(struct kvm_vcpu *vcpu,
+struct kvm_async_pf *work)
+{
+#ifndef CONFIG_KVM_ASYNC_PF_SYNC
+
Il 31/01/2014 13:24, Christian Borntraeger ha scritto:
On 31/01/14 12:38, Paolo Bonzini wrote:
Il 30/01/2014 13:53, Christian Borntraeger ha scritto:
+static inline void kvm_async_page_present_async(struct kvm_vcpu *vcpu,
+struct kvm_async_pf *work)
+{
+#ifndef
From: Dominik Dingel din...@linux.vnet.ibm.com
Commit KVM: async_pf: Provide additional direct page notification
missed the call from kvm_check_async_pf_completion to the new introduced
function.
Reported-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Dominik Dingel
This fixup fixes patch 5 and makes it equivalent to the code that
went through testing. Looks like the change from patch 5 does
not cause real problems. x86 will simply inject the completion
via kvm_arch_async_page_present in kvm_check_async_pf_completion.
s390 will inject twice (sync in execute
On Fri, 31 Jan 2014 12:30:17 +0100
Andreas Färber afaer...@suse.de wrote:
Further, I was under the impression that this series depends on Igor's
feature property series, which I haven't found time to rework and
haven't noticed anyone else do either. So if there's no prereqs (why
uq/master?)
On Thu, 30 Jan 2014 17:48:52 -0200
Eduardo Habkost ehabk...@redhat.com wrote:
Is there any hope to get this into QEMU 2.0, or it is now too late? I got
almost no feedback on take 6 (submitted November 27).
This is the main blocker to allow libvirt finally implement an equivalent to
the
Il 31/01/2014 15:48, Igor Mammedov ha scritto:
that's abusing of object-add interface and due to recent changes, object-add
won't accept arbitrary objects.
I hope that sooner or later device hotplug will be doable with
object-add too. But yes, in the meanwhile device_add could work, and
Il 31/01/2014 14:32, Christian Borntraeger ha scritto:
This fixup fixes patch 5 and makes it equivalent to the code that
went through testing. Looks like the change from patch 5 does
not cause real problems. x86 will simply inject the completion
via kvm_arch_async_page_present in
(CCing Luiz, in case he can give some advice about the expectations of
QMP semantics stability)
On Fri, Jan 31, 2014 at 03:48:53PM +0100, Igor Mammedov wrote:
On Thu, 30 Jan 2014 17:48:52 -0200
Eduardo Habkost ehabk...@redhat.com wrote:
Is there any hope to get this into QEMU 2.0, or it is
Il 31/01/2014 16:10, Eduardo Habkost ha scritto:
I don't mind which command is used, as long as we have the same effect.
I used object-add in my example because device_add rejects the CPU
classes by now (because they have cannot_instantiate_with_device_add_yet=true).
But now I have one
On Fri, Jan 31, 2014 at 03:50:23PM +0100, Paolo Bonzini wrote:
Il 31/01/2014 15:48, Igor Mammedov ha scritto:
that's abusing of object-add interface and due to recent changes, object-add
won't accept arbitrary objects.
I hope that sooner or later device hotplug will be doable with
On Fri, 31 Jan 2014 13:17:53 -0200
Eduardo Habkost ehabk...@redhat.com wrote:
On Fri, Jan 31, 2014 at 03:50:23PM +0100, Paolo Bonzini wrote:
Il 31/01/2014 15:48, Igor Mammedov ha scritto:
that's abusing of object-add interface and due to recent changes,
object-add
won't accept arbitrary
Several QEMU and KVM community members will be at devconf.cz 7-9
February in Brno, Czech Republic. See the schedule for details on KVM
and virtualization talks:
http://devconf.cz/schedule
Thin provisioning in the KVM virtualization stack - how we got there -
Paolo Bonzini
KVM and CPU feature
https://bugzilla.kernel.org/show_bug.cgi?id=69491
--- Comment #4 from Kashyap Chamarthy kashyap...@gmail.com ---
Downstream bug -- https://bugzilla.redhat.com/show_bug.cgi?id=1058209
--
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this
https://bugzilla.kernel.org/show_bug.cgi?id=67751
--- Comment #4 from Kashyap Chamarthy kashyap...@gmail.com ---
For reference, I briefly discussed this with Thomas Graf. It's nothing
serious, but the warnings should be silenced, he said.
--
You are receiving this mail because:
You are watching
On Fri, Jan 31, 2014 at 05:06:21PM +0100, Igor Mammedov wrote:
On Fri, 31 Jan 2014 13:17:53 -0200
Eduardo Habkost ehabk...@redhat.com wrote:
On Fri, Jan 31, 2014 at 03:50:23PM +0100, Paolo Bonzini wrote:
Il 31/01/2014 15:48, Igor Mammedov ha scritto:
that's abusing of object-add
Il 31/01/2014 17:42, Eduardo Habkost ha scritto:
It looks like only -device would be able to create actual CPU models,
but for -device to work we need as minimum this series and conversion
of CPU features to properties in tree. Then I guess we can override
On Thu, Jan 30, 2014 at 05:48:59PM -0200, Eduardo Habkost wrote:
Register separate QOM classes for each x86 CPU model.
This will allow management code to more easily probe what each CPU model
provides, by simply creating objects using the appropriate class name,
without having to restart
Register separate QOM classes for each x86 CPU model.
This will allow management code to more easily probe what each CPU model
provides, by simply creating objects using the appropriate class name,
without having to restart QEMU.
This also allows us to eliminate the
On Fri, Jan 31, 2014 at 05:52:57PM +0100, Paolo Bonzini wrote:
Il 31/01/2014 17:42, Eduardo Habkost ha scritto:
It looks like only -device would be able to create actual CPU models,
but for -device to work we need as minimum this series and conversion
of CPU features to properties in tree.
On 01/31/2014 11:51 AM, Eduardo Habkost wrote:
Allowing -device may be okay, since in the (very?) long term -device
can be replaced by -object. But -object is definitive.
OK, one additional reason to try device_add first.
But then we have one additional problem:
* We want to allow
On Fri, Jan 31, 2014 at 11:56:18AM -0700, Eric Blake wrote:
On 01/31/2014 11:51 AM, Eduardo Habkost wrote:
Allowing -device may be okay, since in the (very?) long term -device
can be replaced by -object. But -object is definitive.
OK, one additional reason to try device_add first.
On Fri, 31 Jan 2014 11:56:18 -0700
Eric Blake ebl...@redhat.com wrote:
On 01/31/2014 11:51 AM, Eduardo Habkost wrote:
Allowing -device may be okay, since in the (very?) long term -device
can be replaced by -object. But -object is definitive.
OK, one additional reason to try
On Fri, Jan 31, 2014 at 08:18:39PM +0100, Igor Mammedov wrote:
On Fri, 31 Jan 2014 11:56:18 -0700
Eric Blake ebl...@redhat.com wrote:
On 01/31/2014 11:51 AM, Eduardo Habkost wrote:
Allowing -device may be okay, since in the (very?) long term -device
can be replaced by -object. But
On Fri, Jan 31, 2014 at 11:47:44AM +0100, Alexander Graf wrote:
On 31.01.2014, at 11:38, Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
wrote:
Alexander Graf ag...@suse.de writes:
On 01/28/2014 05:44 PM, Aneesh Kumar K.V wrote:
We definitely don't need to emulate mtspr, because
Alexander Graf ag...@suse.de writes:
On 01/28/2014 05:44 PM, Aneesh Kumar K.V wrote:
We definitely don't need to emulate mtspr, because both the registers
are hypervisor resource.
This patch description doesn't cover what the patch actually does. It
changes the implementation from always
On 31.01.2014, at 11:38, Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
wrote:
Alexander Graf ag...@suse.de writes:
On 01/28/2014 05:44 PM, Aneesh Kumar K.V wrote:
We definitely don't need to emulate mtspr, because both the registers
are hypervisor resource.
This patch description
Alexander Graf ag...@suse.de writes:
On 01/28/2014 05:44 PM, Aneesh Kumar K.V wrote:
Writing to IC is not allowed in the privileged mode.
This is not a patch description.
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/kvm_host.h | 1 +
On 31.01.2014, at 12:25, Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
wrote:
Alexander Graf ag...@suse.de writes:
On 01/28/2014 05:44 PM, Aneesh Kumar K.V wrote:
Writing to IC is not allowed in the privileged mode.
This is not a patch description.
Signed-off-by: Aneesh Kumar
Paul Mackerras pau...@samba.org writes:
On Tue, Jan 28, 2014 at 10:14:12PM +0530, Aneesh Kumar K.V wrote:
We allow priv-mode update of this. The guest value is saved in fscr,
and the value actually used is saved in shadow_fscr. shadow_fscr
only contains values that are allowed by the host. On
Alexander Graf ag...@suse.de writes:
On 01/28/2014 05:44 PM, Aneesh Kumar K.V wrote:
At this point we allow all the supported facilities except EBB. So
forward the interrupt to guest as illegal instruction.
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
On 31.01.2014, at 12:40, Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
wrote:
Alexander Graf ag...@suse.de writes:
On 01/28/2014 05:44 PM, Aneesh Kumar K.V wrote:
At this point we allow all the supported facilities except EBB. So
forward the interrupt to guest as illegal instruction.
50 matches
Mail list logo
