Re: [RFC PATCH 01/10] KVM: PPC: BOOK3S: PR: Fix PURR and SPURR emulation
On Fri, Jan 31, 2014 at 11:47:44AM +0100, Alexander Graf wrote: > > On 31.01.2014, at 11:38, Aneesh Kumar K.V > wrote: > > > Alexander Graf 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 tell the guest it uses 100%" to > >> "give the guest an accurate amount of cpu time spent inside guest > >> context". > > > > Will fix that > > > >> > >> Also, I think we either go with full hyp semantics which means we also > >> emulate the offset or we go with no hyp awareness in the guest at all > >> which means we also don't emulate SPURR which is a hyp privileged > >> register. > > > > Can you clarify this ? > > In the 2.06 ISA SPURR is hypervisor privileged. That changed for 2.07 where > it became supervisor privileged. So I suppose your patch is ok. When > reviewing those patches I only had 2.06 around because power.org was broken. It's always been supervisor privilege for reading and hypervisor privilege for writing, ever since it was introduced in 2.05, and that hasn't changed. So I think what Aneesh is doing is correct. Regards, Paul. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [libvirt] [uq/master PATCH 0/7] x86 CPU subclasses, take 7
On Fri, Jan 31, 2014 at 08:18:39PM +0100, Igor Mammedov wrote: > On Fri, 31 Jan 2014 11:56:18 -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. > > > > > > But then we have one additional problem: > > > > > > * We want to allow libvirt to probe for CPU model information when > > >running QEMU using "-machine none" (because libvirt already does > > >that, and we don't want to require libvirt to run QEMU multiple > > >times) > > > * "device_add driver=-x86_64-cpu" requires an icc-bus to be > > > present > > > * -machine none doesn't have any bus > > > * I don't see a way to create an icc-bus through QMP (is there a way?) > > > > Is the icc-bus something that makes sense for all architectures, so that > > libvirt could just blindly request a command line that uses '-machine > > none' but also instantiates the icc-bus? Even if icc-bus is > > x86-specific, libvirt DOES have some notion of what architecture a qemu > > executable will be targetting, and could modify the command line based > > on what architecture it guesses the binary will support, if only for the > > purpose of minimizing qemu invocations for its probe of supported cpus. > Since -machine none, will not produce accurate CPUID info anyway and libvirt > knows in advance that it's going to create x86 machine, it might probe with > default machine type. It would be more accurate than -machine none, > but still might be not accurate if another machine type will be eventually > used for running guest. AFAIK, libvirt logic about CPU model features doesn't even take into account that it may change depending machine-type. I believe getting the non-machine-type-specific data will be better than the current state where libvirt relies on the data from cpu_map.xml, which duplicates (and sometimes don't match) what's inside QEMU. We will also need a way to figure out machine-type-specific information about each CPU model without re-running QEMU, but I think we can do this one step at a time. -- Eduardo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [libvirt] [uq/master PATCH 0/7] x86 CPU subclasses, take 7
On Fri, 31 Jan 2014 11:56:18 -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. > > > > But then we have one additional problem: > > > > * We want to allow libvirt to probe for CPU model information when > >running QEMU using "-machine none" (because libvirt already does > >that, and we don't want to require libvirt to run QEMU multiple > >times) > > * "device_add driver=-x86_64-cpu" requires an icc-bus to be present > > * -machine none doesn't have any bus > > * I don't see a way to create an icc-bus through QMP (is there a way?) > > Is the icc-bus something that makes sense for all architectures, so that > libvirt could just blindly request a command line that uses '-machine > none' but also instantiates the icc-bus? Even if icc-bus is > x86-specific, libvirt DOES have some notion of what architecture a qemu > executable will be targetting, and could modify the command line based > on what architecture it guesses the binary will support, if only for the > purpose of minimizing qemu invocations for its probe of supported cpus. Since -machine none, will not produce accurate CPUID info anyway and libvirt knows in advance that it's going to create x86 machine, it might probe with default machine type. It would be more accurate than -machine none, but still might be not accurate if another machine type will be eventually used for running guest. > > -- > Eric Blake eblake redhat com+1-919-301-3266 > Libvirt virtualization library http://libvirt.org > -- Regards, Igor -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [libvirt] [Qemu-devel] [uq/master PATCH 0/7] x86 CPU subclasses, take 7
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. > > > > But then we have one additional problem: > > > > * We want to allow libvirt to probe for CPU model information when > >running QEMU using "-machine none" (because libvirt already does > >that, and we don't want to require libvirt to run QEMU multiple > >times) > > * "device_add driver=-x86_64-cpu" requires an icc-bus to be present > > * -machine none doesn't have any bus > > * I don't see a way to create an icc-bus through QMP (is there a way?) > > Is the icc-bus something that makes sense for all architectures, so that > libvirt could just blindly request a command line that uses '-machine > none' but also instantiates the icc-bus? Even if icc-bus is > x86-specific, libvirt DOES have some notion of what architecture a qemu > executable will be targetting, and could modify the command line based > on what architecture it guesses the binary will support, if only for the > purpose of minimizing qemu invocations for its probe of supported cpus. I don't know if it is possible to instantiate icc-bus from the command-line if using -machine none, either. Does anybody know if it's already possible? -- Eduardo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [libvirt] [Qemu-devel] [uq/master PATCH 0/7] x86 CPU subclasses, take 7
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 libvirt to probe for CPU model information when >running QEMU using "-machine none" (because libvirt already does >that, and we don't want to require libvirt to run QEMU multiple >times) > * "device_add driver=-x86_64-cpu" requires an icc-bus to be present > * -machine none doesn't have any bus > * I don't see a way to create an icc-bus through QMP (is there a way?) Is the icc-bus something that makes sense for all architectures, so that libvirt could just blindly request a command line that uses '-machine none' but also instantiates the icc-bus? Even if icc-bus is x86-specific, libvirt DOES have some notion of what architecture a qemu executable will be targetting, and could modify the command line based on what architecture it guesses the binary will support, if only for the purpose of minimizing qemu invocations for its probe of supported cpus. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [uq/master PATCH 0/7] x86 CPU subclasses, take 7
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. Then I guess we can override > >>> cannot_instantiate_with_device_add_yet for x86 CPUs. > >Setting cannot_instantiate_with_device_add_yet=false looks much simpler > >than implementing UserCreatable. My question is: may we do that, already > >(once this series gets included), or is there something else holding us > >from doing it? > > Once you make something creatable with "-object", the API must not > change anymore. So we would have to think twice about that. > > 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 libvirt to probe for CPU model information when running QEMU using "-machine none" (because libvirt already does that, and we don't want to require libvirt to run QEMU multiple times) * "device_add driver=-x86_64-cpu" requires an icc-bus to be present * -machine none doesn't have any bus * I don't see a way to create an icc-bus through QMP (is there a way?) -- Eduardo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[uq/master PATCH 7/7 v8] target-i386: CPU model subclasses
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 qdev_prop_set_globals_for_type()
hack to set CPU-model-specific global properties.
Instead of creating separate class_init functions for each class, I just
used class_data to store a pointer to the X86CPUDefinition struct for
each CPU model. This should make the patch shorter and easier to review.
Later we can gradually convert each X86CPUDefinition field to lists of
per-class property defaults.
Written based on the ideas from the patch "[RFC v5] target-i386: Slim
conversion to X86CPU subclasses + KVM subclasses" written by Andreas
Färber , Igor Mammedov .
The "host" CPU model is special, as the feature flags depend on KVM
being initialized. So it has its own class_init and instance_init
function, and feature flags are set on instance_init instead of
class_init.
Signed-off-by: Andreas Färber
Signed-off-by: Igor Mammedov
Signed-off-by: Eduardo Habkost
---
This patch is similar to the one sent by Andrea and then later
resubmitted by Igor as "[RFC v5] target-i386: Slim conversion to X86CPU
subclasses + KVM subclasses", as it doesn't create one new class_init
function for each subclass.
Main differences v5 -> v6 are:
* Code was written from scratch (instead of using the previous patches
as base)
* I didn't mean to rewrite it entirely, but when doing additional
simplification of the CPU init logic on other patches, I ended up
rewriting it.
* I chose to keep the Signed-off-by lines because I built upon
Andreas's and Igor's ideas. Is that OK?
* No KVM-specific subclasses, to keep things simpler.
* No embedding of X86CPUDefinition (x86_def_t) inside the class struct,
instead keeping a pointer to the existing X86CPUDefinition struct.
* The "host" class is registered on cpu.c, but the CPUID data
is filled on instance_init instead of class_init (because KVM has to
be initialized already).
* kvm_required field introduced to make sure the "host" class can't
be used without KVM.
Changes v6 -> v7:
* Rebase
Changes v7 -> v8:
* Removed CPU listing code (will be sent as a separate patch)
* Kept x86_cpudef_setup() (will be addressed in a separate patch)
---
target-i386/cpu-qom.h | 13
target-i386/cpu.c | 197 --
2 files changed, 138 insertions(+), 72 deletions(-)
diff --git a/target-i386/cpu-qom.h b/target-i386/cpu-qom.h
index 722f11a..60c5c32 100644
--- a/target-i386/cpu-qom.h
+++ b/target-i386/cpu-qom.h
@@ -37,6 +37,9 @@
#define X86_CPU_GET_CLASS(obj) \
OBJECT_GET_CLASS(X86CPUClass, (obj), TYPE_X86_CPU)
+
+typedef struct X86CPUDefinition X86CPUDefinition;
+
/**
* X86CPUClass:
* @parent_realize: The parent class' realize handler.
@@ -49,6 +52,16 @@ typedef struct X86CPUClass {
CPUClass parent_class;
/*< public >*/
+/* CPU model definition
+ * Should be eventually replaced by subclass-specific property defaults
+ */
+X86CPUDefinition *cpu_def;
+/* CPU model requires KVM to be enabled */
+bool kvm_required;
+/* Optional description of CPU model.
+ * If unavailable, cpu_def->model_id is used */
+const char *model_description;
+
DeviceRealize parent_realize;
void (*parent_reset)(CPUState *cpu);
} X86CPUClass;
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 6659527..bb72e5b 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -484,7 +484,10 @@ static void add_flagname_to_bitmaps(const char *flagname,
}
}
-typedef struct X86CPUDefinition {
+/* CPU model definition data that was not converted to QOM per-subclass
+ * property defaults yet.
+ */
+struct X86CPUDefinition {
const char *name;
uint32_t level;
uint32_t xlevel;
@@ -497,7 +500,7 @@ typedef struct X86CPUDefinition {
FeatureWordArray features;
char model_id[48];
bool cache_info_passthrough;
-} X86CPUDefinition;
+};
#define I486_FEATURES (CPUID_FP87 | CPUID_VME | CPUID_PSE)
#define PENTIUM_FEATURES (I486_FEATURES | CPUID_DE | CPUID_TSC | \
@@ -547,8 +550,29 @@ typedef struct X86CPUDefinition {
CPUID_7_0_EBX_ERMS, CPUID_7_0_EBX_INVPCID, CPUID_7_0_EBX_RTM,
CPUID_7_0_EBX_RDSEED */
-/* built-in CPU model definitions
+/* CPU class name definitions: */
+
+#define X86_CPU_CLASS_SUFFIX "-" TYPE_X86_CPU
+#define CPU_CLASS_NAME(name) (name X86_CPU_CLASS_SUFFIX)
+
+/* Return class name for a given CPU model name
+ * Caller is responsible for freeing the returned string.
*/
+static char *x86_cpu_class_name(const char *model_name)
+{
+return g_strdup_printf(CPU_CLASS_NAME("%s"), model_name);
+}
+
+/* Return X86CPUClass for a CPU model name */
+static X86CPUClass *x86_cpu_class_by_name(const char *name)
+{
+X86CPUClass *cc;
+char *class_name = x86
Re: [Qemu-devel] [uq/master PATCH 7/7] target-i386: CPU model subclasses
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 QEMU. > > This also allows us to eliminate the qdev_prop_set_globals_for_type() > hack to set CPU-model-specific global properties. > > Instead of creating separate class_init functions for each class, I just > used class_dat to store a pointer to the X86CPUDefinition struct for > each CPU model. This should make the patch shorter and easier to review. > Later we can gradually convert each X86CPUDefinition field to lists of > per-class property defaults. > > Signed-off-by: Eduardo Habkost > --- > This version is closer to the version sent by Andrea and then later > resubmitted by Igor as "[RFC v5] target-i386: Slim conversion to X86CPU > subclasses + KVM subclasses", as it doesn't create one new class_init > function for each subclass. One main difference is that this version > does not use KVM-specific subclasses, to keep things simpler. I will submit a new version of this patch later, as I will: * Split some changes that can be made in a separate patch, after the conversion (the x86_cpudef_setup() removal and the CPU listing code); * Add proper attribution to Andreas and Igor, who wrote "[RFC v5] target-i386: Slim conversion to X86CPU subclasses + KVM subclasses". -- Eduardo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [uq/master PATCH 0/7] x86 CPU subclasses, take 7
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 > cannot_instantiate_with_device_add_yet for x86 CPUs. Setting cannot_instantiate_with_device_add_yet=false looks much simpler than implementing UserCreatable. My question is: may we do that, already (once this series gets included), or is there something else holding us from doing it? Once you make something creatable with "-object", the API must not change anymore. So we would have to think twice about that. Allowing -device may be okay, since in the (very?) long term -device can be replaced by -object. But -object is definitive. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [uq/master PATCH 0/7] x86 CPU subclasses, take 7
On Fri, Jan 31, 2014 at 05:06:21PM +0100, Igor Mammedov wrote: > On Fri, 31 Jan 2014 13:17:53 -0200 > Eduardo Habkost 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 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 this patch series is in the right direction anyway. > > > > In that case, what is holding us from setting > > cannot_instantiate_with_device_add_yet on TYPE_X86_CPU? I don't think we > > can recommend using "-device" for CPUs just yet, but we would need to > > allow it in case object-add doesn't work. > > > > (But I liked the fact that object-add worked and (it looks like) it > > didn't run realize(). All libvirt needs is to be able to create the > > object and get instance_init() run, no need for realize() to run.) > > > > I still need to read the reasoning behind the object-add changes. But is > > there some chance we could allow object-add to work for TYPE_X86_CPU > > subclasses, to avoid the device_add/cannot_instantiate_with_device_add_yet > > issues? > > you can hack around by inheriting from UserCreatable interface, > but question is what kind of information libvirt would expect from > -object xxx-cpu > > if it's going to read/interpret feature words then CPU.instance_init() > is not sufficient, since properties (read as compat props) and > realize() itself are changing feature words and CPU model guest is going > to see is very different from what -object would create. I am not sure yet, but maybe that's a good thing? I mean: libvirt has no concept of CPU models changing depending on machine-type yet, and this will be addressed later. In this case, not having the global properties set on the CPU object could be useful. > > 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 > cannot_instantiate_with_device_add_yet for x86 CPUs. Setting cannot_instantiate_with_device_add_yet=false looks much simpler than implementing UserCreatable. My question is: may we do that, already (once this series gets included), or is there something else holding us from doing it? -- Eduardo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 67751] Stack trace with suspicious RCU usage, when starting ovs-switchd
https://bugzilla.kernel.org/show_bug.cgi?id=67751 --- Comment #4 from Kashyap Chamarthy --- 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 the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 69491] Booting into a guest on Intel Haswell (bare-metal) throws soft lockups [qemu-system-x86:911]
https://bugzilla.kernel.org/show_bug.cgi?id=69491 --- Comment #4 from Kashyap Chamarthy --- 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 list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
QEMU & KVM at devconf.cz 7-9 February in Brno, Czech Republic
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 enablement - Eduardo Habkost Virtual vs physical machines - what's the difference to software? - Karen Noel VIRTIO 1.0: Paravirtualized I/O devices for KVM and beyond - Stefan Hajnoczi (There are also a ton of talks about oVirt and OpenStack.) I understand there is no entry fee, so it's easy to come see the talks and chat with us. Hopefully internet access will be stable and we can communicate on #qemu IRC during the conference. Or feel free to reply if you are attending and want to meet up. Stefan -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [uq/master PATCH 0/7] x86 CPU subclasses, take 7
On Fri, 31 Jan 2014 13:17:53 -0200 Eduardo Habkost 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 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 this patch series is in the right direction anyway. > > In that case, what is holding us from setting > cannot_instantiate_with_device_add_yet on TYPE_X86_CPU? I don't think we > can recommend using "-device" for CPUs just yet, but we would need to > allow it in case object-add doesn't work. > > (But I liked the fact that object-add worked and (it looks like) it > didn't run realize(). All libvirt needs is to be able to create the > object and get instance_init() run, no need for realize() to run.) > > I still need to read the reasoning behind the object-add changes. But is > there some chance we could allow object-add to work for TYPE_X86_CPU > subclasses, to avoid the device_add/cannot_instantiate_with_device_add_yet > issues? you can hack around by inheriting from UserCreatable interface, but question is what kind of information libvirt would expect from -object xxx-cpu if it's going to read/interpret feature words then CPU.instance_init() is not sufficient, since properties (read as compat props) and realize() itself are changing feature words and CPU model guest is going to see is very different from what -object would create. 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 cannot_instantiate_with_device_add_yet for x86 CPUs. > > -- > Eduardo -- Regards, Igor -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [uq/master PATCH 0/7] x86 CPU subclasses, take 7
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 > object-add too. But yes, in the meanwhile device_add could work, > and this patch series is in the right direction anyway. In that case, what is holding us from setting cannot_instantiate_with_device_add_yet on TYPE_X86_CPU? I don't think we can recommend using "-device" for CPUs just yet, but we would need to allow it in case object-add doesn't work. (But I liked the fact that object-add worked and (it looks like) it didn't run realize(). All libvirt needs is to be able to create the object and get instance_init() run, no need for realize() to run.) I still need to read the reasoning behind the object-add changes. But is there some chance we could allow object-add to work for TYPE_X86_CPU subclasses, to avoid the device_add/cannot_instantiate_with_device_add_yet issues? -- Eduardo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [uq/master PATCH 0/7] x86 CPU subclasses, take 7
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 question: how can people know which parts of the QMP semantics will be stable, and which parts are subject to change? object-add was added in 2.0, so it was never stable. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [uq/master PATCH 0/7] x86 CPU subclasses, take 7
(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 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
> > "enforce" flag, finally making the CPU configuration safe and sane (today
> > libvirt simply ignores GET_SUPPORTED_CPUID information, and features are
> > silently disabled because "enforce" is not used).
> >
> > This blocks libvirt because the current available interfaces requires
> > re-running
> > QEMU for each CPU model to be probed. Having the x86 CPU subclasses allow
> > libvirt to simply create and destroy CPU objects from each available CPU
> > class,
> > and query for the results using QMP.
> >
> > Demonstration of how this can be used, below:
> >
> > Running QEMU as:
> > $ qemu-system-x86_64 -enable-kvm -machine none -monitor stdio -qmp
> > unix:/tmp/qmp,server,nowait -nographic
> >
> > Then running qmp-shell as:
> > $ ./scripts/qmp/qmp-shell /tmp/qmp
> > [...]
> > (QEMU) object-add qom-type=host-x86_64-cpu id=probing-host-cpu-type
> [...]
> > (QEMU) qom-list path=/objects/
> that's abusing of object-add interface and due to recent changes, object-add
> won't accept arbitrary objects.
>
> see "[PATCH v1 3/4] add optional 2nd stage initialization to
> -object/object-add commands"
>
> libvirt probably could use device_add instead to the same effect.
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 question: how can people know which parts of the QMP
semantics will be stable, and which parts are subject to change?
>
> BTW how libvirt would discover values for qom-type=foo?
I don't know, but I assume there's an appropriate command to list qdev
and/or QOM classes, already?
In the worst case, libvirt can already use the query-cpu-definitions
command. But in this case, libvirt would have to encode the assumption
that the CPU class names will be "--cpu". Or we could
provide a new property on the query-cpu-definitions output containing
the class name (that sounds appropriate, considering that the "-cpu"
option doesn't get a class name (yet?)).
The specifics are not set in stone, and I expect other developers to
help me guide the libvirt developers and give them recommendations on
how to query for the needed information (because there are multiple ways
to do the same thing in QMP, as far as I can see).
>
> > {u'return': [{u'type': u'child', u'name':
> > u'probing-cpu-type-Haswell'}, {u'type': u'child',
> > u'name': u'probing-cpu-type-Westmere'}, {u'type':
> > u'child', u'name': u'probing-cpu-type-Nehalem'},
> > {u'type': u'child', u'name': u'probing-host-cpu-type'},
> > {u'type': u'string', u'name': u'type'}]}
> > (QEMU) qom-list path=/objects/probing-cpu-type-Haswell/
> > {u'return': [{u'type': u'X86CPUFeatureWordInfo', u'name':
> > u'filtered-features'}, {u'type': u'X86CPUFeatureWordInfo', u'name':
> > u'feature-words'}, {u'type': u'int', u'name': u'apic-id'}, {u'type':
> > u'int', u'name': u'tsc-frequency'}, {u'type': u'string', u'name':
> > u'model-id'}, {u'type': u'string', u'name': u'vendor'}, {u'type': u'int',
> > u'name': u'xlevel'}, {u'type': u'int', u'name': u'level'}, {u'type':
> > u'int', u'name': u'stepping'}, {u'type': u'int', u'name': u'model'},
> > {u'type': u'int', u'name': u'family'}, {u'type': u'link', u'name':
> > u'parent_bus'}, {u'type': u'boolean', u'name': u'enforce'}, {u'type':
> > u'boolean', u'name': u'check'}, {u'type': u'boolean', u'name': u'hv-time'},
> > {u'type': u'boolean', u'name': u'hv-vapic'}, {u'type': u'boolean', u'name':
> > u'hv-relaxed'}, {u'type': u'int', u'name': u'hv-spinlocks'}, {u'type':
> > u'boolean', u'name': u'pmu'}, {u'type': u'bool', u'name': u'realized'},
> > {u'type': u'string', u'name': u'type'}]}
> > (QEMU) qom-get path=/objects/probing-cpu-type-Haswell property=feature-words
> > {u'return': [{u'cpuid-register': u'EDX', u'cpuid-input-eax': 2147483658,
> > u'features': 0}, {u'cpuid-register': u'EAX', u'cpuid-input-eax':
> > 1073741825, u'features': 16777339}, {u'cpuid-register': u'EDX',
> > u'cpuid-input-eax': 3221225473, u'features': 0}, {u'cpuid-register':
> > u'ECX', u'cpuid-input-eax': 2147483649, u'features': 1},
> > {u'cpuid-register': u'EDX', u'cpuid-input-eax': 2147483649, u'features':
> > 672139264}, {u'cpuid-register': u'EBX', u'cpuid-input-eax': 7, u'features':
> > 4025, u'cpuid-input-ecx': 0}, {u'cpuid-register': u'ECX',
> > u'cpuid-input-eax': 1, u'features': 2549756419}, {u'cpuid-register':
> > u'EDX', u'cpuid-input-eax': 1, u'features': 126614525}]}
> >
Re: [PATCH] Fixup for patch 5
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 kvm_check_async_pf_completion. s390 will inject twice (sync in execute but also async), but the guest OS can handle that. (thats why I did not catch this in my regression test after rebasing). So the only visible effect is in the counters and in performance. We can handle this as an addon patch Good! I will pull and apply this patch as soon as -rc1 is out. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [uq/master PATCH 0/7] x86 CPU subclasses, take 7
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 this patch series is in the right direction anyway. see "[PATCH v1 3/4] add optional 2nd stage initialization to -object/object-add commands" libvirt probably could use device_add instead to the same effect. BTW how libvirt would discover values for qom-type=foo? With qom-list-types. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [uq/master PATCH 0/7] x86 CPU subclasses, take 7
On Thu, 30 Jan 2014 17:48:52 -0200
Eduardo Habkost 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
> "enforce" flag, finally making the CPU configuration safe and sane (today
> libvirt simply ignores GET_SUPPORTED_CPUID information, and features are
> silently disabled because "enforce" is not used).
>
> This blocks libvirt because the current available interfaces requires
> re-running
> QEMU for each CPU model to be probed. Having the x86 CPU subclasses allow
> libvirt to simply create and destroy CPU objects from each available CPU
> class,
> and query for the results using QMP.
>
> Demonstration of how this can be used, below:
>
> Running QEMU as:
> $ qemu-system-x86_64 -enable-kvm -machine none -monitor stdio -qmp
> unix:/tmp/qmp,server,nowait -nographic
>
> Then running qmp-shell as:
> $ ./scripts/qmp/qmp-shell /tmp/qmp
> [...]
> (QEMU) object-add qom-type=host-x86_64-cpu id=probing-host-cpu-type
[...]
> (QEMU) qom-list path=/objects/
that's abusing of object-add interface and due to recent changes, object-add
won't accept arbitrary objects.
see "[PATCH v1 3/4] add optional 2nd stage initialization to
-object/object-add commands"
libvirt probably could use device_add instead to the same effect.
BTW how libvirt would discover values for qom-type=foo?
> {u'return': [{u'type': u'child', u'name':
> u'probing-cpu-type-Haswell'}, {u'type': u'child',
> u'name': u'probing-cpu-type-Westmere'}, {u'type':
> u'child', u'name': u'probing-cpu-type-Nehalem'},
> {u'type': u'child', u'name': u'probing-host-cpu-type'},
> {u'type': u'string', u'name': u'type'}]}
> (QEMU) qom-list path=/objects/probing-cpu-type-Haswell/
> {u'return': [{u'type': u'X86CPUFeatureWordInfo', u'name':
> u'filtered-features'}, {u'type': u'X86CPUFeatureWordInfo', u'name':
> u'feature-words'}, {u'type': u'int', u'name': u'apic-id'}, {u'type': u'int',
> u'name': u'tsc-frequency'}, {u'type': u'string', u'name': u'model-id'},
> {u'type': u'string', u'name': u'vendor'}, {u'type': u'int', u'name':
> u'xlevel'}, {u'type': u'int', u'name': u'level'}, {u'type': u'int', u'name':
> u'stepping'}, {u'type': u'int', u'name': u'model'}, {u'type': u'int',
> u'name': u'family'}, {u'type': u'link', u'name': u'parent_bus'},
> {u'type': u'boolean', u'name': u'enforce'}, {u'type': u'boolean', u'name':
> u'check'}, {u'type': u'boolean', u'name': u'hv-time'}, {u'type': u'boolean',
> u'name': u'hv-vapic'}, {u'type': u'boolean', u'name': u'hv-relaxed'},
> {u'type': u'int', u'name': u'hv-spinlocks'}, {u'type': u'boolean', u'name':
> u'pmu'}, {u'type': u'bool', u'name': u'realized'}, {u'type': u'string',
> u'name': u'type'}]}
> (QEMU) qom-get path=/objects/probing-cpu-type-Haswell property=feature-words
> {u'return': [{u'cpuid-register': u'EDX', u'cpuid-input-eax': 2147483658,
> u'features': 0}, {u'cpuid-register': u'EAX', u'cpuid-input-eax': 1073741825,
> u'features': 16777339}, {u'cpuid-register': u'EDX', u'cpuid-input-eax':
> 3221225473, u'features': 0}, {u'cpuid-register': u'ECX', u'cpuid-input-eax':
> 2147483649, u'features': 1}, {u'cpuid-register': u'EDX', u'cpuid-input-eax':
> 2147483649, u'features': 672139264}, {u'cpuid-register': u'EBX',
> u'cpuid-input-eax': 7, u'features': 4025, u'cpuid-input-ecx': 0},
> {u'cpuid-register': u'ECX', u'cpuid-input-eax': 1, u'features': 2549756419},
> {u'cpuid-register': u'EDX', u'cpuid-input-eax': 1, u'features': 126614525}]}
> (QEMU) qom-get path=/objects/probing-cpu-type-Haswell
> property=filtered-features
> {u'return': [{u'cpuid-register': u'EDX', u'cpuid-input-eax': 2147483658,
> u'features': 0}, {u'cpuid-register': u'EAX', u'cpuid-input-eax': 1073741825,
> u'features': 0}, {u'cpuid-register': u'EDX', u'cpuid-input-eax': 3221225473,
> u'features': 0}, {u'cpuid-register': u'ECX', u'cpuid-input-eax': 2147483649,
> u'features': 0}, {u'cpuid-register': u'EDX', u'cpuid-input-eax': 2147483649,
> u'features': 0}, {u'cpuid-register': u'EBX', u'cpuid-input-eax': 7,
> u'features': 0, u'cpuid-input-ecx': 0}, {u'cpuid-register': u'ECX',
> u'cpuid-input-eax': 1, u'features': 0}, {u'cpuid-register': u'EDX',
> u'cpuid-input-eax': 1, u'features': 0}]}
> (QEMU) qom-get path=/objects/probing-host-cpu-type property=feature-words
> {u'return': [{u'cpuid-register': u'EDX', u'cpuid-input-eax': 2147483658,
> u'features': 0}, {u'cpuid-register': u'EAX', u'cpuid-input-eax': 1073741825,
> u'features': 16777467}, {u'cpuid-register': u'EDX', u'cpuid-input-eax':
> 3221225473, u'features': 0}, {u'cpuid-register': u'ECX', u'cpuid-input-eax':
> 2147483649, u'features': 1}, {u'cpuid-register': u'EDX', u'cpuid-input-eax':
> 2147483649, u'features': 697564159}, {u'cpuid-register': u'EBX',
> u'cpuid-input-eax': 7, u'features': 2, u'cpuid-input-ecx': 0},
> {u'cpuid-register': u'ECX', u'cpuid-input-eax': 1, u'features': 2193236483
Re: [uq/master PATCH 0/7] x86 CPU subclasses, take 7
On Fri, 31 Jan 2014 12:30:17 +0100 Andreas Färber 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?) I'll happily start reviewing and queuing it. It doesn't depend on properties series. due to recent changes properties series should be reworked anyway and probably should be based on top of this one. [...] > Regards, > Andreas > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- Regards, Igor -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Fixup for patch 5
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 but also async), but the guest OS can handle that. (thats why I did not catch this in my regression test after rebasing). So the only visible effect is in the counters and in performance. We can handle this as an addon patch Dominik Dingel (1): KVM: async_pf: Add missing call for async page present virt/kvm/async_pf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.8.4.2 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] KVM: async_pf: Add missing call for async page present
From: Dominik Dingel 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 Signed-off-by: Dominik Dingel --- virt/kvm/async_pf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/virt/kvm/async_pf.c b/virt/kvm/async_pf.c index 889aad0..10df100 100644 --- a/virt/kvm/async_pf.c +++ b/virt/kvm/async_pf.c @@ -151,7 +151,7 @@ void kvm_check_async_pf_completion(struct kvm_vcpu *vcpu) spin_unlock(&vcpu->async_pf.lock); kvm_arch_async_page_ready(vcpu, work); - kvm_arch_async_page_present(vcpu, work); + kvm_async_page_present_async(vcpu, work); list_del(&work->queue); vcpu->async_pf.queued--; -- 1.8.4.2 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL 5/8] KVM: async_pf: Provide additional direct page notification
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 CONFIG_KVM_ASYNC_PF_SYNC
+kvm_arch_async_page_present(vcpu, work);
+#endif
+}
+
This is not used, should it be used in kvm_check_async_pf_completion?
Yes. Looks like this got mixed up when updating the branch from before
commit f2e106692d5189303997ad7b96de8d8123aa5613 (KVM: Drop FOLL_GET in
GUP when doing async page fault) on top of this commit. Do you want a
respin of the series or an on top patch?
It should only break s390, so your call. I think a respin would be
preferrable for you. :)
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL 5/8] KVM: async_pf: Provide additional direct page notification
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
>> +kvm_arch_async_page_present(vcpu, work);
>> +#endif
>> +}
>> +
>
> This is not used, should it be used in kvm_check_async_pf_completion?
Yes. Looks like this got mixed up when updating the branch from before
commit f2e106692d5189303997ad7b96de8d8123aa5613 (KVM: Drop FOLL_GET in
GUP when doing async page fault) on top of this commit. Do you want a
respin of the series or an on top patch?
Christian
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [uq/master PATCH 0/7] x86 CPU subclasses, take 7
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 there's no prereqs (why > >uq/master?) I'll happily start reviewing and queuing it. > > Yeah, I was also wondering why uq/master too, mostly for patches 5 and 7. I just wanted to indicate that the series can't be applied into master yet because it depends on patches that are still on uq/master. (In the past I have sent patches without a branch identifier in the Subject, and started receiving notifications from some robot saying that the patch doesn't apply to master. I don't know if that robot still exists.) -- Eduardo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [uq/master PATCH 0/7] x86 CPU subclasses, take 7
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). > > > > It's not too late, not for me at least. I wanted to send the next > > uq/master pull request tomorrow or Tuesday, after I've done some more > > testing on enlightenments. I can squeeze this in too. > > Negative, not without my review. It's clearly a CPU series, and apart > from having been on vacation pretty much all of December, Eduardo and > others have objected to my subclass series the last 2 *years*, so 2 > months is peanuts by comparison. I don't remember objecting to your approach, but we simply had lots of details to understand and questions settle. Then in February we (Andreas, Igor, and me) stopped submitting new versions while we focused in other stuff. I was also not aware how the lack of subclasses would badly affect libvirt's ability to use the new QOM properties we have added. I only noticed that while talking to Jiri last November, that's why I resumed the subclass work after months, to try to get it into QEMU 2.0. > > 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 and queuing it. It doesn't depend on the feature properties at all. But the series is based on uq/master only because it depends on KVM-specific patches that are already on uq/master (that's why I added uq/master to the Subject. It doesn't mean it has to be pulled through uq/master necessarily). > > As Eduardo points out below the commit message in the final patch, his > conversion is very similar to one of my earlier patch series, so > committing that with Eduardo as author via uq/master without crediting > me via uq/master would leave a bad taste. Sorry, what would be the proper way to give proper attribution on the commit message in this case? I often don't know if it is appropriate to keep a Signed-off-by line if most of the code is new. Also, I was incorrectly assuming the whole patch was re-written from scratch by me, but now I have noticed I have copied x86_cpu_list_compare() (and other parts) from your code without proper attribution, I am very sorry for that. My poor excuse is that I have 3 or 4 local git branches where I was experimenting with different approaches, and it was hard to keep track of everything. -- Eduardo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 08/10] KVM: PPC: BOOK3S: PR: Add support for facility unavailable interrupt
On 31.01.2014, at 12:40, Aneesh Kumar K.V
wrote:
> Alexander Graf 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
>>> ---
>>> arch/powerpc/include/asm/kvm_asm.h | 4 +++-
>>> arch/powerpc/kvm/book3s.c | 4
>>> arch/powerpc/kvm/book3s_emulate.c | 18 ++
>>> arch/powerpc/kvm/book3s_pr.c | 17 +
>>> 4 files changed, 42 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/powerpc/include/asm/kvm_asm.h
>>> b/arch/powerpc/include/asm/kvm_asm.h
>>> index 1bd92fd43cfb..799244face51 100644
>>> --- a/arch/powerpc/include/asm/kvm_asm.h
>>> +++ b/arch/powerpc/include/asm/kvm_asm.h
>>> @@ -99,6 +99,7 @@
>>> #define BOOK3S_INTERRUPT_PERFMON 0xf00
>>> #define BOOK3S_INTERRUPT_ALTIVEC 0xf20
>>> #define BOOK3S_INTERRUPT_VSX 0xf40
>>> +#define BOOK3S_INTERRUPT_FAC_UNAVAIL0xf60
>>>
>>> #define BOOK3S_IRQPRIO_SYSTEM_RESET0
>>> #define BOOK3S_IRQPRIO_DATA_SEGMENT1
>>> @@ -117,7 +118,8 @@
>>> #define BOOK3S_IRQPRIO_DECREMENTER 14
>>> #define BOOK3S_IRQPRIO_PERFORMANCE_MONITOR 15
>>> #define BOOK3S_IRQPRIO_EXTERNAL_LEVEL 16
>>> -#define BOOK3S_IRQPRIO_MAX 17
>>> +#define BOOK3S_IRQPRIO_FAC_UNAVAIL 17
>>> +#define BOOK3S_IRQPRIO_MAX 18
>>>
>>> #define BOOK3S_HFLAG_DCBZ320x1
>>> #define BOOK3S_HFLAG_SLB 0x2
>>> diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
>>> index 8912608b7e1b..a9aea28c2677 100644
>>> --- a/arch/powerpc/kvm/book3s.c
>>> +++ b/arch/powerpc/kvm/book3s.c
>>> @@ -143,6 +143,7 @@ static int kvmppc_book3s_vec2irqprio(unsigned int vec)
>>> case 0xd00: prio = BOOK3S_IRQPRIO_DEBUG;break;
>>> case 0xf20: prio = BOOK3S_IRQPRIO_ALTIVEC; break;
>>> case 0xf40: prio = BOOK3S_IRQPRIO_VSX; break;
>>> + case 0xf60: prio = BOOK3S_IRQPRIO_FAC_UNAVAIL; break;
>>> default:prio = BOOK3S_IRQPRIO_MAX; break;
>>> }
>>>
>>> @@ -273,6 +274,9 @@ int kvmppc_book3s_irqprio_deliver(struct kvm_vcpu
>>> *vcpu, unsigned int priority)
>>> case BOOK3S_IRQPRIO_PERFORMANCE_MONITOR:
>>> vec = BOOK3S_INTERRUPT_PERFMON;
>>> break;
>>> + case BOOK3S_IRQPRIO_FAC_UNAVAIL:
>>> + vec = BOOK3S_INTERRUPT_FAC_UNAVAIL;
>>> + break;
>>> default:
>>> deliver = 0;
>>> printk(KERN_ERR "KVM: Unknown interrupt: 0x%x\n", priority);
>>> diff --git a/arch/powerpc/kvm/book3s_emulate.c
>>> b/arch/powerpc/kvm/book3s_emulate.c
>>> index 60d0b6b745e7..bf6b11021250 100644
>>> --- a/arch/powerpc/kvm/book3s_emulate.c
>>> +++ b/arch/powerpc/kvm/book3s_emulate.c
>>> @@ -481,6 +481,15 @@ int kvmppc_core_emulate_mtspr_pr(struct kvm_vcpu
>>> *vcpu, int sprn, ulong spr_val)
>>> vcpu->arch.shadow_fscr = vcpu->arch.fscr & host_fscr;
>>> break;
>>> }
>>> + case SPRN_EBBHR:
>>> + vcpu->arch.ebbhr = spr_val;
>>> + break;
>>> + case SPRN_EBBRR:
>>> + vcpu->arch.ebbrr = spr_val;
>>> + break;
>>> + case SPRN_BESCR:
>>> + vcpu->arch.bescr = spr_val;
>>> + break;
>>> unprivileged:
>>> default:
>>> printk(KERN_INFO "KVM: invalid SPR write: %d\n", sprn);
>>> @@ -607,6 +616,15 @@ int kvmppc_core_emulate_mfspr_pr(struct kvm_vcpu
>>> *vcpu, int sprn, ulong *spr_val
>>> case SPRN_FSCR:
>>> *spr_val = vcpu->arch.fscr;
>>> break;
>>> + case SPRN_EBBHR:
>>> + *spr_val = vcpu->arch.ebbhr;
>>> + break;
>>> + case SPRN_EBBRR:
>>> + *spr_val = vcpu->arch.ebbrr;
>>> + break;
>>> + case SPRN_BESCR:
>>> + *spr_val = vcpu->arch.bescr;
>>> + break;
>>> default:
>>> unprivileged:
>>> printk(KERN_INFO "KVM: invalid SPR read: %d\n", sprn);
>>> diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
>>> index 51d469f8c9fd..828056ec208f 100644
>>> --- a/arch/powerpc/kvm/book3s_pr.c
>>> +++ b/arch/powerpc/kvm/book3s_pr.c
>>> @@ -900,6 +900,23 @@ int kvmppc_handle_exit_pr(struct kvm_run *run, struct
>>> kvm_vcpu *vcpu,
>>> case BOOK3S_INTERRUPT_PERFMON:
>>> r = RESUME_GUEST;
>>> break;
>>> + case BOOK3S_INTERRUPT_FAC_UNAVAIL:
>>> + {
>>> + /*
>>> +* Check for the facility that need to be emulated
>>> +*/
>>> + ulong fscr_ic = vcpu->arch.shadow_fscr >> 56;
>>> + if (fscr_ic != FSCR_EBB_LG) {
>>> + /*
>>> +* We only disable EBB facility.
>>> +* So only emulate that.
>>
>> I don't understand the comment. We emulate nothing at all her
Re: [uq/master PATCH 1/7] target-i386: Eliminate CONFIG_KVM #ifdefs
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 check
CONFIG_KVM, as they don't have any KVM-specific function calls.
Tested to build successfully with CONFIG_KVM disabled, using the
following CFLAGS combinations: "-DNDEBUG", "-DNDEBUG -O', "-DNDEBUG
-O0", "-DNDEBUG -O1", "-DNDEBUG -O2".
Signed-off-by: Eduardo Habkost
---
Changes v2:
* Check for __i386__ on host_cpuid() so the code compiles properly
on non-x86 hosts.
Suggested-by: Paolo Bonzini
Change v3:
* Don't add assert(kvm_enabled()) line, which is not necessary to help
the compiler (and wouldn't help it if using -DNDEBUG, anyway).
Reported-by: Richard Henderson
* Commit message update
---
target-i386/cpu.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 1f30efd..8425212 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -374,7 +374,6 @@ void disable_kvm_pv_eoi(void)
void host_cpuid(uint32_t function, uint32_t count,
uint32_t *eax, uint32_t *ebx, uint32_t *ecx, uint32_t *edx)
{
-#if defined(CONFIG_KVM)
uint32_t vec[4];
#ifdef __x86_64__
@@ -382,7 +381,7 @@ void host_cpuid(uint32_t function, uint32_t count,
: "=a"(vec[0]), "=b"(vec[1]),
"=c"(vec[2]), "=d"(vec[3])
: "0"(function), "c"(count) : "cc");
-#else
+#elif defined(__i386__)
asm volatile("pusha \n\t"
"cpuid \n\t"
"mov %%eax, 0(%2) \n\t"
@@ -392,6 +391,8 @@ void host_cpuid(uint32_t function, uint32_t count,
"popa"
: : "a"(function), "c"(count), "S"(vec)
: "memory", "cc");
+#else
+abort();
#endif
if (eax)
@@ -402,7 +403,6 @@ void host_cpuid(uint32_t function, uint32_t count,
*ecx = vec[2];
if (edx)
*edx = vec[3];
-#endif
}
#define iswhite(c) ((c) && ((c) <= ' ' || '~' < (c)))
@@ -1119,7 +1119,6 @@ void x86_cpu_compat_set_features(const char *cpu_model,
FeatureWord w,
}
}
-#ifdef CONFIG_KVM
static int cpu_x86_fill_model_id(char *str)
{
uint32_t eax = 0, ebx = 0, ecx = 0, edx = 0;
@@ -1134,7 +1133,6 @@ static int cpu_x86_fill_model_id(char *str)
}
return 0;
}
-#endif
/* Fill a x86_def_t struct with information about the host CPU, and
* the CPU features supported by the host hardware + host kernel
@@ -1143,7 +1141,6 @@ static int cpu_x86_fill_model_id(char *str)
*/
static void kvm_cpu_fill_host(x86_def_t *x86_cpu_def)
{
-#ifdef CONFIG_KVM
KVMState *s = kvm_state;
uint32_t eax = 0, ebx = 0, ecx = 0, edx = 0;
@@ -1173,8 +1170,6 @@ static void kvm_cpu_fill_host(x86_def_t *x86_cpu_def)
kvm_arch_get_supported_cpuid(s, wi->cpuid_eax, wi->cpuid_ecx,
wi->cpuid_reg);
}
-
-#endif /* CONFIG_KVM */
}
static int unavailable_host_feature(FeatureWordInfo *f, uint32_t mask)
@@ -1817,7 +1812,6 @@ CpuDefinitionInfoList *arch_query_cpu_definitions(Error
**errp)
return cpu_list;
}
-#ifdef CONFIG_KVM
static void filter_features_for_kvm(X86CPU *cpu)
{
CPUX86State *env = &cpu->env;
@@ -1834,7 +1828,6 @@ static void filter_features_for_kvm(X86CPU *cpu)
cpu->filtered_features[w] = requested_features & ~env->features[w];
}
}
-#endif
static void cpu_x86_register(X86CPU *cpu, const char *name, Error **errp)
{
@@ -2545,9 +2538,7 @@ static void x86_cpu_realizefn(DeviceState *dev, Error
**errp)
"Host's CPU doesn't support requested features");
goto out;
}
-#ifdef CONFIG_KVM
filter_features_for_kvm(cpu);
-#endif
}
#ifndef CONFIG_USER_ONLY
Reviewed-by: Paolo Bonzini
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [uq/master PATCH 4/7] target-i386: Rename cpu_x86_register() to x86_cpu_load_def()
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.
Signed-off-by: Eduardo Habkost
---
target-i386/cpu.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 0e8812a..58b4c71 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -1817,7 +1817,9 @@ static void filter_features_for_kvm(X86CPU *cpu)
}
}
-static void cpu_x86_register(X86CPU *cpu, const char *name, Error **errp)
+/* Load CPU definition for a given CPU model name
+ */
+static void x86_cpu_load_def(X86CPU *cpu, const char *name, Error **errp)
{
CPUX86State *env = &cpu->env;
x86_def_t def1, *def = &def1;
@@ -1900,7 +1902,7 @@ X86CPU *cpu_x86_create(const char *cpu_model, DeviceState
*icc_bridge,
object_unref(OBJECT(cpu));
#endif
-cpu_x86_register(cpu, name, &error);
+x86_cpu_load_def(cpu, name, &error);
if (error) {
goto out;
}
Reviewed-by: Paolo Bonzini
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [uq/master PATCH 2/7] target-i386: Don't change x86_def_t struct on cpu_x86_register()
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 Habkost
---
target-i386/cpu.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 8425212..be54f84 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -1841,11 +1841,6 @@ static void cpu_x86_register(X86CPU *cpu, const char
*name, Error **errp)
return;
}
-if (kvm_enabled()) {
-def->features[FEAT_KVM] |= kvm_default_features;
-}
-def->features[FEAT_1_ECX] |= CPUID_EXT_HYPERVISOR;
-
object_property_set_str(OBJECT(cpu), def->vendor, "vendor", errp);
object_property_set_int(OBJECT(cpu), def->level, "level", errp);
object_property_set_int(OBJECT(cpu), def->family, "family", errp);
@@ -1864,6 +1859,12 @@ static void cpu_x86_register(X86CPU *cpu, const char
*name, Error **errp)
cpu->cache_info_passthrough = def->cache_info_passthrough;
object_property_set_str(OBJECT(cpu), def->model_id, "model-id", errp);
+
+/* Special cases not set in the x86_def_t structs: */
+if (kvm_enabled()) {
+env->features[FEAT_KVM] |= kvm_default_features;
+}
+env->features[FEAT_1_ECX] |= CPUID_EXT_HYPERVISOR;
}
X86CPU *cpu_x86_create(const char *cpu_model, DeviceState *icc_bridge,
Reviewed-by: Paolo Bonzini
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [uq/master PATCH 3/7] target-i386: Move KVM default-vendor hack to instance_init
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
---
target-i386/cpu.c | 32 +++-
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index be54f84..0e8812a 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -1601,18 +1601,6 @@ static int cpu_x86_find_by_name(X86CPU *cpu, x86_def_t
*x86_cpu_def,
def = &builtin_x86_defs[i];
if (strcmp(name, def->name) == 0) {
memcpy(x86_cpu_def, def, sizeof(*def));
-/* sysenter isn't supported in compatibility mode on AMD,
- * syscall isn't supported in compatibility mode on Intel.
- * Normally we advertise the actual CPU vendor, but you can
- * override this using the 'vendor' property if you want to use
- * KVM's sysenter/syscall emulation in compatibility mode and
- * when doing cross vendor migration
- */
-if (kvm_enabled()) {
-uint32_t ebx = 0, ecx = 0, edx = 0;
-host_cpuid(0, 0, NULL, &ebx, &ecx, &edx);
-x86_cpu_vendor_words2str(x86_cpu_def->vendor, ebx, edx, ecx);
-}
return 0;
}
}
@@ -1841,7 +1829,6 @@ static void cpu_x86_register(X86CPU *cpu, const char
*name, Error **errp)
return;
}
-object_property_set_str(OBJECT(cpu), def->vendor, "vendor", errp);
object_property_set_int(OBJECT(cpu), def->level, "level", errp);
object_property_set_int(OBJECT(cpu), def->family, "family", errp);
object_property_set_int(OBJECT(cpu), def->model, "model", errp);
@@ -1865,6 +1852,25 @@ static void cpu_x86_register(X86CPU *cpu, const char
*name, Error **errp)
env->features[FEAT_KVM] |= kvm_default_features;
}
env->features[FEAT_1_ECX] |= CPUID_EXT_HYPERVISOR;
+
+/* sysenter isn't supported in compatibility mode on AMD,
+ * syscall isn't supported in compatibility mode on Intel.
+ * Normally we advertise the actual CPU vendor, but you can
+ * override this using the 'vendor' property if you want to use
+ * KVM's sysenter/syscall emulation in compatibility mode and
+ * when doing cross vendor migration
+ */
+const char *vendor = def->vendor;
+char host_vendor[CPUID_VENDOR_SZ + 1];
+if (kvm_enabled()) {
+uint32_t ebx = 0, ecx = 0, edx = 0;
+host_cpuid(0, 0, NULL, &ebx, &ecx, &edx);
+x86_cpu_vendor_words2str(host_vendor, ebx, edx, ecx);
+vendor = host_vendor;
+}
+
+object_property_set_str(OBJECT(cpu), vendor, "vendor", errp);
+
}
X86CPU *cpu_x86_create(const char *cpu_model, DeviceState *icc_bridge,
Reviewed-by: Paolo Bonzini
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [uq/master PATCH 6/7] target-i386: Rename x86_def_t to X86CPUDefinition
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
---
target-i386/cpu.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 5c13ed6..6659527 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -484,7 +484,7 @@ static void add_flagname_to_bitmaps(const char *flagname,
}
}
-typedef struct x86_def_t {
+typedef struct X86CPUDefinition {
const char *name;
uint32_t level;
uint32_t xlevel;
@@ -497,7 +497,7 @@ typedef struct x86_def_t {
FeatureWordArray features;
char model_id[48];
bool cache_info_passthrough;
-} x86_def_t;
+} X86CPUDefinition;
#define I486_FEATURES (CPUID_FP87 | CPUID_VME | CPUID_PSE)
#define PENTIUM_FEATURES (I486_FEATURES | CPUID_DE | CPUID_TSC | \
@@ -549,7 +549,7 @@ typedef struct x86_def_t {
/* built-in CPU model definitions
*/
-static x86_def_t builtin_x86_defs[] = {
+static X86CPUDefinition builtin_x86_defs[] = {
{
.name = "qemu64",
.level = 4,
@@ -1108,7 +1108,7 @@ static x86_def_t builtin_x86_defs[] = {
void x86_cpu_compat_set_features(const char *cpu_model, FeatureWord w,
uint32_t feat_add, uint32_t feat_remove)
{
-x86_def_t *def;
+X86CPUDefinition *def;
int i;
for (i = 0; i < ARRAY_SIZE(builtin_x86_defs); i++) {
def = &builtin_x86_defs[i];
@@ -1134,12 +1134,12 @@ static int cpu_x86_fill_model_id(char *str)
return 0;
}
-/* Fill a x86_def_t struct with information about the host CPU, and
+/* Fill a X86CPUDefinition struct with information about the host CPU, and
* the CPU features supported by the host hardware + host kernel
*
* This function may be called only if KVM is enabled.
*/
-static void kvm_cpu_fill_host(x86_def_t *x86_cpu_def)
+static void kvm_cpu_fill_host(X86CPUDefinition *x86_cpu_def)
{
KVMState *s = kvm_state;
uint32_t eax = 0, ebx = 0, ecx = 0, edx = 0;
@@ -1582,10 +1582,10 @@ static PropertyInfo qdev_prop_spinlocks = {
.set = x86_set_hv_spinlocks,
};
-static int cpu_x86_find_by_name(X86CPU *cpu, x86_def_t *x86_cpu_def,
+static int cpu_x86_find_by_name(X86CPU *cpu, X86CPUDefinition *x86_cpu_def,
const char *name)
{
-x86_def_t *def;
+X86CPUDefinition *def;
int i;
if (name == NULL) {
@@ -1753,7 +1753,7 @@ static void listflags(char *buf, int bufsize, uint32_t
fbits,
/* generate CPU information. */
void x86_cpu_list(FILE *f, fprintf_function cpu_fprintf)
{
-x86_def_t *def;
+X86CPUDefinition *def;
char buf[256];
int i;
@@ -1780,7 +1780,7 @@ void x86_cpu_list(FILE *f, fprintf_function cpu_fprintf)
CpuDefinitionInfoList *arch_query_cpu_definitions(Error **errp)
{
CpuDefinitionInfoList *cpu_list = NULL;
-x86_def_t *def;
+X86CPUDefinition *def;
int i;
for (i = 0; i < ARRAY_SIZE(builtin_x86_defs); i++) {
@@ -1822,7 +1822,7 @@ static void filter_features_for_kvm(X86CPU *cpu)
static void x86_cpu_load_def(X86CPU *cpu, const char *name, Error **errp)
{
CPUX86State *env = &cpu->env;
-x86_def_t def1, *def = &def1;
+X86CPUDefinition def1, *def = &def1;
memset(def, 0, sizeof(*def));
@@ -1849,7 +1849,7 @@ static void x86_cpu_load_def(X86CPU *cpu, const char
*name, Error **errp)
object_property_set_str(OBJECT(cpu), def->model_id, "model-id", errp);
-/* Special cases not set in the x86_def_t structs: */
+/* Special cases not set in the X86CPUDefinition structs: */
if (kvm_enabled()) {
env->features[FEAT_KVM] |= kvm_default_features;
}
@@ -1971,7 +1971,7 @@ void x86_cpudef_setup(void)
static const char *model_with_versions[] = { "qemu32", "qemu64", "athlon"
};
for (i = 0; i < ARRAY_SIZE(builtin_x86_defs); ++i) {
-x86_def_t *def = &builtin_x86_defs[i];
+X86CPUDefinition *def = &builtin_x86_defs[i];
/* Look for specific "cpudef" models that */
/* have the QEMU version in .model_id */
Reviewed-by: Paolo Bonzini
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [uq/master PATCH 0/7] x86 CPU subclasses, take 7
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 and queuing it. Yeah, I was also wondering why uq/master too, mostly for patches 5 and 7. The first 3 patches are KVM-ish, and I can apply them if you prefer. Patches 4 and 6 are mostly trivial, but I'll leave them to you. As Eduardo points out below the commit message in the final patch, his conversion is very similar to one of my earlier patch series, so committing that with Eduardo as author via uq/master without crediting me via uq/master would leave a bad taste. I'll leave this to you to sort out. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 08/10] KVM: PPC: BOOK3S: PR: Add support for facility unavailable interrupt
Alexander Graf 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
>> ---
>> arch/powerpc/include/asm/kvm_asm.h | 4 +++-
>> arch/powerpc/kvm/book3s.c | 4
>> arch/powerpc/kvm/book3s_emulate.c | 18 ++
>> arch/powerpc/kvm/book3s_pr.c | 17 +
>> 4 files changed, 42 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/include/asm/kvm_asm.h
>> b/arch/powerpc/include/asm/kvm_asm.h
>> index 1bd92fd43cfb..799244face51 100644
>> --- a/arch/powerpc/include/asm/kvm_asm.h
>> +++ b/arch/powerpc/include/asm/kvm_asm.h
>> @@ -99,6 +99,7 @@
>> #define BOOK3S_INTERRUPT_PERFMON 0xf00
>> #define BOOK3S_INTERRUPT_ALTIVEC 0xf20
>> #define BOOK3S_INTERRUPT_VSX 0xf40
>> +#define BOOK3S_INTERRUPT_FAC_UNAVAIL0xf60
>>
>> #define BOOK3S_IRQPRIO_SYSTEM_RESET0
>> #define BOOK3S_IRQPRIO_DATA_SEGMENT1
>> @@ -117,7 +118,8 @@
>> #define BOOK3S_IRQPRIO_DECREMENTER 14
>> #define BOOK3S_IRQPRIO_PERFORMANCE_MONITOR 15
>> #define BOOK3S_IRQPRIO_EXTERNAL_LEVEL 16
>> -#define BOOK3S_IRQPRIO_MAX 17
>> +#define BOOK3S_IRQPRIO_FAC_UNAVAIL 17
>> +#define BOOK3S_IRQPRIO_MAX 18
>>
>> #define BOOK3S_HFLAG_DCBZ320x1
>> #define BOOK3S_HFLAG_SLB 0x2
>> diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
>> index 8912608b7e1b..a9aea28c2677 100644
>> --- a/arch/powerpc/kvm/book3s.c
>> +++ b/arch/powerpc/kvm/book3s.c
>> @@ -143,6 +143,7 @@ static int kvmppc_book3s_vec2irqprio(unsigned int vec)
>> case 0xd00: prio = BOOK3S_IRQPRIO_DEBUG;break;
>> case 0xf20: prio = BOOK3S_IRQPRIO_ALTIVEC; break;
>> case 0xf40: prio = BOOK3S_IRQPRIO_VSX; break;
>> +case 0xf60: prio = BOOK3S_IRQPRIO_FAC_UNAVAIL; break;
>> default:prio = BOOK3S_IRQPRIO_MAX; break;
>> }
>>
>> @@ -273,6 +274,9 @@ int kvmppc_book3s_irqprio_deliver(struct kvm_vcpu *vcpu,
>> unsigned int priority)
>> case BOOK3S_IRQPRIO_PERFORMANCE_MONITOR:
>> vec = BOOK3S_INTERRUPT_PERFMON;
>> break;
>> +case BOOK3S_IRQPRIO_FAC_UNAVAIL:
>> +vec = BOOK3S_INTERRUPT_FAC_UNAVAIL;
>> +break;
>> default:
>> deliver = 0;
>> printk(KERN_ERR "KVM: Unknown interrupt: 0x%x\n", priority);
>> diff --git a/arch/powerpc/kvm/book3s_emulate.c
>> b/arch/powerpc/kvm/book3s_emulate.c
>> index 60d0b6b745e7..bf6b11021250 100644
>> --- a/arch/powerpc/kvm/book3s_emulate.c
>> +++ b/arch/powerpc/kvm/book3s_emulate.c
>> @@ -481,6 +481,15 @@ int kvmppc_core_emulate_mtspr_pr(struct kvm_vcpu *vcpu,
>> int sprn, ulong spr_val)
>> vcpu->arch.shadow_fscr = vcpu->arch.fscr & host_fscr;
>> break;
>> }
>> +case SPRN_EBBHR:
>> +vcpu->arch.ebbhr = spr_val;
>> +break;
>> +case SPRN_EBBRR:
>> +vcpu->arch.ebbrr = spr_val;
>> +break;
>> +case SPRN_BESCR:
>> +vcpu->arch.bescr = spr_val;
>> +break;
>> unprivileged:
>> default:
>> printk(KERN_INFO "KVM: invalid SPR write: %d\n", sprn);
>> @@ -607,6 +616,15 @@ int kvmppc_core_emulate_mfspr_pr(struct kvm_vcpu *vcpu,
>> int sprn, ulong *spr_val
>> case SPRN_FSCR:
>> *spr_val = vcpu->arch.fscr;
>> break;
>> +case SPRN_EBBHR:
>> +*spr_val = vcpu->arch.ebbhr;
>> +break;
>> +case SPRN_EBBRR:
>> +*spr_val = vcpu->arch.ebbrr;
>> +break;
>> +case SPRN_BESCR:
>> +*spr_val = vcpu->arch.bescr;
>> +break;
>> default:
>> unprivileged:
>> printk(KERN_INFO "KVM: invalid SPR read: %d\n", sprn);
>> diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
>> index 51d469f8c9fd..828056ec208f 100644
>> --- a/arch/powerpc/kvm/book3s_pr.c
>> +++ b/arch/powerpc/kvm/book3s_pr.c
>> @@ -900,6 +900,23 @@ int kvmppc_handle_exit_pr(struct kvm_run *run, struct
>> kvm_vcpu *vcpu,
>> case BOOK3S_INTERRUPT_PERFMON:
>> r = RESUME_GUEST;
>> break;
>> +case BOOK3S_INTERRUPT_FAC_UNAVAIL:
>> +{
>> +/*
>> + * Check for the facility that need to be emulated
>> + */
>> +ulong fscr_ic = vcpu->arch.shadow_fscr >> 56;
>> +if (fscr_ic != FSCR_EBB_LG) {
>> +/*
>> + * We only disable EBB facility.
>> + * So only emulate that.
>
> I don't understand the comment. We emulate nothing at all here. We either
> - hit an EBB unavailable in which case we send the guest an illegal
> instr
Re: [PULL 5/8] KVM: async_pf: Provide additional direct page notification
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
+}
+
This is not used, should it be used in kvm_check_async_pf_completion?
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [uq/master PATCH 0/7] x86 CPU subclasses, take 7
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 > uq/master pull request tomorrow or Tuesday, after I've done some more > testing on enlightenments. I can squeeze this in too. Negative, not without my review. It's clearly a CPU series, and apart from having been on vacation pretty much all of December, Eduardo and others have objected to my subclass series the last 2 *years*, so 2 months is peanuts by comparison. 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 and queuing it. As Eduardo points out below the commit message in the final patch, his conversion is very similar to one of my earlier patch series, so committing that with Eduardo as author via uq/master without crediting me via uq/master would leave a bad taste. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 07/10] KVM: PPC: BOOK3S: PR: Emulate facility status and control register
Paul Mackerras 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 >> facility unavailable interrupt, if the facility is allowed by fscr >> but disabled in shadow_fscr we need to emulate the support. Currently >> all but EBB is disabled. We still don't support performance monitoring >> in PR guest. > > ... > >> +/* >> + * Save the current fscr in shadow fscr >> + */ >> +mfspr r3,SPRN_FSCR >> +PPC_STL r3, VCPU_SHADOW_FSCR(r7) > > I don't think you need to do this. What could possibly have changed > FSCR since we loaded it on the way into the guest? The reason for facility unavailable interrupt is encoded in FSCR right ? -aneesh -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 03/10] KVM: PPC: BOOK3S: PR: Emulate instruction counter
On 31.01.2014, at 12:25, Aneesh Kumar K.V
wrote:
> Alexander Graf 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
>>> ---
>>> arch/powerpc/include/asm/kvm_host.h | 1 +
>>> arch/powerpc/kvm/book3s_emulate.c | 3 +++
>>> arch/powerpc/kvm/book3s_pr.c| 2 ++
>>> 3 files changed, 6 insertions(+)
>>>
>>> diff --git a/arch/powerpc/include/asm/kvm_host.h
>>> b/arch/powerpc/include/asm/kvm_host.h
>>> index 9ebdd12e50a9..e0b13aca98e6 100644
>>> --- a/arch/powerpc/include/asm/kvm_host.h
>>> +++ b/arch/powerpc/include/asm/kvm_host.h
>>> @@ -509,6 +509,7 @@ struct kvm_vcpu_arch {
>>> /* Time base value when we entered the guest */
>>> u64 entry_tb;
>>> u64 entry_vtb;
>>> + u64 entry_ic;
>>> u32 tcr;
>>> ulong tsr; /* we need to perform set/clr_bits() which requires ulong */
>>> u32 ivor[64];
>>> diff --git a/arch/powerpc/kvm/book3s_emulate.c
>>> b/arch/powerpc/kvm/book3s_emulate.c
>>> index 4b58d8a90cb5..abe6f3057e5b 100644
>>> --- a/arch/powerpc/kvm/book3s_emulate.c
>>> +++ b/arch/powerpc/kvm/book3s_emulate.c
>>> @@ -531,6 +531,9 @@ int kvmppc_core_emulate_mfspr_pr(struct kvm_vcpu *vcpu,
>>> int sprn, ulong *spr_val
>>> case SPRN_VTB:
>>> *spr_val = vcpu->arch.vtb;
>>> break;
>>> + case SPRN_IC:
>>> + *spr_val = vcpu->arch.ic;
>>> + break;
>>> case SPRN_GQR0:
>>> case SPRN_GQR1:
>>> case SPRN_GQR2:
>>> diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
>>> index b5598e9cdd09..51d469f8c9fd 100644
>>> --- a/arch/powerpc/kvm/book3s_pr.c
>>> +++ b/arch/powerpc/kvm/book3s_pr.c
>>> @@ -121,6 +121,7 @@ void kvmppc_copy_to_svcpu(struct
>>> kvmppc_book3s_shadow_vcpu *svcpu,
>>> */
>>> vcpu->arch.entry_tb = get_tb();
>>> vcpu->arch.entry_vtb = get_vtb();
>>> + vcpu->arch.entry_ic = mfspr(SPRN_IC);
>>
>> Is this implemented on all systems?
>>
>>>
>>> }
>>>
>>> @@ -174,6 +175,7 @@ out:
>>> vcpu->arch.purr += get_tb() - vcpu->arch.entry_tb;
>>> vcpu->arch.spurr += get_tb() - vcpu->arch.entry_tb;
>>> vcpu->arch.vtb += get_vtb() - vcpu->arch.entry_vtb;
>>> + vcpu->arch.ic += mfspr(SPRN_IC) - vcpu->arch.entry_ic;
>>
>> This is getting quite convoluted. How about we act slightly more fuzzy
>> and put all of this into vcpu_load/put?
>>
>
> I am not sure whether vcpu_load/put is too early/late to save these
> context ?
It'd mean we treat instruction emulation as part of guest overhead and time,
but we'd make the entry/exit path faster. Unlike with HV KVM, guest entry/exit
is pretty hot due to the massive amounts of instruction emulation we need to do.
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 03/10] KVM: PPC: BOOK3S: PR: Emulate instruction counter
Alexander Graf 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
>> ---
>> arch/powerpc/include/asm/kvm_host.h | 1 +
>> arch/powerpc/kvm/book3s_emulate.c | 3 +++
>> arch/powerpc/kvm/book3s_pr.c| 2 ++
>> 3 files changed, 6 insertions(+)
>>
>> diff --git a/arch/powerpc/include/asm/kvm_host.h
>> b/arch/powerpc/include/asm/kvm_host.h
>> index 9ebdd12e50a9..e0b13aca98e6 100644
>> --- a/arch/powerpc/include/asm/kvm_host.h
>> +++ b/arch/powerpc/include/asm/kvm_host.h
>> @@ -509,6 +509,7 @@ struct kvm_vcpu_arch {
>> /* Time base value when we entered the guest */
>> u64 entry_tb;
>> u64 entry_vtb;
>> +u64 entry_ic;
>> u32 tcr;
>> ulong tsr; /* we need to perform set/clr_bits() which requires ulong */
>> u32 ivor[64];
>> diff --git a/arch/powerpc/kvm/book3s_emulate.c
>> b/arch/powerpc/kvm/book3s_emulate.c
>> index 4b58d8a90cb5..abe6f3057e5b 100644
>> --- a/arch/powerpc/kvm/book3s_emulate.c
>> +++ b/arch/powerpc/kvm/book3s_emulate.c
>> @@ -531,6 +531,9 @@ int kvmppc_core_emulate_mfspr_pr(struct kvm_vcpu *vcpu,
>> int sprn, ulong *spr_val
>> case SPRN_VTB:
>> *spr_val = vcpu->arch.vtb;
>> break;
>> +case SPRN_IC:
>> +*spr_val = vcpu->arch.ic;
>> +break;
>> case SPRN_GQR0:
>> case SPRN_GQR1:
>> case SPRN_GQR2:
>> diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
>> index b5598e9cdd09..51d469f8c9fd 100644
>> --- a/arch/powerpc/kvm/book3s_pr.c
>> +++ b/arch/powerpc/kvm/book3s_pr.c
>> @@ -121,6 +121,7 @@ void kvmppc_copy_to_svcpu(struct
>> kvmppc_book3s_shadow_vcpu *svcpu,
>> */
>> vcpu->arch.entry_tb = get_tb();
>> vcpu->arch.entry_vtb = get_vtb();
>> +vcpu->arch.entry_ic = mfspr(SPRN_IC);
>
> Is this implemented on all systems?
>
>>
>> }
>>
>> @@ -174,6 +175,7 @@ out:
>> vcpu->arch.purr += get_tb() - vcpu->arch.entry_tb;
>> vcpu->arch.spurr += get_tb() - vcpu->arch.entry_tb;
>> vcpu->arch.vtb += get_vtb() - vcpu->arch.entry_vtb;
>> +vcpu->arch.ic += mfspr(SPRN_IC) - vcpu->arch.entry_ic;
>
> This is getting quite convoluted. How about we act slightly more fuzzy
> and put all of this into vcpu_load/put?
>
I am not sure whether vcpu_load/put is too early/late to save these
context ?
-aneesh
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 02/10] KVM: PPC: BOOK3S: PR: Emulate virtual timebase register
Paul Mackerras 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 CONFIG_PPC_BOOK3S_64
>> +#define mfvtb() ({unsigned long rval;
>> \
>> +asm volatile("mfspr %0, %1" : \
>> + "=r" (rval) : "i" (SPRN_VTB)); rval;})
>
> The mfspr will be a no-op on anything before POWER8, meaning the
> result will be whatever value was in the destination GPR before the
> mfspr. I suppose that may not matter if the result is only ever used
> when we're running on a POWER8 host, but I would feel more comfortable
> if we had explicit feature tests to make sure of that, rather than
> possibly doing computations with unpredictable values.
>
> With your patch, a guest on a POWER7 or a PPC970 could do a read from
> VTB and get garbage -- first, there is nothing to stop userspace from
> requesting POWER8 emulation on an older machine, and secondly, even if
> the virtual machine is a PPC970 (say) you don't implement
> unimplemented SPR semantics for VTB (no-op if PR=0, illegal
> instruction interrupt if PR=1).
Ok that means we need to do something like ?
struct cpu_spec *s = find_cpuspec(vcpu->arch.pvr);
if (s->cpu_features & CPU_FTR_ARCH_207S) {
}
>
> On the whole I think it is reasonable to reject an attempt to set the
> virtual PVR to a POWER8 PVR value if we are not running on a POWER8
> host, because emulating all the new POWER8 features in software
> (particularly transactional memory) would not be feasible. Alex may
> disagree. :)
That would make it much simpler.
-aneesh
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 01/10] KVM: PPC: BOOK3S: PR: Fix PURR and SPURR emulation
On 31.01.2014, at 11:38, Aneesh Kumar K.V wrote: > Alexander Graf 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 tell the guest it uses 100%" to >> "give the guest an accurate amount of cpu time spent inside guest >> context". > > Will fix that > >> >> Also, I think we either go with full hyp semantics which means we also >> emulate the offset or we go with no hyp awareness in the guest at all >> which means we also don't emulate SPURR which is a hyp privileged >> register. > > Can you clarify this ? In the 2.06 ISA SPURR is hypervisor privileged. That changed for 2.07 where it became supervisor privileged. So I suppose your patch is ok. When reviewing those patches I only had 2.06 around because power.org was broken. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 01/10] KVM: PPC: BOOK3S: PR: Fix PURR and SPURR emulation
Alexander Graf 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 tell the guest it uses 100%" to > "give the guest an accurate amount of cpu time spent inside guest > context". Will fix that > > Also, I think we either go with full hyp semantics which means we also > emulate the offset or we go with no hyp awareness in the guest at all > which means we also don't emulate SPURR which is a hyp privileged > register. Can you clarify this ? > > Otherwise I like the patch :). > -aneesh -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
