kvm: notify host when the guest is panicked

We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm.

Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked.

We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.

We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when startint the kernel

Signed-off-by Wen Congyang <[email protected]>

---
 arch/ia64/include/asm/kvm_para.h    |    5 +++++
 arch/powerpc/include/asm/kvm_para.h |    5 +++++
 arch/s390/include/asm/kvm_para.h    |    5 +++++
 arch/x86/include/asm/kvm_para.h     |    7 +++++++
 arch/x86/kernel/kvm.c               |   14 ++++++++++++++
 include/linux/kvm_para.h            |   13 +++++++++++++
 6 files changed, 49 insertions(+), 0 deletions(-)

arch/ia64/include/asm/kvm_para.h +5 -0

index 2019cb9..187c0e2 100644
@@ -31,6 +31,11 @@ static inline bool kvm_check_and_clear_guest_paused(void)
 	return false;
 }
 
+static inline unsigned int kvm_arch_pv_features(void)
+{
+	return 0;
+}
+
 #endif
 
 #endif

arch/powerpc/include/asm/kvm_para.h +5 -0

index c18916b..be81aac 100644
@@ -211,6 +211,11 @@ static inline bool kvm_check_and_clear_guest_paused(void)
 	return false;
 }
 
+static inline unsigned int kvm_arch_pv_features(void)
+{
+	return 0;
+}
+
 #endif /* __KERNEL__ */
 
 #endif /* __POWERPC_KVM_PARA_H__ */

arch/s390/include/asm/kvm_para.h +5 -0

index a988329..3d993b7 100644
@@ -154,6 +154,11 @@ static inline bool kvm_check_and_clear_guest_paused(void)
 	return false;
 }
 
+static inline unsigned int kvm_arch_pv_features(void)
+{
+	return 0;
+}
+
 #endif
 
 #endif /* __S390_KVM_PARA_H */

arch/x86/include/asm/kvm_para.h +7 -0

index 63ab166..c8ad86e 100644
@@ -89,6 +89,8 @@ struct kvm_vcpu_pv_apf_data {
 	__u32 enabled;
 };
 
+#define KVM_PV_PORT	(0x505UL)
+
 #ifdef __KERNEL__
 #include <asm/processor.h>
 

@@ -221,6 +223,11 @@ static inline void kvm_disable_steal_time(void)
 }
 #endif
 
+static inline unsigned int kvm_arch_pv_features(void)
+{
+	return inl(KVM_PV_PORT);
+}
+
 #endif /* __KERNEL__ */
 
 #endif /* _ASM_X86_KVM_PARA_H */

arch/x86/kernel/kvm.c +14 -0

index e554e5a..9a97f7e 100644
@@ -328,6 +328,17 @@ static struct notifier_block kvm_pv_reboot_nb = {
 	.notifier_call = kvm_pv_reboot_notify,
 };
 
+static int
+kvm_pv_panic_notify(struct notifier_block *nb, unsigned long code, void *unused)
+{
+	outl(KVM_PV_PANICKED, KVM_PV_PORT);
+	return NOTIFY_DONE;
+}
+
+static struct notifier_block kvm_pv_panic_nb = {
+	.notifier_call = kvm_pv_panic_notify,
+};
+
 static u64 kvm_steal_clock(int cpu)
 {
 	u64 steal;

@@ -414,6 +425,9 @@ void __init kvm_guest_init(void)
 
 	paravirt_ops_setup();
 	register_reboot_notifier(&kvm_pv_reboot_nb);
+	if (kvm_pv_has_feature(KVM_PV_FEATURE_PANICKED))
+		atomic_notifier_chain_register(&panic_notifier_list,
+			&kvm_pv_panic_nb);
 	for (i = 0; i < KVM_TASK_SLEEP_HASHSIZE; i++)
 		spin_lock_init(&async_pf_sleepers[i].lock);
 	if (kvm_para_has_feature(KVM_FEATURE_ASYNC_PF))

include/linux/kvm_para.h +6 -0

index ff476dd..e73efcf 100644
@@ -20,6 +20,12 @@
 #define KVM_HC_FEATURES			3
 #define KVM_HC_PPC_MAP_MAGIC_PAGE	4
 
+/* The bit of the value read from KVM_PV_PORT */
+#define KVM_PV_FEATURE_PANICKED	0
+
+/* The value writen to KVM_PV_PORT */
+#define KVM_PV_PANICKED		1
+
 /*
  * hypercalls use architecture specific
  */

include/linux/kvm_para.h +3 -0

+		return 1;
+	return 0;
+}
 #endif /* __KERNEL__ */
 #endif /* __LINUX_KVM_PARA_H */

