kvm_pv_eoi: add flag support

PATCH Applied Michael S. Tsirkin 4 participants 6 messages Jul 1, 2012 – Jul 13, 2012 KVM

Share & tools

Michael S. Tsirkin

author

2012-07-01 15:08 UTC #0 lore raw

PATCH v2 1/1 kvm_pv_eoi: add flag support

Support the new PV EOI flag in kvm - it recently got merged into kvm.git. Set by default with -cpu kvm.
Set for -cpu qemu by adding +kvm_pv_eoi.
Clear by adding -kvm_pv_eoi to -cpu option.

Signed-off-by Michael S. Tsirkin <[email protected]>

---

Changes from v1:
rebased to uq/master

 target-i386/cpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

target-i386/cpu.c +1 -1

index 5521709..ee1b64a 100644
@@ -77,7 +77,7 @@ static const char *ext3_feature_name[] = {
 };
 
 static const char *kvm_feature_name[] = {
-    "kvmclock", "kvm_nopiodelay", "kvm_mmu", "kvmclock", "kvm_asyncpf", NULL, NULL, NULL,
+    "kvmclock", "kvm_nopiodelay", "kvm_mmu", "kvmclock", "kvm_asyncpf", NULL, "kvm_pv_eoi", NULL,
     NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
     NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
     NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,

Signature · 1 line

MST

Marcelo Tosatti

Applied

2012-07-03 20:08 UTC #1 lore raw

Quoted 6 lines · Michael S. Tsirkin

Support the new PV EOI flag in kvm - it recently got merged into kvm.git. Set by default with -cpu kvm.
Set for -cpu qemu by adding +kvm_pv_eoi.
Clear by adding -kvm_pv_eoi to -cpu option.
Signed-off-by Michael S. Tsirkin <[email protected]>

Applied to uq/master, thanks.

Dor Laor

2012-07-10 08:40 UTC #2 lore raw

In reply to Michael S. Tsirkin

Quoted 4 lines · Michael S. Tsirkin

Support the new PV EOI flag in kvm - it recently got merged into kvm.git. Set by default with -cpu kvm.
Set for -cpu qemu by adding +kvm_pv_eoi.
Clear by adding -kvm_pv_eoi to -cpu option.

What about adding them to our cpu models?
It should go w/o saying for all models (SandyBridge, OpteronGx,..) but there is the issue of backward compat. I remember we had a discussion about pair the models w/ the current machine type (-M) but I don't remember the final call.

What's your take Eduardo?

Cheers,
Dor

Quoted 24 lines

Signed-off-by Michael S. Tsirkin <[email protected]>

---

Changes from v1:
rebased to uq/master

  target-i386/cpu.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

target-i386/cpu.c +1 -1

index 5521709..ee1b64a 100644
@@ -77,7 +77,7 @@ static const char *ext3_feature_name[] = {
  };
 
  static const char *kvm_feature_name[] = {
-    "kvmclock", "kvm_nopiodelay", "kvm_mmu", "kvmclock", "kvm_asyncpf", NULL, NULL, NULL,
+    "kvmclock", "kvm_nopiodelay", "kvm_mmu", "kvmclock", "kvm_asyncpf", NULL, "kvm_pv_eoi", NULL,
      NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
      NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
      NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,

Eduardo Habkost

2012-07-10 12:55 UTC #3 lore raw

Quoted 6 lines · Dor Laor

Quoted 4 lines · Michael S. Tsirkin
Support the new PV EOI flag in kvm - it recently got merged into kvm.git. Set by default with -cpu kvm.
Set for -cpu qemu by adding +kvm_pv_eoi.
Clear by adding -kvm_pv_eoi to -cpu option.

Quoted 7 lines

What about adding them to our cpu models?
It should go w/o saying for all models (SandyBridge, OpteronGx,..) but there is the issue of backward compat. I remember we had a discussion about pair the models w/ the current machine type (-M) but I don't remember the final call.
What's your take Eduardo?

We can really add it, but only after adding the infra-structure to allow "versioned" CPU models (with per-machine-type aliases for backwards compatibility with older machine types).

(The current status of this is "I am going to implement it", but there's no code do do that yet).

Quoted 30 lines

Cheers,
Dor

Quoted 24 lines

Signed-off-by Michael S. Tsirkin <[email protected]>

---

Changes from v1:
rebased to uq/master

 target-i386/cpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

target-i386/cpu.c +1 -1

index 5521709..ee1b64a 100644
@@ -77,7 +77,7 @@ static const char *ext3_feature_name[] = {
 };
 
 static const char *kvm_feature_name[] = {
-    "kvmclock", "kvm_nopiodelay", "kvm_mmu", "kvmclock", "kvm_asyncpf", NULL, NULL, NULL,
+    "kvmclock", "kvm_nopiodelay", "kvm_mmu", "kvmclock", "kvm_asyncpf", NULL, "kvm_pv_eoi", NULL,
     NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
     NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
     NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,

Signature · 1 line

Eduardo

Michael S. Tsirkin

author

2012-07-13 00:03 UTC #4 lore raw

Quoted 13 lines · Eduardo Habkost

Quoted 12 lines · Dor Laor
Quoted 4 lines · Michael S. Tsirkin
Support the new PV EOI flag in kvm - it recently got merged into kvm.git. Set by default with -cpu kvm.
Set for -cpu qemu by adding +kvm_pv_eoi.
Clear by adding -kvm_pv_eoi to -cpu option.
What about adding them to our cpu models?
It should go w/o saying for all models (SandyBridge, OpteronGx,..) but there is the issue of backward compat. I remember we had a discussion about pair the models w/ the current machine type (-M) but I don't remember the final call.

Quoted 8 lines

Quoted 1 line
What's your take Eduardo?
We can really add it, but only after adding the infra-structure to allow "versioned" CPU models (with per-machine-type aliases for backwards compatibility with older machine types).
(The current status of this is "I am going to implement it", but there's no code do do that yet).

OK so I'll just wait and you'll make it happen?
Also is libvirt support needed?

Quoted 33 lines

Quoted 30 lines

Cheers,
Dor

Quoted 24 lines

Signed-off-by Michael S. Tsirkin <[email protected]>

---

Changes from v1:
rebased to uq/master

 target-i386/cpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

target-i386/cpu.c +1 -1

index 5521709..ee1b64a 100644
@@ -77,7 +77,7 @@ static const char *ext3_feature_name[] = {
 };
 
 static const char *kvm_feature_name[] = {
-    "kvmclock", "kvm_nopiodelay", "kvm_mmu", "kvmclock", "kvm_asyncpf", NULL, NULL, NULL,
+    "kvmclock", "kvm_nopiodelay", "kvm_mmu", "kvmclock", "kvm_asyncpf", NULL, "kvm_pv_eoi", NULL,
     NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
     NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
     NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,

Signature · 1 line

Eduardo

Eduardo Habkost

2012-07-13 13:30 UTC #5 lore raw

Quoted 16 lines · Michael S. Tsirkin

Quoted 15 lines · Eduardo Habkost
Quoted 13 lines · Dor Laor
Quoted 4 lines · Michael S. Tsirkin
Support the new PV EOI flag in kvm - it recently got merged into kvm.git. Set by default with -cpu kvm.
Set for -cpu qemu by adding +kvm_pv_eoi.
Clear by adding -kvm_pv_eoi to -cpu option.
What about adding them to our cpu models?
It should go w/o saying for all models (SandyBridge, OpteronGx,..) but there is the issue of backward compat. I remember we had a discussion about pair the models w/ the current machine type (-M) but I don't remember the final call.
What's your take Eduardo?

Quoted 8 lines

Quoted 6 lines
We can really add it, but only after adding the infra-structure to allow "versioned" CPU models (with per-machine-type aliases for backwards compatibility with older machine types).
(The current status of this is "I am going to implement it", but there's no code do do that yet).
OK so I'll just wait and you'll make it happen?

Yes, when we start supporting versioned CPU models, I can send a patch to add kvm_pv_eoi to the existing models on newer machine-types.

Quoted 1 line

Also is libvirt support needed?

Only if we want to allow libvirt to control the feature directly. Otherwise, it would be simply controlled just by the machine-type + cpu-model combination.

In either case, it will probably be better to add libvirt support only after we have the proper QEMU<->libvirt CPU feature probing interface implemented.

Signature · 1 line

Eduardo