[PATCH RESEND] virtio: Fix typecast of pointer in vring_init()
The virtio_ring.h header is used in userspace programs (ie. QEMU), too. Here we can not assume that sizeof(pointer) is the same as sizeof(long), e.g. when compiling for Windows, so the typecast in vring_init() should be done with (uintptr_t) instead of (unsigned long). Signed-off-by: Thomas Huth th...@redhat.com --- include/uapi/linux/virtio_ring.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/uapi/linux/virtio_ring.h b/include/uapi/linux/virtio_ring.h index 915980a..8682551 100644 --- a/include/uapi/linux/virtio_ring.h +++ b/include/uapi/linux/virtio_ring.h @@ -143,7 +143,7 @@ static inline void vring_init(struct vring *vr, unsigned int num, void *p, vr-num = num; vr-desc = p; vr-avail = p + num*sizeof(struct vring_desc); - vr-used = (void *)(((unsigned long)vr-avail-ring[num] + sizeof(__virtio16) + vr-used = (void *)(((uintptr_t)vr-avail-ring[num] + sizeof(__virtio16) + align-1) ~(align - 1)); } -- 1.8.3.1 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PULL] virtio/vhost: cross endian support
On Wed, Jul 01, 2015 at 12:03:59PM -0700, Linus Torvalds wrote: On Wed, Jul 1, 2015 at 12:02 PM, Linus Torvalds torva...@linux-foundation.org wrote: Doing a unconditional byte swap is faster and simpler than the crazy conditionals. Unconditional endianness not only makes for simpler and faster code, it also ends up being easier to debug and add things like type annotations for sparse. Linus At least this last one is well covered by these patches: this uses separate sparse types so all accesses are statically verified by sparse to use the correct accessor. -- MST ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PULL] virtio/vhost: cross endian support
On Wed, Jul 01, 2015 at 12:02:50PM -0700, Linus Torvalds wrote: On Wed, Jul 1, 2015 at 2:31 AM, Michael S. Tsirkin m...@redhat.com wrote: virtio/vhost: cross endian support Ugh. Does this really have to be dynamic? Can't virtio do the sane thing, and just use a _fixed_ endianness? Doing a unconditional byte swap is faster and simpler than the crazy conditionals. That's true regardless of endianness, but gets to be even more so if the fixed endianness is little-endian, since BE is not-so-slowly fading from the world. Linus Yea, well - support for legacy BE guests on the new LE hosts is exactly the motivation for this. I dislike it too, but there are two redeeming properties that made me merge this: 1. It's a trivial amount of code: since we wrap host/guest accesses anyway, almost all of it is well hidden from drivers. 2. Sane platforms would never set flags like VHOST_CROSS_ENDIAN_LEGACY - and when it's clear, there's zero overhead (as some point it was tested by compiling with and without the patches, got the same stripped binary). Maybe we could create a Kconfig symbol to enforce point (2): prevent people from enabling it e.g. on x86. I will look into this - but it can be done by a patch on top, so I think this can be merged as is. Or do you know of someone using kernel with all config options enabled undiscriminately? Thanks, -- MST ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [RFC] virtio_net: Adding tx_timeout function.
On Wed, Jun 24, 2015 at 10:31:09PM -0300, Julio Faracco wrote:
2015-06-24 3:10 GMT-03:00 Michael S. Tsirkin m...@redhat.com:
On Tue, Jun 23, 2015 at 10:44:29PM -0300, Julio Faracco wrote:
virtio_net paravirtualized driver does not have a tx_timeout() function
to
guarantee that the driver will recover properly after receiving a
timeout
during a transmission of a packet. This patch add this feature and
throw a
timeout exception after 5 HZ. Considering some tests, this is the best
time to use here.
Signed-off-by: Julio Faracco jcfara...@gmail.com
Cc: Jason Wang jasow...@redhat.com
Looks like a bunch of locks and flushes are missing in this patch. IMHO
that's just too painful with current hardware. IMO the right thing to
do here is to add ability to reset specific queues to hardware.
I agree, Michael. This model is the default one resetting the device
due to transmission timeout.
To have a better performance, only some queues must be reset.
It's not a question of performance. You would need to write
a bunch of code anyway. Why not do it in the hypervisor
so guest can simply write into a register and reset
a ring?
BTW now that I think about it, this requires Jason's
patches that introduce the tx interrupt, otherwise
packet will timeout simply because no packets are sent.
I am trying to understand how TX interrupt patches will help
here? This function will be called when driver fails to send
packets. Even before TX interrupt patches, packets are flowing.
Is my understanding wrong some where?
---
drivers/net/virtio_net.c | 69
+-
1 file changed, 68 insertions(+), 1 deletion(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 63c7810..75ac45c 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -135,6 +135,9 @@ struct virtnet_info {
/* Work struct for config space updates */
struct work_struct config_work;
+ /* Work struct for resetting the virtio-net driver. */
+ struct work_struct reset_task;
+
/* Does the affinity hint is set for virtqueues? */
bool affinity_hint_set;
@@ -1394,6 +1397,18 @@ static int virtnet_change_mtu(struct net_device
*dev, int new_mtu)
return 0;
}
+static void virtnet_tx_timeout(struct net_device *dev)
+{
+ struct virtnet_info *vi = netdev_priv(dev);
+
+ dev_warn(dev-dev, TX Timeout exception with latency: %ld\n,
+ jiffies - dev_trans_start(dev));
+
+ schedule_work(vi-reset_task);
What if after this triggers user does something
to the device (e.g. attempts to remove it)?
Or if a packet is transmitted or used?
At some point, this work must be canceled.
Yes, you are right. Specially, when the driver is being removed.
+}
+
+static void virtnet_reset_task(struct work_struct *work);
+
static const struct net_device_ops virtnet_netdev = {
.ndo_open= virtnet_open,
.ndo_stop= virtnet_close,
@@ -1405,6 +1420,7 @@ static const struct net_device_ops virtnet_netdev
= {
.ndo_get_stats64 = virtnet_stats,
.ndo_vlan_rx_add_vid = virtnet_vlan_rx_add_vid,
.ndo_vlan_rx_kill_vid = virtnet_vlan_rx_kill_vid,
+ .ndo_tx_timeout = virtnet_tx_timeout,
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller = virtnet_netpoll,
#endif
@@ -1750,6 +1766,7 @@ static int virtnet_probe(struct virtio_device
*vdev)
dev-netdev_ops = virtnet_netdev;
dev-features = NETIF_F_HIGHDMA;
+ dev-watchdog_timeo = 5 * HZ;
dev-ethtool_ops = virtnet_ethtool_ops;
SET_NETDEV_DEV(dev, vdev-dev);
@@ -1811,6 +1828,7 @@ static int virtnet_probe(struct virtio_device
*vdev)
}
INIT_WORK(vi-config_work, virtnet_config_changed_work);
+ INIT_WORK(vi-reset_task, virtnet_reset_task);
/* If we can receive ANY GSO packets, we must allocate large
ones. */
if (virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_TSO4) ||
@@ -1891,7 +1909,7 @@ static int virtnet_probe(struct virtio_device
*vdev)
netif_carrier_on(dev);
}
- pr_debug(virtnet: registered device %s with %d RX and TX
vq's\n,
+ pr_debug(virtio_net: registered device %s with %d RX and TX
vq's\n,
dev-name, max_queue_pairs);
return 0;
@@ -2001,6 +2019,55 @@ static int virtnet_restore(struct virtio_device
*vdev)
}
#endif
+static void virtnet_reset_task(struct work_struct *work)
+{
+ struct virtnet_info *vi =
+ container_of(work, struct virtnet_info, reset_task);
+ struct net_device *dev
Re: [PULL] virtio/vhost: cross endian support
On Thu, 2 Jul 2015 08:01:28 +0200 Michael S. Tsirkin m...@redhat.com wrote: On Wed, Jul 01, 2015 at 12:02:50PM -0700, Linus Torvalds wrote: On Wed, Jul 1, 2015 at 2:31 AM, Michael S. Tsirkin m...@redhat.com wrote: virtio/vhost: cross endian support Ugh. Does this really have to be dynamic? Can't virtio do the sane thing, and just use a _fixed_ endianness? Doing a unconditional byte swap is faster and simpler than the crazy conditionals. That's true regardless of endianness, but gets to be even more so if the fixed endianness is little-endian, since BE is not-so-slowly fading from the world. Linus Yea, well - support for legacy BE guests on the new LE hosts is exactly the motivation for this. I dislike it too, but there are two redeeming properties that made me merge this: 1. It's a trivial amount of code: since we wrap host/guest accesses anyway, almost all of it is well hidden from drivers. 2. Sane platforms would never set flags like VHOST_CROSS_ENDIAN_LEGACY - and when it's clear, there's zero overhead (as some point it was tested by compiling with and without the patches, got the same stripped binary). Maybe we could create a Kconfig symbol to enforce point (2): prevent people from enabling it e.g. on x86. I will look into this - but it can be done by a patch on top, so I think this can be merged as is. This cross-endian *oddity* is targeting PowerPC book3s_64 processors... I am not aware of any other users. Maybe create a symbol that would be only selected by PPC_BOOK3S_64 ? Or do you know of someone using kernel with all config options enabled undiscriminately? Thanks, ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] MAINTAINERS: separate section for s390 virtio drivers
Am 01.07.2015 um 17:15 schrieb Cornelia Huck: The s390-specific virtio drivers have probably more to do with virtio than with kvm today; let's move them out into a separate section to reflect this and to be able to add relevant mailing lists. CC: Christian Borntraeger borntrae...@de.ibm.com Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com Acked-by: Christian Borntraeger borntrae...@de.ibm.com --- MAINTAINERS | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 246d9d8..fca5c00 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5766,7 +5766,6 @@ S: Supported F: Documentation/s390/kvm.txt F: arch/s390/include/asm/kvm* F: arch/s390/kvm/ -F: drivers/s390/kvm/ KERNEL VIRTUAL MACHINE (KVM) FOR ARM M: Christoffer Dall christoffer.d...@linaro.org @@ -10671,6 +10670,15 @@ F: drivers/block/virtio_blk.c F: include/linux/virtio_*.h F: include/uapi/linux/virtio_*.h +VIRTIO DRIVERS FOR S390 +M: Christian Borntraeger borntrae...@de.ibm.com +M: Cornelia Huck cornelia.h...@de.ibm.com +L: linux-s...@vger.kernel.org +L: virtualization@lists.linux-foundation.org +L: k...@vger.kernel.org +S: Supported +F: drivers/s390/kvm/ + VIRTIO HOST (VHOST) M: Michael S. Tsirkin m...@redhat.com L: k...@vger.kernel.org ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH] virtio: define virtio_pci_cfg_cap in header.
We already have VIRTIO_PCI_CAP_PCI_CFG, let's define the structure that
goes with it.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
include/uapi/linux/virtio_pci.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/uapi/linux/virtio_pci.h b/include/uapi/linux/virtio_pci.h
index 7530146..90007a1 100644
--- a/include/uapi/linux/virtio_pci.h
+++ b/include/uapi/linux/virtio_pci.h
@@ -157,6 +157,12 @@ struct virtio_pci_common_cfg {
__le32 queue_used_hi; /* read-write */
};
+/* Fields in VIRTIO_PCI_CAP_PCI_CFG: */
+struct virtio_pci_cfg_cap {
+ struct virtio_pci_cap cap;
+ __u8 pci_cfg_data[4]; /* Data for BAR access. */
+};
+
/* Macro versions of offsets for the Old Timers! */
#define VIRTIO_PCI_CAP_VNDR0
#define VIRTIO_PCI_CAP_NEXT1
--
MST
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[RFC PATCH 1/1] mshyperv: fix recognition of Hyper-V guest crash MSR's
From: Andrey Smetanin asmeta...@virtuozzo.com
Hypervisor Top Level Functional Specification v3.1/4.0 notes that cpuid
(0x4003) EDX's 10th bit should be used to check that Hyper-V guest
crash MSR's functionality available.
This patch should fix this recognition. Currently the code checks EAX
register instead of EDX.
Signed-off-by: Andrey Smetanin asmeta...@virtuozzo.com
Signed-off-by: Denis V. Lunev d...@openvz.org
CC: Nick Meier nme...@microsoft.com
CC: K. Y. Srinivasan k...@microsoft.com
CC: Haiyang Zhang haiya...@microsoft.com
---
arch/x86/include/asm/mshyperv.h | 1 +
arch/x86/kernel/cpu/mshyperv.c | 1 +
drivers/hv/vmbus_drv.c | 4 ++--
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index c163215..eebe433 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -7,6 +7,7 @@
struct ms_hyperv_info {
u32 features;
+ u32 misc_features;
u32 hints;
};
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index aad4bd8..6d172a2 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -114,6 +114,7 @@ static void __init ms_hyperv_init_platform(void)
* Extract the features and hints
*/
ms_hyperv.features = cpuid_eax(HYPERV_CPUID_FEATURES);
+ ms_hyperv.misc_features = cpuid_edx(HYPERV_CPUID_FEATURES);
ms_hyperv.hints= cpuid_eax(HYPERV_CPUID_ENLIGHTMENT_INFO);
printk(KERN_INFO HyperV: features 0x%x, hints 0x%x\n,
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index cf20400..67af13a 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -841,7 +841,7 @@ static int vmbus_bus_init(int irq)
/*
* Only register if the crash MSRs are available
*/
- if (ms_hyperv.features HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE) {
+ if (ms_hyperv.misc_features HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE) {
atomic_notifier_chain_register(panic_notifier_list,
hyperv_panic_block);
}
@@ -1110,7 +1110,7 @@ static void __exit vmbus_exit(void)
hv_remove_vmbus_irq();
tasklet_kill(msg_dpc);
vmbus_free_channels();
- if (ms_hyperv.features HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE) {
+ if (ms_hyperv.misc_features HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE) {
atomic_notifier_chain_unregister(panic_notifier_list,
hyperv_panic_block);
}
--
2.1.4
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PULL] virtio/vhost: cross endian support
On Thu, Jul 02, 2015 at 11:12:56AM +0200, Greg Kurz wrote: On Thu, 2 Jul 2015 08:01:28 +0200 Michael S. Tsirkin m...@redhat.com wrote: On Wed, Jul 01, 2015 at 12:02:50PM -0700, Linus Torvalds wrote: On Wed, Jul 1, 2015 at 2:31 AM, Michael S. Tsirkin m...@redhat.com wrote: virtio/vhost: cross endian support Ugh. Does this really have to be dynamic? Can't virtio do the sane thing, and just use a _fixed_ endianness? Doing a unconditional byte swap is faster and simpler than the crazy conditionals. That's true regardless of endianness, but gets to be even more so if the fixed endianness is little-endian, since BE is not-so-slowly fading from the world. Linus Yea, well - support for legacy BE guests on the new LE hosts is exactly the motivation for this. I dislike it too, but there are two redeeming properties that made me merge this: 1. It's a trivial amount of code: since we wrap host/guest accesses anyway, almost all of it is well hidden from drivers. 2. Sane platforms would never set flags like VHOST_CROSS_ENDIAN_LEGACY - and when it's clear, there's zero overhead (as some point it was tested by compiling with and without the patches, got the same stripped binary). Maybe we could create a Kconfig symbol to enforce point (2): prevent people from enabling it e.g. on x86. I will look into this - but it can be done by a patch on top, so I think this can be merged as is. This cross-endian *oddity* is targeting PowerPC book3s_64 processors... I am not aware of any other users. Maybe create a symbol that would be only selected by PPC_BOOK3S_64 ? I think some ARM systems are trying to support cross-endian configurations as well. Besides that, yes, this is more or less what I had in mind. Or do you know of someone using kernel with all config options enabled undiscriminately? Thanks, ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [RFC] virtio_net: Adding tx_timeout function.
On Thu, Jul 02, 2015 at 03:23:56AM -0400, Pankaj Gupta wrote:
On Wed, Jun 24, 2015 at 10:31:09PM -0300, Julio Faracco wrote:
2015-06-24 3:10 GMT-03:00 Michael S. Tsirkin m...@redhat.com:
On Tue, Jun 23, 2015 at 10:44:29PM -0300, Julio Faracco wrote:
virtio_net paravirtualized driver does not have a tx_timeout()
function
to
guarantee that the driver will recover properly after receiving a
timeout
during a transmission of a packet. This patch add this feature and
throw a
timeout exception after 5 HZ. Considering some tests, this is the best
time to use here.
Signed-off-by: Julio Faracco jcfara...@gmail.com
Cc: Jason Wang jasow...@redhat.com
Looks like a bunch of locks and flushes are missing in this patch. IMHO
that's just too painful with current hardware. IMO the right thing to
do here is to add ability to reset specific queues to hardware.
I agree, Michael. This model is the default one resetting the device
due to transmission timeout.
To have a better performance, only some queues must be reset.
It's not a question of performance. You would need to write
a bunch of code anyway. Why not do it in the hypervisor
so guest can simply write into a register and reset
a ring?
BTW now that I think about it, this requires Jason's
patches that introduce the tx interrupt, otherwise
packet will timeout simply because no packets are sent.
I am trying to understand how TX interrupt patches will help
here? This function will be called when driver fails to send
packets. Even before TX interrupt patches, packets are flowing.
Is my understanding wrong some where?
Without tx interrupts, skbs are never freed until you send
more packets. Which might never happen.
---
drivers/net/virtio_net.c | 69
+-
1 file changed, 68 insertions(+), 1 deletion(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 63c7810..75ac45c 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -135,6 +135,9 @@ struct virtnet_info {
/* Work struct for config space updates */
struct work_struct config_work;
+ /* Work struct for resetting the virtio-net driver. */
+ struct work_struct reset_task;
+
/* Does the affinity hint is set for virtqueues? */
bool affinity_hint_set;
@@ -1394,6 +1397,18 @@ static int virtnet_change_mtu(struct net_device
*dev, int new_mtu)
return 0;
}
+static void virtnet_tx_timeout(struct net_device *dev)
+{
+ struct virtnet_info *vi = netdev_priv(dev);
+
+ dev_warn(dev-dev, TX Timeout exception with latency: %ld\n,
+ jiffies - dev_trans_start(dev));
+
+ schedule_work(vi-reset_task);
What if after this triggers user does something
to the device (e.g. attempts to remove it)?
Or if a packet is transmitted or used?
At some point, this work must be canceled.
Yes, you are right. Specially, when the driver is being removed.
+}
+
+static void virtnet_reset_task(struct work_struct *work);
+
static const struct net_device_ops virtnet_netdev = {
.ndo_open= virtnet_open,
.ndo_stop= virtnet_close,
@@ -1405,6 +1420,7 @@ static const struct net_device_ops
virtnet_netdev
= {
.ndo_get_stats64 = virtnet_stats,
.ndo_vlan_rx_add_vid = virtnet_vlan_rx_add_vid,
.ndo_vlan_rx_kill_vid = virtnet_vlan_rx_kill_vid,
+ .ndo_tx_timeout = virtnet_tx_timeout,
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller = virtnet_netpoll,
#endif
@@ -1750,6 +1766,7 @@ static int virtnet_probe(struct virtio_device
*vdev)
dev-netdev_ops = virtnet_netdev;
dev-features = NETIF_F_HIGHDMA;
+ dev-watchdog_timeo = 5 * HZ;
dev-ethtool_ops = virtnet_ethtool_ops;
SET_NETDEV_DEV(dev, vdev-dev);
@@ -1811,6 +1828,7 @@ static int virtnet_probe(struct virtio_device
*vdev)
}
INIT_WORK(vi-config_work, virtnet_config_changed_work);
+ INIT_WORK(vi-reset_task, virtnet_reset_task);
/* If we can receive ANY GSO packets, we must allocate large
ones. */
if (virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_TSO4) ||
@@ -1891,7 +1909,7 @@ static int virtnet_probe(struct virtio_device
*vdev)
netif_carrier_on(dev);
}
- pr_debug(virtnet: registered device %s with %d RX and TX
vq's\n,
+ pr_debug(virtio_net: registered device %s with %d RX and TX
vq's\n,
dev-name, max_queue_pairs);
return 0;
@@
Re: [RFC PATCH 1/1] mshyperv: fix recognition of Hyper-V guest crash MSR's
Denis V. Lunev d...@openvz.org writes:
From: Andrey Smetanin asmeta...@virtuozzo.com
Hypervisor Top Level Functional Specification v3.1/4.0 notes that cpuid
(0x4003) EDX's 10th bit should be used to check that Hyper-V guest
crash MSR's functionality available.
This patch should fix this recognition. Currently the code checks EAX
register instead of EDX.
Signed-off-by: Andrey Smetanin asmeta...@virtuozzo.com
Signed-off-by: Denis V. Lunev d...@openvz.org
CC: Nick Meier nme...@microsoft.com
CC: K. Y. Srinivasan k...@microsoft.com
CC: Haiyang Zhang haiya...@microsoft.com
Something went wrong and I don't see K.Y. on the CC: list of your
email. Fixed now.
---
arch/x86/include/asm/mshyperv.h | 1 +
arch/x86/kernel/cpu/mshyperv.c | 1 +
drivers/hv/vmbus_drv.c | 4 ++--
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index c163215..eebe433 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -7,6 +7,7 @@
struct ms_hyperv_info {
u32 features;
+ u32 misc_features;
u32 hints;
};
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index aad4bd8..6d172a2 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -114,6 +114,7 @@ static void __init ms_hyperv_init_platform(void)
* Extract the features and hints
*/
ms_hyperv.features = cpuid_eax(HYPERV_CPUID_FEATURES);
+ ms_hyperv.misc_features = cpuid_edx(HYPERV_CPUID_FEATURES);
ms_hyperv.hints= cpuid_eax(HYPERV_CPUID_ENLIGHTMENT_INFO);
printk(KERN_INFO HyperV: features 0x%x, hints 0x%x\n,
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index cf20400..67af13a 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -841,7 +841,7 @@ static int vmbus_bus_init(int irq)
/*
* Only register if the crash MSRs are available
*/
- if (ms_hyperv.features HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE) {
+ if (ms_hyperv.misc_features HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE) {
atomic_notifier_chain_register(panic_notifier_list,
hyperv_panic_block);
}
@@ -1110,7 +1110,7 @@ static void __exit vmbus_exit(void)
hv_remove_vmbus_irq();
tasklet_kill(msg_dpc);
vmbus_free_channels();
- if (ms_hyperv.features HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE) {
+ if (ms_hyperv.misc_features HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE) {
atomic_notifier_chain_unregister(panic_notifier_list,
hyperv_panic_block);
}
--
Vitaly
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