Quoted 154 lines

We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm.

Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked.

We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.

We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when startint the kernel

Signed-off-by Wen Congyang <[email protected]>

---
 arch/ia64/include/asm/kvm_para.h    |    5 +++++
 arch/powerpc/include/asm/kvm_para.h |    5 +++++
 arch/s390/include/asm/kvm_para.h    |    5 +++++
 arch/x86/include/asm/kvm_para.h     |    7 +++++++
 arch/x86/kernel/kvm.c               |   14 ++++++++++++++
 include/linux/kvm_para.h            |   13 +++++++++++++
 6 files changed, 49 insertions(+), 0 deletions(-)

arch/ia64/include/asm/kvm_para.h +5 -0

index 2019cb9..187c0e2 100644
@@ -31,6 +31,11 @@ static inline bool kvm_check_and_clear_guest_paused(void)
 	return false;
 }
 
+static inline unsigned int kvm_arch_pv_features(void)
+{
+	return 0;
+}
+
 #endif
 
 #endif

arch/powerpc/include/asm/kvm_para.h +5 -0

index c18916b..be81aac 100644
@@ -211,6 +211,11 @@ static inline bool kvm_check_and_clear_guest_paused(void)
 	return false;
 }
 
+static inline unsigned int kvm_arch_pv_features(void)
+{
+	return 0;
+}
+
 #endif /* __KERNEL__ */
 
 #endif /* __POWERPC_KVM_PARA_H__ */

arch/s390/include/asm/kvm_para.h +5 -0

index a988329..3d993b7 100644
@@ -154,6 +154,11 @@ static inline bool kvm_check_and_clear_guest_paused(void)
 	return false;
 }
 
+static inline unsigned int kvm_arch_pv_features(void)
+{
+	return 0;
+}
+
 #endif
 
 #endif /* __S390_KVM_PARA_H */

arch/x86/include/asm/kvm_para.h +7 -0

index 63ab166..c8ad86e 100644
@@ -89,6 +89,8 @@ struct kvm_vcpu_pv_apf_data {
 	__u32 enabled;
 };
 
+#define KVM_PV_PORT	(0x505UL)
+
 #ifdef __KERNEL__
 #include <asm/processor.h>
 

@@ -221,6 +223,11 @@ static inline void kvm_disable_steal_time(void)
 }
 #endif
 
+static inline unsigned int kvm_arch_pv_features(void)
+{
+	return inl(KVM_PV_PORT);
+}
+
 #endif /* __KERNEL__ */
 
 #endif /* _ASM_X86_KVM_PARA_H */

arch/x86/kernel/kvm.c +14 -0

index e554e5a..9a97f7e 100644
@@ -328,6 +328,17 @@ static struct notifier_block kvm_pv_reboot_nb = {
 	.notifier_call = kvm_pv_reboot_notify,
 };
 
+static int
+kvm_pv_panic_notify(struct notifier_block *nb, unsigned long code, void *unused)
+{
+	outl(KVM_PV_PANICKED, KVM_PV_PORT);
+	return NOTIFY_DONE;
+}
+
+static struct notifier_block kvm_pv_panic_nb = {
+	.notifier_call = kvm_pv_panic_notify,
+};
+
 static u64 kvm_steal_clock(int cpu)
 {
 	u64 steal;

@@ -414,6 +425,9 @@ void __init kvm_guest_init(void)
 
 	paravirt_ops_setup();
 	register_reboot_notifier(&kvm_pv_reboot_nb);
+	if (kvm_pv_has_feature(KVM_PV_FEATURE_PANICKED))
+		atomic_notifier_chain_register(&panic_notifier_list,
+			&kvm_pv_panic_nb);
 	for (i = 0; i < KVM_TASK_SLEEP_HASHSIZE; i++)
 		spin_lock_init(&async_pf_sleepers[i].lock);
 	if (kvm_para_has_feature(KVM_FEATURE_ASYNC_PF))

include/linux/kvm_para.h +6 -0

index ff476dd..e73efcf 100644
@@ -20,6 +20,12 @@
 #define KVM_HC_FEATURES			3
 #define KVM_HC_PPC_MAP_MAGIC_PAGE	4
 
+/* The bit of the value read from KVM_PV_PORT */
+#define KVM_PV_FEATURE_PANICKED	0
+
+/* The value writen to KVM_PV_PORT */
+#define KVM_PV_PANICKED		1
+
 /*
  * hypercalls use architecture specific
  */

@@ -33,5 +39,12 @@ static inline int kvm_para_has_feature(unsigned int feature)
 		return 1;
 	return 0;

include/linux/kvm_para.h static inline int kvm_para_has_feature(unsigned int feature) · line 45

Quoted 5 lines

include/linux/kvm_para.h +4 -0

 }
