Re: [PATCH v2] staging: android: ion: Zero CMA allocated memory
On Wed, 24 Jan 2018, Laura Abbott wrote:
> On 01/22/2018 09:46 AM, Liam Mark wrote:
> > Since commit 204f672255c2 ("staging: android: ion: Use CMA APIs directly")
> > the CMA API is now used directly and therefore the allocated memory is no
> > longer automatically zeroed.
> >
> > Explicitly zero CMA allocated memory to ensure that no data is exposed to
> > userspace.
> >
> > Fixes: 204f672255c2 ("staging: android: ion: Use CMA APIs directly")
> > Signed-off-by: Liam Mark
> > ---
> > Changes in v2:
> >- Clean up the commit message.
> >- Add 'Fixes:'
> >
> > drivers/staging/android/ion/ion_cma_heap.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/staging/android/ion/ion_cma_heap.c
> > b/drivers/staging/android/ion/ion_cma_heap.c
> > index 86196ffd2faf..91a98785607a 100644
> > --- a/drivers/staging/android/ion/ion_cma_heap.c
> > +++ b/drivers/staging/android/ion/ion_cma_heap.c
> > @@ -51,6 +51,8 @@ static int ion_cma_allocate(struct ion_heap *heap, struct
> > ion_buffer *buffer,
> > if (!pages)
> > return -ENOMEM;
> >
> > + memset(page_address(pages), 0, size);
> > +
>
> This won't work for highmem pages. You need to zero by page via
> kmap_atomic in that case. You can use PageHighMem to separate the
> paths.
Thanks for catching that, I will update the patch.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: imx-media-vdic: fix inconsistent IS_ERR and PTR_ERR
Acked-by: Steve Longerbeam
On 01/23/2018 04:43 PM, Gustavo A. R. Silva wrote:
Fix inconsistent IS_ERR and PTR_ERR in vdic_get_ipu_resources.
The proper pointer to be passed as argument is ch.
This issue was detected with the help of Coccinelle.
Fixes: 0b2e9e7947e7 ("media: staging/imx: remove confusing IS_ERR_OR_NULL
usage")
Signed-off-by: Gustavo A. R. Silva
---
drivers/staging/media/imx/imx-media-vdic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/imx/imx-media-vdic.c
b/drivers/staging/media/imx/imx-media-vdic.c
index 433474d..ed35684 100644
--- a/drivers/staging/media/imx/imx-media-vdic.c
+++ b/drivers/staging/media/imx/imx-media-vdic.c
@@ -177,7 +177,7 @@ static int vdic_get_ipu_resources(struct vdic_priv *priv)
priv->vdi_in_ch = ch;
ch = ipu_idmac_get(priv->ipu, IPUV3_CHANNEL_MEM_VDI_NEXT);
- if (IS_ERR(priv->vdi_in_ch_n)) {
+ if (IS_ERR(ch)) {
err_chan = IPUV3_CHANNEL_MEM_VDI_NEXT;
ret = PTR_ERR(ch);
goto out_err_chan;
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 6/6] uio_hv_generic: support sub-channels
On Wed, 10 Jan 2018 17:42:56 +0100 Greg KH wrote: > On Tue, Jan 09, 2018 at 12:57:33PM -0800, Stephen Hemminger wrote: > > Use sysfs to allow supporting sub-channels. The userspace application > > makes request to host to create sub-channels and the UIO kernel > > driver populates the sysfs per-channel directory with a binary > > attribute file that can be used to read/write ring. > > > > Signed-off-by: Stephen Hemminger > > --- > > Documentation/driver-api/uio-howto.rst | 5 ++ > > drivers/uio/uio_hv_generic.c | 95 > > -- > > 2 files changed, 97 insertions(+), 3 deletions(-) > > > > diff --git a/Documentation/driver-api/uio-howto.rst > > b/Documentation/driver-api/uio-howto.rst > > index 693e3bd84e79..7d36a50c0484 100644 > > --- a/Documentation/driver-api/uio-howto.rst > > +++ b/Documentation/driver-api/uio-howto.rst > > @@ -709,6 +709,11 @@ The vmbus device regions are mapped into uio device > > resources: > > 3) Network receive buffer region > > 4) Network send buffer region > > > > +If a subchannel is created by a request to host, then the uio_hv_generic > > +device driver will create a sysfs binary file for the per-channel ring > > buffer. > > +For example: > > + > > /sys/bus/vmbus/devices/3811fe4d-0fa0-4b62-981a-74fc1084c757/channels/21/ring_buffer > > + > > Further information > > === > > > > No Documentation/ABI/ update for this new sysfs file? > I thought it better to put in uio documentation where it was likely to be seen. Also file doesn't exist until sub channel is created on UIO device. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/1] scsi: storvsc: Increase cmd_per_lun for higher speed devices
Increase cmd_per_lun to allow more I/Os in progress per device, particularly for NVMe's. The Hyper-V host side can handle the higher count with no issues. Signed-off-by: Michael Kelley --- drivers/scsi/storvsc_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c index f3264c4..6205107 100644 --- a/drivers/scsi/storvsc_drv.c +++ b/drivers/scsi/storvsc_drv.c @@ -1657,7 +1657,7 @@ static int storvsc_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *scmnd) .eh_timed_out = storvsc_eh_timed_out, .slave_alloc = storvsc_device_alloc, .slave_configure = storvsc_device_configure, - .cmd_per_lun = 255, + .cmd_per_lun = 2048, .this_id = -1, .use_clustering = ENABLE_CLUSTERING, /* Make sure we dont get a sg segment crosses a page boundary */ -- 1.8.3.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 1/1] scsi: storvsc: Spread interrupts when picking a channel for I/O requests
Updated/corrected two email addresses ...
> -Original Message-
> From: Michael Kelley (EOSG)
> Sent: Wednesday, January 24, 2018 2:14 PM
> To: KY Srinivasan ; Stephen Hemminger
> ;
> martin.peter...@oracle.com; lo...@microsoft.com; jbottom...@odin.com;
> de...@linuxdriverproject.org; linux-ker...@vger.kernel.org;
> linux-s...@vger.kernel.org
> Cc: Michael Kelley (EOSG)
> Subject: [PATCH 1/1] scsi: storvsc: Spread interrupts when picking a channel
> for I/O requests
>
> Update the algorithm in storvsc_do_io to look for a channel
> starting with the current CPU + 1 and wrap around (within the
> current NUMA node). This spreads VMbus interrupts more evenly
> across CPUs. Previous code always started with first CPU in
> the current NUMA node, skewing the interrupt load to that CPU.
>
> Signed-off-by: Michael Kelley
> ---
> drivers/scsi/storvsc_drv.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> index e07907d..f3264c4 100644
> --- a/drivers/scsi/storvsc_drv.c
> +++ b/drivers/scsi/storvsc_drv.c
> @@ -1310,7 +1310,8 @@ static int storvsc_do_io(struct hv_device *device,
>*/
> cpumask_and(&alloced_mask, &stor_device->alloced_cpus,
> cpumask_of_node(cpu_to_node(q_num)));
> - for_each_cpu(tgt_cpu, &alloced_mask) {
> + for_each_cpu_wrap(tgt_cpu, &alloced_mask,
> + outgoing_channel->target_cpu + 1) {
> if (tgt_cpu != outgoing_channel->target_cpu) {
> outgoing_channel =
> stor_device->stor_chns[tgt_cpu];
> --
> 1.8.3.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/1] scsi: storvsc: Spread interrupts when picking a channel for I/O requests
Update the algorithm in storvsc_do_io to look for a channel
starting with the current CPU + 1 and wrap around (within the
current NUMA node). This spreads VMbus interrupts more evenly
across CPUs. Previous code always started with first CPU in
the current NUMA node, skewing the interrupt load to that CPU.
Signed-off-by: Michael Kelley
---
drivers/scsi/storvsc_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index e07907d..f3264c4 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1310,7 +1310,8 @@ static int storvsc_do_io(struct hv_device *device,
*/
cpumask_and(&alloced_mask, &stor_device->alloced_cpus,
cpumask_of_node(cpu_to_node(q_num)));
- for_each_cpu(tgt_cpu, &alloced_mask) {
+ for_each_cpu_wrap(tgt_cpu, &alloced_mask,
+ outgoing_channel->target_cpu + 1) {
if (tgt_cpu != outgoing_channel->target_cpu) {
outgoing_channel =
stor_device->stor_chns[tgt_cpu];
--
1.8.3.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: ccree: Fix missing blank line after declaration
Fix the following warning found by checkpatch.pl
WARNING: Missing a blank line after declarations
+ struct cc_cipher_handle *blkcipher_handle = drvdata->blkcipher_handle;
+ if (blkcipher_handle) {
Signed-off-by: Kamal Heib
---
drivers/staging/ccree/cc_cipher.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/ccree/cc_cipher.c
b/drivers/staging/ccree/cc_cipher.c
index 5c7e91f1cde7..d4ac0ff2ffcf 100644
--- a/drivers/staging/ccree/cc_cipher.c
+++ b/drivers/staging/ccree/cc_cipher.c
@@ -1094,6 +1094,7 @@ int cc_cipher_free(struct cc_drvdata *drvdata)
{
struct cc_crypto_alg *t_alg, *n;
struct cc_cipher_handle *blkcipher_handle = drvdata->blkcipher_handle;
+
if (blkcipher_handle) {
/* Remove registered algs */
list_for_each_entry_safe(t_alg, n,
--
2.14.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: iio: ade7758: Expand buf_lock to cover both buffer
Hi Shreeya, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on iio/togreg] [also build test WARNING on v4.15-rc9 next-20180119] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Shreeya-Patel/Staging-iio-ade7758-Expand-buf_lock-to-cover-both-buffer/20180124-234049 base: https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg reproduce: # apt-get install sparse make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) >> drivers/staging/iio/meter/ade7758_core.c:28:5: sparse: symbol >> '__ade7758_spi_write_reg_8' was not declared. Should it be >> drivers/staging/iio/meter/ade7758_core.c:104:5: sparse: symbol >> '__ade7758_spi_read_reg_8' was not declared. Should it be Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[RFC PATCH] Staging: iio: ade7758: __ade7758_spi_write_reg_8() can be static
Fixes: c1960999e575 ("Staging: iio: ade7758: Expand buf_lock to cover both
buffer")
Signed-off-by: Fengguang Wu
---
ade7758_core.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/iio/meter/ade7758_core.c
b/drivers/staging/iio/meter/ade7758_core.c
index 7f8f8c4..5794ebb 100644
--- a/drivers/staging/iio/meter/ade7758_core.c
+++ b/drivers/staging/iio/meter/ade7758_core.c
@@ -25,7 +25,7 @@
#include "ade7758.h"
/* Unlocked version of ade7758_spi_write_reg_8 function */
-int __ade7758_spi_write_reg_8(struct device *dev, u8 reg_address, u8 val)
+static int __ade7758_spi_write_reg_8(struct device *dev, u8 reg_address, u8
val)
{
struct iio_dev *indio_dev = dev_to_iio_dev(dev);
struct ade7758_state *st = iio_priv(indio_dev);
@@ -101,7 +101,7 @@ static int ade7758_spi_write_reg_24(struct device *dev, u8
reg_address,
}
/* Unlocked version of ade7758_spi_read_reg_16 function */
-int __ade7758_spi_read_reg_8(struct device *dev, u8 reg_address, u8 *val)
+static int __ade7758_spi_read_reg_8(struct device *dev, u8 reg_address, u8
*val)
{
struct iio_dev *indio_dev = dev_to_iio_dev(dev);
struct ade7758_state *st = iio_priv(indio_dev);
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
possible deadlock in shmem_file_llseek
Hello, syzbot tried to test the proposed patch but build/boot failed: patch is already applied Tested on https://github.com/joelagnel/linux.git/test-ashmem commit 32f813bb0d06c1e189ac336f8c3c7377f85c71f0 (Wed Jan 24 01:45:04 2018 +) ashmem: Fix lockdep issue during llseek compiler: gcc (GCC) 7.1.1 20170620 Patch is attached. --- a/drivers/staging/android/ashmem.c +++ b/drivers/staging/android/ashmem.c @@ -343,7 +343,9 @@ static loff_t ashmem_llseek(struct file *file, loff_t offset, int origin) goto out; } + mutex_unlock(&ashmem_mutex); ret = vfs_llseek(asma->file, offset, origin); + mutex_lock(&ashmem_mutex); if (ret < 0) goto out; ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Patch] vmbus: Simply hv_get_next_write_location() function
On Wed, 24 Jan 2018 14:21:30 +0800
lantianyu1...@gmail.com wrote:
> From: Tianyu Lan
>
> The "next" variable is redundant in hv_get_next_write_location().
> This patch is to remove it and return write_index directly.
>
> Signed-off-by: Tianyu Lan
> ---
> drivers/hv/ring_buffer.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c
> index 12eb8ca..71558e7 100644
> --- a/drivers/hv/ring_buffer.c
> +++ b/drivers/hv/ring_buffer.c
> @@ -82,9 +82,7 @@ static void hv_signal_on_write(u32 old_write, struct
> vmbus_channel *channel)
> static inline u32
> hv_get_next_write_location(struct hv_ring_buffer_info *ring_info)
> {
> - u32 next = ring_info->ring_buffer->write_index;
> -
> - return next;
> + return ring_info->ring_buffer->write_index;
> }
>
> /* Set the next write location for the specified ring buffer. */
Looks good.
But let's go farther since function is only used in one location in the file
just eliminate it completely and do simple variable references.
The get/set functions in this file are unnecessary.
Better still it is possible to replace the lock based ring structure
with a compare-exchange solution.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 5/7] x86/irq: Count Hyper-V reenlightenment interrupts
2018-01-24 14:23+0100, Vitaly Kuznetsov: > Hyper-V reenlightenment interrupts arrive when the VM is migrated, we're > not supposed to see many of them. However, it may be important to know > that the event has happened in case we have L2 nested guests. > > Signed-off-by: Vitaly Kuznetsov > Reviewed-by: Thomas Gleixner > --- Thomas, I think the expectation is that this series will go through the KVM tree. Would you prefer a topic branch? Thanks. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] staging: lustre: separate a connection destroy from free struct kib_conn
On Wed, Jan 24, 2018 at 05:14:12PM +0300, Dmitry Eremin wrote:
> Rewrite the logic of the original commit 4d99b2581eff ("staging: lustre: avoid
> intensive reconnecting for ko2iblnd") and move the freeing a struct kib_conn
> outside of the function kiblnd_destroy_conn(). The freeing of struct kib_conn
> should be depending on the second argument free_conn of function
> kiblnd_destroy_conn(struct kib_conn *conn, bool free_conn). If it true the
> structure should be freed.
>
> Fixes: 4d99b2581eff ("staging: lustre: avoid intensive reconnecting for
> ko2iblnd")
> Signed-off-by: Dmitry Eremin
> ---
> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c| 7 +++
> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h| 2 +-
> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c | 6 --
> 3 files changed, 8 insertions(+), 7 deletions(-)
What changed from version 2 and 1? Always included that below the ---
line please.
4th try is a charm? :)
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3] staging: lustre: separate a connection destroy from free struct kib_conn
Rewrite the logic of the original commit 4d99b2581eff ("staging: lustre: avoid
intensive reconnecting for ko2iblnd") and move the freeing a struct kib_conn
outside of the function kiblnd_destroy_conn(). The freeing of struct kib_conn
should be depending on the second argument free_conn of function
kiblnd_destroy_conn(struct kib_conn *conn, bool free_conn). If it true the
structure should be freed.
Fixes: 4d99b2581eff ("staging: lustre: avoid intensive reconnecting for
ko2iblnd")
Signed-off-by: Dmitry Eremin
---
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c| 7 +++
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h| 2 +-
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c | 6 --
3 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
index 2ebc484385b3..ec84edfda271 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
@@ -824,14 +824,15 @@ struct kib_conn *kiblnd_create_conn(struct kib_peer
*peer, struct rdma_cm_id *cm
return conn;
failed_2:
- kiblnd_destroy_conn(conn, true);
+ kiblnd_destroy_conn(conn);
+ kfree(conn);
failed_1:
kfree(init_qp_attr);
failed_0:
return NULL;
}
-void kiblnd_destroy_conn(struct kib_conn *conn, bool free_conn)
+void kiblnd_destroy_conn(struct kib_conn *conn)
{
struct rdma_cm_id *cmid = conn->ibc_cmid;
struct kib_peer *peer = conn->ibc_peer;
@@ -889,8 +890,6 @@ void kiblnd_destroy_conn(struct kib_conn *conn, bool
free_conn)
rdma_destroy_id(cmid);
atomic_dec(&net->ibn_nconns);
}
-
- kfree(conn);
}
int kiblnd_close_peer_conns_locked(struct kib_peer *peer, int why)
diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h
index 171eced213f8..b18911d09e9a 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h
@@ -1016,7 +1016,7 @@ int kiblnd_close_stale_conns_locked(struct kib_peer
*peer,
struct kib_conn *kiblnd_create_conn(struct kib_peer *peer,
struct rdma_cm_id *cmid,
int state, int version);
-void kiblnd_destroy_conn(struct kib_conn *conn, bool free_conn);
+void kiblnd_destroy_conn(struct kib_conn *conn);
void kiblnd_close_conn(struct kib_conn *conn, int error);
void kiblnd_close_conn_locked(struct kib_conn *conn, int error);
diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
index 9b3328c5d1e7..b3e7f28eb978 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
@@ -3314,11 +3314,13 @@ static int kiblnd_resolve_addr(struct rdma_cm_id *cmid,
spin_unlock_irqrestore(lock, flags);
dropped_lock = 1;
- kiblnd_destroy_conn(conn, !peer);
+ kiblnd_destroy_conn(conn);
spin_lock_irqsave(lock, flags);
- if (!peer)
+ if (!peer) {
+ kfree(conn);
continue;
+ }
conn->ibc_peer = peer;
if (peer->ibp_reconnected < KIB_RECONN_HIGH_RACE)
--
1.8.3.1
Joint Stock Company Intel A/O
Registered legal address: Krylatsky Hills Business Park,
17 Krylatskaya Str., Bldg 4, Moscow 121614,
Russian Federation
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v4 4/7] x86/hyper-v: redirect reenlightment notifications on CPU offlining
It is very unlikely for CPUs to get offlined when we run on Hyper-V as
we have a protection in vmbus module which prevents it when we have any
VMBus devices assigned. This, however, may change in future if an option
to reassign an already active channel will be added. It is also possible
to run without any Hyper-V devices of have a CPU with no assigned channels.
Reassign reenlightenment notifications to some other active CPU when
the CPU which is assigned to get them goes offline.
Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Thomas Gleixner
---
arch/x86/hyperv/hv_init.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 712ac40081f7..e4377e2f2a10 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -191,6 +191,26 @@ void clear_hv_tscchange_cb(void)
}
EXPORT_SYMBOL_GPL(clear_hv_tscchange_cb);
+static int hv_cpu_die(unsigned int cpu)
+{
+ struct hv_reenlightenment_control re_ctrl;
+ unsigned int new_cpu;
+
+ if (hv_reenlightenment_cb == NULL)
+ return 0;
+
+ rdmsrl(HV_X64_MSR_REENLIGHTENMENT_CONTROL, *((u64 *)&re_ctrl));
+ if (re_ctrl.target_vp == hv_vp_index[cpu]) {
+ /* Reassign to some other online CPU */
+ new_cpu = cpumask_any_but(cpu_online_mask, cpu);
+
+ re_ctrl.target_vp = hv_vp_index[new_cpu];
+ wrmsrl(HV_X64_MSR_REENLIGHTENMENT_CONTROL, *((u64 *)&re_ctrl));
+ }
+
+ return 0;
+}
+
/*
* This function is to be invoked early in the boot sequence after the
* hypervisor has been detected.
@@ -220,7 +240,7 @@ void hyperv_init(void)
return;
if (cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "x86/hyperv_init:online",
- hv_cpu_init, NULL) < 0)
+ hv_cpu_init, hv_cpu_die) < 0)
goto free_vp_index;
/*
--
2.14.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v4 7/7] x86/kvm: support Hyper-V reenlightenment
When we run nested KVM on Hyper-V guests we need to update masterclocks for
all guests when L1 migrates to a host with different TSC frequency.
Implement the procedure in the following way:
- Pause all guests.
- Tell our host (Hyper-V) to stop emulating TSC accesses.
- Update our gtod copy, recompute clocks.
- Unpause all guests.
This is somewhat similar to cpufreq but we have two important differences:
we can only disable TSC emulation globally (on all CPUs) and we don't know
the new TSC frequency until we turn the emulation off so we can't
'prepare' ourselves to the event.
Signed-off-by: Vitaly Kuznetsov
Acked-by: Paolo Bonzini
---
v3 -> v4:
add static to kvm_hyperv_tsc_notifier() [kbuild robot]
---
arch/x86/kvm/x86.c | 45 +
1 file changed, 45 insertions(+)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index b1ce368a07af..879a99987401 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -68,6 +68,7 @@
#include
#include
#include
+#include
#define CREATE_TRACE_POINTS
#include "trace.h"
@@ -5932,6 +5933,43 @@ static void tsc_khz_changed(void *data)
__this_cpu_write(cpu_tsc_khz, khz);
}
+static void kvm_hyperv_tsc_notifier(void)
+{
+#ifdef CONFIG_X86_64
+ struct kvm *kvm;
+ struct kvm_vcpu *vcpu;
+ int cpu;
+
+ spin_lock(&kvm_lock);
+ list_for_each_entry(kvm, &vm_list, vm_list)
+ kvm_make_mclock_inprogress_request(kvm);
+
+ hyperv_stop_tsc_emulation();
+
+ /* TSC frequency always matches when on Hyper-V */
+ for_each_present_cpu(cpu)
+ per_cpu(cpu_tsc_khz, cpu) = tsc_khz;
+ kvm_max_guest_tsc_khz = tsc_khz;
+
+ list_for_each_entry(kvm, &vm_list, vm_list) {
+ struct kvm_arch *ka = &kvm->arch;
+
+ spin_lock(&ka->pvclock_gtod_sync_lock);
+
+ pvclock_update_vm_gtod_copy(kvm);
+
+ kvm_for_each_vcpu(cpu, vcpu, kvm)
+ kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu);
+
+ kvm_for_each_vcpu(cpu, vcpu, kvm)
+ kvm_clear_request(KVM_REQ_MCLOCK_INPROGRESS, vcpu);
+
+ spin_unlock(&ka->pvclock_gtod_sync_lock);
+ }
+ spin_unlock(&kvm_lock);
+#endif
+}
+
static int kvmclock_cpufreq_notifier(struct notifier_block *nb, unsigned long
val,
void *data)
{
@@ -6217,6 +6255,9 @@ int kvm_arch_init(void *opaque)
kvm_lapic_init();
#ifdef CONFIG_X86_64
pvclock_gtod_register_notifier(&pvclock_gtod_notifier);
+
+ if (x86_hyper_type == X86_HYPER_MS_HYPERV)
+ set_hv_tscchange_cb(kvm_hyperv_tsc_notifier);
#endif
return 0;
@@ -6229,6 +6270,10 @@ int kvm_arch_init(void *opaque)
void kvm_arch_exit(void)
{
+#ifdef CONFIG_X86_64
+ if (x86_hyper_type == X86_HYPER_MS_HYPERV)
+ clear_hv_tscchange_cb();
+#endif
kvm_lapic_exit();
perf_unregister_guest_info_callbacks(&kvm_guest_cbs);
--
2.14.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v4 6/7] x86/kvm: pass stable clocksource to guests when running nested on Hyper-V
Currently, KVM is able to work in 'masterclock' mode passing
PVCLOCK_TSC_STABLE_BIT to guests when the clocksource we use on the host
is TSC. When running nested on Hyper-V we normally use a different one:
TSC page which is resistant to TSC frequency changes on event like L1
migration. Add support for it in KVM.
The only non-trivial change in the patch is in vgettsc(): when updating
our gtod copy we now need to get both the clockread and tsc value.
Signed-off-by: Vitaly Kuznetsov
Acked-by: Paolo Bonzini
---
arch/x86/kvm/x86.c | 93 +++---
1 file changed, 68 insertions(+), 25 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c53298dfbf50..b1ce368a07af 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -67,6 +67,7 @@
#include
#include
#include
+#include
#define CREATE_TRACE_POINTS
#include "trace.h"
@@ -1377,6 +1378,11 @@ static u64 compute_guest_tsc(struct kvm_vcpu *vcpu, s64
kernel_ns)
return tsc;
}
+static inline int gtod_is_based_on_tsc(int mode)
+{
+ return mode == VCLOCK_TSC || mode == VCLOCK_HVCLOCK;
+}
+
static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu)
{
#ifdef CONFIG_X86_64
@@ -1396,7 +1402,7 @@ static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu)
* perform request to enable masterclock.
*/
if (ka->use_master_clock ||
- (gtod->clock.vclock_mode == VCLOCK_TSC && vcpus_matched))
+ (gtod_is_based_on_tsc(gtod->clock.vclock_mode) && vcpus_matched))
kvm_make_request(KVM_REQ_MASTERCLOCK_UPDATE, vcpu);
trace_kvm_track_tsc(vcpu->vcpu_id, ka->nr_vcpus_matched_tsc,
@@ -1459,6 +1465,19 @@ static void kvm_vcpu_write_tsc_offset(struct kvm_vcpu
*vcpu, u64 offset)
vcpu->arch.tsc_offset = offset;
}
+static inline bool kvm_check_tsc_unstable(void)
+{
+#ifdef CONFIG_X86_64
+ /*
+* TSC is marked unstable when we're running on Hyper-V,
+* 'TSC page' clocksource is good.
+*/
+ if (pvclock_gtod_data.clock.vclock_mode == VCLOCK_HVCLOCK)
+ return false;
+#endif
+ return check_tsc_unstable();
+}
+
void kvm_write_tsc(struct kvm_vcpu *vcpu, struct msr_data *msr)
{
struct kvm *kvm = vcpu->kvm;
@@ -1504,7 +1523,7 @@ void kvm_write_tsc(struct kvm_vcpu *vcpu, struct msr_data
*msr)
*/
if (synchronizing &&
vcpu->arch.virtual_tsc_khz == kvm->arch.last_tsc_khz) {
- if (!check_tsc_unstable()) {
+ if (!kvm_check_tsc_unstable()) {
offset = kvm->arch.cur_tsc_offset;
pr_debug("kvm: matched tsc offset for %llu\n", data);
} else {
@@ -1604,18 +1623,43 @@ static u64 read_tsc(void)
return last;
}
-static inline u64 vgettsc(u64 *cycle_now)
+static inline u64 vgettsc(u64 *tsc_timestamp, int *mode)
{
long v;
struct pvclock_gtod_data *gtod = &pvclock_gtod_data;
+ u64 tsc_pg_val;
+
+ switch (gtod->clock.vclock_mode) {
+ case VCLOCK_HVCLOCK:
+ tsc_pg_val = hv_read_tsc_page_tsc(hv_get_tsc_page(),
+ tsc_timestamp);
+ if (tsc_pg_val != U64_MAX) {
+ /* TSC page valid */
+ *mode = VCLOCK_HVCLOCK;
+ v = (tsc_pg_val - gtod->clock.cycle_last) &
+ gtod->clock.mask;
+ } else {
+ /* TSC page invalid */
+ *mode = VCLOCK_NONE;
+ }
+ break;
+ case VCLOCK_TSC:
+ *mode = VCLOCK_TSC;
+ *tsc_timestamp = read_tsc();
+ v = (*tsc_timestamp - gtod->clock.cycle_last) &
+ gtod->clock.mask;
+ break;
+ default:
+ *mode = VCLOCK_NONE;
+ }
- *cycle_now = read_tsc();
+ if (*mode == VCLOCK_NONE)
+ *tsc_timestamp = v = 0;
- v = (*cycle_now - gtod->clock.cycle_last) & gtod->clock.mask;
return v * gtod->clock.mult;
}
-static int do_monotonic_boot(s64 *t, u64 *cycle_now)
+static int do_monotonic_boot(s64 *t, u64 *tsc_timestamp)
{
struct pvclock_gtod_data *gtod = &pvclock_gtod_data;
unsigned long seq;
@@ -1624,9 +1668,8 @@ static int do_monotonic_boot(s64 *t, u64 *cycle_now)
do {
seq = read_seqcount_begin(>od->seq);
- mode = gtod->clock.vclock_mode;
ns = gtod->nsec_base;
- ns += vgettsc(cycle_now);
+ ns += vgettsc(tsc_timestamp, &mode);
ns >>= gtod->clock.shift;
ns += gtod->boot_ns;
} while (unlikely(read_seqcount_retry(>od->seq, seq)));
@@ -1635,7 +1678,7 @@ static int do_monotonic_boot(s64 *t, u64 *cycle_now)
return mode;
}
-static int do_realtime(struct timespec *ts, u64 *cycle_now)
[PATCH v4 2/7] x86/hyper-v: add a function to read both TSC and TSC page value simulateneously
This is going to be used from KVM code where we need to get both
TSC and TSC page value.
Nobody is supposed to use the function when Hyper-V code is compiled out,
just BUG().
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/hyperv/hv_init.c | 1 +
arch/x86/include/asm/mshyperv.h | 23 +++
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 21f9d53d9f00..1a6c63f721bc 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -37,6 +37,7 @@ struct ms_hyperv_tsc_page *hv_get_tsc_page(void)
{
return tsc_pg;
}
+EXPORT_SYMBOL_GPL(hv_get_tsc_page);
static u64 read_hv_clock_tsc(struct clocksource *arg)
{
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index 8bf450b13d9f..6b1d4ea78270 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -325,9 +325,10 @@ static inline void hyperv_setup_mmu_ops(void) {}
#ifdef CONFIG_HYPERV_TSCPAGE
struct ms_hyperv_tsc_page *hv_get_tsc_page(void);
-static inline u64 hv_read_tsc_page(const struct ms_hyperv_tsc_page *tsc_pg)
+static inline u64 hv_read_tsc_page_tsc(const struct ms_hyperv_tsc_page *tsc_pg,
+ u64 *cur_tsc)
{
- u64 scale, offset, cur_tsc;
+ u64 scale, offset;
u32 sequence;
/*
@@ -358,7 +359,7 @@ static inline u64 hv_read_tsc_page(const struct
ms_hyperv_tsc_page *tsc_pg)
scale = READ_ONCE(tsc_pg->tsc_scale);
offset = READ_ONCE(tsc_pg->tsc_offset);
- cur_tsc = rdtsc_ordered();
+ *cur_tsc = rdtsc_ordered();
/*
* Make sure we read sequence after we read all other values
@@ -368,7 +369,14 @@ static inline u64 hv_read_tsc_page(const struct
ms_hyperv_tsc_page *tsc_pg)
} while (READ_ONCE(tsc_pg->tsc_sequence) != sequence);
- return mul_u64_u64_shr(cur_tsc, scale, 64) + offset;
+ return mul_u64_u64_shr(*cur_tsc, scale, 64) + offset;
+}
+
+static inline u64 hv_read_tsc_page(const struct ms_hyperv_tsc_page *tsc_pg)
+{
+ u64 cur_tsc;
+
+ return hv_read_tsc_page_tsc(tsc_pg, &cur_tsc);
}
#else
@@ -376,5 +384,12 @@ static inline struct ms_hyperv_tsc_page
*hv_get_tsc_page(void)
{
return NULL;
}
+
+static inline u64 hv_read_tsc_page_tsc(const struct ms_hyperv_tsc_page *tsc_pg,
+ u64 *cur_tsc)
+{
+ BUG();
+ return U64_MAX;
+}
#endif
#endif
--
2.14.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v4 3/7] x86/hyper-v: reenlightenment notifications support
Hyper-V supports Live Migration notification. This is supposed to be used
in conjunction with TSC emulation: when we are migrated to a host with
different TSC frequency for some short period host emulates our accesses
to TSC and sends us an interrupt to notify about the event. When we're
done updating everything we can disable TSC emulation and everything will
start working fast again.
We didn't need these notifications before as Hyper-V guests are not
supposed to use TSC as a clocksource: in Linux we even mark it as unstable
on boot. Guests normally use 'tsc page' clocksouce and host updates its
values on migrations automatically.
Things change when we want to run nested virtualization: even when we pass
through PV clocksources (kvm-clock or tsc page) to our guests we need to
know TSC frequency and when it changes.
Hyper-V Top Level Functional Specification (as of v5.0b) wrongly specifies
EAX:BIT(12) of CPUID:0x4009 as the feature identification bit. The
right one to check is EAX:BIT(13) of CPUID:0x4003. I was assured that
the fix in on the way.
Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Thomas Gleixner
---
v3 -> v4:
- drop 'include ' (and __visible/_irq_entry from
hyperv_reenlightenment_intr declaration) from mshyperv.h
[kbuild robot]
---
arch/x86/entry/entry_32.S | 3 ++
arch/x86/entry/entry_64.S | 3 ++
arch/x86/hyperv/hv_init.c | 89 ++
arch/x86/include/asm/irq_vectors.h | 7 ++-
arch/x86/include/asm/mshyperv.h| 9
arch/x86/include/uapi/asm/hyperv.h | 27
arch/x86/kernel/cpu/mshyperv.c | 6 +++
7 files changed, 143 insertions(+), 1 deletion(-)
diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index 60c4c342316c..2938cf89d473 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -894,6 +894,9 @@ BUILD_INTERRUPT3(xen_hvm_callback_vector,
HYPERVISOR_CALLBACK_VECTOR,
BUILD_INTERRUPT3(hyperv_callback_vector, HYPERVISOR_CALLBACK_VECTOR,
hyperv_vector_handler)
+BUILD_INTERRUPT3(hyperv_reenlightenment_vector, HYPERV_REENLIGHTENMENT_VECTOR,
+hyperv_reenlightenment_intr)
+
#endif /* CONFIG_HYPERV */
ENTRY(page_fault)
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index ff6f8022612c..b04cfd7f6e4c 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -1244,6 +1244,9 @@ apicinterrupt3 HYPERVISOR_CALLBACK_VECTOR \
#if IS_ENABLED(CONFIG_HYPERV)
apicinterrupt3 HYPERVISOR_CALLBACK_VECTOR \
hyperv_callback_vector hyperv_vector_handler
+
+apicinterrupt3 HYPERV_REENLIGHTENMENT_VECTOR \
+ hyperv_reenlightenment_vector hyperv_reenlightenment_intr
#endif /* CONFIG_HYPERV */
idtentry debug do_debughas_error_code=0
paranoid=1 shift_ist=DEBUG_STACK
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 1a6c63f721bc..712ac40081f7 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -18,6 +18,8 @@
*/
#include
+#include
+#include
#include
#include
#include
@@ -102,6 +104,93 @@ static int hv_cpu_init(unsigned int cpu)
return 0;
}
+static void (*hv_reenlightenment_cb)(void);
+
+static void hv_reenlightenment_notify(struct work_struct *dummy)
+{
+ struct hv_tsc_emulation_status emu_status;
+
+ rdmsrl(HV_X64_MSR_TSC_EMULATION_STATUS, *(u64 *)&emu_status);
+
+ /* Don't issue the callback if TSC accesses are not emulated */
+ if (hv_reenlightenment_cb && emu_status.inprogress)
+ hv_reenlightenment_cb();
+}
+static DECLARE_DELAYED_WORK(hv_reenlightenment_work,
hv_reenlightenment_notify);
+
+void hyperv_stop_tsc_emulation(void)
+{
+ u64 freq;
+ struct hv_tsc_emulation_status emu_status;
+
+ rdmsrl(HV_X64_MSR_TSC_EMULATION_STATUS, *(u64 *)&emu_status);
+ emu_status.inprogress = 0;
+ wrmsrl(HV_X64_MSR_TSC_EMULATION_STATUS, *(u64 *)&emu_status);
+
+ rdmsrl(HV_X64_MSR_TSC_FREQUENCY, freq);
+ tsc_khz = div64_u64(freq, 1000);
+}
+EXPORT_SYMBOL_GPL(hyperv_stop_tsc_emulation);
+
+static inline bool hv_reenlightenment_available(void)
+{
+ /*
+* Check for required features and priviliges to make TSC frequency
+* change notifications work.
+*/
+ return ms_hyperv.features & HV_X64_ACCESS_FREQUENCY_MSRS &&
+ ms_hyperv.misc_features & HV_FEATURE_FREQUENCY_MSRS_AVAILABLE &&
+ ms_hyperv.features & HV_X64_ACCESS_REENLIGHTENMENT;
+}
+
+__visible void __irq_entry hyperv_reenlightenment_intr(struct pt_regs *regs)
+{
+ entering_ack_irq();
+
+ schedule_delayed_work(&hv_reenlightenment_work, HZ/10);
+
+ exiting_irq();
+}
+
+void set_hv_tscchange_cb(void (*cb)(void))
+{
+ struct hv_reenlightenment_control re_ctrl = {
+ .vector = HYPERV_REENLIGHTENMENT_VECTOR,
+ .enabled = 1,
+ .target_vp = hv_vp_index[s
[PATCH v4 5/7] x86/irq: Count Hyper-V reenlightenment interrupts
Hyper-V reenlightenment interrupts arrive when the VM is migrated, we're
not supposed to see many of them. However, it may be important to know
that the event has happened in case we have L2 nested guests.
Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Thomas Gleixner
---
arch/x86/hyperv/hv_init.c | 2 ++
arch/x86/include/asm/hardirq.h | 3 +++
arch/x86/kernel/irq.c | 9 +
3 files changed, 14 insertions(+)
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index e4377e2f2a10..a3adece392f1 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -147,6 +147,8 @@ __visible void __irq_entry
hyperv_reenlightenment_intr(struct pt_regs *regs)
{
entering_ack_irq();
+ inc_irq_stat(irq_hv_reenlightenment_count);
+
schedule_delayed_work(&hv_reenlightenment_work, HZ/10);
exiting_irq();
diff --git a/arch/x86/include/asm/hardirq.h b/arch/x86/include/asm/hardirq.h
index 51cc979dd364..7c341a74ec8c 100644
--- a/arch/x86/include/asm/hardirq.h
+++ b/arch/x86/include/asm/hardirq.h
@@ -38,6 +38,9 @@ typedef struct {
#if IS_ENABLED(CONFIG_HYPERV) || defined(CONFIG_XEN)
unsigned int irq_hv_callback_count;
#endif
+#if IS_ENABLED(CONFIG_HYPERV)
+ unsigned int irq_hv_reenlightenment_count;
+#endif
} cacheline_aligned irq_cpustat_t;
DECLARE_PER_CPU_SHARED_ALIGNED(irq_cpustat_t, irq_stat);
diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
index 68e1867cca80..45fb4d2565f8 100644
--- a/arch/x86/kernel/irq.c
+++ b/arch/x86/kernel/irq.c
@@ -141,6 +141,15 @@ int arch_show_interrupts(struct seq_file *p, int prec)
irq_stats(j)->irq_hv_callback_count);
seq_puts(p, " Hypervisor callback interrupts\n");
}
+#endif
+#if IS_ENABLED(CONFIG_HYPERV)
+ if (test_bit(HYPERV_REENLIGHTENMENT_VECTOR, system_vectors)) {
+ seq_printf(p, "%*s: ", prec, "HRE");
+ for_each_online_cpu(j)
+ seq_printf(p, "%10u ",
+ irq_stats(j)->irq_hv_reenlightenment_count);
+ seq_puts(p, " Hyper-V reenlightenment interrupts\n");
+ }
#endif
seq_printf(p, "%*s: %10u\n", prec, "ERR", atomic_read(&irq_err_count));
#if defined(CONFIG_X86_IO_APIC)
--
2.14.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v4 0/7] x86/kvm/hyperv: stable clocksource for L2 guests when running nested KVM on Hyper-V
Changes since v3: - PATCH3: - drop 'include ' (and __visible/_irq_entry from hyperv_reenlightenment_intr declaration -- but not from implementation) from mshyperv.h [kbuild robot] I'm retaining Thomas' Reviewed-by tag as the change is small, hope that's OK. - PATCH7: - add static to kvm_hyperv_tsc_notifier() [kbuild robot]. I'm also keeping Paolo's Acked-by as the change is trivial. So currently only PATCH2 of the series doesn't have a Reviewed-by/ Acked-by tag. Original description: Currently, KVM passes PVCLOCK_TSC_STABLE_BIT to its guests when running in so called 'masterclock' mode and this is only possible when the clocksource on the host is TSC. When running nested on Hyper-V we're using a different clocksource in L1 (Hyper-V TSC Page) which can actually be used for masterclock. This series brings the required support. Making KVM work with TSC page clocksource is relatively easy, it is done in PATCH 6 of the series. All the rest is required to support L1 migration when TSC frequency changes, we use a special feature from Hyper-V to do the job. Vitaly Kuznetsov (7): x86/hyper-v: check for required priviliges in hyperv_init() x86/hyper-v: add a function to read both TSC and TSC page value simulateneously x86/hyper-v: reenlightenment notifications support x86/hyper-v: redirect reenlightment notifications on CPU offlining x86/irq: Count Hyper-V reenlightenment interrupts x86/kvm: pass stable clocksource to guests when running nested on Hyper-V x86/kvm: support Hyper-V reenlightenment arch/x86/entry/entry_32.S | 3 + arch/x86/entry/entry_64.S | 3 + arch/x86/hyperv/hv_init.c | 123 - arch/x86/include/asm/hardirq.h | 3 + arch/x86/include/asm/irq_vectors.h | 7 +- arch/x86/include/asm/mshyperv.h| 32 +++-- arch/x86/include/uapi/asm/hyperv.h | 27 arch/x86/kernel/cpu/mshyperv.c | 6 ++ arch/x86/kernel/irq.c | 9 +++ arch/x86/kvm/x86.c | 138 ++--- 10 files changed, 319 insertions(+), 32 deletions(-) -- 2.14.3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v4 1/7] x86/hyper-v: check for required priviliges in hyperv_init()
In hyperv_init() we presume we always have access to VP index and hypercall
MSRs while according to the specification we should check if we're allowed
to access the corresponding MSRs before accessing them.
Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Thomas Gleixner
---
arch/x86/hyperv/hv_init.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 189a398290db..21f9d53d9f00 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -110,12 +110,19 @@ static int hv_cpu_init(unsigned int cpu)
*/
void hyperv_init(void)
{
- u64 guest_id;
+ u64 guest_id, required_msrs;
union hv_x64_msr_hypercall_contents hypercall_msr;
if (x86_hyper_type != X86_HYPER_MS_HYPERV)
return;
+ /* Absolutely required MSRs */
+ required_msrs = HV_X64_MSR_HYPERCALL_AVAILABLE |
+ HV_X64_MSR_VP_INDEX_AVAILABLE;
+
+ if ((ms_hyperv.features & required_msrs) != required_msrs)
+ return;
+
/* Allocate percpu VP index */
hv_vp_index = kmalloc_array(num_possible_cpus(), sizeof(*hv_vp_index),
GFP_KERNEL);
--
2.14.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] staging: lustre: Fix avoid intensive reconnecting for ko2iblnd patch
From: Dmitry Eremin
The logic of the original commit 4d99b2581eff ("staging: lustre: avoid
intensive reconnecting for ko2iblnd")
was assumed conditional free of struct kib_conn if the second argument free_conn
in function kiblnd_destroy_conn(struct kib_conn *conn, bool free_conn) is true.
But this hunk of code was dropped from original commit. As result the logic
works wrong and current code use struct kib_conn after free.
> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
> 3317 kiblnd_destroy_conn(conn, !peer);
> Freed always (but should be conditionally)
> 3318
> 3319 spin_lock_irqsave(lock, flags);
> 3320 if (!peer)
> 3321 continue;
> 3322
> 3323 conn->ibc_peer = peer;
> ^^ Use after free
> 3324 if (peer->ibp_reconnected < KIB_RECONN_HIGH_RACE)
> 3325 list_add_tail(&conn->ibc_list,
> ^^ Use after free
> 3326&kiblnd_data.kib_reconn_list);
> 3327 else
> 3328 list_add_tail(&conn->ibc_list,
> ^^ Use after free
> 3329&kiblnd_data.kib_reconn_wait);
After attached patch this code will use struct kib_conn only when it was not
freed.
Cc: # v4.6
Fixes: 4d99b2581eff ("staging: lustre: avoid intensive reconnecting for
ko2iblnd")
Signed-off-by: Dmitry Eremin
Signed-off-by: Dmitry Eremin
---
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
index 2ebc484385b3..a15a625ee9b6 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
@@ -890,7 +890,8 @@ void kiblnd_destroy_conn(struct kib_conn *conn, bool
free_conn)
atomic_dec(&net->ibn_nconns);
}
- kfree(conn);
+ if (free_conn)
+ kfree(conn);
}
int kiblnd_close_peer_conns_locked(struct kib_peer *peer, int why)
--
1.8.3.1
Joint Stock Company Intel A/O
Registered legal address: Krylatsky Hills Business Park,
17 Krylatskaya Str., Bldg 4, Moscow 121614,
Russian Federation
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] x86/hyper-v: stop suppressing X86_FEATURE_PCID
When hypercall-based TLB flush was enabled for Hyper-V guests PCID feature
was deliberately suppressed as a precaution: back then PCID was never
exposed to Hyper-V guests and it wasn't clear what will happen if some day
it becomes available. The day came and PCID/INVPCID features are already
exposed on certain Hyper-V hosts.
I was asked if we can stop suppressing PCID. From TLFS (as of 5.0b) is is
unclear how TLB flush hypercalls combine with PCID. In particular, I was
worried about our usage of PCID where it is per-cpu based: the same mm gets
different CR3 values on different CPUs and if hypercall does exact matching
we're screwed. However, this is not the case. David Zhang writes:
"In practice, the AddressSpace argument is ignored on any VM that supports
PCIDs.
Architecturally, the AddressSpace argument must match the CR3 with PCID
bits stripped out (i.e., the low 12 bits of AddressSpace should be 0 in
long mode). The flush hypercalls flush all PCIDs for the specified
AddressSpace."
With this, PCID can be enabled.
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/hyperv/mmu.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/x86/hyperv/mmu.c b/arch/x86/hyperv/mmu.c
index 9cc9e1c1e2db..993a5dff1e40 100644
--- a/arch/x86/hyperv/mmu.c
+++ b/arch/x86/hyperv/mmu.c
@@ -137,7 +137,12 @@ static void hyperv_flush_tlb_others(const struct cpumask
*cpus,
}
if (info->mm) {
- flush->address_space = virt_to_phys(info->mm->pgd);
+ /*
+* AddressSpace argument must match the CR3 with PCID bits
+* stripped out.
+*/
+ flush->address_space =
+ virt_to_phys(info->mm->pgd) & CR3_ADDR_MASK;
flush->flags = 0;
} else {
flush->address_space = 0;
@@ -219,7 +224,12 @@ static void hyperv_flush_tlb_others_ex(const struct
cpumask *cpus,
}
if (info->mm) {
- flush->address_space = virt_to_phys(info->mm->pgd);
+ /*
+* AddressSpace argument must match the CR3 with PCID bits
+* stripped out.
+*/
+ flush->address_space =
+ virt_to_phys(info->mm->pgd) & CR3_ADDR_MASK;
flush->flags = 0;
} else {
flush->address_space = 0;
@@ -278,8 +288,6 @@ void hyperv_setup_mmu_ops(void)
if (!(ms_hyperv.hints & HV_X64_REMOTE_TLB_FLUSH_RECOMMENDED))
return;
- setup_clear_cpu_cap(X86_FEATURE_PCID);
-
if (!(ms_hyperv.hints & HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED)) {
pr_info("Using hypercall for remote TLB flush\n");
pv_mmu_ops.flush_tlb_others = hyperv_flush_tlb_others;
--
2.14.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: android: ion: Zero CMA allocated memory
On 01/22/2018 09:46 AM, Liam Mark wrote:
Since commit 204f672255c2 ("staging: android: ion: Use CMA APIs directly")
the CMA API is now used directly and therefore the allocated memory is no
longer automatically zeroed.
Explicitly zero CMA allocated memory to ensure that no data is exposed to
userspace.
Fixes: 204f672255c2 ("staging: android: ion: Use CMA APIs directly")
Signed-off-by: Liam Mark
---
Changes in v2:
- Clean up the commit message.
- Add 'Fixes:'
drivers/staging/android/ion/ion_cma_heap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/android/ion/ion_cma_heap.c
b/drivers/staging/android/ion/ion_cma_heap.c
index 86196ffd2faf..91a98785607a 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -51,6 +51,8 @@ static int ion_cma_allocate(struct ion_heap *heap, struct
ion_buffer *buffer,
if (!pages)
return -ENOMEM;
+ memset(page_address(pages), 0, size);
+
This won't work for highmem pages. You need to zero by page via
kmap_atomic in that case. You can use PageHighMem to separate the
paths.
Thanks,
Laura
table = kmalloc(sizeof(*table), GFP_KERNEL);
if (!table)
goto err;
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: media: remove unused VIDEO_ATOMISP_OV8858 kconfig
On Tue, Jan 23, 2018 at 07:31:27PM +0200, Andy Shevchenko wrote:
> On Tue, Jan 23, 2018 at 4:37 PM, Corentin Labbe wrote:
> > Nothing in kernel use VIDEO_ATOMISP_OV8858 since commit 3a81c7660f80
> > ("media: staging: atomisp: Remove IMX sensor support")
> > Lets remove this kconfig option.
>
> First of all, I hardly understand how that change is related.
It's pretty obvious if you look at the commit.
-obj-$(CONFIG_VIDEO_ATOMISP_OV8858) += atomisp-ov8858.o
It sounds like you deleted that line by mistake and re-added it to your
local Makefile?
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
