On 01/25/10 23:35, Dor Laor wrote:
On 01/25/2010 04:21 PM, Anthony Liguori wrote:
Another way to look at this is that implementing a somewhat arbitrary
policy within QEMU's .c files is something we should try to avoid.
Implementing arbitrary policy in our default config file is a fine thing
to
On 01/26/10 07:46, Gleb Natapov wrote:
On Mon, Jan 25, 2010 at 06:13:35PM +0100, Jes Sorensen wrote:
I am fine with having QEMU build the e820 tables completely if there is
a consensus to take that path.
QEMU can't build the e820 map completely. There are things it doesn't
know. Like how much
Hi, after upgrade to current qemu-kvm (download from
http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=snapshot;h=34f6b13147766789fc2ef289f5b420f85e51d049;sf=tgz),
i can not open the readonly vm image, it can work before.
please help, thank you.
--
To unsubscribe from this list: send the line
On 01/26/2010 10:49 AM, John Wong wrote:
Hi, after upgrade to current qemu-kvm (download from
http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=snapshot;h=34f6b13147766789fc2ef289f5b420f85e51d049;sf=tgz),
i can not open the readonly vm image, it can work before.
please help, thank you.
On 01/26/2010 10:59 AM, wzt wzt wrote:
Hi:
In kernel 2.6.32 kernel/arch/x86/kvm/i8254.c， I found
pit_ioport_read maybe have a integer buffer overflow hole:
static int pit_ioport_read(struct kvm_io_device *this,
gpa_t addr, int len, void *data)
{
…
if
On 26.01.2010, at 07:49, Chris Wright wrote:
Please send in any agenda items you are interested in covering.
KVM Hardware Inquiry Tool
One of the things I have on my todo list is a tool you can run on your machine
that tells you which virtualization features it supports. Imaginary output of
The default action of coalesced MMIO is, cache the writing in buffer, until:
1. The buffer is full.
2. Or the exit to QEmu due to other reasons.
But this would result in a very late writing in some condition.
1. The each time write to MMIO content is small.
2. The writing interval is big.
3. No
Avi Kivity wrote:
Unfortunately, no such luck. Apparently this is not msr/cpuid related -
perhaps power management. Can you enable the kvm_mmio and kvm_pio
events? Perhaps they will provide a clue.
Yeah, I did take a quick glance at the trace and figured that there
would be some (#GP)
On 26.01.2010, at 10:41, Sheng Yang wrote:
The default action of coalesced MMIO is, cache the writing in buffer, until:
1. The buffer is full.
2. Or the exit to QEmu due to other reasons.
But this would result in a very late writing in some condition.
1. The each time write to MMIO
Avi Kivity 提到:
On 01/26/2010 10:49 AM, John Wong wrote:
Hi, after upgrade to current qemu-kvm (download from
http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=snapshot;h=34f6b13147766789fc2ef289f5b420f85e51d049;sf=tgz),
i can not open the readonly vm image, it can work before.
please
On Tue, Jan 26, 2010 at 10:59:17AM +0100, Alexander Graf wrote:
On 26.01.2010, at 10:41, Sheng Yang wrote:
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -59,6 +59,7 @@ struct KVMState
int vmfd;
int regs_modified;
int coalesced_mmio;
+struct kvm_coalesced_mmio_ring
The default action of coalesced MMIO is, cache the writing in buffer, until:
1. The buffer is full.
2. Or the exit to QEmu due to other reasons.
But this would result in a very late writing in some condition.
1. The each time write to MMIO content is small.
2. The writing interval is big.
3. No
On Mon, Jan 25, 2010 at 07:36:02PM +0200, Avi Kivity wrote:
We don't trace failed msr access (wrmsr or rdmsr which end up generating a
#GP), which loses important data.
Avi Kivity (2):
KVM: Fix msr trace
KVM: Trace failed msr reads and writes
arch/x86/kvm/svm.c | 13
On Tue, Jan 26, 2010 at 07:21:16PM +0800, Sheng Yang wrote:
The default action of coalesced MMIO is, cache the writing in buffer, until:
1. The buffer is full.
2. Or the exit to QEmu due to other reasons.
But this would result in a very late writing in some condition.
1. The each time write
Dear list,
is there a document that describes the level of support of trusted
computing technology in KVM and how things work?
I read in various sources that KVM should support virtual Trusted
Platform Modules in virtual machines but I coudln't find any evidence
and/or document about this on the
On 01/26/2010 02:26 AM, Gerd Hoffmann wrote:
On 01/25/10 23:35, Dor Laor wrote:
On 01/25/2010 04:21 PM, Anthony Liguori wrote:
Another way to look at this is that implementing a somewhat arbitrary
policy within QEMU's .c files is something we should try to avoid.
Implementing arbitrary policy
On 01/26/2010 06:47 AM, Martin Schneider wrote:
Dear list,
is there a document that describes the level of support of trusted
computing technology in KVM and how things work?
I read in various sources that KVM should support virtual Trusted
Platform Modules in virtual machines but I coudln't
On 01/26/2010 03:09 AM, Alexander Graf wrote:
On 26.01.2010, at 07:49, Chris Wright wrote:
Please send in any agenda items you are interested in covering.
KVM Hardware Inquiry Tool
Avi beat you to it ;-) See vmxcap in the tree.
One of the things I have on my todo list is a
On 01/26/2010 03:11 PM, Anthony Liguori wrote:
On 01/26/2010 03:09 AM, Alexander Graf wrote:
On 26.01.2010, at 07:49, Chris Wright wrote:
Please send in any agenda items you are interested in covering.
KVM Hardware Inquiry Tool
Avi beat you to it ;-) See vmxcap in the tree.
I knew I
On 26.01.2010, at 14:11, Anthony Liguori wrote:
On 01/26/2010 03:09 AM, Alexander Graf wrote:
On 26.01.2010, at 07:49, Chris Wright wrote:
Please send in any agenda items you are interested in covering.
KVM Hardware Inquiry Tool
Avi beat you to it ;-) See vmxcap in the
On 01/26/2010 03:18 PM, Alexander Graf wrote:
The main question is where does it belong?
a) built into qemu
b) built as separate tool, but shipped with qemu
c) completely separate
I'm personally leaning towards a. That way we can reuse the detection code and
give help when an option is used
On Tue, Jan 26, 2010 at 03:24:50PM +0200, Avi Kivity wrote:
On 01/26/2010 03:18 PM, Alexander Graf wrote:
The main question is where does it belong?
a) built into qemu
b) built as separate tool, but shipped with qemu
c) completely separate
I'm personally leaning towards a. That way we
On 26.01.2010, at 14:33, Daniel P. Berrange wrote:
On Tue, Jan 26, 2010 at 03:24:50PM +0200, Avi Kivity wrote:
On 01/26/2010 03:18 PM, Alexander Graf wrote:
The main question is where does it belong?
a) built into qemu
b) built as separate tool, but shipped with qemu
c) completely
On 01/26/2010 03:33 PM, Daniel P. Berrange wrote:
Me too, especially as the whole stack is involved, and qemu is the
topmost part from our perspective (no doubt libvirt will want to
integrate that functionality as well).
FYI, libvirt already exposes this kind of functionality. The API
Hello Glennie,
Am 26.01.2010 14:46, schrieb Glennie Vignarajah:
Le 24/01/2010 vers 18:16, dans le message intitulé Re: How to properly turn
off guest VM on server shutdown?, Markus Breitländer(Markus Breitländer
breitlaen...@stud.fh-dortmund.de) a écrit:
Hi!
Hello;
Does anyone have
On 01/26/2010 07:24 AM, Avi Kivity wrote:
On 01/26/2010 03:18 PM, Alexander Graf wrote:
The main question is where does it belong?
a) built into qemu
b) built as separate tool, but shipped with qemu
c) completely separate
I'm personally leaning towards a. That way we can reuse the detection
On 01/25/2010 10:40 PM, Izik Eidus wrote:
Or is this a feature you need?
I dont need it (I asked Avi to do something), So he said he want to nuke the
aliasing
from kvm and keep supporting the old userspace`s
Do you have any other way to achive this?
Btw I do realize it might be
On 01/26/2010 04:13 PM, Anthony Liguori wrote:
Me too, especially as the whole stack is involved, and qemu is the
topmost part from our perspective (no doubt libvirt will want to
integrate that functionality as well).
I'm not sure I agree. It would use no code from qemu and really
benefit
On Tue, 26 Jan 2010 16:14:47 +0200
Avi Kivity a...@redhat.com wrote:
On 01/25/2010 10:40 PM, Izik Eidus wrote:
Or is this a feature you need?
I dont need it (I asked Avi to do something), So he said he want to nuke
the aliasing
from kvm and keep supporting the old
On 01/26/2010 08:26 AM, Avi Kivity wrote:
On 01/26/2010 04:22 PM, Anthony Liguori wrote:
On 01/26/2010 08:15 AM, Avi Kivity wrote:
On 01/26/2010 04:13 PM, Anthony Liguori wrote:
Me too, especially as the whole stack is involved, and qemu is the
topmost part from our perspective (no doubt
These features are unused by modern userspace and can go away. Paravirt
mmu needs to stay a little longer for live migration.
Signed-off-by: Avi Kivity a...@redhat.com
---
Documentation/feature-removal-schedule.txt | 23 +++
1 files changed, 23 insertions(+), 0
On 01/26/2010 04:32 PM, Anthony Liguori wrote:
It would need to know which cpuid bits qemu supports. Only qemu
knows that.
I'm not sure I understand why. Can you elaborate?
If qemu doesn't recognize -cpu qemu64,+nx, then no amount of hardware
and kvm.ko support will allow the user to
On 26.01.2010, at 15:37, Avi Kivity wrote:
On 01/26/2010 04:32 PM, Anthony Liguori wrote:
It would need to know which cpuid bits qemu supports. Only qemu knows
that.
I'm not sure I understand why. Can you elaborate?
If qemu doesn't recognize -cpu qemu64,+nx, then no amount of
On 01/26/2010 08:37 AM, Avi Kivity wrote:
People who use discovery tools are probably setting up a migration
cluster. They aren't going to use -cpu host.
BTW, it might be neat to introduce a qemu command line that runs a
monitor command and exits without creating a VM. We could then
On 01/26/2010 04:42 PM, Anthony Liguori wrote:
On 01/26/2010 08:37 AM, Avi Kivity wrote:
People who use discovery tools are probably setting up a migration
cluster. They aren't going to use -cpu host.
BTW, it might be neat to introduce a qemu command line that runs a
monitor command and
On 01/26/2010 04:42 PM, Alexander Graf wrote:
That's /proc/cpuinfo, we should just extend it, maybe that's what Alex meant,
but I'd like to see something more capable.
I think we're all looking at different use-cases.
First and frontmost the one type of user I'm concerned with in this
On 26.01.2010, at 15:47, Avi Kivity wrote:
On 01/26/2010 04:42 PM, Alexander Graf wrote:
That's /proc/cpuinfo, we should just extend it, maybe that's what Alex
meant, but I'd like to see something more capable.
I think we're all looking at different use-cases.
First and frontmost
On 01/26/2010 08:50 AM, Alexander Graf wrote:
On 26.01.2010, at 15:47, Avi Kivity wrote:
On 01/26/2010 04:42 PM, Alexander Graf wrote:
That's /proc/cpuinfo, we should just extend it, maybe that's what Alex meant,
but I'd like to see something more capable.
I
2010/1/26 Markus Breitländer breitlaen...@stud.fh-dortmund.de:
Hello Glennie,
Am 26.01.2010 14:46, schrieb Glennie Vignarajah:
Le 24/01/2010 vers 18:16, dans le message intitulé Re: How to properly turn
off guest VM on server shutdown?, Markus Breitländer(Markus Breitländer
* Martin Schneider (martincschnei...@googlemail.com) wrote:
Dear list,
is there a document that describes the level of support of trusted
computing technology in KVM and how things work?
There's host level trusted boot, which simply needs tboot and a new
enough kernel to support CONFIG_TXT.
Yolkfull, I am copying Michael and Lawrence on the e-mail so they can
comment on the points I am going to present.
I've been meaning to comment on this test for a while, but refrained to
do so because I wanted to think a little about using image copy as an
alternate install method. Here are my
Hello,
I have the following issue:
Our HW device is SRIOV capable, I have tried passing through one of its Virtual
Functions to a guest OS Running RH5.4 on the guest and the host.
The function is seen by lspci on the guest, however, when the HW tries to DMA
the guest with the BDF of the VF, it
* Yevgeny Petrilin (yevge...@mellanox.co.il) wrote:
Hello,
I have the following issue:
Our HW device is SRIOV capable, I have tried passing through one of its
Virtual Functions to a guest OS Running RH5.4 on the guest and the host.
The function is seen by lspci on the guest, however, when
Jan Kiszka wrote:
Toralf Förster wrote:
Hi,
under a mostly stable Gentoo I observed this new msg :
tfoer...@n22 ~/virtual/kvm $ qemu -hda gentoo_kdevm.img -hdb
portage_kdeprefix.img -hdd swap.img -smp 2 -m 768 -vga std -soundhw es1370
Which kvm/qemu-kvm version? Newer ones will verify that you actually have
VT-d fully enabled.
kvm module version is :kvm-83-105.el5_4.13 (from modinfo)
Can you do 'dmesg | grep -e DMAR -e IOMMU' in the host and then we can verify
that the IOMMU is functioning.
dmesg output:
ACPI: DMAR
* Yevgeny Petrilin (yevge...@mellanox.co.il) wrote:
Which kvm/qemu-kvm version? Newer ones will verify that you actually have
VT-d fully enabled.
kvm module version is :kvm-83-105.el5_4.13 (from modinfo)
Can you do 'dmesg | grep -e DMAR -e IOMMU' in the host and then we can
verify
On Tue, 2010-01-26 at 11:25 +0800, Yolkfull Chow wrote:
This is designed to test all subcommands of 'qemu-img' however
so far 'commit' is not implemented.
Hi Yolkful, this is very good! Seeing this test made me think about that
stand alone autotest module we commited a while ago, that does
Most of the unattended windows install files added a
static ip network connection before reporting end of
install. That is fine when you are using user mode
networking only, but this is certainly restrictive,
and will give problems on subsequent tests if you are
using tap mode. Let's do all
On Mon, Jan 25, 2010 at 10:51 PM, Brian Jackson i...@theiggy.com wrote:
Nope. When support was being developed, there was, but it was never merged,
and I highly doubt the patches would be remotely able to be applied at this
point with all the code churn qemu has had.
Then, I'm stuck on xen.
Am 26.01.2010 16:56, schrieb Chris Wright:
* Martin Schneider (martincschnei...@googlemail.com) wrote:
Dear list,
is there a document that describes the level of support of trusted
computing technology in KVM and how things work?
There's host level trusted boot, which simply needs tboot
While testing QMP on qemu-kvm I found that it's not emitting basic
events like RESET or POWERDOWN.
The reason is that in QEMU upstream those events are triggered
in QEMU's main loop (ie. vl.c:main_loop()), but control doesn't
reach there in qemu-kvm as it has its own main loop in
This patch adds raw socket backend to qemu and is based on Or Gerlitz's
patch re-factored and ported to the latest qemu-kvm git tree.
It also includes support for vnet_hdr option that enables gso/checksum
offload with raw backend. You can find the linux kernel patch to support
this feature here.
This patch adds generic peer routines for the remaining tap specific
routines(using_vnet_hdr set_offload). This makes it easier to add
new backends like raw(packet sockets) that support gso/checksum-offload.
Signed-off-by: Sridhar Samudrala s...@us.ibm.com
diff --git a/hw/virtio-net.c
On 01/26/2010 02:40 PM, Sridhar Samudrala wrote:
This patch adds raw socket backend to qemu and is based on Or Gerlitz's
patch re-factored and ported to the latest qemu-kvm git tree.
It also includes support for vnet_hdr option that enables gso/checksum
offload with raw backend. You can find the
On 01/26/2010 02:47 PM, Anthony Liguori wrote:
On 01/26/2010 02:40 PM, Sridhar Samudrala wrote:
This patch adds raw socket backend to qemu and is based on Or Gerlitz's
patch re-factored and ported to the latest qemu-kvm git tree.
It also includes support for vnet_hdr option that enables
Hi,
Thank you for the responses.
I've managed to get further in the process while running KVM with
Fedora rather than Ubuntu.
I've gotten Windows 7 to recognize the graphics card but mark it with
an error about hardware resources (I assume memory/interrupts).
I've found the same error was
Hi,
Based on the feedback I received over the e820 reserve patch, I have
changed it to have QEMU pass in a list of entries that can cover more
than just the TSS/EPT range. This should provide the flexibility that
people were asking for.
The Seabios portion should allow for unlimited sized
Hi,
This is the QEMU-KVM part of the patch. If we can agree on this
approach, I will do a version for upstream QEMU as well.
Cheers,
Jes
Use qemu-cfg to provide the BIOS with an optional table of e820 entries.
Notify the BIOS of the location of the TSS+EPT range to by reserving
it via the
On 26.01.2010, at 22:53, Jes Sorensen wrote:
Hi,
This is the QEMU-KVM part of the patch. If we can agree on this
approach, I will do a version for upstream QEMU as well.
It shows as attachment again :(.
Alex
Cheers,
Jes
0011-qemu-kvm-e820-table.patch
--
To unsubscribe from this
On Wednesday 20 January 2010 09:48:04 am Tom Lendacky wrote:
On Tuesday 19 January 2010 05:57:53 pm Chris Wright wrote:
* Tom Lendacky (t...@linux.vnet.ibm.com) wrote:
On Wednesday 13 January 2010 03:52:28 pm Chris Wright wrote:
(Mark cc'd, sound familiar?)
* Tom Lendacky
On Tue, 2010-01-26 at 14:47 -0600, Anthony Liguori wrote:
On 01/26/2010 02:40 PM, Sridhar Samudrala wrote:
This patch adds raw socket backend to qemu and is based on Or Gerlitz's
patch re-factored and ported to the latest qemu-kvm git tree.
It also includes support for vnet_hdr option that
On Tue, 2010-01-26 at 14:50 -0600, Anthony Liguori wrote:
On 01/26/2010 02:47 PM, Anthony Liguori wrote:
On 01/26/2010 02:40 PM, Sridhar Samudrala wrote:
This patch adds raw socket backend to qemu and is based on Or Gerlitz's
patch re-factored and ported to the latest qemu-kvm git tree.
On 01/26/2010 05:15 PM, Sridhar Samudrala wrote:
On Tue, 2010-01-26 at 14:47 -0600, Anthony Liguori wrote:
On 01/26/2010 02:40 PM, Sridhar Samudrala wrote:
This patch adds raw socket backend to qemu and is based on Or Gerlitz's
patch re-factored and ported to the latest qemu-kvm git
qemu-kvm should reset and save/restore vcpu events.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/kvm.h b/kvm.h
index e2a945b..9fa4e25 100644
--- a/kvm.h
+++ b/kvm.h
@@ -52,6 +52,9 @@ int kvm_set_migration_log(int enable);
int kvm_has_sync_mmu(void);
#endif /* KVM_UPSTREAM
Every time I start a Windows Vista or Windows 7 virtual machine it
request a that a location be set for the network, regardless of the fact
that the network location has already been set the same way every time
the system is started. Near as I can tell the VM's NIC MAC, IP address,
DNS
On Wednesday 27 January 2010, Anthony Liguori wrote:
The raw backend can be attached to a physical device
This is equivalent to bridging with tun/tap except that it has the
unexpected behaviour of unreliable host/guest networking (which is not
universally consistent across platforms
On Mon, Jan 25, 2010 at 3:32 AM, Liu Yu-B13201 b13...@freescale.com wrote:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Friday, January 22, 2010 7:33 PM
To: Liu Yu-B13201
Cc: hol...@penguinppc.org; kvm-ppc@vger.kernel.org;
k...@vger.kernel.org
Subject: Re:
67 matches
Mail list logo