+
+static inline int kvm_pv_has_feature(unsigned int feature)
+{
+	if (kvm_arch_pv_features() & (1UL << feature))

Reading from an invalid I/O port will return -1. So your test will deliver a wrong result on a platform that doesn't support this PV channel.

Jan

Quoted 6 lines

include/linux/kvm_para.h +3 -0

+		return 1;
+	return 0;
+}
 #endif /* __KERNEL__ */
 #endif /* __LINUX_KVM_PARA_H */

We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm.

Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked.

We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.

We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel

Quoted 13 lines · Wen Congyang

We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm.

Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked.

We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.

Quoted 5 lines

We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel

Was the option of implementing a virtio-watchdog driver considered?

You're basically re-implementing a watchdog, a guest-host interface and a set of protocols for guest-host communications.

Why can't we re-use everything we have now, push a virtio watchdog driver into drivers/watchdog/, and gain a more complete solution to detecting hangs inside the guest.

Quoted 20 lines · Sasha Levin

Quoted 13 lines · Wen Congyang

We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm.

Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked.

We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.

Quoted 5 lines

We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel

Quoted 7 lines

Was the option of implementing a virtio-watchdog driver considered?

You're basically re-implementing a watchdog, a guest-host interface and a set of protocols for guest-host communications.

Why can't we re-use everything we have now, push a virtio watchdog driver into drivers/watchdog/, and gain a more complete solution to detecting hangs inside the guest.

The purpose of virtio is not to reinvent every possible type of device. There are plenty of hardware watchdogs that are very suitable to be used for this purpose. QEMU implements quite a few already.

Watchdogs are not performance sensitive so there's no point in using virtio.

Quoted 34 lines · Anthony Liguori

Quoted 20 lines · Sasha Levin

Quoted 13 lines · Wen Congyang

We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm.

Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked.

We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.

Quoted 5 lines

We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel

Quoted 7 lines

Was the option of implementing a virtio-watchdog driver considered?

You're basically re-implementing a watchdog, a guest-host interface and a set of protocols for guest-host communications.

Why can't we re-use everything we have now, push a virtio watchdog driver into drivers/watchdog/, and gain a more complete solution to detecting hangs inside the guest.

The purpose of virtio is not to reinvent every possible type of device. There are plenty of hardware watchdogs that are very suitable to be used for this purpose. QEMU implements quite a few already.

Quoted 2 lines

Watchdogs are not performance sensitive so there's no point in using virtio.

The issue here is not performance, but the adding of a brand new guest-host interface.

virtio-rng isn't performance sensitive either, yet it was implemented using virtio so there wouldn't be yet another interface to communicate between guest and host.

This patch goes ahead to add a "arch pv features" interface using ioports, without any idea what it might be used for beyond this watchdog.

Quoted 35 lines · Sasha Levin

Quoted 34 lines · Anthony Liguori

Quoted 20 lines · Sasha Levin

Quoted 13 lines · Wen Congyang

We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm.

Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked.

We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.

Quoted 5 lines

We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel

Quoted 7 lines

Was the option of implementing a virtio-watchdog driver considered?

You're basically re-implementing a watchdog, a guest-host interface and a set of protocols for guest-host communications.

Why can't we re-use everything we have now, push a virtio watchdog driver into drivers/watchdog/, and gain a more complete solution to detecting hangs inside the guest.

The purpose of virtio is not to reinvent every possible type of device. There are plenty of hardware watchdogs that are very suitable to be used for this purpose. QEMU implements quite a few already.

Quoted 5 lines

Quoted 2 lines

