On 6/19/2009 12:50 AM, David Huff wrote:
Second pass at the unattended install test. Both Linux and Windows guests are
working however currently it just uses the existing boot test and extends
timeouts. We still need a good way of determining if an unattended install
completed without error.
Hello Rusty,
this is a result of a two month internship about virtio testing.
From: Adrian Schneider adrian.schnei...@de.ibm.com
From: Tim Hofmann tim.hofm...@de.ibm.com
From: Christian Ehrhardt ehrha...@de.ibm.com
From: Christian Borntraeger borntrae...@de.ibm.com
This patch introduces a
On Friday 19 June 2009 00:28:41 Alex Williamson wrote:
On Thu, 2009-06-18 at 13:30 +0800, Yang, Sheng wrote:
On Tuesday 16 June 2009 00:29:17 Alex Williamson wrote:
The PCI code already knows about option ROMs, so we just need to
mmap some space for it, load it with a copy of the
On 19.06.2009, at 03:19, Ben Sanders wrote:
I needed nested paging to have things work, so phenom was mandatory.
Also, because I was running things on a Phenom, I figured the
safest bet is
to be truthful in telling the guest what it's running on. Also ESX
checked
for specific cpuid
From: Paolo Bonzini pbonz...@redhat.com
KVM's optimization of guest port 80 accesses was removed last May 11
in commit 99f85a. However, this probably has speed penalties. I don't
have a machine to test but the equivalent VMX patch (fdef3ad) reported
a speedup of 3-5%, and on the Xen mailing
On Thu, 2009-06-18 at 17:16 +0800, Yolkfull Chow wrote:
Hi Lucas, I also found the number counting problem later after sending
the patch. I haven't been able to re-send the updated one since I got
some other things to deal with in these days. Sorry for that...
Please see attachment for
With the new name and the corresponding backend changes this function
can now support multiple hugepage sizes.
Signed-off-by: Joerg Roedel joerg.roe...@amd.com
---
arch/x86/kvm/mmu.c | 100 +--
arch/x86/kvm/paging_tmpl.h |4 +-
2 files
Signed-off-by: Joerg Roedel joerg.roe...@amd.com
---
arch/x86/include/asm/kvm_host.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 397f992..26ea9b8 100644
--- a/arch/x86/include/asm/kvm_host.h
+++
Signed-off-by: Joerg Roedel joerg.roe...@amd.com
---
arch/ia64/include/asm/kvm_host.h|3 +-
arch/powerpc/include/asm/kvm_host.h |3 +-
arch/x86/include/asm/kvm_host.h | 12
arch/x86/kvm/mmu.c | 30 ++-
arch/x86/kvm/paging_tmpl.h
This function is required by KVM.
Signed-off-by: Joerg Roedel joerg.roe...@amd.com
---
mm/hugetlb.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index e83ad2c..e2016ef 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -234,6 +234,7 @@
Signed-off-by: Joerg Roedel joerg.roe...@amd.com
---
arch/x86/include/asm/kvm_host.h |2 +-
arch/x86/kvm/mmu.c | 60 ++-
arch/x86/kvm/paging_tmpl.h |6 ++--
3 files changed, 38 insertions(+), 30 deletions(-)
diff --git
This patch removes the largepage parameter from the rmap_add function.
Together with rmap_remove this function now uses the role.level field to
find determine if the page is a huge page.
Signed-off-by: Joerg Roedel joerg.roe...@amd.com
---
arch/x86/kvm/mmu.c | 53
If userspace knows that the kernel part supports 1GB pages it can enable
the corresponding cpuid bit so that guests actually use GB pages.
Signed-off-by: Joerg Roedel joerg.roe...@amd.com
---
arch/x86/include/asm/kvm_host.h |1 +
arch/x86/kvm/svm.c |6 ++
Hi,
this is the third version of the patches for KVM to support 1GB pages. Changes
to the last version include:
- changed reporting of 1GB page support to userspace to use
SUPPORTED_CPUID ioctl
- added support for 1GB pages to the software page walker code too
This
On Fri, 2009-06-19 at 15:27 +0800, Yang, Sheng wrote:
On Friday 19 June 2009 00:28:41 Alex Williamson wrote:
The one oddity I noticed is that even when the enable bit is clear, the
guest can read the ROM. I don't know that this is actually illegal, vs
returning zeros or ones though. It
Jan Kiszka wrote:
Beth Kon wrote:
When kvm is in hpet_legacy_mode, the hpet is providing the
timer interrupt and the pit should not be. So in legacy mode, the pit timer is
destroyed, but the *state* of the pit is maintained. So if kvm or the guest
tries to modify the state of the pit, this
Hi,
This one introduces a -maxcpus setting, allowing the user to specify
the maximum number of vCPUs the system can have, as discussed with Gleb
earlier in the week.
Cheers,
Jes
Introduce -maxcpus flag to QEMU and pass the value to the BIOS through
FW_CFG.
Follow on patch will use it to
Hi,
This one goes on top of the -maxcpus patch. It changes the bios to use
max_cpus to determine the size of the MADT table.
When no -maxcpus argument is given, we still fall back to the old
default of 16.
Cheers,
Jes
Build madt table based on max_cpus count.
Signed-off-by: Jes Sorensen
On Fri, Jun 19, 2009 at 03:59:57PM +0200, Jes Sorensen wrote:
Hi,
This one introduces a -maxcpus setting, allowing the user to specify
the maximum number of vCPUs the system can have, as discussed with Gleb
earlier in the week.
What is the maximum value for the 'maxcpus' setting for KVM ?
On 06/19/2009 04:15 PM, Daniel P. Berrange wrote:
On Fri, Jun 19, 2009 at 03:59:57PM +0200, Jes Sorensen wrote:
Hi,
This one introduces a -maxcpus setting, allowing the user to specify
the maximum number of vCPUs the system can have, as discussed with Gleb
earlier in the week.
What is the
JFYI: qemu-kvm commit de408d70d8 works fine with -no-kvm, a5b526135d
produces
qemu: fatal: Trying to execute code outside RAM or ROM at 0x0001000d5f4f
EAX=0001 EBX=0070 ECX=005f EDX=0001
ESI= EDI= EBP= ESP=
EIP=000e5f4f EFL=0002 [---]
On (Fri) Jun 19 2009 [15:59:57], Jes Sorensen wrote:
Hi,
This one introduces a -maxcpus setting, allowing the user to specify
the maximum number of vCPUs the system can have, as discussed with Gleb
earlier in the week.
ACK, but please fix this:
+DEF(maxcpus, HAS_ARG, QEMU_OPTION_maxcpus,
+
On Thu, Jun 18, 2009 at 12:29:31PM -0400, Gregory Haskins wrote:
Michael S. Tsirkin wrote:
On Thu, Jun 18, 2009 at 10:03:36AM -0400, Gregory Haskins wrote:
Michael S. Tsirkin wrote:
On Thu, Jun 18, 2009 at 08:00:39AM -0400, Gregory Haskins wrote:
Michael S.
Michael S. Tsirkin wrote:
On Thu, Jun 18, 2009 at 12:29:31PM -0400, Gregory Haskins wrote:
Michael S. Tsirkin wrote:
On Thu, Jun 18, 2009 at 10:03:36AM -0400, Gregory Haskins wrote:
Michael S. Tsirkin wrote:
On Thu, Jun 18, 2009 at 08:00:39AM -0400,
Fix regression in CPU initialization caused by merge a5b526135d and try
to avoid this in the future by dropping qemu-kvm specific pc_new_cpu. If
such refactoring is desired, it should go through upstream first.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/pc.c | 44
Jan Kiszka wrote:
Fix regression in CPU initialization caused by merge a5b526135d and try
to avoid this in the future by dropping qemu-kvm specific pc_new_cpu. If
such refactoring is desired, it should go through upstream first.
F...ine. I'll write a hundred times: Don't post while still
Hi list,
I need to monitor some guest memory pages. I need to know if the
information in these pages was changed. For this, I was thinking to mark the
guest memory pages in some way (like write protecting them) so a page fault is
generated. Then manage this fault inside qemu. Is there
By default a block driver bounces highmem requests, but virtio-blk is
perfectly fine with any request that fit into it's 64 bit addressing scheme,
mapped in the kernel virtual space or not.
Besides improving performance on highmem systems this also makes the
reproducible oops in __bounce_end_io
From: Davide Libenzi davi...@xmailserver.org
And give them a change to unregister from the wait queue.
This is turn allows eventfd users to use the eventfd file* w/out holding a
live reference to it.
After the eventfd user callbacks returns, any usage of the eventfd file*
should be dropped.
Davide Libenzi wrote:
On Thu, 18 Jun 2009, Gregory Haskins wrote:
But the fact is: I do not see any way to actually use your referenceless
POLLHUP release code in a race free way without doing something like I
propose in 3/4, 4/4. Lets keep the discussion focused on that for now,
if we
eventfd currently emits a POLLHUP wakeup on f_ops-release() to generate a
notifier-release() callback. This lets notification clients know if
the eventfd is about to go away and is very useful particularly for
in-kernel clients. However, as it stands today it is not possible to
use the
On Fri, 19 Jun 2009, Gregory Haskins wrote:
eventfd currently emits a POLLHUP wakeup on f_ops-release() to generate a
notifier-release() callback. This lets notification clients know if
the eventfd is about to go away and is very useful particularly for
in-kernel clients. However, as it
I see this problem with a x86 sles10 guest running on x86_64 intel host.
If the guest is reset abruptly and rebooted, some where
before grub sequence it hangs and the following message is seen in the
logs
emulation failed (pagetable) rip 7ed5 66 60 ac 20.
I located this instruction sequence in
Davide Libenzi wrote:
On Fri, 19 Jun 2009, Gregory Haskins wrote:
eventfd currently emits a POLLHUP wakeup on f_ops-release() to generate a
notifier-release() callback. This lets notification clients know if
the eventfd is about to go away and is very useful particularly for
in-kernel
On Fri, 19 Jun 2009, Gregory Haskins wrote:
Davide Libenzi wrote:
On Fri, 19 Jun 2009, Gregory Haskins wrote:
eventfd currently emits a POLLHUP wakeup on f_ops-release() to generate a
notifier-release() callback. This lets notification clients know if
the eventfd is about to go
Davide Libenzi wrote:
On Fri, 19 Jun 2009, Gregory Haskins wrote:
Davide Libenzi wrote:
On Fri, 19 Jun 2009, Gregory Haskins wrote:
eventfd currently emits a POLLHUP wakeup on f_ops-release() to generate a
notifier-release() callback. This lets notification clients
On Fri, 19 Jun 2009, Gregory Haskins wrote:
I am fairly confident it is not that simple after having thought about
this issue over the last few days. But I've been wrong in the past.
Propose a patch and I will review it for races/correctness, if you
like. Perhaps a combination of that plus
On Fri, 19 Jun 2009, Davide Libenzi wrote:
On Fri, 19 Jun 2009, Gregory Haskins wrote:
I am fairly confident it is not that simple after having thought about
this issue over the last few days. But I've been wrong in the past.
Propose a patch and I will review it for races/correctness,
Davide Libenzi wrote:
On Fri, 19 Jun 2009, Davide Libenzi wrote:
On Fri, 19 Jun 2009, Gregory Haskins wrote:
I am fairly confident it is not that simple after having thought about
this issue over the last few days. But I've been wrong in the past.
Propose a patch and I will
Hi, all,
This Luvalley release is for machines with AMD CPUs only. It cannot
work on Intel CPUs. Also, this release is for Linux dom0 only. Please
refer to Luvalley-2 if you have a machine with Intel CPUs.
Due to the limitations of AMD CPUs, this Luvalley release has a new
architecture different
40 matches
Mail list logo
