On 01/13/2014 02:44 AM, Alexander Graf wrote:
On 10.01.2014, at 08:21, Alexey Kardashevskiy a...@ozlabs.ru wrote:
When write to MMIO happens and there is an ioeventfd for that and
is handled successfully, ioeventfd_write() returns 0 (success) and
kvmppc_handle_store() returns EMULATE_DONE.
On 04.02.2014, at 09:03, Alexey Kardashevskiy a...@ozlabs.ru wrote:
On 01/13/2014 02:44 AM, Alexander Graf wrote:
On 10.01.2014, at 08:21, Alexey Kardashevskiy a...@ozlabs.ru wrote:
When write to MMIO happens and there is an ioeventfd for that and
is handled successfully,
On Tue, Feb 04, 2014 at 09:19:30AM +0100, Maria Soler wrote:
On 29 January 2014 16:35, Andrew Jones drjo...@redhat.com wrote:
On Tue, Jan 28, 2014 at 07:16:11PM +0100, María Soler Heredia wrote:
Hello Andrew,
I have been experimenting a little with your tests and I have some
Il 04/02/2014 08:24, Aleksey Larionov ha scritto:
No, I can't. My kvm version is a part of proxmoxve hipervizor and this
system have own kernel, if I use different kernel then the system
breaks down.
Then you have to contact proxmox.
Paolo
--
To unsubscribe from this list: send the line
On 03.02.2014 08:45, Stefan Hajnoczi wrote:
KVM libvirt: you are welcome to join the QEMU umbrella organization
like last year.
I've updated wiki with a libvirt idea. But I can sense more to come
later as I have some time to think about it :)
Michal
--
To unsubscribe from this list: send
Juan Quintela quint...@redhat.com wrote:
Hi
Please, send any topic that you are interested in covering.
* Should we change anything to get more people to sign for the call?
There hasn't been a call in quite a long time. Ideas?
Any further discussion here?
No topics for this week, so
Good day. Very little speed drives Virtio. Drivers are the latest guest
on the system Windows server 2008. Host system centos 6.5.
All that can be tried, but failed to increase the speed. And there I
have a database running.
Screenshots test speed drives
We may have seen this as well. Initial speed tests were actually
pretty good, but after running a few IO test it would actually cause
the physical disks that were dedicated to the windows vm host side to
be stuck at 100% util with no throughput for 30 seconds at a time
according to iostat. We were
Despite not being used anymore, there are still traces of BAR 3 in both
the code and comments for the virtio pci msix implementation.
This patch removes the redundant code and fixes up the comments to match
what we're actually doing.
Cc: Sasha Levin sasha.le...@oracle.com
Signed-off-by: Will
All architectures are now doing the same thing for irq__alloc_line:
1. Initialise a global counter to some fixed offset
2. Return the current value of the counter and increment it
This is better off in core code, with each architecture specifying the
initial offset, which is specific to the
For the MMIO and PCI buses, drivers typically allocate an IRQ line for
their device before registering the device with the device tree for the
relevant bus.
This patch moves the IRQ allocation into the bus code, which is then
called directly by the device tree when a new device is registered.
Now that we have some common OF PCI definitions in of_pci.h, make use
of them when generating the devicetree for spapr_pci on ppc.
Signed-off-by: Will Deacon will.dea...@arm.com
---
tools/kvm/powerpc/spapr_pci.c | 114 ++
1 file changed, 48 insertions(+),
BARs must be naturally aligned, so enforce this in the PCI IO space
allocator.
Signed-off-by: Will Deacon will.dea...@arm.com
---
tools/kvm/pci.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/tools/kvm/pci.c b/tools/kvm/pci.c
index e735352eb042..c4442c85b5cf 100644
Rather than performing all config accesses via ioports, map in a 24-bit
memory-mapped configuration space directly below the PCI MMIO region.
This will allow architectures to support PCI without having to support
legacy ioports in the guest kernel. Instead, kvm tool can forward the
config
Rather than performing all config accesses via ioports, map in a 24-bit
memory-mapped configuration space directly below the PCI MMIO region.
This will allow architectures to support PCI without having to support
legacy ioports in the guest kernel. Instead, kvm tool can forward the
config
When attempting to initialise a mixture of pci and mmio virtio devices,
we cannot share an ops structure, otherwise the transport-specific
fields (init/exit and signal handling) will be globally set to the
transport of the last registered device.
This patch dynamically allocates a new ops
With the removal of the x86 irq rbtree, the only parameter used by
irq__register_device is actually used to return the new line.
This patch removes all of the parameters from irq__register_device and
returns the allocated line directly.
Signed-off-by: Will Deacon will.dea...@arm.com
---
The x86 code keeps its own rbtree of PCI devices in order to allocate
interrupts. However, this functionality can be moved into the generic
PCI device tree and be reused by other architectures.
This patch removes the x86 tree and reworks the ACPI mptable generation
to use the PCI device tree for
In preparation for moving the irq allocation into generic code, remove
the pin parameter from irq__register_device and temporarily place the
onus on the emulation driver to allocate the pin (which is always 1 and
only used on PCI anyway).
Signed-off-by: Will Deacon will.dea...@arm.com
---
Currently, if a -tx or -rx callback into the net_dev_operations
encounters an error, it returns -1 to the virtio-net code, which in turn
treats this as an unsigned (size_t) size describing the data available.
The resulting memcpy operation then quickly explodes with a SEGV.
This patch detects the
This patch changes VIRTIO_DEFAULT_TRANS to take a struct kvm parameter,
allowing architectures to choose the default transport dynamically.
For ARM, this is driven by an arch-specific cmdline option.
Signed-off-by: Will Deacon will.dea...@arm.com
---
tools/kvm/arm/include/arm-common/kvm-arch.h
BARs must be naturally aligned, so enforce this in the PCI IO space
allocator.
Signed-off-by: Will Deacon will.dea...@arm.com
---
tools/kvm/pci.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/tools/kvm/pci.c b/tools/kvm/pci.c
index e735352eb042..c4442c85b5cf 100644
For the MMIO and PCI buses, drivers typically allocate an IRQ line for
their device before registering the device with the device tree for the
relevant bus.
This patch moves the IRQ allocation into the bus code, which is then
called directly by the device tree when a new device is registered.
Now that we have some common OF PCI definitions in of_pci.h, make use
of them when generating the devicetree for spapr_pci on ppc.
Signed-off-by: Will Deacon will.dea...@arm.com
---
tools/kvm/powerpc/spapr_pci.c | 114 ++
1 file changed, 48 insertions(+),
With the removal of the x86 irq rbtree, the only parameter used by
irq__register_device is actually used to return the new line.
This patch removes all of the parameters from irq__register_device and
returns the allocated line directly.
Signed-off-by: Will Deacon will.dea...@arm.com
---
This patch factors out some of the openfirmware PCI binding definitions
from the powerpc spapr PCI code and uses them to generate appropriate
FDT properties for the PCI node on ARM.
Signed-off-by: Will Deacon will.dea...@arm.com
---
tools/kvm/Makefile | 2 +-
All architectures are now doing the same thing for irq__alloc_line:
1. Initialise a global counter to some fixed offset
2. Return the current value of the counter and increment it
This is better off in core code, with each architecture specifying the
initial offset, which is specific to the
The x86 code keeps its own rbtree of PCI devices in order to allocate
interrupts. However, this functionality can be moved into the generic
PCI device tree and be reused by other architectures.
This patch removes the x86 tree and reworks the ACPI mptable generation
to use the PCI device tree for
This patch adds an MMIO interface for each virtio-pci device, so that
they can be accessed without having to use an ioport. For each device, a
new memory BAR is added which corresponds to an area of MMIO space with
a shim trap handler. This handler simply translates the access into an
ioport
In preparation for moving the irq allocation into generic code, remove
the pin parameter from irq__register_device and temporarily place the
onus on the emulation driver to allocate the pin (which is always 1 and
only used on PCI anyway).
Signed-off-by: Will Deacon will.dea...@arm.com
---
This patch factors out some of the openfirmware PCI binding definitions
from the powerpc spapr PCI code and uses them to generate appropriate
FDT properties for the PCI node on ARM.
Signed-off-by: Will Deacon will.dea...@arm.com
---
tools/kvm/Makefile | 2 +-
This patch routes guest PCI accesses to kvm__emulate_mmio, rather than
exiting lkvm via a die invocation. The guest command-line is also
updated to prevent the guest from attempting to program the BARs with
new addresses (i.e. probe-only).
Signed-off-by: Will Deacon will.dea...@arm.com
---
Currently, if a -tx or -rx callback into the net_dev_operations
encounters an error, it returns -1 to the virtio-net code, which in turn
treats this as an unsigned (size_t) size describing the data available.
The resulting memcpy operation then quickly explodes with a SEGV.
This patch detects the
This patch adds an MMIO interface for each virtio-pci device, so that
they can be accessed without having to use an ioport. For each device, a
new memory BAR is added which corresponds to an area of MMIO space with
a shim trap handler. This handler simply translates the access into an
ioport
This patch routes guest PCI accesses to kvm__emulate_mmio, rather than
exiting lkvm via a die invocation. The guest command-line is also
updated to prevent the guest from attempting to program the BARs with
new addresses (i.e. probe-only).
Signed-off-by: Will Deacon will.dea...@arm.com
---
Since irq__register_device no longer registers a device with anything,
rename it to irq__alloc_line, which better describes what is actually
going on.
Signed-off-by: Will Deacon will.dea...@arm.com
---
tools/kvm/arm/irq.c | 2 +-
tools/kvm/hw/pci-shmem.c| 2 +-
tools/kvm/hw/vesa.c
Hello,
This patch series adds PCI support for ARM targets to lkvm. Note that
there are corresponding kernel patches in order for Linux to use the
virtual PCI host controller, so the interface is still subject to
change.
The main parts of this series are:
- Fixes to the MSI-X bar and
Despite allocating and providing code to handle accesses to the pba
structure, virtio msix blocks in fact only register the msix table with
kvm.
This patch fixes the MMIO region so that it includes the pba structure
for msix io blocks of virtio pci devices. The corresponding BAR is also
updated
Despite not being used anymore, there are still traces of BAR 3 in both
the code and comments for the virtio pci msix implementation.
This patch removes the redundant code and fixes up the comments to match
what we're actually doing.
Cc: Sasha Levin sasha.le...@oracle.com
Signed-off-by: Will
Hello,
This patch series adds PCI support for ARM targets to lkvm. Note that
there are corresponding kernel patches in order for Linux to use the
virtual PCI host controller, so the interface is still subject to
change.
The main parts of this series are:
- Fixes to the MSI-X bar and
Hello,
I`ve got strange results during benchmarking migration speed for
different kinds of loads on source/target host: when source host is
'empty', migration takes approx. 30 percent longer than the same for
host already occupied by one VM with CPU overcommit ratio=1.
[src host, three equal
When attempting to initialise a mixture of pci and mmio virtio devices,
we cannot share an ops structure, otherwise the transport-specific
fields (init/exit and signal handling) will be globally set to the
transport of the last registered device.
This patch dynamically allocates a new ops
Despite allocating and providing code to handle accesses to the pba
structure, virtio msix blocks in fact only register the msix table with
kvm.
This patch fixes the MMIO region so that it includes the pba structure
for msix io blocks of virtio pci devices. The corresponding BAR is also
updated
This patch changes VIRTIO_DEFAULT_TRANS to take a struct kvm parameter,
allowing architectures to choose the default transport dynamically.
For ARM, this is driven by an arch-specific cmdline option.
Signed-off-by: Will Deacon will.dea...@arm.com
---
tools/kvm/arm/include/arm-common/kvm-arch.h
Since irq__register_device no longer registers a device with anything,
rename it to irq__alloc_line, which better describes what is actually
going on.
Signed-off-by: Will Deacon will.dea...@arm.com
---
tools/kvm/arm/irq.c | 2 +-
tools/kvm/hw/pci-shmem.c| 2 +-
tools/kvm/hw/vesa.c
-mem-prealloc asks to preallocate memory residing on -mem-path path.
Currently QEMU exits in case:
- Memory file has been created but allocation via explicit write
fails.
And it fallbacks to malloc in case:
- Querying huge page size fails.
- Lack of sync MMU support.
- Open fails.
- mmap
On Tue, Feb 04, 2014 at 01:41:53PM -0500, Marcelo Tosatti wrote:
-mem-prealloc asks to preallocate memory residing on -mem-path path.
Currently QEMU exits in case:
- Memory file has been created but allocation via explicit write
fails.
And it fallbacks to malloc in case:
- Querying
On Mon, Feb 3, 2014 at 9:31 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 03/02/2014 18:06, Xin Tong ha scritto:
/.../qemu-system-x86_64 TID 2537 [TID 2537] (877 ticks/71.24%)
This is the CPU thread (calls into the KVM modules).
This is the thread that calls the int
We've had this in linux-next for 2+ weeks (thanks Stephen!) as a
linux-stable like queue of patches, and as can be seen here:
https://git.kernel.org/pub/scm/linux/kernel/git/paulg/init.git
most of the changes in the last week have been trivial adding acks
or dropping patches that maintainers
04.02.2014 20:32, Marcus пишет:
We may have seen this as well. Initial speed tests were actually
pretty good, but after running a few IO test it would actually cause
the physical disks that were dedicated to the windows vm host side to
be stuck at 100% util with no throughput for 30 seconds at a
* Paul Gortmaker paul.gortma...@windriver.com wrote:
On Feb 4, 2014 3:52 PM, Paul Gortmaker paul.gortma...@windriver.com
wrote:
We've had this in linux-next for 2+ weeks (thanks Stephen!) as a
linux-stable like queue of patches, and as can be seen here:
Hi Ingo,
On Wed, 5 Feb 2014 07:06:33 +0100 Ingo Molnar mi...@kernel.org wrote:
So, if you meant Linus to pull it, you probably want to cite a real
Git URI along the lines of:
git://git.kernel.org/pub/scm/linux/kernel/git/paulg/init.git
Paul provided the proper git url further down in
* Stephen Rothwell s...@canb.auug.org.au wrote:
Hi Ingo,
On Wed, 5 Feb 2014 07:06:33 +0100 Ingo Molnar mi...@kernel.org wrote:
So, if you meant Linus to pull it, you probably want to cite a real
Git URI along the lines of:
Il 04/02/2014 18:06, Andrey Korolyov ha scritto:
Migration time is almost independent of VM RSS(varies by ten percent at
maximum), for situation when VM is active on target host, time is about
85 seconds to migrate 8G between hosts, and when it is turned off,
migration time *increasing* to 120s.
On 04.02.2014, at 09:03, Alexey Kardashevskiy a...@ozlabs.ru wrote:
On 01/13/2014 02:44 AM, Alexander Graf wrote:
On 10.01.2014, at 08:21, Alexey Kardashevskiy a...@ozlabs.ru wrote:
When write to MMIO happens and there is an ioeventfd for that and
is handled successfully,
55 matches
Mail list logo