Watchdogs are not performance sensitive so there's no point in using virtio.

The issue here is not performance, but the adding of a brand new guest-host interface.

We have:

1) Virtio--this is our preferred PV interface. It needs PCI to be fully initialized and probably will live as a module.

2) Hypercalls--this a secondary PV interface but is available very early. It's terminated in kvm.ko which means it can only operate on things that are logically part of the CPU and/or APIC complex.

This patch introduces a third interface which is available early like hypercalls but not necessarily terminated in kvm.ko. That means it can have a broader scope in functionality than (2).

We could just as well use a hypercall and have multiple commands issued to that hypercall as a convention and add a new exit type to KVM that sent that specific hypercall to userspace for processing.

But a PIO operation already has this behavior and requires no changes to kvm.ko.

Quoted 56 lines

Quoted 35 lines · Sasha Levin

Quoted 34 lines · Anthony Liguori

Quoted 20 lines · Sasha Levin

Quoted 13 lines · Wen Congyang

We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm.

Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked.

We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.

Quoted 5 lines

We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel

Quoted 7 lines

Was the option of implementing a virtio-watchdog driver considered?

You're basically re-implementing a watchdog, a guest-host interface and a set of protocols for guest-host communications.

Why can't we re-use everything we have now, push a virtio watchdog driver into drivers/watchdog/, and gain a more complete solution to detecting hangs inside the guest.

The purpose of virtio is not to reinvent every possible type of device. There are plenty of hardware watchdogs that are very suitable to be used for this purpose. QEMU implements quite a few already.

Quoted 5 lines

Quoted 2 lines

Watchdogs are not performance sensitive so there's no point in using virtio.

The issue here is not performance, but the adding of a brand new guest-host interface.

We have:

1) Virtio--this is our preferred PV interface. It needs PCI to be fully initialized and probably will live as a module.

2) Hypercalls--this a secondary PV interface but is available very early. It's terminated in kvm.ko which means it can only operate on things that are logically part of the CPU and/or APIC complex.

This patch introduces a third interface which is available early like hypercalls but not necessarily terminated in kvm.ko. That means it can have a broader scope in functionality than (2).

Quoted 5 lines

We could just as well use a hypercall and have multiple commands issued to that hypercall as a convention and add a new exit type to KVM that sent that specific hypercall to userspace for processing.

But a PIO operation already has this behavior and requires no changes to kvm.ko.

I don't dispute that there may be a need for another guest-host interface, but this patch can basically be called "kvm: notify host when the guest is panicked, oh, btw, and add a brand new undocumented interface"

The new interface should at least come in it's own patch, with documentation. --
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Quoted 13 lines

We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm.

Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked.

We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.

Quoted 5 lines

We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel

Was the option of implementing a virtio-watchdog driver considered?

You're basically re-implementing a watchdog, a guest-host interface and a set of protocols for guest-host communications.

Why can't we re-use everything we have now, push a virtio watchdog driver into drivers/watchdog/, and gain a more complete solution to detecting hangs inside the guest. --
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

arch/x86/include/asm/kvm_para.h +2 -0

+#define KVM_PV_PORT	(0x505UL)
+
 #ifdef __KERNEL__
 #include <asm/processor.h>

Quoted 6 lines · Wen Congyang

arch/x86/include/asm/kvm_para.h +2 -0

+#define KVM_PV_PORT	(0x505UL)
+
 #ifdef __KERNEL__
 #include <asm/processor.h>

arch/x86/include/asm/kvm_para.h static inline void kvm_disable_steal_time(void) · line 230

Quoted 8 lines

arch/x86/include/asm/kvm_para.h +5 -0

@@ -221,6 +223,11 @@ static inline void kvm_disable_steal_time(void)
 }
 #endif
 
+static inline unsigned int kvm_arch_pv_features(void)
+{
+	return inl(KVM_PV_PORT);
+}
+

Why is this safe?

I'm not sure you can just pick any ioport you'd like and use it.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 18 lines · Sasha Levin

Quoted 6 lines · Wen Congyang

arch/x86/include/asm/kvm_para.h +2 -0

+#define KVM_PV_PORT	(0x505UL)
+
 #ifdef __KERNEL__
 #include <asm/processor.h>

arch/x86/include/asm/kvm_para.h static inline void kvm_disable_steal_time(void) · line 230

