Hi, ALL
Currently kvm hypervisor have lots of features depend on linux standard apis,
like vcpupin/mempin/processpin etc. But in the real production environment,
we need an automated resource assign and/or scheduling, is there any plan to
implement it?
resource assignment requirements like:
cpu
On 04/24/2014 09:39 AM, Steve Capper wrote:
> On Wed, Apr 23, 2014 at 12:18:07AM +0100, Mario Smarduch wrote:
>>
>>
>> Support for live migration initial write protect.
>> - moved write protect to architecture memory region prepare function. This
>> way you can fail, abort migration without keep
On Fri, Apr 25, 2014 at 12:57:48AM +0200, Paolo Bonzini wrote:
> Il 24/04/2014 22:57, Eduardo Habkost ha scritto:
> >On Thu, Apr 24, 2014 at 04:42:33PM -0400, Paolo Bonzini wrote:
> >>Il 22/04/2014 21:14, Eduardo Habkost ha scritto:
> >>>Not for "-cpu host". If somebody needs migration to work, the
Il 24/04/2014 22:57, Eduardo Habkost ha scritto:
On Thu, Apr 24, 2014 at 04:42:33PM -0400, Paolo Bonzini wrote:
Il 22/04/2014 21:14, Eduardo Habkost ha scritto:
Not for "-cpu host". If somebody needs migration to work, they shouldn't
be using "-cpu host" anyway (I don't know if you have seen th
> > >>> So, do I have to pull something (which I'd rather not, since pulling
> > >>> the wrong thing in a submaintainer tree will make Linus angry), or
> > >>> should I do it in the next merge window after pci_enable_msix_exact
> > >>> gets in?
> > >So it is already in.
> >
> > It is not, because
On Thu, Apr 24, 2014 at 04:42:33PM -0400, Paolo Bonzini wrote:
> Il 22/04/2014 21:14, Eduardo Habkost ha scritto:
> >Not for "-cpu host". If somebody needs migration to work, they shouldn't
> >be using "-cpu host" anyway (I don't know if you have seen the other
> >comments in my message?).
>
> I'm
Il 22/04/2014 21:14, Eduardo Habkost ha scritto:
Not for "-cpu host". If somebody needs migration to work, they shouldn't
be using "-cpu host" anyway (I don't know if you have seen the other
comments in my message?).
I'm not entirely sure. If you have hosts with exactly identical
chipsets, "-
On Wed, Apr 23, 2014 at 06:04:45PM -0300, Marcelo Tosatti wrote:
>
> Invariant TSC documentation mentions that "invariant TSC will run at a
> constant rate in all ACPI P-, C-. and T-states".
>
> This is not the case if migration to a host with different TSC frequency
> is allowed, or if savevm i
This patch series adds some infrastructure to kvmtool to allow a BE
guest to use virtio-mmio on a LE host, provided that the architecture
actually supports such madness.
Not all the backend have been converted, only those I actually cared
about. Converting them is pretty easy though, and will be d
Configure the queues to follow the guest endianness, and make sure
the configuration space is doing the same.
Signed-off-by: Marc Zyngier
---
tools/kvm/virtio/console.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/kvm/virtio/console.c b/tools/kvm/virtio/consol
Implement the kcm_cpu__get_endianness call for both AArch32 and
AArch64, and advertise the bi-endianness support.
Signed-off-by: Marc Zyngier
---
tools/kvm/arm/aarch32/kvm-cpu.c | 14 +
tools/kvm/arm/aarch64/include/kvm/kvm-cpu-arch.h | 2 ++
tools/kvm/arm/aarch64/k
Save the CPU endianness when the device is reset. It is widely
assumed that the guest won't change its endianness after, or at
least not without reseting the device first.
A default implementation of the endianness sampling just returns
the default "host endianness" value so that unsuspecting arch
Add a utility function that transfers the endianness sampled
at device reset time to a queue being set up.
Signed-off-by: Marc Zyngier
---
tools/kvm/include/kvm/virtio.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/tools/kvm/include/kvm/virtio.h b/tools/kvm/include/kvm/virtio.h
ind
Configure the queues to follow the guest endianness, and make sure
the configuration space is doing the same.
Signed-off-by: Marc Zyngier
---
tools/kvm/virtio/blk.c | 31 +--
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/tools/kvm/virtio/blk.c b/tools
Configure the queues to follow the guest endianness, and make sure
the configuration space is doing the same.
Extra care is taken for the handling of the virtio_net_hdr structures
on both the TX and RX ends.
Signed-off-by: Marc Zyngier
---
tools/kvm/virtio/net.c | 45 +++
Configure the queues to follow the guest endianness, and make sure
the configuration space is doing the same.
Signed-off-by: Marc Zyngier
---
tools/kvm/virtio/9p.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/kvm/virtio/9p.c b/tools/kvm/virtio/9p.c
index 847eddb..9073a1e 100644
-
Define a simple infrastructure to configure a virt_queue
depending on the guest endianness, as reported by the feature
flags. At this stage, the endianness is always the host's.
Wrap all accesses to virt_queue data structures shared between
host and guest with byte swapping helpers.
Should the ar
In order to be able to find out about the endianness of a virtual
CPU, it is necessary to pass a pointer to the kvm_cpu structure
down to the MMIO accessors.
This patch just pushes such pointer as far as required for the
MMIO accessors to have a play with the vcpu.
Signed-off-by: Marc Zyngier
--
This small series addresses a number of issues that have been
pestering me for a while. Nothing major though:
The first two patches simply ensure that we can always use THP if the
have been enabled on the host. Third one fixes an annoying issue when
-tty is used.
The fourth patch allows me to use
The --tty option allows the redirection of a console (serial or virtio)
to a pseudo-terminal. As long as the slave port of this pseudo-terminal
is not opened by another process, a poll() call on the master port will
return POLLHUP in the .event field.
This confuses the virtio console code, as term
Use of THP requires that the VMA containing the guest memory is
2MB aligned. Unfortunately, nothing in kvmtool ensures that the
memory is actually aligned, making the use of THP very unlikely.
Just follow what we're already doing for virtio, and expand our
forced alignment to 2M.
* without this p
If the host kernel is configured with CONFIG_TRANSPARENT_HUGEPAGE_MADVISE,
it is important to madvise(MADV_HUGEPAGE) the memory region.
Otherwise, the guest won't benefit from using THP.
Acked-by: Will Deacon
Signed-off-by: Marc Zyngier
---
tools/kvm/arm/kvm.c | 2 +-
1 file changed, 1 insertio
In order to overcome the fact that a TAP interface can only be created
by root, allow the use of an interface that has already been created,
configured, made persistent and owned by a specific user/group (such
as done with tunctl).
In this case, any kind of configuration can be skipped (IP, up and
On Thu, Apr 24, 2014 at 05:39:29PM +0100, Steve Capper wrote:
[ ... ]
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> c
On Wed, Apr 23, 2014 at 12:18:07AM +0100, Mario Smarduch wrote:
>
>
> Support for live migration initial write protect.
> - moved write protect to architecture memory region prepare function. This
> way you can fail, abort migration without keep track of migration status.
> - Above also allows to
On Thu, Apr 17, 2014 at 05:06:11PM +0800, Xiao Guangrong wrote:
> Since Marcelo has agreed the comments improving in the off-line mail, i
> consider this is his Ack. :) Please let me know If i misunderstood it.
>
> This patchset is splited from my previous patchset:
> [PATCH v3 00/15] KVM: MMU: lo
On 04/24, Christian Borntraeger wrote:
>
> On 21/04/14 15:25, Oleg Nesterov wrote:
> > Hello.
> >
> > Completely untested and I know nothing about kvm ;) Please review.
> >
> > But use_mm() really looks misleading, and the usage of mm_users looks
> > "obviously wrong". I already sent this change wh
On 21/04/14 15:25, Oleg Nesterov wrote:
> Hello.
>
> Completely untested and I know nothing about kvm ;) Please review.
>
> But use_mm() really looks misleading, and the usage of mm_users looks
> "obviously wrong". I already sent this change while we were discussing
> vmacache, but it was ignored
To control whether we should inject interrupts in little or big endian
mode, user space sets the LPCR.ILE bit accordingly via ONE_REG.
Let's implement it, so we are able to trigger interrupts in LE mode.
Signed-off-by: Alexander Graf
---
arch/powerpc/include/asm/kvm_book3s.h | 1 +
arch/powerpc
With the previous patches applied, we can now successfully use PR KVM on
little endian hosts which means we can now allow users to select it.
However, HV KVM still needs some work, so let's keep the kconfig conflict
on that one.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/Kconfig | 2 +-
During the enablement of ppc64le KVM has been kept unfixed. This patch set
is the initial attempt to make all of KVM work on ppc64le hosts. It starts
the effort by bringing PR KVM over.
With this patch set I am successfully able to run book3s_32 (BE) and
book3s_64 (BE, LE) guests on a host ppc64le
When we calculate the actual MSR that the guest is running with when in guest
context, we take a few MSR bits from the MSR the guest thinks it's using.
Add MSR_LE to these bits, so the guest gets full control over its own endianness
setting.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/bo
The HTAB is always big endian. We access the guest's HTAB using
copy_from/to_user, but don't yet take care of the fact that we might
be running on an LE host.
Wrap all accesses to the guest HTAB with big endian accessors.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/book3s_32_mmu.c | 16 +
We expose a blob of hypercall instructions to user space that it gives to
the guest via device tree again. That blob should contain a stream of
instructions necessary to do a hypercall in big endian, as it just gets
passed into the guest and old guests use them straight away.
Signed-off-by: Alexan
The HTAB is always big endian. We access the guest's HTAB using
copy_from/to_user, but don't yet take care of the fact that we might
be running on an LE host.
Wrap all accesses to the guest HTAB with big endian accessors.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/book3s_64_mmu.c | 11 +
The "shadow SLB" in the PACA is shared with the hypervisor, so it has to
be big endian. We access the shadow SLB during world switch, so let's make
sure we access it in big endian even when we're on a little endian host.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/book3s_64_slb.S | 33 +++
When the guest does an RTAS hypercall it keeps all RTAS variables inside a
big endian data structure.
To make sure we don't have to bother about endianness inside the actual RTAS
handlers, let's just convert the whole structure to host endian before we
call our RTAS handlers and back to big endian
Commit 9308ab8e2d made C/R HTAB updates go byte-wise into the target HTAB.
However, it didn't update the guest's copy of the HTAB, but instead the
host local copy of it.
Write to the guest's HTAB instead.
Signed-off-by: Alexander Graf
CC: Paul Mackerras
---
arch/powerpc/kvm/book3s_32_mmu.c | 2
The HTAB on PPC is always in big endian. When we access it via hypercalls
on behalf of the guest and we're running on a little endian host, we need
to make sure we swap the bits accordingly.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/book3s_pr_papr.c | 14 +++---
1 file changed,
The shared (magic) page is a data structure that contains often used
supervisor privileged SPRs accessible via memory to the user to reduce
the number of exits we have to take to read/write them.
When we actually share this structure with the guest we have to maintain
it in guest endianness, becau
When the host CPU we're running on doesn't support dcbz32 itself, but the
guest wants to have dcbz only clear 32 bytes of data, we loop through every
executable mapped page to search for dcbz instructions and patch them with
a special privileged instruction that we emulate as dcbz32.
The only gues
The default MSR when user space does not define anything should be identical
on little and big endian hosts, so remove MSR_LE from it.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/book3s_pr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/book3s_pr.c b
Hi Rik,
On Tue, Apr 22, 2014 at 10:40:17AM -0400, Rik van Riel wrote:
> On 04/22/2014 07:57 AM, Christian Borntraeger wrote:
> > On 22/04/14 12:55, Christian Borntraeger wrote:
> >> While preparing/testing some KVM on s390 patches for the next merge window
> >> (target is kvm/next which is based
Thank you very much!
I will post a patch tomorrow.
--Best wishes!
//Zhang Jie
-Original Message-
From: Michael S. Tsirkin [mailto:m...@redhat.com]
Sent: Thursday, April 24, 2014 7:45 PM
To: Zhangjie (HZ)
Cc: jasow...@redhat.com; Qinchuanyu; Liuyongan; kvm@vger.kernel.org;
net...@vger.ker
On Thu, Apr 24, 2014 at 10:19:58AM +, Zhangjie (HZ) wrote:
> Hi!
>
> Patch “virtio-net: put virtio net header inline with data” , has a notable
> improvement for TCP packages.
>
> But UDP packages from virtio_net nic, do not have enough head room. I wonder
> if
> we can set dev->needed_headr
3.11.10.9 -stable review patch. If anyone has any objections, please let me
know.
--
From: James Hogan
commit 15505679362270d02c449626385cb74af8905514 upstream.
Previously a reserved instruction exception while in guest code would
cause a KVM internal error if kvm_mips_handle
46 matches
Mail list logo