Hi, Jan
Can you provide details of your test environment?
-Original Message-
From: Jan Kiszka [mailto:jan.kis...@web.de]
Sent: Sunday, April 28, 2013 5:36 PM
To: Xu, Xinhao
Cc: Nakajima, Jun; kvm@vger.kernel.org
Subject: Re: [PATCH 11/11] nEPT: Provide the correct exit qualification upon
On Sat, Apr 27, 2013 at 10:28:37AM -, Paul Mackerras wrote:
> This adds the API for userspace to instantiate an XICS device in a VM
> and connect VCPUs to it. The API consists of a new device type for
> the KVM_CREATE_DEVICE ioctl, a new capability KVM_CAP_IRQ_XICS, which
> functions similarly
On Wed, May 01, 2013 at 08:40:54PM -0700, Tom Lyon wrote:
> Virtiio_mmio attempts to mimic the layout of some control registers
> from virtio_pci. These registers, in particular
> VIRTIO_MMIO_QUEUE_SEL and VIRTIO_PCI_QUEUE_SEL,
> are active in nature, and not just passive like a normal memory
> lo
From: Wei Yongjun
Add the missing unlock before return from function set_base_addr()
when disables the mapping.
Introduced by commit 5df554ad5b7522ea62b0ff9d5be35183494efc21
(kvm/ppc/mpic: in-kernel MPIC emulation)
Signed-off-by: Wei Yongjun
---
arch/powerpc/kvm/mpic.c | 2 +-
1 file changed,
On Sun, Apr 28, 2013 at 03:11:49PM +0300, Michael S. Tsirkin wrote:
> On Sun, Apr 28, 2013 at 06:55:20PM +0800, Asias He wrote:
> > On Sun, Apr 28, 2013 at 12:27:15PM +0300, Michael S. Tsirkin wrote:
> > > On Sun, Apr 28, 2013 at 04:52:08PM +0800, Asias He wrote:
> > > > On Sun, Apr 28, 2013 at 11:
On Thu, May 02, 2013 at 04:45:30AM +0300, Michael S. Tsirkin wrote:
> This reorgs the files a bit, renaming tcm_vhost to
> vhost_scsi as that's how userspace refers to it.
> While at it, cleanup some leftovers from when it was a
> staging driver.
>
> Signed-off-by: Michael S. Tsirkin
Reviewed-by
On Wed, May 01, 2013 at 09:42:22AM +0300, Michael S. Tsirkin wrote:
> On Sat, Apr 27, 2013 at 11:42:09AM +0800, Asias He wrote:
> > Signed-off-by: Asias He
>
>
> Nicholas, thoughts?
> How about we move tcm_vhost.c to scsi.c
> call module vhost_scsi and add tcm_vhost as an alias?
This is even be
Virtiio_mmio attempts to mimic the layout of some control registers from
virtio_pci. These registers, in particular VIRTIO_MMIO_QUEUE_SEL and
VIRTIO_PCI_QUEUE_SEL,
are active in nature, and not just passive like a normal memory
location. Thus, the host side must react immediately upon write of
On Thu, 2013-05-02 at 04:45 +0300, Michael S. Tsirkin wrote:
> This reorgs the files a bit, renaming tcm_vhost to
> vhost_scsi as that's how userspace refers to it.
> While at it, cleanup some leftovers from when it was a
> staging driver.
>
> Signed-off-by: Michael S. Tsirkin
>
>
Acked-by: Ni
On Wed, May 01, 2013 at 03:05:48PM -0400, David Miller wrote:
> From: "Michael S. Tsirkin"
> Date: Wed, 1 May 2013 18:01:31 +0300
>
> > Please pull the following vhost core updates for 3.10 -
> > they affect both vhost-net and vhost-scsi devices.
> > They also *depend* on both net-next and target
Rename module and update Kconfig and Makefile.
Add alias for compatibility with old userspace
scripts if any.
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/Kconfig | 10 +++---
drivers/vhost/Kconfig.tcm | 6 --
drivers/vhost/Makefile| 4 ++--
drivers/vhost/scsi.c |
move uapi parts to vhost.h
move .c private parts to .c itself
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/scsi.c | 112 +++---
drivers/vhost/tcm_vhost.h | 131 -
include/uapi/linux/vhost.h | 28 ++
Move tcm_vhost.c -> scsi.c
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/Makefile| 1 +
drivers/vhost/{tcm_vhost.c => scsi.c} | 0
2 files changed, 1 insertion(+)
rename drivers/vhost/{tcm_vhost.c => scsi.c} (100%)
diff --git a/drivers/vhost/Makefile b/drivers/vhost/Makef
This reorgs the files a bit, renaming tcm_vhost to
vhost_scsi as that's how userspace refers to it.
While at it, cleanup some leftovers from when it was a
staging driver.
Signed-off-by: Michael S. Tsirkin
Michael S. Tsirkin (3):
vhost: src file renames
tcm_vhost: header split up
vhost_scs
On 05/01/2013 07:27:23 PM, Scott Wood wrote:
On 05/01/2013 07:15:53 PM, Marcelo Tosatti wrote:
This is not good practice (codepaths should either hold srcu or not
hold
it, unconditionally).
How is it different from moving the srcu lock into individual cases
of the switch? I just did it th
On 05/01/2013 07:15:53 PM, Marcelo Tosatti wrote:
On Fri, Apr 26, 2013 at 07:53:38PM -0500, Scott Wood wrote:
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index 1020119..506c87d 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -832,6 +832,8 @@
On Fri, Apr 26, 2013 at 07:53:38PM -0500, Scott Wood wrote:
> KVM core expects arch code to acquire the srcu lock when calling
> gfn_to_memslot and similar functions.
>
> Signed-off-by: Scott Wood
> ---
> arch/powerpc/kvm/44x_tlb.c |5 +
> arch/powerpc/kvm/booke.c| 19
On 27.04.2013, at 02:53, Scott Wood wrote:
> Nobody is actually calling these functions with slots_lock held.
> The srcu read lock, OTOH, is required.
>
> Signed-off-by: Scott Wood
Marcelo, could you please ack?
Alex
> ---
> virt/kvm/kvm_main.c |4 ++--
> 1 file changed, 2 insertions(+),
On Wed, May 01, 2013 at 10:19:24AM -0300, Marcelo Tosatti wrote:
> Applied, thanks.
You shouldn't have - Ingo took it already.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body o
On Fri, Apr 26, 2013 at 11:51:40AM +0200, Borislav Petkov wrote:
> On Fri, Apr 26, 2013 at 08:42:50AM +0200, Ingo Molnar wrote:
> >
> > ... < take all review comments >
>
> Here it is:
>
> --
> >From 56880e448600ca1504df8c68c59f31153f7b5b0f Mon Sep 17 00:00:00 2001
> From: Borislav Petkov
> Date
On Thu, Apr 25, 2013 at 11:13:40PM +0200, Alexander Graf wrote:
>
> On 25.04.2013, at 21:03, Scott Wood wrote:
>
> > On 04/25/2013 09:49:23 AM, Alexander Graf wrote:
> >> On 25.04.2013, at 13:30, Alexander Graf wrote:
> >> >
> >> > On 19.04.2013, at 20:51, Scott Wood wrote:
> >> >
> >> >> On 04/1
From: "Michael S. Tsirkin"
Date: Wed, 1 May 2013 18:01:31 +0300
> Please pull the following vhost core updates for 3.10 -
> they affect both vhost-net and vhost-scsi devices.
> They also *depend* on both net-next and target-pending. Since Linus
> merged target-pending but not net-next at this po
On Wed, May 1, 2013 at 9:49 AM, Dave P Martin wrote:
> Currently, kvmtool unconditionally declares that HVC should be used
> to call PSCI, so the function numbers in the DT tell the guest
> nothing about the function ID namespace or calling convention for
> SMC.
>
> We already assume that the gues
On Wed, May 01, 2013 at 09:07:56AM -0700, Nicholas A. Bellinger wrote:
> On Wed, 2013-05-01 at 09:42 +0300, Michael S. Tsirkin wrote:
> > On Sat, Apr 27, 2013 at 11:42:09AM +0800, Asias He wrote:
> > > Signed-off-by: Asias He
> >
> >
> > Nicholas, thoughts?
> > How about we move tcm_vhost.c to s
On Wed, May 01, 2013 at 09:05:35AM -0700, Nicholas A. Bellinger wrote:
> On Wed, 2013-05-01 at 18:01 +0300, Michael S. Tsirkin wrote:
> > Please pull the following vhost core updates for 3.10 -
> > they affect both vhost-net and vhost-scsi devices.
> > They also *depend* on both net-next and target
Currently, kvmtool unconditionally declares that HVC should be used
to call PSCI, so the function numbers in the DT tell the guest
nothing about the function ID namespace or calling convention for
SMC.
We already assume that the guest will examine and honour the DT,
since there is no way it could
On Wed, 2013-05-01 at 09:42 +0300, Michael S. Tsirkin wrote:
> On Sat, Apr 27, 2013 at 11:42:09AM +0800, Asias He wrote:
> > Signed-off-by: Asias He
>
>
> Nicholas, thoughts?
> How about we move tcm_vhost.c to scsi.c
> call module vhost_scsi and add tcm_vhost as an alias?
> If not - want this al
On Wed, 2013-05-01 at 18:01 +0300, Michael S. Tsirkin wrote:
> Please pull the following vhost core updates for 3.10 -
> they affect both vhost-net and vhost-scsi devices.
> They also *depend* on both net-next and target-pending. Since Linus
> merged target-pending but not net-next at this point,
From: Marc Zyngier
Kvmtool suppresses any output to a console that has not been elected
as *the* console.
While this makes sense on the input side (we want the input to be sent
to one console driver only), it seems to be the wrong thing to do on
the output side, as it effectively prevents the gu
Hi guys,
This RFC series does a number of things, but the main goal is to allow
re-use of the emulation code under hw/ on architectures other than x86.
It also comes about after discussions concerning virtio-console for
earlyprintk:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-Apr
From: Marc Zyngier
Having several uarts with the same name makes the kernel (and dtc)
choke. Add the base address as a qualifier so we get unique names.
Signed-off-by: Marc Zyngier
Signed-off-by: Will Deacon
---
tools/kvm/hw/serial.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions
If an architecture other than x86 wants to make use of ioport devices, the
interrupt lines will likely need remapping from their fixed values.
This patch allows an architecture callback, ioport__map_irq, to map
interrupts as appropriate.
Signed-off-by: Will Deacon
---
tools/kvm/arm/ioport.c
This patch adds fdt node generation to the 8250 emulation. The
serial8250_device is now stashed inside the ioport priv field, so that
it can be retrieved from the ioport passed back to the generation code.
Signed-off-by: Will Deacon
---
tools/kvm/hw/serial.c | 55 +++-
Generating fdt nodes for virtio-mmio devices should be in the core code,
not hidden inside the architecture code for ARM.
This patch reworks the .data field of struct device_header for
virtio-mmio devices, so that it contains a function pointer which can
be called to generate the FDT node for each
Whilst ARM neither needs or wants a complete x86 legacy ioport emulation,
the 8250 is a useful alternative to virtio-console, so carve out 64k at the
bottom of our virtual memory map where we can add ioports if we choose.
Signed-off-by: Will Deacon
---
tools/kvm/arm/include/arm-common/kvm-arch.h
Architectures without a legacy ioport may wish to emulate one, but not
at address 0x0.
This patch introduces KVM_IOPORT_AREA, which each architecture defines
to be the start of the ioport region (i.e. where port addresses are
offset from).
Signed-off-by: Will Deacon
---
tools/kvm/arm/include/ar
libfdt is used by powerpc, arm and arm64.
This patch factors out the Makefile parts including it and defines a
CONFIG_HAS_LIBFDT, so architecture-portable code can make use of fdt
if it is available.
Signed-off-by: Will Deacon
---
tools/kvm/Makefile | 31 +++
1 file
Now that ioport devices can generate fdt nodes, iterate over the ioport
bus when generating our fdt.
Signed-off-by: Will Deacon
---
tools/kvm/arm/fdt.c | 8
1 file changed, 8 insertions(+)
diff --git a/tools/kvm/arm/fdt.c b/tools/kvm/arm/fdt.c
index 7198fe8..5e18c11 100644
--- a/tools/
Devices in the ioport space may have fdt bindings (e.g. 8250, rtc) and
on architectures where a fixed ioport is not defined, it is necessary
to generate fdt nodes for them.
This patch creates a new virtual bus (tree of device_headers) for ioport
devices, allowing architecture code to callback to t
If we're using the 8250 as a fully-fledged console (i.e. not early
console), then we need to allow input as well as output.
Signed-off-by: Will Deacon
---
tools/kvm/arm/kvm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tools/kvm/arm/kvm.c b/tools/kvm/arm/kvm.c
index 1
Please pull the following vhost core updates for 3.10 -
they affect both vhost-net and vhost-scsi devices.
They also *depend* on both net-next and target-pending. Since Linus
merged target-pending but not net-next at this point, merging through
the net tree seems to make sense.
The following chan
On Thu, Apr 18, 2013 at 02:52:31AM +0800, Xiao Guangrong wrote:
> On 04/18/2013 02:45 AM, Robin Holt wrote:
>
> >>> For the v3.10 release, we should work on making this more
> >>> correct and completely documented.
> >>
> >> Better document is always welcomed.
> >>
> >> Dou
42 matches
Mail list logo