Quoted 8 lines

arch/x86/include/asm/kvm_para.h +5 -0

@@ -221,6 +223,11 @@ static inline void kvm_disable_steal_time(void)
 }
 #endif
 
+static inline unsigned int kvm_arch_pv_features(void)
+{
+	return inl(KVM_PV_PORT);
+}
+

Why is this safe?

Quoted 1 line

I'm not sure you can just pick any ioport you'd like and use it.

There are three ways I/O ports get used on a PC:

1) Platform devices
- This is well defined since the vast majority of platform devices are implemented within a single chip. If you're emulating an i440fx chipset, the PIIX4 spec has an exhaustive list.

2) PCI devices
- Typically, PCI only allocates ports starting at 0x0d00 to avoid conflicts with ISA devices.

3) ISA devices
- ISA uses subtractive decoding so any ISA device can access. In theory, an ISA device could attempt to use port 0x0505 but it's unlikely. In a modern guest, there aren't really any ISA devices being added either.

So yes, picking port 0x0505 is safe for something like this (as long as you check to make sure that you really are under KVM).

Quoted 33 lines · Anthony Liguori

Quoted 18 lines · Sasha Levin

Quoted 6 lines · Wen Congyang

arch/x86/include/asm/kvm_para.h +2 -0

+#define KVM_PV_PORT	(0x505UL)
+
 #ifdef __KERNEL__
 #include <asm/processor.h>

arch/x86/include/asm/kvm_para.h static inline void kvm_disable_steal_time(void) · line 230

Quoted 8 lines

arch/x86/include/asm/kvm_para.h +5 -0

@@ -221,6 +223,11 @@ static inline void kvm_disable_steal_time(void)
 }
 #endif
 
+static inline unsigned int kvm_arch_pv_features(void)
+{
+	return inl(KVM_PV_PORT);
+}
+

Why is this safe?

Quoted 1 line

I'm not sure you can just pick any ioport you'd like and use it.

There are three ways I/O ports get used on a PC:

1) Platform devices
- This is well defined since the vast majority of platform devices are implemented within a single chip. If you're emulating an i440fx chipset, the PIIX4 spec has an exhaustive list.

2) PCI devices
- Typically, PCI only allocates ports starting at 0x0d00 to avoid conflicts with ISA devices.

Quoted 8 lines

3) ISA devices
- ISA uses subtractive decoding so any ISA device can access. In theory, an ISA device could attempt to use port 0x0505 but it's unlikely. In a modern guest, there aren't really any ISA devices being added either.

So yes, picking port 0x0505 is safe for something like this (as long as you check to make sure that you really are under KVM).

Is there anything that actually prevents me from using PCI ports lower than 0x0d00? As you said in (3), ISA isn't really used anymore (nor is implemented by lkvm for example), so placing PCI below 0x0d00 might even make sense in that case.

Furthermore, I can place one of these brand new virtio-mmio devices which got introduced recently wherever I want right now - Having a device that uses 0x505 would cause a pretty non-obvious failure mode.

Either way, If we are going to grab an ioport, then:

- It should be documented well somewhere in Documentation/virt/kvm
- It should go through request_region() to actually claim those ioports.
- It should fail gracefully if that port is taken for some reason, instead of not even checking it.

Quoted 45 lines · Sasha Levin

Quoted 33 lines · Anthony Liguori

Quoted 18 lines · Sasha Levin

Quoted 6 lines · Wen Congyang

arch/x86/include/asm/kvm_para.h +2 -0

+#define KVM_PV_PORT	(0x505UL)
+
 #ifdef __KERNEL__
 #include <asm/processor.h>

arch/x86/include/asm/kvm_para.h static inline void kvm_disable_steal_time(void) · line 230

Quoted 8 lines

arch/x86/include/asm/kvm_para.h +5 -0

@@ -221,6 +223,11 @@ static inline void kvm_disable_steal_time(void)
 }
 #endif
 
+static inline unsigned int kvm_arch_pv_features(void)
+{
+	return inl(KVM_PV_PORT);
+}
+

Why is this safe?

Quoted 1 line

I'm not sure you can just pick any ioport you'd like and use it.

There are three ways I/O ports get used on a PC:

1) Platform devices
- This is well defined since the vast majority of platform devices are implemented within a single chip. If you're emulating an i440fx chipset, the PIIX4 spec has an exhaustive list.

