On 2011-08-31 23:06, Lucas Meneghel Rodrigues wrote:
> Add a test device which supports the kvmctl ioports,
> for running the KVM test suite.
>
> Usage:
>
> qemu
> -chardev file,path=/log/file/some/where,id=testlog
> -device pc-testdev,chardev=testlog
>
> lmr: I've tried to address t
Hi Lukas,
I'm curious about motivation behind these tests, because
if I'm not mistaken you are starting from scratch here.
Can you compare it to other cgroup tests out there?
Like the ones in ltp:
http://ltp.git.sourceforge.net/git/gitweb.cgi?p=ltp/ltp.git;a=tree;f=testcases/kernel/controllers;h
On 09/01/2011 12:11 AM, Lucas Meneghel Rodrigues wrote:
Rather than letting the test dev do it.
+
+unsigned fwcfg_get_ram_size(void)
+{
+return fwcfg_get_u64(FW_CFG_RAM_SIZE);
+}
Should return a 64-bit type here.
--
error compiling committee.c: too many arguments to function
--
To uns
On 08/31/2011 11:06 PM, Lucas Meneghel Rodrigues wrote:
+CharDriverState *chr;
I think it's unused, no?
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-inf
On 2011-02-22 19:08, Marcelo Tosatti wrote:
> On Fri, Feb 18, 2011 at 04:53:09PM +0800, Sheng Yang wrote:
>> Sorry for the long delay, just come back from vacation...
>>
>> Change from v8:
>> 1. Update struct kvm_run to contain MSI-X routing update exit specific
>> information.
>> 2. Fix a mmio_nr
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 for
Signed-off-by: Zhi Yong Wu
---
block.c |8
block_int.h | 21 +
blockdev.c | 29 +
qemu-config.c | 24
qemu-options.hx |1 +
5 files changed, 83 insertions(+), 0 deletions(-)
diff --
Signed-off-by: Zhi Yong Wu
---
Makefile.objs |2 +-
block/blk-queue.c | 226 +
block/blk-queue.h | 63 +++
3 files changed, 290 insertions(+), 1 deletions(-)
create mode 100644 block/blk-queue.c
create mode 100644 block/
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 b
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
---
block.c | 26 +++-
block.h |1 -
blockdev.c | 69 +++
On Thu, Sep 1, 2011 at 12:44 PM, Zhi Yong Wu wrote:
> +struct BlockIORequest {
> + QTAILQ_ENTRY(BlockIORequest) entry;
> + BlockDriverState *bs;
> + BlockRequestHandler *handler;
> + int64_t sector_num;
> + QEMUIOVector *qiov;
> + int nb_sectors;
> + BlockDriverCompletionFunc
On Thu, Sep 1, 2011 at 12:44 PM, Zhi Yong Wu wrote:
> 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
> lar
Hi all,
I started playing with nested KVMs, but the inner VM doesn't boot. It
fails after grub's "Starting up ..." with
> Failed to execute /init
> Kernel panic - not syncing: No init found. Try passing init= option
> to kernel. See Linux Documentation/init.txt for guidance.
> Pid: 1, comm: ini
The RH bit exists in the message address register (lower 32 bits of
the address).
The bit indicates whether the message should go to the processor which was
indicated in the destination ID bits, or whether it should go to the
processor running at the lowest priority.
Cc: Avi Kivity
Cc: Marcelo T
On Thu, Sep 01, 2011 at 07:05:35PM +0300, Sasha Levin wrote:
> The RH bit exists in the message address register (lower 32 bits of
> the address).
>
> The bit indicates whether the message should go to the processor which was
> indicated in the destination ID bits, or whether it should go to the
>
On Thu, 2011-09-01 at 20:45 +0300, Gleb Natapov wrote:
> On Thu, Sep 01, 2011 at 07:05:35PM +0300, Sasha Levin wrote:
> > The RH bit exists in the message address register (lower 32 bits of
> > the address).
> >
> > The bit indicates whether the message should go to the processor which was
> > ind
On 08/30/2011 07:26 AM, Marcelo Tosatti wrote:
On Mon, Aug 29, 2011 at 05:27:11PM -0600, Eric B Munson wrote:
Currently, when qemu stops a guest kernel that guest will issue a soft lockup
message when it resumes. This set provides the ability for qemu to comminucate
to the guest that it has bee
On Thu, Sep 01, 2011 at 09:59:52PM +0300, Sasha Levin wrote:
> On Thu, 2011-09-01 at 20:45 +0300, Gleb Natapov wrote:
> > On Thu, Sep 01, 2011 at 07:05:35PM +0300, Sasha Levin wrote:
> > > The RH bit exists in the message address register (lower 32 bits of
> > > the address).
> > >
> > > The bit i
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 see groups, devices, and iommus interacting. This is just
the framework, no code to actually support user space driver
An IOMMU group is a set of devices for which the IOMMU cannot
distinguish transactions. For PCI devices, a group often occurs
when a PCI bridge is involved. Transactions from any device
behind the bridge appear to be sourced from the bridge itself.
We leave it to the IOMMU driver to define the gr
We generally have BDF granularity for devices, so we just need
to make sure devices aren't hidden behind PCIe-to-PCI bridges.
We can then make up a group number that's simply the concatenated
seg|bus|dev|fn so we don't have to track them (not that users
should depend on that).
Also add an option t
Signed-off-by: Alex Williamson
---
drivers/Kconfig |2
drivers/Makefile|1
drivers/vfio/Kconfig|5
drivers/vfio/Makefile |3
drivers/vfio/vfio_device.c | 109 +
drivers/vfio/vfio_iommu.c | 81
drivers/vfio/vfio_main.c|
Signed-off-by: Alex Williamson
---
drivers/vfio/Kconfig|7 ++
drivers/vfio/Makefile |1
drivers/vfio/vfio_main.c| 10 +++
drivers/vfio/vfio_pci.c | 124 +++
drivers/vfio/vfio_private.h |5 ++
5 files changed, 147 inser
Signed-off-by: Alex Williamson
---
tools/testing/vfio/Makefile|4
tools/testing/vfio/vfio_test.c | 406
2 files changed, 410 insertions(+), 0 deletions(-)
create mode 100644 tools/testing/vfio/Makefile
create mode 100644 tools/testing/vfio/vfi
On Thu, 2011-09-01 at 22:31 +0300, Gleb Natapov wrote:
> On Thu, Sep 01, 2011 at 09:59:52PM +0300, Sasha Levin wrote:
> > On Thu, 2011-09-01 at 20:45 +0300, Gleb Natapov wrote:
> > > On Thu, Sep 01, 2011 at 07:05:35PM +0300, Sasha Levin wrote:
> > > > The RH bit exists in the message address regist
On Mon, Aug 29, 2011 at 04:51:20PM +, Yoder Stuart-B08248 wrote:
> Alex Graf, Scott Wood, and I met last week to try to flesh out
> some details as to how vfio could work for non-PCI devices,
> like we have in embedded systems. This most likely will
> require a different kernel driver than vf
On Thu, Sep 01, 2011 at 10:58:31PM +0300, Sasha Levin wrote:
> By "actual addressing model" I meant checking the ICR of of each APIC to
> see if we should address it logically or physically.
>
This is definitely not what ICR of each APIC is about.
--
Gleb.
--
To unsubscrib
On Thu, 2011-09-01 at 23:03 +0300, Gleb Natapov wrote:
> On Thu, Sep 01, 2011 at 10:58:31PM +0300, Sasha Levin wrote:
> > By "actual addressing model" I meant checking the ICR of of each APIC to
> > see if we should address it logically or physically.
> >
> This is definitely not what ICR of each
On Thu, Sep 01, 2011 at 11:05:00PM +0300, Sasha Levin wrote:
> On Thu, 2011-09-01 at 23:03 +0300, Gleb Natapov wrote:
> > On Thu, Sep 01, 2011 at 10:58:31PM +0300, Sasha Levin wrote:
> > > By "actual addressing model" I meant checking the ICR of of each APIC to
> > > see if we should address it log
On Thu, 2011-09-01 at 23:19 +0300, Gleb Natapov wrote:
> On Thu, Sep 01, 2011 at 11:05:00PM +0300, Sasha Levin wrote:
> > On Thu, 2011-09-01 at 23:03 +0300, Gleb Natapov wrote:
> > > On Thu, Sep 01, 2011 at 10:58:31PM +0300, Sasha Levin wrote:
> > > > By "actual addressing model" I meant checking t
On 09/01/2011 03:00 PM, Michael S. Tsirkin wrote:
> That's a very rich interface, and easy to get wrong.
> AFAIK the only reason vfio uses read/write for PCI was to avoid inventing
> a custom interface. But if you do, it looks like a set of ioctls would
> be much easier? You can even fit the existi
On Thu, 2011-09-01 at 14:10 +1000, David Gibson wrote:
> On Tue, Aug 30, 2011 at 08:51:38AM -0600, Alex Williamson wrote:
> > On Tue, 2011-08-30 at 17:48 +1000, David Gibson wrote:
> > > On Mon, Aug 29, 2011 at 10:24:43PM -0600, Alex Williamson wrote:
> > > > On Tue, 2011-08-30 at 13:04 +1000, Davi
On Thu, 01 Sep 2011 14:24:12 -0500, Anthony Liguori wrote:
On 08/30/2011 07:26 AM, Marcelo Tosatti wrote:
On Mon, Aug 29, 2011 at 05:27:11PM -0600, Eric B Munson wrote:
Currently, when qemu stops a guest kernel that guest will issue a
soft lockup
message when it resumes. This set provides the
Signed-off-by: Scott Wood
---
arch/powerpc/kvm/booke.c |4 ++--
arch/powerpc/kvm/e500.c |3 ---
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index ee45fa0..d967faf 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/power
From: Jeremy Fitzhardinge
Replace the old Xen implementation of PV spinlocks with and implementation
of xen_lock_spinning and xen_unlock_kick.
xen_lock_spinning simply registers the cpu in its entry in lock_waiting,
adds itself to the waiting_cpus set, and blocks on an event channel
until the ch
From: Jeremy Fitzhardinge
Increment ticket head/tails by 2 rather than 1 to leave the LSB free
to store a "is in slowpath state" bit. This halves the number
of possible CPUs for a given ticket size, but this shouldn't matter
in practice - kernels built for 32k+ CPU systems are probably
specially
From: Jeremy Fitzhardinge
Signed-off-by: Jeremy Fitzhardinge
---
arch/x86/xen/spinlock.c | 28 +---
1 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index 2ed5d05..7b89439 100644
--- a/arch/x86/xen/spinlo
From: Jeremy Fitzhardinge
Use __ticket_t for the ticket argument to the pvops, to prevent
unnecessary zero-extension in the calling code.
Signed-off-by: Jeremy Fitzhardinge
---
arch/x86/include/asm/paravirt.h |6 --
arch/x86/include/asm/spinlock_types.h |4
arch/x86/xen/
From: Jeremy Fitzhardinge
Maintain a flag in both LSBs of the ticket lock which indicates whether
anyone is in the lock slowpath and may need kicking when the current
holder unlocks. The flags are set when the first locker enters
the slowpath, and cleared when unlocking to an empty queue.
In th
From: Jeremy Fitzhardinge
We need to make sure interrupts are disabled while we're relying on the
contents of the per-cpu lock_waiting values, otherwise an interrupt
handler could come in, try to take some other lock, block, and overwrite
our values.
Signed-off-by: Jeremy Fitzhardinge
---
arch
From: Jeremy Fitzhardinge
__ticket_unlock_kick() is now only called from known slowpaths, so there's
no need for it to do any checking of its own.
Signed-off-by: Jeremy Fitzhardinge
---
arch/x86/include/asm/paravirt.h |2 +-
arch/x86/include/asm/spinlock.h | 14 --
2 files ch
From: Jeremy Fitzhardinge
This series replaces the existing paravirtualized spinlock mechanism
with a paravirtualized ticketlock mechanism.
Ticket locks have an inherent problem in a virtualized case, because
the vCPUs are scheduled rather than running concurrently (ignoring
gang scheduled vCPUs
From: Jeremy Fitzhardinge
If we're releasing the lock into an uncontended state, there's nobody
waiting on it, so there's no need to kick anyone.
Signed-off-by: Jeremy Fitzhardinge
---
arch/x86/kernel/paravirt-spinlocks.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git
From: Jeremy Fitzhardinge
Now that the paravirtualization layer doesn't exist at the spinlock
level any more, we can collapse the __ticket_ functions into the arch_
functions.
Signed-off-by: Jeremy Fitzhardinge
---
arch/x86/include/asm/spinlock.h | 35 +--
1 f
From: Jeremy Fitzhardinge
Rather than outright replacing the entire spinlock implementation in
order to paravirtualize it, keep the ticket lock implementation but add
a couple of pvops hooks on the slow patch (long spin on lock, unlocking
a contended lock).
Ticket locks have a number of nice pro
From: Jeremy Fitzhardinge
Otherwise the generated code for raw_spin_lock will look awful.
Signed-off-by: Jeremy Fitzhardinge
---
arch/x86/include/asm/paravirt.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/pa
From: Srivatsa Vaddagiri
We must release the lock before checking to see if the lock is in
slowpath or else there's a potential race where the lock enters the
slow path after the unlocker has checked the slowpath flag, but before
it has actually unlocked.
Signed-off-by: Srivatsa Vaddagiri
Signe
From: Jeremy Fitzhardinge
Although the lock_spinning calls in the spinlock code are on the
uncommon path, their presence can cause the compiler to generate many
more register save/restores in the function pre/postamble, which is in
the fast path. To avoid this, convert it to using the pvops call
Scott Wood wrote:
> Signed-off-by: Scott Wood
How about providing a better description?
--
Timur Tabi
Linux kernel developer at Freescale
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.ke
On Thu, Sep 01, 2011 at 02:27:00PM -0600, Alex Williamson wrote:
> On Thu, 2011-09-01 at 14:10 +1000, David Gibson wrote:
> > On Tue, Aug 30, 2011 at 08:51:38AM -0600, Alex Williamson wrote:
[snip]
> > > > If you open a group, merge in a bunch of other groups, then re-open
> > > > /dev/vfio/NNN for
50 matches
Mail list logo
