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
---
arch/x86/include/asm/kvm_host.h | 2 --
include/linux/kvm_host.h| 4
2 files changed, 6 deletions(-)
di
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
> ---
> arch/x86/include/asm/kvm_host.h | 2 --
> include/linux/kvm_hos
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 r
On 27/01/15 01:51, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> 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 thing i
On Wed, 04 Feb 2015 09:26:11 +0100
Christian Borntraeger 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:
When classic channel I/
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 thi
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
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 eithe
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 battery-bac
Am 05.02.2015 um 17:35 schrieb r...@redhat.com:
> From: Rik van Riel
>
> 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 excepti
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
>>
>> 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
From: Rik van Riel
Export context_tracking_user_enter/exit so it can be used by KVM.
Signed-off-by: Rik van Riel
---
kernel/context_tracking.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c
index 97806c4deec5..a3f4a2840637 100644
---
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 use
From: Rik van Riel
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
---
include/linux/context_
From: Rik van Riel
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 van Riel
---
From: Rik van Riel
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
interrupt, which is
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 partic
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
> >>
> >> The host kernel is not doing anything while the CPU is executing
> >> a KVM guest VCPU, so it c
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
>
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
The host kernel is not doing anything while
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"
> >
> > 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 modifie
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
work
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:
> Fr
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.
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 critica
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 mi
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
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
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
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
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 use
From: Rik van Riel
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
---
include/linux/context_tracking_state
From: Rik van Riel
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
---
include/linux/context_
From: Rik van Riel
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
interrupt, which is
From: Rik van Riel
Export context_tracking_user_enter/exit so it can be used by KVM.
Signed-off-by: Rik van Riel
---
kernel/context_tracking.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c
index 97806c4deec5..a3f4a2840637 100644
---
From: Rik van Riel
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 van Riel
---
On Thu, Feb 5, 2015 at 8: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.
Awesome. I have been working on the same feature in parallel
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, mo
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 kvm_inject_page_
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 wor
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
On Thu, Feb 05, 2015 at 03:23:52PM -0500, r...@redhat.com wrote:
> From: Rik van Riel
>
> 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
On Thu, Feb 05, 2015 at 03:23:48PM -0500, r...@redhat.com wrote:
> From: Rik van Riel
>
> 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 <> g
On Thu, Feb 05, 2015 at 03:23:51PM -0500, r...@redhat.com wrote:
> From: Rik van Riel
>
> 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.
>
>
On Thu, Feb 05, 2015 at 03:23:50PM -0500, r...@redhat.com wrote:
> From: Rik van Riel
>
> Export context_tracking_user_enter/exit so it can be used by KVM.
>
> Signed-off-by: Rik van Riel
Acked-by: Paul E. McKenney
> ---
> kernel/context_tracking.c | 2 ++
> 1 file changed, 2 insertions(+)
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 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.
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:~# fre
From: Nicholas Bellinger
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 starting virtio-scsi req
From: Nicholas Bellinger
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 processing when struct iovec
From: Nicholas Bellinger
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 pointer from &vq->iov[out]
From: Nicholas Bellinger
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
Acked-by: Michael S. Tsirkin
Cc: Paolo Bonzini
Signed-off-by: Nicholas Bellinger
From: Nicholas Bellinger
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
Acked-by: Michael S. Tsirkin
Cc: Paolo Bonzini
Signed-off-by: Nicholas Bellinger
---
drivers/vhost/scsi.c | 4 +++-
From: Nicholas Bellinger
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 tcm_vhost_cmd->tvc_n
From: Nicholas Bellinger
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 iov_iter,
assuming the lay
From: Nicholas Bellinger
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
Cc: Paolo Bonzini
Signed-off-by: Nic
From: Nicholas Bellinger
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
Acked-by: Michael S. Tsirkin
Cc: Paolo Bonzini
Sign
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 fin
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 f
60 matches
Mail list logo