2) PCI devices
- Typically, PCI only allocates ports starting at 0x0d00 to avoid conflicts with ISA devices.

Quoted 8 lines

3) ISA devices
- ISA uses subtractive decoding so any ISA device can access. In theory, an ISA device could attempt to use port 0x0505 but it's unlikely. In a modern guest, there aren't really any ISA devices being added either.

So yes, picking port 0x0505 is safe for something like this (as long as you check to make sure that you really are under KVM).

Is there anything that actually prevents me from using PCI ports lower than 0x0d00? As you said in (3), ISA isn't really used anymore (nor is implemented by lkvm for example), so placing PCI below 0x0d00 might even make sense in that case.

Quoted 8 lines

Furthermore, I can place one of these brand new virtio-mmio devices which got introduced recently wherever I want right now - Having a device that uses 0x505 would cause a pretty non-obvious failure mode.

Either way, If we are going to grab an ioport, then:

- It should be documented well somewhere in Documentation/virt/kvm
- It should go through request_region() to actually claim those ioports.
- It should fail gracefully if that port is taken for some reason, instead of not even checking it.

Out of curiosity I tested that, and apparently lkvm has no problem allocating virtio-pci devices in that range:

sh-4.2# pwd /sys/devices/pci0000:00/0000:00:01.0
sh-4.2# cat resource | head -n1 0x0000000000000500 0x00000000000005ff 0x0000000000040101

This was with the commit in question applied.

Quoted 62 lines · Sasha Levin

Quoted 45 lines · Sasha Levin

Quoted 33 lines · Anthony Liguori

Quoted 18 lines · Sasha Levin

Quoted 6 lines · Wen Congyang

arch/x86/include/asm/kvm_para.h +2 -0

+#define KVM_PV_PORT	(0x505UL)
+
 #ifdef __KERNEL__
 #include <asm/processor.h>

arch/x86/include/asm/kvm_para.h static inline void kvm_disable_steal_time(void) · line 230

Quoted 8 lines

arch/x86/include/asm/kvm_para.h +5 -0

@@ -221,6 +223,11 @@ static inline void kvm_disable_steal_time(void)
 }
 #endif
 
+static inline unsigned int kvm_arch_pv_features(void)
+{
+	return inl(KVM_PV_PORT);
+}
+

Why is this safe?

Quoted 1 line

I'm not sure you can just pick any ioport you'd like and use it.

There are three ways I/O ports get used on a PC:

1) Platform devices
- This is well defined since the vast majority of platform devices are implemented within a single chip. If you're emulating an i440fx chipset, the PIIX4 spec has an exhaustive list.

2) PCI devices
- Typically, PCI only allocates ports starting at 0x0d00 to avoid conflicts with ISA devices.

Quoted 8 lines

3) ISA devices
- ISA uses subtractive decoding so any ISA device can access. In theory, an ISA device could attempt to use port 0x0505 but it's unlikely. In a modern guest, there aren't really any ISA devices being added either.

So yes, picking port 0x0505 is safe for something like this (as long as you check to make sure that you really are under KVM).

Is there anything that actually prevents me from using PCI ports lower than 0x0d00? As you said in (3), ISA isn't really used anymore (nor is implemented by lkvm for example), so placing PCI below 0x0d00 might even make sense in that case.

Quoted 8 lines

Furthermore, I can place one of these brand new virtio-mmio devices which got introduced recently wherever I want right now - Having a device that uses 0x505 would cause a pretty non-obvious failure mode.

Either way, If we are going to grab an ioport, then:

- It should be documented well somewhere in Documentation/virt/kvm
- It should go through request_region() to actually claim those ioports.
- It should fail gracefully if that port is taken for some reason, instead of not even checking it.

Out of curiosity I tested that, and apparently lkvm has no problem allocating virtio-pci devices in that range:

sh-4.2# pwd /sys/devices/pci0000:00/0000:00:01.0
sh-4.2# cat resource | head -n1 0x0000000000000500 0x00000000000005ff 0x0000000000040101

Quoted 1 line

This was with the commit in question applied.

With all due respect, lkvm has a half-baked implementation of PCI. This is why you have to pass kernel parameters to disable ACPI and disable PCI BIOS probing.

So yeah, you can do funky things in lkvm but that doesn't mean a system that emulated actual hardware would ever do that.

