On 08.05.14 03:33, Marcelo Tosatti wrote:
On Mon, May 05, 2014 at 03:51:22PM +0200, Alexander Graf wrote:
When we migrate we ask the kernel about its current belief on what the guest
time would be. However, I've seen cases where the kvmclock guest structure
indicates a time more recent than the
https://bugzilla.kernel.org/show_bug.cgi?id=73721
--- Comment #4 from Marcus Schmidt ---
Thanks, now everything works good.
--
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a messag
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
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
--
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
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
Implement the kvm_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/kvm-cp
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/console.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/kvm/virtio/console.c b/tools/kvm/virtio/consol
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
-
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 +++
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
On 05/06/2014 04:30 PM, Aneesh Kumar K.V wrote:
Although it's optional IBM POWER cpus always had DAR value set on
alignment interrupt. So don't try to compute these values.
Signed-off-by: Aneesh Kumar K.V
The patch body is fine now. The commit message however is not. The patch
does two thing
On 8 May 2014 10:32, Marc Zyngier wrote:
> +int kvm_cpu__get_endianness(struct kvm_cpu *vcpu)
> +{
> + struct kvm_one_reg reg;
> + u64 psr;
> + u64 sctlr;
> +
> + /*
> +* Quoting the definition given by Peter Maydell:
> +*
> +* "Endianness of the CPU
On 05/06/2014 05:54 PM, Aneesh Kumar K.V wrote:
Today when KVM tries to reserve memory for the hash page table it
allocates from the normal page allocator first. If that fails it
falls back to CMA's reserved region. One of the side effects of
this is that we could end up exhausting the page alloc
On 05/06/2014 08:01 PM, Aneesh Kumar K.V wrote:
On recent IBM Power CPUs, while the hashed page table is looked up using
the page size from the segmentation hardware (i.e. the SLB), it is
possible to have the HPT entry indicate a larger page size. Thus for
example it is possible to put a 16MB pa
On 08/05/14 11:06, Peter Maydell wrote:
> On 8 May 2014 10:32, Marc Zyngier wrote:
>> +int kvm_cpu__get_endianness(struct kvm_cpu *vcpu)
>> +{
>> + struct kvm_one_reg reg;
>> + u64 psr;
>> + u64 sctlr;
>> +
>> + /*
>> +* Quoting the definition given by Peter Maydell
On Thu, May 08, 2014 at 10:32:48AM +0100, Marc Zyngier wrote:
> Implement the kvm_cpu__get_endianness call for both AArch32 and
> AArch64, and advertise the bi-endianness support.
>
> Signed-off-by: Marc Zyngier
Acked-by: Will Deacon
Will
--
To unsubscribe from this list: send the line "unsu
On 05/07/2014 09:09 AM, Paul Mackerras wrote:
On Fri, May 02, 2014 at 10:35:09AM +0200, Alexander Graf wrote:
On 05/01/2014 12:12 AM, Paul Mackerras wrote:
On Tue, Apr 29, 2014 at 06:17:37PM +0200, Alexander Graf wrote:
When we expose a POWER8 CPU into the guest, it will start accessing PMU SP
On 5/7/14, 6:52 PM, Paolo Bonzini wrote:
Il 07/05/2014 14:32, Nadav Amit ha scritto:
32-bit operations are zero extended in 64-bit mode. Currently, the
code does
not handle them correctly and keeps the high bits. In 16-bit mode, the
high
32-bits are kept intact.
In addition, although it is not
Attn:Beneficiary,
We have concluded the arrangement of releasing your total sum of ($5.2m USD)
in ATM CARD as instructed by United Nation U.N and Africa Union (A.U). We
tried as much as possible to uphold the already laid down principle of law
regarding the legitimate procedures necessary i
On 05/06/2014 09:06 PM, mihai.cara...@freescale.com wrote:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Friday, May 02, 2014 12:55 PM
To: Caraman Mihai Claudiu-B02008
Cc: kvm-...@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PA
Hi,
I am unable to get PCI passthrough to work on my Opteron system. I
keep getting an 'adapter reset' within the VM that has the PCI ethernet
assigned to it. It is running 2 x 6 core Opterons on a SuperMicro H8DCL
motherboard that has 2 Intel 82574L network interfaces on it.
On Thu, 2014-05-08 at 10:55 -0400, Derek Piper wrote:
>
>Hi,
>
> I am unable to get PCI passthrough to work on my Opteron system. I
> keep getting an 'adapter reset' within the VM that has the PCI ethernet
> assigned to it. It is running 2 x 6 core Opterons on a SuperMicro H8DC
On Thu, 2014-05-08 at 11:28 -0400, Derek Piper wrote:
>
> Attached is the dmesg from the host and the vm. I tried email these
> before but it seemed to make the message get rejected from the mailing list.
>
> I attached the PCIe device via the virt-manager, which modified the
>
On 05/07/2014 03:07 PM, Konrad Rzeszutek Wilk wrote:
Raghavendra KT had done some performance testing on this patch with
the following results:
Overall we are seeing good improvement for pv-unfair version.
System: 32 cpu sandybridge with HT on (4 node with 32 GB each)
Guest : 8GB with 16 vcpu/V
On 05/07/2014 03:07 PM, Konrad Rzeszutek Wilk wrote:
On Wed, May 07, 2014 at 11:01:28AM -0400, Waiman Long wrote:
v9->v10:
- Make some minor changes to qspinlock.c to accommodate review feedback.
- Change author to PeterZ for 2 of the patches.
- Include Raghavendra KT's test results in
On Wed, May 07, 2014 at 11:01:31AM -0400, Waiman Long wrote:
> +/**
> + * trylock_pending - try to acquire queue spinlock using the pending bit
> + * @lock : Pointer to queue spinlock structure
> + * @pval : Pointer to value of the queue spinlock 32-bit word
> + * Return: 1 if lock acquired, 0 othe
On Wed, May 07, 2014 at 11:01:34AM -0400, Waiman Long wrote:
> @@ -221,11 +222,37 @@ static inline int trylock_pending(struct qspinlock
> *lock, u32 *pval)
>*/
> for (;;) {
> /*
> - * If we observe any contention; queue.
> + * If we observe tha
On Wed, May 07, 2014 at 11:01:35AM -0400, Waiman Long wrote:
> @@ -94,23 +94,29 @@ static inline struct mcs_spinlock *decode_tail(u32 tail)
> * can allow better optimization of the lock acquisition for the pending
> * bit holder.
> */
> -#if _Q_PENDING_BITS == 8
> -
> struct __qspinlock {
>
On Wed, May 07, 2014 at 11:01:35AM -0400, Waiman Long wrote:
> /**
> + * get_qlock - Set the lock bit and own the lock
> + * @lock: Pointer to queue spinlock structure
> + *
> + * This routine should only be called when the caller is the only one
> + * entitled to acquire the lock.
> + */
> +stati
On Wed, May 07, 2014 at 11:01:36AM -0400, Waiman Long wrote:
> /*
> + * To have additional features for better virtualization support, it is
> + * necessary to store additional data in the queue node structure. So
> + * a new queue node structure will have to be defined and used here.
> + */
> +st
On Wed, May 07, 2014 at 11:01:37AM -0400, Waiman Long wrote:
> If unfair lock is supported, the lock acquisition loop at the end of
> the queue_spin_lock_slowpath() function may need to detect the fact
> the lock can be stolen. Code are added for the stolen lock detection.
>
> A new qhead macro is
On Wed, May 07, 2014 at 11:01:38AM -0400, Waiman Long wrote:
No, we want the unfair thing for VIRT, not PARAVIRT.
> diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c
> index 9e7659e..10e87e1 100644
> --- a/kernel/locking/qspinlock.c
> +++ b/kernel/locking/qspinlock.c
> @@ -22
On Wed, May 07, 2014 at 11:01:40AM -0400, Waiman Long wrote:
> +#define DEF_LOOP_CNT(c) int c = 0
> +#define INC_LOOP_CNT(c) (c)++
> +#define LOOP_CNT(c) c
> +#define LSTEAL_MIN (1 << 3)
> +#define LSTEAL_MAX (1 << 10)
> +#define LSTEAL_MIN_MAS
On Thu, May 08, 2014 at 09:21:29AM +0200, Alexander Graf wrote:
>
> On 08.05.14 03:33, Marcelo Tosatti wrote:
> >On Mon, May 05, 2014 at 03:51:22PM +0200, Alexander Graf wrote:
> >>When we migrate we ask the kernel about its current belief on what the guest
> >>time would be. However, I've seen ca
Alexander Graf writes:
> On 05/07/2014 11:57 AM, Marc Zyngier wrote:
> How virtio implementations should determine their endianness is
> a spec question, I think; at any rate QEMU and kvmtool ought to
> agree on how it's done. I think the most recent suggestion on the
> QEMU mailin
37 matches
Mail list logo
