From: Nicholas Bellinger n...@linux-iscsi.org
There is a large amount of code that still references the original
'tcm_vhost' naming conventions, instead of modern 'vhost_scsi'.
Go ahead and do a global rename to make the usage consistent.
Cc: Michael S. Tsirkin m...@redhat.com
Acked-by: Michael
From: Nicholas Bellinger n...@linux-iscsi.org
Required for ANY_LAYOUT support when the incoming virtio-scsi response
header + fixed size sense buffer payload may span more than a single
iovec entry.
This changes existing code to save cmd-tvc_resp_iov instead of the
first single iovec base
From: Nicholas Bellinger n...@linux-iscsi.org
With the recent removal of MSG_*_TAG defines in commit 68d81f40,
vhost-scsi is now using TCM_*_TAG and doesn't depend upon host
side scsi_tcq.h definitions anymore.
Cc: Michael S. Tsirkin m...@redhat.com
Acked-by: Michael S. Tsirkin m...@redhat.com
From: Nicholas Bellinger n...@linux-iscsi.org
Signal support of VIRTIO_F_ANY_LAYOUT + VIRTIO_F_VERSION_1 feature bits
required for virtio-scsi 1.0 spec layout requirements.
Cc: Michael S. Tsirkin m...@redhat.com
Acked-by: Michael S. Tsirkin m...@redhat.com
Cc: Paolo Bonzini pbonz...@redhat.com
From: Nicholas Bellinger n...@linux-iscsi.org
This patch fixes vhost_scsi_handle_vq() failure cases that result in BUG_ON()
getting triggered when vhost_scsi_free_cmd() is called, and -tvc_se_cmd has
not been initialized by target_submit_cmd_map_sgls().
It changes tcm_vhost_release_cmd() to use
From: Nicholas Bellinger n...@linux-iscsi.org
This patch adds ANY_LAYOUT compatible support within the existing
vhost_scsi_handle_vq() -handle_kick() callback.
It calculates data_direction + exp_data_len for the new tcm_vhost_cmd
descriptor by walking both outgoing + incoming iovecs using
From: Nicholas Bellinger n...@linux-iscsi.org
This patch changes vhost_scsi_map_to_sgl() parameters to accept virtio
iovec ptr + len when determing pages_nr.
This is currently done with iov_num_pages() - PAGE_ALIGN, so allow
the same parameters as well.
Cc: Michael S. Tsirkin m...@redhat.com
From: Nicholas Bellinger n...@linux-iscsi.org
Hi MST, Paolo, Al Co,
Here is v4 patch series for vhost/scsi ANY_LAYOUT + VERSION_1 support.
It updates vhost_virtqueue-handle_kick() - vhost_scsi_handle_vq()
callback code to determine the start of protection + data payloads iovecs
past the
From: Nicholas Bellinger n...@linux-iscsi.org
This patch adds ANY_LAYOUT prerequisites logic for accepting a set of
protection + data payloads via iov_iter. Also includes helpers for
calcuating SGLs + invoking vhost_scsi_map_to_sgl() with a known number
of iovecs.
Required by ANY_LAYOUT
G'day all,
I'm at a bit of a loss. I run a CCTV storage server on a Windows XP
guest running on an AMD64 (Piledriver) host with 64 bit kernel and
userspace. This has been running well for a number of years.
I recently upgraded from a 3.15 kernel to 3.17 and now 3.18. The 3.15
kernel runs
On 06/02/2015 00:34, Marcelo Tosatti wrote:
You want at least a basic procedure to estimate a value
(its a function of the device after all).
I will add a tracepoint.
Rather than halt_successful_poll's, i suppose the optimum
can be estimated from a dataset containing entries
in the form:
On 27/01/15 01:51, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This v5 nukes tracing as David said it was useless, it also
only adds support for 64-bit as its the only thing I can test,
and slightly modifies the documentation in code as to why we
want this. The no krobe
On Wed, 04 Feb 2015 09:26:11 +0100
Christian Borntraeger borntrae...@de.ibm.com wrote:
the classic channel I/O does set the storage key change/reference and
also triggers errors in the storage key protection value mismatches.
Just a bit of background for the benefit of innocent bystanders:
2015-02-05 14:29+0800, Kai Huang:
+ /* Still write protect RO slot */
+ if (new-flags KVM_MEM_READONLY) {
+ kvm_mmu_slot_remove_write_access(kvm, new);
We didn't write protect RO slots before, does this patch depend on it?
No PML doesn't depend on it to work. It's suggested by
2015-02-05 13:59+0800, Kai Huang:
Thanks for your review and sorry for the late reply. I was working on
something else these days.
(No problem, a reply within a week is instantaneous for me :)
For rest of your comments, as this patch series have already been in Paolo's
queue branch, I think
This patch introduces a new module parameter for the KVM module; when it
is present, KVM attempts a bit of polling on every HLT before scheduling
itself out via kvm_vcpu_block.
This parameter helps a lot for latency-bound workloads---in particular
I tested it with O_DSYNC writes with a
On 05/02/2015 21:39, David Matlack wrote:
This parameter helps a lot for latency-bound workloads [...]
KVM's performance here is usually around 30% of bare metal,
or 50% if you use cache=directsync or cache=writethrough.
With this patch performance reaches 60-65% of bare metal and, more
On 02/05/2015 01:56 PM, Paul E. McKenney wrote:
The real danger is doing neither.
On tick_nohz_full_cpu() CPUs, the exit-to-userspace code should invoke
rcu_user_enter(), which sets some per-CPU state telling RCU to ignore
that CPU, since it cannot possibly do host RCU read-side critical
On 05/02/2015 18:53, Radim Krčmář wrote:
99% of what you get if you use idle=poll in the guest.
(Hm, I would have thought that this can outperform idle=poll ...)
It outperforms idle=poll in the host. A vmexit is probably too cheap to
outperform having idle=poll in the guest.
On 05/02/2015 19:55, Jan Kiszka wrote:
This patch introduces a new module parameter for the KVM module; when it
is present, KVM attempts a bit of polling on every HLT before scheduling
itself out via kvm_vcpu_block.
Wouldn't it be better to tune this on a per-VM basis? Think of mixed
On 02/05/2015 02:20 PM, Paolo Bonzini wrote:
On 05/02/2015 19:55, Jan Kiszka wrote:
This patch introduces a new module parameter for the KVM module; when it
is present, KVM attempts a bit of polling on every HLT before scheduling
itself out via kvm_vcpu_block.
Wouldn't it be better to
On Thu, Feb 05, 2015 at 02:02:35PM -0500, Rik van Riel wrote:
On 02/05/2015 01:56 PM, Paul E. McKenney wrote:
The real danger is doing neither.
On tick_nohz_full_cpu() CPUs, the exit-to-userspace code should invoke
rcu_user_enter(), which sets some per-CPU state telling RCU to ignore
2015-02-05 14:23+0800, Kai Huang:
On 02/03/2015 11:18 PM, Radim Krčmář wrote:
You have it protected by CONFIG_X86_64, but use it unconditionally.
Thanks for catching. This has been fixed by another patch, and the fix has
also been merged by Paolo.
(And I haven't noticed the followup either
Hi all,
I'm trying to inject a page fault into a Linux guest, but when tracing the guest
OS I don't see the injected fault making it to do_page_fault in the guest. That
is, I don't see a do_page_fault call with a CR2 matching the address I'm passing.
I'm currently calling the
On 02/05/2015 11:04 PM, Radim Krčmář wrote:
2015-02-05 14:23+0800, Kai Huang:
On 02/03/2015 11:18 PM, Radim Krčmář wrote:
You have it protected by CONFIG_X86_64, but use it unconditionally.
Thanks for catching. This has been fixed by another patch, and the fix has
also been merged by Paolo.
On Thu, Feb 05, 2015 at 05:05:25PM +0100, Paolo Bonzini wrote:
This patch introduces a new module parameter for the KVM module; when it
is present, KVM attempts a bit of polling on every HLT before scheduling
itself out via kvm_vcpu_block.
This parameter helps a lot for latency-bound
On Thu, Feb 05, 2015 at 09:34:06PM -0200, Marcelo Tosatti wrote:
On Thu, Feb 05, 2015 at 05:05:25PM +0100, Paolo Bonzini wrote:
This patch introduces a new module parameter for the KVM module; when it
is present, KVM attempts a bit of polling on every HLT before scheduling
itself out via
On Thu, Feb 05, 2015 at 03:23:50PM -0500, r...@redhat.com wrote:
From: Rik van Riel r...@redhat.com
Export context_tracking_user_enter/exit so it can be used by KVM.
Signed-off-by: Rik van Riel r...@redhat.com
Acked-by: Paul E. McKenney paul...@linux.vnet.ibm.com
---
On Thu, Feb 05, 2015 at 03:23:52PM -0500, r...@redhat.com wrote:
From: Rik van Riel r...@redhat.com
With code elsewhere doing something conditional on whether or not
context tracking is enabled, we want a stub function that tells us
context tracking is not enabled, when
On Thu, Feb 05, 2015 at 03:23:48PM -0500, r...@redhat.com wrote:
From: Rik van Riel r...@redhat.com
Add the expected ctx_state as a parameter to context_tracking_user_enter
and context_tracking_user_exit, allowing the same functions to not just
track kernel user space switching, but also
On Thu, Feb 05, 2015 at 03:23:51PM -0500, r...@redhat.com wrote:
From: Rik van Riel r...@redhat.com
The host kernel is not doing anything while the CPU is executing
a KVM guest VCPU, so it can be marked as being in an extended
quiescent state, identical to that used when running user space
On 02/05/2015 11:04 PM, Radim Krčmář wrote:
2015-02-05 14:23+0800, Kai Huang:
On 02/03/2015 11:18 PM, Radim Krčmář wrote:
You have it protected by CONFIG_X86_64, but use it unconditionally.
Thanks for catching. This has been fixed by another patch, and the fix has
also been merged by Paolo.
From: Rik van Riel r...@redhat.com
The host kernel is not doing anything while the CPU is executing
a KVM guest VCPU, so it can be marked as being in an extended
quiescent state, identical to that used when running user space
code.
The only exception to that rule is when the host handles an
From: Rik van Riel r...@redhat.com
Export context_tracking_user_enter/exit so it can be used by KVM.
Signed-off-by: Rik van Riel r...@redhat.com
---
kernel/context_tracking.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c
index
When running a KVM guest on a system with NOHZ_FULL enabled, and the
KVM guest running with idle=poll mode, we still get wakeups of the
rcuos/N threads.
This problem has already been solved for user space by telling the
RCU subsystem that the CPU is in an extended quiescent state while
running
From: Rik van Riel r...@redhat.com
Add the expected ctx_state as a parameter to context_tracking_user_enter
and context_tracking_user_exit, allowing the same functions to not just
track kernel user space switching, but also kernel guest transitions.
Signed-off-by: Rik van Riel r...@redhat.com
From: Rik van Riel r...@redhat.com
Only run vtime_user_enter and vtime_user_exit when we are entering
or exiting user state, respectively.
The RCU code only distinguishes between idle and not idle or kernel.
There should be no need to add an additional (unused) state there.
Signed-off-by: Rik
Am 05.02.2015 um 17:35 schrieb r...@redhat.com:
From: Rik van Riel r...@redhat.com
The host kernel is not doing anything while the CPU is executing
a KVM guest VCPU, so it can be marked as being in an extended
quiescent state, identical to that used when running user space
code.
The only
On 02/05/2015 11:44 AM, Christian Borntraeger wrote:
Am 05.02.2015 um 17:35 schrieb r...@redhat.com:
From: Rik van Riel r...@redhat.com
The host kernel is not doing anything while the CPU is executing
a KVM guest VCPU, so it can be marked as being in an extended
quiescent state, identical to
Hi,
I'm looking into qemu/balloon driver VM overcommit. I noticed
virtio-balloon driver will take any setting from virtio-balloon-device
to the point Guest dies.
For a 1G guest
$ sudo echo balloon 100 | socat - tcp4-connect:127.0.0.1:
you get (same with libvirt setmem)
root@localhost:~#
On 04/02/2015 20:32, Christian Borntraeger wrote:
A new architecture extends STSI 3.2.2 with UUID and long names. KVM will
provide the first implementation. This patch adds the additional data
fields (Extended Name and UUID) from the 4KB block returned by the STSI
3.2.2 command and
After f78146b0f923, KVM: Fix page-crossing MMIO, and
87da7e66a405, KVM: x86: fix vcpu-mmio_fragments overflow,
actually KVM_MMIO_SIZE is gone.
Signed-off-by: Tiejun Chen tiejun.c...@intel.com
---
arch/x86/include/asm/kvm_host.h | 2 --
include/linux/kvm_host.h| 4
2 files changed, 6
On 02/05/2015 11:05 AM, Paolo Bonzini wrote:
This patch introduces a new module parameter for the KVM module; when it
is present, KVM attempts a bit of polling on every HLT before scheduling
itself out via kvm_vcpu_block.
This parameter helps a lot for latency-bound workloads---in particular
On Thu, Feb 05, 2015 at 11:52:37AM -0500, Rik van Riel wrote:
On 02/05/2015 11:44 AM, Christian Borntraeger wrote:
Am 05.02.2015 um 17:35 schrieb r...@redhat.com:
From: Rik van Riel r...@redhat.com
The host kernel is not doing anything while the CPU is executing
a KVM guest VCPU, so it
On Thu, Feb 05, 2015 at 12:47:15PM +, David Vrabel wrote:
On 27/01/15 01:51, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This v5 nukes tracing as David said it was useless, it also
only adds support for 64-bit as its the only thing I can test,
and slightly
On 2015-02-05 17:05, Paolo Bonzini wrote:
This patch introduces a new module parameter for the KVM module; when it
is present, KVM attempts a bit of polling on every HLT before scheduling
itself out via kvm_vcpu_block.
Wouldn't it be better to tune this on a per-VM basis? Think of mixed
On Thu, Feb 05, 2015 at 01:09:19PM -0500, Rik van Riel wrote:
On 02/05/2015 12:50 PM, Paul E. McKenney wrote:
On Thu, Feb 05, 2015 at 11:52:37AM -0500, Rik van Riel wrote:
On 02/05/2015 11:44 AM, Christian Borntraeger wrote:
Am 05.02.2015 um 17:35 schrieb r...@redhat.com:
From: Rik van
On 02/05/2015 01:56 PM, Paul E. McKenney wrote:
On Thu, Feb 05, 2015 at 01:09:19PM -0500, Rik van Riel wrote:
On 02/05/2015 12:50 PM, Paul E. McKenney wrote:
On Thu, Feb 05, 2015 at 11:52:37AM -0500, Rik van Riel wrote:
On 02/05/2015 11:44 AM, Christian Borntraeger wrote:
Am 05.02.2015 um
On 05/02/2015 10:22, Tiejun Chen wrote:
After f78146b0f923, KVM: Fix page-crossing MMIO, and
87da7e66a405, KVM: x86: fix vcpu-mmio_fragments overflow,
actually KVM_MMIO_SIZE is gone.
Signed-off-by: Tiejun Chen tiejun.c...@intel.com
---
arch/x86/include/asm/kvm_host.h | 2 --
2015-02-05 17:05+0100, Paolo Bonzini:
This patch introduces a new module parameter for the KVM module; when it
is present, KVM attempts a bit of polling on every HLT before scheduling
itself out via kvm_vcpu_block.
This parameter helps a lot for latency-bound workloads---in particular
I
On 02/05/2015 12:50 PM, Paul E. McKenney wrote:
On Thu, Feb 05, 2015 at 11:52:37AM -0500, Rik van Riel wrote:
On 02/05/2015 11:44 AM, Christian Borntraeger wrote:
Am 05.02.2015 um 17:35 schrieb r...@redhat.com:
From: Rik van Riel r...@redhat.com
The host kernel is not doing anything while
On 05/02/2015 20:23, Rik van Riel wrote:
3) long term anyway we want it to auto tune, which is better than tuning
it per-VM.
We may want to auto tune it per VM.
We may even want to auto tune it per VCPU.
However, if we make auto tuning work well, I do not
think we want to expose a user
On 02/05/2015 02:27 PM, Paul E. McKenney wrote:
On Thu, Feb 05, 2015 at 02:02:35PM -0500, Rik van Riel wrote:
Looking at context_tracking.h, I see the
function context_tracking_cpu_is_enabled().
That looks like it should do the right thing
in this case.
Right you are -- that same check
When running a KVM guest on a system with NOHZ_FULL enabled, and the
KVM guest running with idle=poll mode, we still get wakeups of the
rcuos/N threads.
This problem has already been solved for user space by telling the
RCU subsystem that the CPU is in an extended quiescent state while
running
From: Rik van Riel r...@redhat.com
With code elsewhere doing something conditional on whether or not
context tracking is enabled, we want a stub function that tells us
context tracking is not enabled, when CONFIG_CONTEXT_TRACKING is
not set.
Signed-off-by: Rik van Riel r...@redhat.com
---
From: Rik van Riel r...@redhat.com
Add the expected ctx_state as a parameter to context_tracking_user_enter
and context_tracking_user_exit, allowing the same functions to not just
track kernel user space switching, but also kernel guest transitions.
Signed-off-by: Rik van Riel r...@redhat.com
From: Rik van Riel r...@redhat.com
The host kernel is not doing anything while the CPU is executing
a KVM guest VCPU, so it can be marked as being in an extended
quiescent state, identical to that used when running user space
code.
The only exception to that rule is when the host handles an
From: Rik van Riel r...@redhat.com
Only run vtime_user_enter and vtime_user_exit when we are entering
or exiting user state, respectively.
The RCU code only distinguishes between idle and not idle or kernel.
There should be no need to add an additional (unused) state there.
Signed-off-by: Rik
From: Rik van Riel r...@redhat.com
Export context_tracking_user_enter/exit so it can be used by KVM.
Signed-off-by: Rik van Riel r...@redhat.com
---
kernel/context_tracking.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c
index
On Thu, Feb 5, 2015 at 8:05 AM, Paolo Bonzini pbonz...@redhat.com wrote:
This patch introduces a new module parameter for the KVM module; when it
is present, KVM attempts a bit of polling on every HLT before scheduling
itself out via kvm_vcpu_block.
Awesome. I have been working on the same
60 matches
Mail list logo