Quoted 39 lines · Anthony Liguori

Quoted 18 lines · Sasha Levin

Quoted 6 lines · Wen Congyang

arch/x86/include/asm/kvm_para.h +2 -0

+#define KVM_PV_PORT	(0x505UL)
+
 #ifdef __KERNEL__
 #include <asm/processor.h>

arch/x86/include/asm/kvm_para.h static inline void kvm_disable_steal_time(void) · line 230

Quoted 8 lines

arch/x86/include/asm/kvm_para.h +5 -0

@@ -221,6 +223,11 @@ static inline void kvm_disable_steal_time(void)
 }
 #endif
 
+static inline unsigned int kvm_arch_pv_features(void)
+{
+	return inl(KVM_PV_PORT);
+}
+

Why is this safe?

Quoted 1 line

I'm not sure you can just pick any ioport you'd like and use it.

There are three ways I/O ports get used on a PC:

1) Platform devices
- This is well defined since the vast majority of platform devices are implemented within a single chip. If you're emulating an i440fx chipset, the PIIX4 spec has an exhaustive list.

2) PCI devices
- Typically, PCI only allocates ports starting at 0x0d00 to avoid conflicts with ISA devices.

3) ISA devices
- ISA uses subtractive decoding so any ISA device can access. In theory, an ISA device could attempt to use port 0x0505 but it's unlikely. In a modern guest, there aren't really any ISA devices being added either.

Quoted 2 lines

So yes, picking port 0x0505 is safe for something like this (as long as you check to make sure that you really are under KVM).

Is there anything that actually prevents me from using PCI ports lower than 0x0d00? As you said in (3), ISA isn't really used anymore (nor is implemented by lkvm for example), so placing PCI below 0x0d00 might even make sense in that case.

Furthermore, I can place one of these brand new virtio-mmio devices which got introduced recently wherever I want right now - Having a device that uses 0x505 would cause a pretty non-obvious failure mode.

Either way, If we are going to grab an ioport, then:

- It should be documented well somewhere in Documentation/virt/kvm
- It should go through request_region() to actually claim those ioports.
- It should fail gracefully if that port is taken for some reason, instead of not even checking it.

Quoted 33 lines

Quoted 18 lines · Sasha Levin

Quoted 6 lines · Wen Congyang

arch/x86/include/asm/kvm_para.h +2 -0

+#define KVM_PV_PORT	(0x505UL)
+
 #ifdef __KERNEL__
 #include <asm/processor.h>

arch/x86/include/asm/kvm_para.h static inline void kvm_disable_steal_time(void) · line 230

Quoted 8 lines

arch/x86/include/asm/kvm_para.h +5 -0

@@ -221,6 +223,11 @@ static inline void kvm_disable_steal_time(void)
 }
 #endif
 
+static inline unsigned int kvm_arch_pv_features(void)
+{
+	return inl(KVM_PV_PORT);
+}
+

Why is this safe?

Quoted 1 line

I'm not sure you can just pick any ioport you'd like and use it.

There are three ways I/O ports get used on a PC:

1) Platform devices
- This is well defined since the vast majority of platform devices are implemented within a single chip. If you're emulating an i440fx chipset, the PIIX4 spec has an exhaustive list.

2) PCI devices
- Typically, PCI only allocates ports starting at 0x0d00 to avoid conflicts with ISA devices.

Quoted 8 lines

3) ISA devices
- ISA uses subtractive decoding so any ISA device can access. In theory, an ISA device could attempt to use port 0x0505 but it's unlikely. In a modern guest, there aren't really any ISA devices being added either.

So yes, picking port 0x0505 is safe for something like this (as long as you check to make sure that you really are under KVM).

Is there anything that actually prevents me from using PCI ports lower than 0x0d00? As you said in (3), ISA isn't really used anymore (nor is implemented by lkvm for example), so placing PCI below 0x0d00 might even make sense in that case.

Furthermore, I can place one of these brand new virtio-mmio devices which got introduced recently wherever I want right now - Having a device that uses 0x505 would cause a pretty non-obvious failure mode.

Either way, If we are going to grab an ioport, then:

- It should be documented well somewhere in Documentation/virt/kvm
- It should go through request_region() to actually claim those ioports.

- It should fail gracefully if that port is taken for some reason, instead of not even checking it.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/