On 09/07/2011 09:55 PM, Konrad Rzeszutek Wilk wrote:
If you don't know what to do here, say N.
+
+menuconfig VFIO_PCI
+ bool VFIO support for PCI devices
+ depends on VFIO PCI
+ default y if X86
Hahah.. And Linus is going to tear your behind for that.
Default should be 'n'
It
On 09/07/2011 10:09 PM, Jeremy Fitzhardinge wrote:
On 09/07/2011 10:41 AM, Avi Kivity wrote:
Hm, I'm interested to know what you're thinking in more detail. Can you
leave an NMI pending before you block in the same way you can with
sti;halt with normal interrupts?
Nope. But you can
On Wed, Sep 07, 2011 at 12:44:45PM -0700, Greg KH wrote:
On Wed, Sep 07, 2011 at 09:19:19PM +0200, Joerg Roedel wrote:
Hi Greg,
the bus_set_iommu() function will be called by the IOMMU driver. There
can be different drivers for the same bus, depending on the hardware. On
PCI for
On Wed, Sep 07, 2011 at 04:37:11PM -0400, Don Dutile wrote:
On 09/07/2011 03:44 PM, Greg KH wrote:
Why are you pushing this down into the driver core? What other busses
becides PCI use/need this?
If you can have a different IOMMU driver on the same bus, then wouldn't
this be a per-device
This is a report of strange cfq behaviour which seems to be triggered by
QEMU posix aio threads.
Host environment:
OS: RHEL6.0 KVM/qemu-kvm (with no patch applied)
IO scheduler: cfq (with the default parameters)
On the host, we were running 3 linux guests to see if I/O from these guests
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
Makefile.objs |2 +-
block/blk-queue.c | 201 +
block/blk-queue.h | 59
block_int.h | 27 +++
4 files changed, 288 insertions(+), 1 deletions(-)
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
block.c | 59 +++
block.h |5
block_int.h |3 ++
blockdev.c | 29 +++
qemu-config.c | 24 ++
Note:
1.) When bps/iops limits are specified to a small value such as 511
bytes/s, this VM will hang up. We are considering how to handle this senario.
2.) When dd command is issued in guest, if its option bs is set to a
large value such as bs=1024K, the result speed will slightly
The patch introduce one new command block_set_io_throttle; For its usage
syntax, if you have better idea, pls let me know.
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
block.c | 26 +++-
blockdev.c | 69
The main goal of the patch is to effectively cap the disk I/O speed or counts
of one single VM.It is only one draft, so it unavoidably has some drawbacks, if
you catch them, please let me know.
The patch will mainly introduce one block I/O throttling algorithm, one timer
and one block queue
Resolve all unneeded deviations from upstream code. No functional
changes.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/pci.c | 11 +++
hw/pci.h |5 -
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index e4c166a..4d8845c 100644
Factor out apic_next_timer from apic_timer_update. The former can then
be used to update next_timer without actually starting the qemu timer.
KVM's in-kernel APIC model will make use of it.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/apic.c | 45
apic_timer_update not only calculates the next timer expiry that we need
to write out the vmstate, it may also start the timer of the user space
APIC model. That can cause spurious signals to the corresponding vCPU
thread when the timer expires. Fix this by using the new apic_next_timer
that does
On Wed, Sep 07, 2011 at 10:20:28PM -0700, Roopa Prabhu wrote:
On 9/7/11 5:34 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Sep 06, 2011 at 03:35:40PM -0700, Roopa Prabhu wrote:
This patch is an attempt at providing address filtering support for macvtap
devices in PASSTHRU mode.
On Thu, Sep 08, 2011 at 06:13:53PM +0900, Takuya Yoshikawa wrote:
This is a report of strange cfq behaviour which seems to be triggered by
QEMU posix aio threads.
Host environment:
OS: RHEL6.0 KVM/qemu-kvm (with no patch applied)
IO scheduler: cfq (with the default parameters)
So you
On 06.09.2011 23:22, Nikola Ciprich wrote:
Hello guys,
thanks to both of You for Your replies. The problem is solved,
exactly as Avi said, the DMA in windows got somehow disabled.
So this certainly was not related to adding the memory...
anyways, note for further generations:
in windows
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -229,6 +229,8 @@
#define MSR_IA32_APICBASE_ENABLE (111)
#define MSR_IA32_APICBASE_BASE (0xf12)
+#define MSR_IA32_TSCDEADLINE 0x06e0
+
#define MSR_IA32_UCODE_WRITE
On 9/8/11 10:42 AM, Sridhar Samudrala s...@us.ibm.com wrote:
On Thu, 2011-09-08 at 09:19 -0700, Roopa Prabhu wrote:
On 9/8/11 4:08 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Sep 07, 2011 at 10:20:28PM -0700, Roopa Prabhu wrote:
On 9/7/11 5:34 AM, Michael S. Tsirkin
On 09/08/2011 12:51 AM, Avi Kivity wrote:
On 09/07/2011 10:09 PM, Jeremy Fitzhardinge wrote:
On 09/07/2011 10:41 AM, Avi Kivity wrote:
Hm, I'm interested to know what you're thinking in more detail.
Can you
leave an NMI pending before you block in the same way you can with
sti;halt
On Wed, 2011-09-07 at 13:58 +0200, Alexander Graf wrote:
On 01.09.2011, at 21:50, Alex Williamson wrote:
Trying to move beyond talking about how VFIO should work to
re-writing the code. This is pre-alpha, known broken, will
probably crash your system but it illustrates some of how
I
On Thu, Sep 08, 2011 at 09:19:32AM -0700, Roopa Prabhu wrote:
There are more features we'll want down the road though,
so let's see whether the interface will be able to
satisfy them in a backwards compatible way before we
set it in stone. Here's what I came up with:
How will the
On 9/8/11 4:08 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Sep 07, 2011 at 10:20:28PM -0700, Roopa Prabhu wrote:
On 9/7/11 5:34 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Sep 06, 2011 at 03:35:40PM -0700, Roopa Prabhu wrote:
This patch is an attempt at providing
On Thu, Sep 08, 2011 at 12:23:56PM -0700, Roopa Prabhu wrote:
I think the main usecase for passthru mode is to assign a SR-IOV VF to
a single guest.
Yes and for the passthru usecase this patch should be enough to enable
filtering in hw (eventually like I indicated before I need to fix
blkdebug files allow to inject errors in the block
subsystem, allowing more types of tests to be
executed. Now it is possible to set a blkdebug file
for an arbitrary image 'imagefoo' used just like this
drive_blkdebug_imagefoo = blkdebug/default.conf
The blkdebug files can be stored on the
In order to solve task:
http://autotest.kernel.org/ticket/50
Implemented support to providing blkdebug files to arbitrary guest images in
autotest. Also, modified a bit the migrate test and introduced the variant
migrate.with_blkdebug variant, that tries to mimic as much as possible the
testcase
In order to test a special guest configuration (special blkdebug
config files to inject errors on the block subsystem), added a
migration_living_guest param. If the param is set to no, no
attempt to have a session on the guest will be made, since the
guest block subsystem will stop when the first
In order to solve task
http://autotest.kernel.org/ticket/50
Create a migrate.with_blkdebug variant, that will
migrate the vm with state check before and after
migration. As the reporter of the original problem
on task 50 said, indeed we have a lot of migration
state mismatch problems with a
On Thu, 2011-09-08 at 10:52 +0300, Avi Kivity wrote:
On 09/07/2011 09:55 PM, Konrad Rzeszutek Wilk wrote:
If you don't know what to do here, say N.
+
+menuconfig VFIO_PCI
+bool VFIO support for PCI devices
+depends on VFIO PCI
+default y
Yesterday I had a second VM guest fail. The day before one failed in the same
way. Both suddenly had read only file systems. In both cases these are the
last lines in the syslog:
Sep 7 21:19:59 dev init: tty (/dev/tty1) main process ended, respawning
Sep 7 21:59:23 dev kernel: ata1.00:
- Original Message -
On Wed, 07 Sep 2011 14:07:49 +0800, Amos Kong ak...@redhat.com
wrote:
System services on guest and host take uncertain resource, it
effects
the perf results. We can use the below two scripts to disable some
services of host and guest.
On 08/18/2011 11:08 PM, Avi Kivity wrote:
On 08/18/2011 12:35 AM, Sasha Levin wrote:
On Thu, 2011-08-18 at 09:13 +0300, Pekka Enberg wrote:
Hi,
On Thu, Aug 18, 2011 at 6:06 AM, Xiao Guangrong
xiaoguangr...@cn.fujitsu.com wrote:
When kvm emulates repeation io read instruction, it
On Thu, 2011-09-08 at 09:19 -0700, Roopa Prabhu wrote:
On 9/8/11 4:08 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Sep 07, 2011 at 10:20:28PM -0700, Roopa Prabhu wrote:
On 9/7/11 5:34 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Sep 06, 2011 at 03:35:40PM -0700,
On 9/8/11 12:11 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Sep 08, 2011 at 09:19:32AM -0700, Roopa Prabhu wrote:
There are more features we'll want down the road though,
so let's see whether the interface will be able to
satisfy them in a backwards compatible way before we
set
On 9/8/2011 8:00 PM, Roopa Prabhu wrote:
On 9/8/11 12:33 PM, Michael S. Tsirkinm...@redhat.com wrote:
On Thu, Sep 08, 2011 at 12:23:56PM -0700, Roopa Prabhu wrote:
I think the main usecase for passthru mode is to assign a SR-IOV VF to
a single guest.
Yes and for the passthru usecase this
On Thu, Sep 08, 2011 at 12:48:02PM +0200, Jan Kiszka wrote:
Resolve all unneeded deviations from upstream code. No functional
changes.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Acked-by: Michael S. Tsirkin m...@redhat.com
---
hw/pci.c | 11 +++
hw/pci.h |5 -
2
On Thu, Sep 08, 2011 at 07:53:11PM -0700, Roopa Prabhu wrote:
Phase 1: Goal: Enable hardware filtering for all macvlan modes
- In macvlan passthru mode the single guest virtio-nic connected will
receive traffic that he requested for
- In macvlan non-passthru mode all guest
On Wed, Sep 07, 2011 at 12:41:35PM +0200, Alexander Graf wrote:
Yes, but why can't we do this in the vcpu thread's context so we only
ever have a single instance accessing the vcpu struct? It makes a lot
of things a lot easier.
Why? We don't do it for external interrupts. It would
On 08.09.2011, at 17:34, Scott Wood wrote:
On Wed, Sep 07, 2011 at 12:41:35PM +0200, Alexander Graf wrote:
Yes, but why can't we do this in the vcpu thread's context so we only
ever have a single instance accessing the vcpu struct? It makes a lot
of things a lot easier.
Why? We don't do
38 matches
Mail list logo
