MSRC001_1029 had duplicate definitions in msr-index.h and
amd.c. Remove the local definition in favor of the more
widely used version.
Signed-off-by: Venkatesh Srinivas
---
arch/x86/kernel/cpu/amd.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/x86/kernel/cpu/amd.c
On Mon, Nov 30, 2015 at 11:15:23AM +0200, Michael S. Tsirkin wrote:
> We know vring num is a power of 2, so use &
> to mask the high bits.
>
> Signed-off-by: Michael S. Tsirkin
> ---
The generated code switches from DIV -> masking, source is clearer as well.
Tested-
> static inline __virtio64 cpu_to_virtio64(struct virtio_device *vdev, u64 val)
> {
> - return __cpu_to_virtio64(virtio_has_feature(vdev, VIRTIO_F_VERSION_1),
> val);
> + return __cpu_to_virtio64(virtio_is_little_endian(vdev), val);
> }
Tested patch with vring-bench. (I did somethin
is clearer as well.
Tested-by: Venkatesh Srinivas <venkate...@google.com>
-- vs;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
tio_is_little_endian(vdev), val);
> }
>
> static inline __virtio64 cpu_to_virtio64(struct virtio_device *vdev, u64 val)
> {
> - return __cpu_to_virtio64(virtio_has_feature(vdev, VIRTIO_F_VERSION_1),
> val);
> + return __cpu_to_virtio64(virtio_is_little_endian(vdev), v
e the core never receives
> another interrupt. The host kernel panics pretty quickly due to the
> effects (CVE-2015-5307).
>
> Signed-off-by: Eric Northup
> Cc: sta...@vger.kernel.org
> Signed-off-by: Paolo Bonzini
Tested-by: Venkatesh Srinivas
-- vs;
--
To unsubscribe from this li
an infinite loop where the core never receives
> another interrupt. The host kernel panics pretty quickly due to the
> effects (CVE-2015-5307).
>
> Signed-off-by: Eric Northup <digitale...@google.com>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Paolo Bonzini <pb
On Mon, Mar 23, 2015 at 2:06 PM, K. Y. Srinivasan wrote:
> Size the queue depth based on the ringbuffer size. Also accomodate for the
> fact that we could have multiple channels (ringbuffers) per adaptor.
>
> Signed-off-by: K. Y. Srinivasan
> Reviewed-by: Long Li
> ---
>
On Mon, Mar 23, 2015 at 2:06 PM, K. Y. Srinivasan k...@microsoft.com wrote:
Size the queue depth based on the ringbuffer size. Also accomodate for the
fact that we could have multiple channels (ringbuffers) per adaptor.
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Reviewed-by: Long Li
work serialized. With this change, the panic goes
> away.
>
> Signed-off-by: Fam Zheng
Reviewed-by: Venkatesh Srinivas
> ---
>
> v4: Addressing MST's comments:
> Use ordered workqueue, with WQ_FREEZABLE and WQ_MEM_RECLAIM flags.
> Coding style fixes.
>
>
, the panic goes
away.
Signed-off-by: Fam Zheng f...@redhat.com
Reviewed-by: Venkatesh Srinivas venkate...@google.com
---
v4: Addressing MST's comments:
Use ordered workqueue, with WQ_FREEZABLE and WQ_MEM_RECLAIM flags.
Coding style fixes.
v3: Fix spacing and destroy order. (MST
mempool_destroy(virtscsi_cmd_pool);
> virtscsi_cmd_pool = NULL;
> @@ -1142,6 +1153,7 @@ static void __exit fini(void)
> unregister_virtio_driver(_scsi_driver);
> mempool_destroy(virtscsi_cmd_pool);
> kmem_cache_destroy(virtscsi_cmd_cache);
&g
);
+ destroy_workqueue(virtscsi_scan_wq);
}
module_init(init);
module_exit(fini);
--
1.9.3
Reviewed-by: Venkatesh Srinivas venkate...@google.com
-- vs;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
csi->num_queues + VIRTIO_SCSI_VQ_BASE;
> vqs = kmalloc(num_vqs * sizeof(struct virtqueue *), GFP_KERNEL);
> callbacks = kmalloc(num_vqs * sizeof(vq_callback_t *), GFP_KERNEL);
> --
> 1.9.3
Nice find.
This fix does have the effect of serializing all event handling via
scan
the effect of serializing all event handling via
scan_lock; perhaps you want to instead create a singlethreaded
workqueue in virtio_scsi and queue handle_event there, rather than
waiting on scan_lock on the system workqueue?
Reviewed-by: Venkatesh Srinivas venkate...@google.com
-- vs;
--
To unsubscribe
Should we wrap the sdev->device_busy read and test in a new
scsi_device_busy(), so as to preserve the old polarity?
Reviewed-by: Venkatesh Srinivas
On 8/11/14, Jens Axboe wrote:
> On 2014-08-10 06:54, Guenter Roeck wrote:
>> The latest kernel fails to boot qemu arm images whe
Should we wrap the sdev-device_busy read and test in a new
scsi_device_busy(), so as to preserve the old polarity?
Reviewed-by: Venkatesh Srinivas venkate...@google.com
On 8/11/14, Jens Axboe ax...@kernel.dk wrote:
On 2014-08-10 06:54, Guenter Roeck wrote:
The latest kernel fails to boot qemu
On 6/4/14, Paolo Bonzini wrote:
> Il 04/06/2014 19:29, Venkatesh Srinivas ha scritto:
>> Do you really want to poll the request VQs for completions if the TMF
>> was rejected?
>
> I wasn't sure, but bugs in this path are hard enough that I preferred
> the s
On 6/4/14, Paolo Bonzini wrote:
> Even though the virtio-scsi spec guarantees that all requests related
> to the TMF will have been completed by the time the TMF itself completes,
> the request queue's callback might not have run yet. This causes requests
> to be completed more than once, and as
test.
>
> Signed-off-by: Ming Lei
> [Add initialization in virtscsi_target_alloc. - Paolo]
> Signed-off-by: Paolo Bonzini
Reviewed-by: Venkatesh Srinivas
-- vs;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ma
% on random read test.
Signed-off-by: Ming Lei ming@canonical.com
[Add initialization in virtscsi_target_alloc. - Paolo]
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Reviewed-by: Venkatesh Srinivas venkate...@google.com
-- vs;
--
To unsubscribe from this list: send the line unsubscribe
On 6/4/14, Paolo Bonzini pbonz...@redhat.com wrote:
Even though the virtio-scsi spec guarantees that all requests related
to the TMF will have been completed by the time the TMF itself completes,
the request queue's callback might not have run yet. This causes requests
to be completed more
On 6/4/14, Paolo Bonzini pbonz...@redhat.com wrote:
Il 04/06/2014 19:29, Venkatesh Srinivas ha scritto:
Do you really want to poll the request VQs for completions if the TMF
was rejected?
I wasn't sure, but bugs in this path are hard enough that I preferred
the safer patch.
Ok. As long
returns 0 on success.
>> The current code was failing to detect the RAPL PMU
>> on real hardware (missing /sys/devices/power) because
>> the return value of rdmsrl_safe() was misinterpreted.
>>
>> Signed-off-by: Stephane Eranian
>
> Acked-by: Borislav Petkov
code was failing to detect the RAPL PMU
on real hardware (missing /sys/devices/power) because
the return value of rdmsrl_safe() was misinterpreted.
Signed-off-by: Stephane Eranian eran...@google.com
Acked-by: Borislav Petkov b...@suse.de
Brown-Paper-Bag-Worn-By: Venkatesh Srinivas venkate
Commit-ID: 24223657806a0ebd0ae5c9caaf7b021091889cf2
Gitweb: http://git.kernel.org/tip/24223657806a0ebd0ae5c9caaf7b021091889cf2
Author: Venkatesh Srinivas
AuthorDate: Thu, 13 Mar 2014 12:36:26 -0700
Committer: Ingo Molnar
CommitDate: Fri, 18 Apr 2014 12:14:26 +0200
perf/x86/intel: Use
Commit-ID: 24223657806a0ebd0ae5c9caaf7b021091889cf2
Gitweb: http://git.kernel.org/tip/24223657806a0ebd0ae5c9caaf7b021091889cf2
Author: Venkatesh Srinivas venkate...@google.com
AuthorDate: Thu, 13 Mar 2014 12:36:26 -0700
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Fri, 18 Apr 2014
On Wed, Mar 19, 2014 at 10:48 AM, Venkatesh Srinivas
wrote:
>> And I rewrote it substantially, mainly to take
>> VIRTIO_RING_F_INDIRECT_DESC into account.
>>
>> As QEMU sets the vq size for PCI to 128, Venkatash's patch wouldn't
>> have made a change. This versio
On Wed, Mar 19, 2014 at 10:48 AM, Venkatesh Srinivas
venkate...@google.com wrote:
And I rewrote it substantially, mainly to take
VIRTIO_RING_F_INDIRECT_DESC into account.
As QEMU sets the vq size for PCI to 128, Venkatash's patch wouldn't
have made a change. This version does (since QEMU
On Fri, Mar 21, 2014 at 10:46 AM, Peter Wu wrote:
> cc'ing kvm people and list.
>
> On Friday 21 March 2014 18:42:40 Peter Wu wrote:
>> Hi,
>>
>> While trying to run QEMU with `-enable-kvm -host cpu`, I get a GPF in
>> intel_pmu_lbr_reset():
>>
>> [0.024000] general protection fault:
On Fri, Mar 21, 2014 at 10:46 AM, Peter Wu pe...@lekensteyn.nl wrote:
cc'ing kvm people and list.
On Friday 21 March 2014 18:42:40 Peter Wu wrote:
Hi,
While trying to run QEMU with `-enable-kvm -host cpu`, I get a GPF in
intel_pmu_lbr_reset():
[0.024000] general protection fault:
produced the same queue depth as the prior
computation in QEMU was deliberate -- but raising it to 128 seems
pretty reasonable.
Signed-off-by: Venkatesh Srinivas
-- vs;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vg
depth as the prior
computation in QEMU was deliberate -- but raising it to 128 seems
pretty reasonable.
Signed-off-by: Venkatesh Srinivas venkate...@google.com
-- vs;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
On Fri, Mar 14, 2014 at 10:57:58AM -0600, David Ahern wrote:
On 3/14/14, 10:17 AM, Andi Kleen wrote:
The Intel ISR section for RDMSR seems to say: "Specifying a reserved
or unimplemented
MSR address in ECX will also cause a general protection exception".
From a guest's perspective,
On Fri, Mar 14, 2014 at 6:56 AM, Andi Kleen wrote:
> On Fri, Mar 14, 2014 at 09:44:29AM +0100, Peter Zijlstra wrote:
>> On Thu, Mar 13, 2014 at 12:36:26PM -0700, Venkatesh Srinivas wrote:
>> > CPUs which should support the RAPL counters according to
>> > Family/Model/S
On Fri, Mar 14, 2014 at 6:56 AM, Andi Kleen a...@linux.intel.com wrote:
On Fri, Mar 14, 2014 at 09:44:29AM +0100, Peter Zijlstra wrote:
On Thu, Mar 13, 2014 at 12:36:26PM -0700, Venkatesh Srinivas wrote:
CPUs which should support the RAPL counters according to
Family/Model/Stepping may still
On Fri, Mar 14, 2014 at 10:57:58AM -0600, David Ahern wrote:
On 3/14/14, 10:17 AM, Andi Kleen wrote:
The Intel ISR section for RDMSR seems to say: Specifying a reserved
or unimplemented
MSR address in ECX will also cause a general protection exception.
From a guest's perspective,
MSR; if this fails, do not
attempt to use this PMU.
Signed-off-by: Venkatesh Srinivas
---
arch/x86/kernel/cpu/perf_event_intel_rapl.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_rapl.c
b/arch/x86/kernel/cpu
MSR; if this fails, do not
attempt to use this PMU.
Signed-off-by: Venkatesh Srinivas venkate...@google.com
---
arch/x86/kernel/cpu/perf_event_intel_rapl.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_rapl.c
b/arch/x86/kernel
MSR; if this fails, do not
attempt to use this PMU.
Signed-off-by: Venkatesh Srinivas
---
arch/x86/kernel/cpu/perf_event_intel_rapl.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_rapl.c
b/arch/x86/kernel/cpu
MSR; if this fails, do not
attempt to use this PMU.
Signed-off-by: Venkatesh Srinivas venkate...@google.com
---
arch/x86/kernel/cpu/perf_event_intel_rapl.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_rapl.c
b/arch/x86/kernel
The virtio spec requires byte 0 of the virtio-scsi LUN structure
to be '1'.
Signed-off-by: Venkatesh Srinivas
---
drivers/vhost/scsi.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 0a025b8..e48d4a6 100644
--- a/drivers/vhost/scsi.c
The virtio spec requires byte 0 of the virtio-scsi LUN structure
to be '1'.
Signed-off-by: Venkatesh Srinivas venkate...@google.com
---
drivers/vhost/scsi.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 0a025b8..e48d4a6 100644
fast enough.
Looks good! Tested as V5.
Tested-by: Venkatesh Srinivas
-- vs;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
enough.
Looks good! Tested as V5.
Tested-by: Venkatesh Srinivas venkate...@google.com
-- vs;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
Engine's virtio-scsi device.
Reviewed-and-tested-by: Venkatesh Srinivas
Thanks,
-- vs;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please re
Engine's virtio-scsi device.
Reviewed-and-tested-by: Venkatesh Srinivas venkate...@google.com
Thanks,
-- vs;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
47 matches
Mail list logo
