On Sun, Feb 3, 2013 at 2:10 PM, Pandarathil, Vijaymohan R
vijaymohan.pandarat...@hp.com wrote:
- New VFIO_SET_IRQ ioctl option to pass the eventfd that is signaled
when
an error occurs in the vfio_pci_device
- Register pci_error_handler for the vfio_pci driver
On Sun, Feb 3, 2013 at 2:10 PM, Pandarathil, Vijaymohan R
vijaymohan.pandarat...@hp.com wrote:
- Create eventfd per vfio device assigned to a guest and register an
event handler
- This fd is passed to the vfio_pci driver through the SET_IRQ ioctl
- When the
On Tue, Jan 29, 2013 at 1:50 PM, Jason Wang jasow...@redhat.com wrote:
On 01/26/2013 03:13 AM, Blue Swirl wrote:
On Fri, Jan 25, 2013 at 10:35 AM, Jason Wang jasow...@redhat.com wrote:
This patch introduce a new bit - enabled in TAPState which tracks whether a
specific queue/fd is enabled
On Fri, Jan 25, 2013 at 10:35 AM, Jason Wang jasow...@redhat.com wrote:
This patch introduce a new bit - enabled in TAPState which tracks whether a
specific queue/fd is enabled. The tap/fd is enabled during initialization and
could be enabled/disabled by tap_enalbe() and tap_disable() which
On Wed, Jan 9, 2013 at 6:26 AM, Pandarathil, Vijaymohan R
vijaymohan.pandarat...@hp.com wrote:
- Create eventfd per vfio device assigned to a guest and register an
event handler
- This fd is passed to the vfio_pci driver through a new ioctl
- When the device
On Fri, Jan 4, 2013 at 5:12 AM, Jason Wang jasow...@redhat.com wrote:
On 12/29/2012 01:52 AM, Blue Swirl wrote:
On Fri, Dec 28, 2012 at 10:32 AM, Jason Wang jasow...@redhat.com wrote:
This patch implements both userspace and vhost support for multiple queue
virtio-net (VIRTIO_NET_F_MQ
On Fri, Jan 4, 2013 at 2:52 PM, Eduardo Habkost ehabk...@redhat.com wrote:
This is a cleanup that tries to solve two small issues:
- We don't need a separate kvm_pv_eoi_features variable just to keep a
constant calculated at compile-time, and this style would require
adding a separate
On Fri, Jan 4, 2013 at 2:52 PM, Eduardo Habkost ehabk...@redhat.com wrote:
The kvm_mmu_op feature was removed from the kernel since v3.3 (released
in March 2012), it was marked for removal since January 2011 and it's
slower than shadow or hardware assisted paging (see kernel commit
On Fri, Jan 4, 2013 at 3:37 PM, Eduardo Habkost ehabk...@redhat.com wrote:
The -cpu check/enforce warnings are printing incorrect information about the
missing flags. There are no feature flags on CPUID leaves 0 and 0x8000,
but
there were references to 0 and 0x8000 in the table at
On Fri, Dec 28, 2012 at 10:32 AM, Jason Wang jasow...@redhat.com wrote:
This patch implements both userspace and vhost support for multiple queue
virtio-net (VIRTIO_NET_F_MQ). This is done by introducing an array of
VirtIONetQueue to VirtIONet.
Signed-off-by: Jason Wang jasow...@redhat.com
On Fri, Dec 28, 2012 at 10:31 AM, Jason Wang jasow...@redhat.com wrote:
This patch adds basic multiqueue support for qemu. The idea is simple, an
array
of NetClientStates were introduced in NICState, parse_netdev() were extended
to
find and match all NetClientStates belongs to the backend
On Fri, Nov 2, 2012 at 5:38 AM, Xudong Hao xudong@intel.com wrote:
Enable 64 bits bar emulation.
Signed-off-by: Xudong Hao xudong@intel.com
---
hw/kvm/pci-assign.c | 18 --
1 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/hw/kvm/pci-assign.c
Pass around CPUState instead of using global cpu_single_env.
Signed-off-by: Blue Swirl blauwir...@gmail.com
---
target-i386/kvm.c | 21 +++--
1 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 3aa62b2..3329d5e 100644
On Thu, Oct 18, 2012 at 12:33 PM, Avi Kivity a...@redhat.com wrote:
On 10/18/2012 11:27 AM, Vasilis Liaskovitis wrote:
On Wed, Oct 17, 2012 at 12:03:51PM +0200, Avi Kivity wrote:
On 10/17/2012 11:19 AM, Vasilis Liaskovitis wrote:
I don't think so, but probably there's a limit of DIMMs that
On Tue, Oct 9, 2012 at 5:04 PM, Vasilis Liaskovitis
vasilis.liaskovi...@profitbricks.com wrote:
Hi,
sorry for the delayed answer.
On Sat, Sep 29, 2012 at 11:13:04AM +, Blue Swirl wrote:
The -dimm option is supposed to specify the dimm/memory layout, and not
create
any devices
On Wed, Oct 10, 2012 at 3:07 PM, Peter Maydell peter.mayd...@linaro.org wrote:
From: Christoffer Dall cd...@cs.columbia.edu
Add basic support for KVM on ARM architecture.
Signed-off-by: Christoffer Dall cd...@cs.columbia.edu
[PMM: Minor tweaks and code cleanup, switch to ONE_REG]
On Fri, Oct 5, 2012 at 5:11 PM, Alex Williamson
alex.william...@redhat.com wrote:
On Fri, 2012-10-05 at 16:54 +, Blue Swirl wrote:
On Wed, Sep 26, 2012 at 5:19 PM, Alex Williamson
alex.william...@redhat.com wrote:
+
+typedef struct QEMU_PACKED VFIOIRQSetFD {
+struct vfio_irq_set
On Fri, Oct 5, 2012 at 5:33 PM, Alex Williamson
alex.william...@redhat.com wrote:
On Fri, 2012-10-05 at 17:22 +, Blue Swirl wrote:
On Fri, Oct 5, 2012 at 5:11 PM, Alex Williamson
alex.william...@redhat.com wrote:
On Fri, 2012-10-05 at 16:54 +, Blue Swirl wrote:
On Wed, Sep 26, 2012
On Mon, Oct 1, 2012 at 4:20 PM, Anthony Liguori anth...@codemonkey.ws wrote:
Jan Kiszka jan.kis...@siemens.com writes:
If we built a target for a host that supports KVM in principle, set the
default accelerator to KVM as well. This also means the start of QEMU
will fail to start if KVM
On Mon, Sep 24, 2012 at 10:42 AM, Vasilis Liaskovitis
vasilis.liaskovi...@profitbricks.com wrote:
On Sat, Sep 22, 2012 at 01:46:57PM +, Blue Swirl wrote:
On Fri, Sep 21, 2012 at 11:17 AM, Vasilis Liaskovitis
vasilis.liaskovi...@profitbricks.com wrote:
Example:
-dimm id=dimm0,size=512M
On Mon, Sep 24, 2012 at 3:27 PM, Vasilis Liaskovitis
vasilis.liaskovi...@profitbricks.com wrote:
On Sat, Sep 22, 2012 at 02:15:28PM +, Blue Swirl wrote:
+
+/* Function to configure memory offsets of hotpluggable dimms */
+
+target_phys_addr_t pc_set_hp_memory_offset(uint64_t size
On Thu, Sep 20, 2012 at 5:43 AM, Gerd Hoffmann kra...@redhat.com wrote:
Hi,
+vbe_ioport_write_index(d-vga, 0, index);
+return vbe_ioport_read_data(d-vga, 0);
These functions are only available with CONFIG_BOCHS_VBE #defined, so
this code should be conditional as well.
But
On Sat, Sep 22, 2012 at 12:13 AM, Don Slutz d...@cloudswitch.com wrote:
Also known as Paravirtualization CPUIDs.
This is primarily done so that the guest will think it is running
under vmware when hypervisor-vendor=vmware is specified as a
property of a cpu.
Please use checkpatch.pl to check
On Fri, Sep 21, 2012 at 11:17 AM, Vasilis Liaskovitis
vasilis.liaskovi...@profitbricks.com wrote:
Example:
-dimm id=dimm0,size=512M,node=0,populated=off
There should not be a need to introduce a new top level option,
instead you should just use -device, like
-device
On Fri, Sep 21, 2012 at 11:17 AM, Vasilis Liaskovitis
vasilis.liaskovi...@profitbricks.com wrote:
A 32-byte register is used to present up to 256 hotplug-able memory devices
to BIOS and OSPM. Hot-add and hot-remove functions trigger an ACPI hotplug
event through these. Only reads are allowed
On Fri, Sep 21, 2012 at 11:17 AM, Vasilis Liaskovitis
vasilis.liaskovi...@profitbricks.com wrote:
Dimm physical address offsets are calculated automatically and memory map is
adjusted accordingly. If a DIMM can fit before the PCI_HOLE_START (currently
0xe000), it will be added normally,
On Fri, Sep 21, 2012 at 11:17 AM, Vasilis Liaskovitis
vasilis.liaskovi...@profitbricks.com wrote:
This is v3 of the ACPI memory hotplug functionality. Only x86_64 target is
supported
for now.
Overview:
Dimm device layout is modeled with a new qemu command line
-dimm
On Tue, Sep 18, 2012 at 9:51 AM, Gerd Hoffmann kra...@redhat.com wrote:
This patch adds a mmio bar to the qemu standard vga which allows to
access the standard vga registers and bochs dispi interface registers
via mmio.
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Signed-off-by: Gerd
On Thu, Sep 6, 2012 at 3:42 AM, Alexander Graf ag...@suse.de wrote:
On 05.09.2012, at 15:38, Blue Swirl wrote:
On Wed, Sep 5, 2012 at 7:22 PM, Anthony Liguori anth...@codemonkey.ws
wrote:
Blue Swirl blauwir...@gmail.com writes:
On Wed, Sep 5, 2012 at 3:41 PM, Anthony Liguori anth
On Thu, Sep 6, 2012 at 4:06 PM, Andreas Färber afaer...@suse.de wrote:
Am 06.09.2012 10:44, schrieb Jan Kiszka:
On 2012-08-30 20:30, Jan Kiszka wrote:
This adds PCI device assignment for i386 targets using the classic KVM
interfaces. This version is 100% identical to what is being maintained
On Thu, Sep 6, 2012 at 8:44 AM, Avi Kivity a...@redhat.com wrote:
On 09/05/2012 10:04 PM, Blue Swirl wrote:
Reinventing a disassembler for ever growing x86 assembly is
no fun.
We can try linking to a disassembler library. I use udis86 to
disassemble instructions in kvm tracepoints
(http
On Sat, Sep 8, 2012 at 9:28 AM, Alexander Graf ag...@suse.de wrote:
On 08.09.2012, at 10:06, Blue Swirl blauwir...@gmail.com wrote:
On Thu, Sep 6, 2012 at 8:44 AM, Avi Kivity a...@redhat.com wrote:
On 09/05/2012 10:04 PM, Blue Swirl wrote:
Reinventing a disassembler for ever growing x86
On Sat, Sep 8, 2012 at 12:13 PM, Alexander Graf ag...@suse.de wrote:
On 08.09.2012, at 12:16, Blue Swirl blauwir...@gmail.com wrote:
On Sat, Sep 8, 2012 at 9:28 AM, Alexander Graf ag...@suse.de wrote:
On 08.09.2012, at 10:06, Blue Swirl blauwir...@gmail.com wrote:
On Thu, Sep 6, 2012
On Wed, Sep 5, 2012 at 3:41 PM, Anthony Liguori anth...@codemonkey.ws wrote:
Avi Kivity a...@redhat.com writes:
On 09/05/2012 12:00 AM, Anthony Liguori wrote:
Why? The way this is being submitted I don't see why we should treat
Jan's patch any different from a patch by IBM or Samsung where
On Tue, Sep 4, 2012 at 9:28 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Sep 04, 2012 at 07:27:32PM +, Blue Swirl wrote:
On Tue, Sep 4, 2012 at 8:32 AM, Avi Kivity a...@redhat.com wrote:
On 09/03/2012 10:32 PM, Blue Swirl wrote:
On Mon, Sep 3, 2012 at 4:14 PM, Avi Kivity
On Wed, Sep 5, 2012 at 7:22 PM, Anthony Liguori anth...@codemonkey.ws wrote:
Blue Swirl blauwir...@gmail.com writes:
On Wed, Sep 5, 2012 at 3:41 PM, Anthony Liguori anth...@codemonkey.ws
wrote:
Avi Kivity a...@redhat.com writes:
On 09/05/2012 12:00 AM, Anthony Liguori wrote:
Why? The way
On Wed, Sep 5, 2012 at 7:24 PM, Eric Blake ebl...@redhat.com wrote:
On 09/05/2012 01:04 PM, Blue Swirl wrote:
I don't mind GPLv2+, if people want to share code from QEMU in GPLv3
projects, GPLv2+ enables that.
The advantage of 100% GPLv2+ (or other GPLv3 compatible) would be that
QEMU could
On Tue, Sep 4, 2012 at 8:32 AM, Avi Kivity a...@redhat.com wrote:
On 09/03/2012 10:32 PM, Blue Swirl wrote:
On Mon, Sep 3, 2012 at 4:14 PM, Avi Kivity a...@redhat.com wrote:
On 08/29/2012 11:27 AM, Markus Armbruster wrote:
I don't see a point in making contributors avoid non-problems
On Mon, Sep 3, 2012 at 4:14 PM, Avi Kivity a...@redhat.com wrote:
On 08/29/2012 11:27 AM, Markus Armbruster wrote:
I don't see a point in making contributors avoid non-problems that might
conceivably become trivial problems some day. Especially when there's
no automated help with the
On Tue, Aug 28, 2012 at 9:51 PM, Anthony Liguori anth...@codemonkey.ws wrote:
Blue Swirl blauwir...@gmail.com writes:
On Tue, Aug 28, 2012 at 7:31 PM, Anthony Liguori anth...@codemonkey.ws
wrote:
Blue Swirl blauwir...@gmail.com writes:
On Tue, Aug 28, 2012 at 5:28 PM, Michael S. Tsirkin m
On Tue, Aug 28, 2012 at 7:35 AM, Michael Tokarev m...@tls.msk.ru wrote:
On 27.08.2012 22:56, Blue Swirl wrote:
[]
+static uint32_t slow_bar_readb(void *opaque, target_phys_addr_t addr)
+{
+AssignedDevRegion *d = opaque;
+uint8_t *in = d-u.r_virtbase + addr;
Don't perform arithmetic
On Tue, Aug 28, 2012 at 1:22 PM, Michael S. Tsirkin m...@redhat.com wrote:
In preparation for adding PV EOI support, disable PV EOI by default for
1.1 and older machine types, to avoid CPUID changing during migration.
PV EOI can still be enabled/disabled by specifying it explicitly.
On Tue, Aug 28, 2012 at 5:22 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Aug 28, 2012 at 05:05:25PM +, Blue Swirl wrote:
+static bool _kvm_pv_eoi_disabled;
NACK. I find your lack of compliance disturbing.
Compliance with what? Could you please add some
motivation for the NACK
On Tue, Aug 28, 2012 at 5:28 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Aug 28, 2012 at 05:01:55PM +, Blue Swirl wrote:
On Tue, Aug 28, 2012 at 7:35 AM, Michael Tokarev m...@tls.msk.ru wrote:
On 27.08.2012 22:56, Blue Swirl wrote:
[]
+static uint32_t slow_bar_readb(void
On Tue, Aug 28, 2012 at 7:31 PM, Anthony Liguori anth...@codemonkey.ws wrote:
Blue Swirl blauwir...@gmail.com writes:
On Tue, Aug 28, 2012 at 5:28 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Aug 28, 2012 at 05:01:55PM +, Blue Swirl wrote:
On Tue, Aug 28, 2012 at 7:35 AM, Michael
On Mon, Aug 27, 2012 at 12:20 PM, Michael S. Tsirkin m...@redhat.com wrote:
In preparation for adding PV EOI support, disable PV EOI by default for
1.1 and older machine types, to avoid CPUID changing during migration.
PV EOI can still be enabled/disabled by specifying it explicitly.
On Mon, Aug 27, 2012 at 7:01 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Aug 27, 2012 at 06:56:38PM +, Blue Swirl wrote:
+static uint32_t slow_bar_readb(void *opaque, target_phys_addr_t addr)
+{
+AssignedDevRegion *d = opaque;
+uint8_t *in = d-u.r_virtbase + addr
On Mon, Aug 27, 2012 at 7:06 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Aug 27, 2012 at 06:58:29PM +, Blue Swirl wrote:
On Mon, Aug 27, 2012 at 12:20 PM, Michael S. Tsirkin m...@redhat.com wrote:
In preparation for adding PV EOI support, disable PV EOI by default for
1.1
On Mon, Aug 27, 2012 at 7:24 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Aug 27, 2012 at 07:12:27PM +, Blue Swirl wrote:
On Mon, Aug 27, 2012 at 7:06 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Aug 27, 2012 at 06:58:29PM +, Blue Swirl wrote:
On Mon, Aug 27, 2012
On Wed, Aug 22, 2012 at 7:30 AM, Wen Congyang we...@cn.fujitsu.com wrote:
At 08/09/2012 03:01 AM, Blue Swirl Wrote:
On Wed, Aug 8, 2012 at 2:47 AM, Wen Congyang we...@cn.fujitsu.com wrote:
If the target is x86/x86_64, the guest's kernel will write 0x01 to the
port KVM_PV_EVENT_PORT when
On Mon, Aug 13, 2012 at 8:35 AM, Nicholas A. Bellinger
n...@linux-iscsi.org wrote:
From: Nicholas Bellinger n...@linux-iscsi.org
This is required to get past the following assert with:
commit 1523ed9e1d46b0b54540049d491475ccac7e6421
Author: Jan Kiszka jan.kis...@siemens.com
Date: Thu May
On Mon, Aug 13, 2012 at 8:35 AM, Nicholas A. Bellinger
n...@linux-iscsi.org wrote:
From: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
This patch adds a new type of host device that drives the vhost_scsi
device. The syntax to add vhost-scsi is:
qemu -vhost-scsi
an accelerated patch for this through KVM. I'd
like to get this base driver in first and enable the remaining
support in-tree.
I've split this version up a little from the RFC to make it a bit
easier to review. Review comments from Blue Swirl and Avi are
already incorporated, including Avi's
On Thu, Aug 9, 2012 at 7:28 AM, liu ping fan qemul...@gmail.com wrote:
On Thu, Aug 9, 2012 at 3:17 AM, Blue Swirl blauwir...@gmail.com wrote:
On Wed, Aug 8, 2012 at 6:25 AM, Liu Ping Fan qemul...@gmail.com wrote:
From: Liu Ping Fan pingf...@linux.vnet.ibm.com
Using mem_map_lock to protect
On Wed, Aug 8, 2012 at 2:47 AM, Wen Congyang we...@cn.fujitsu.com wrote:
If the target is x86/x86_64, the guest's kernel will write 0x01 to the
port KVM_PV_EVENT_PORT when it is panciked. This patch introduces a new
qom device kvm_pv_ioport to listen this I/O port, and deal with panicked
event
On Wed, Aug 8, 2012 at 8:28 AM, Cornelia Huck cornelia.h...@de.ibm.com wrote:
On Tue, 7 Aug 2012 20:47:22 +
Blue Swirl blauwir...@gmail.com wrote:
diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
new file mode 100644
index 000..8a90c3a
--- /dev/null
+++ b/hw/s390x
On Wed, Aug 8, 2012 at 8:17 AM, Cornelia Huck cornelia.h...@de.ibm.com wrote:
On Tue, 7 Aug 2012 21:00:59 +
Blue Swirl blauwir...@gmail.com wrote:
diff --git a/hw/s390x/css.c b/hw/s390x/css.c
new file mode 100644
index 000..7941c44
--- /dev/null
+++ b/hw/s390x/css.c
@@ -0,0
On Wed, Aug 8, 2012 at 6:25 AM, Liu Ping Fan qemul...@gmail.com wrote:
From: Liu Ping Fan pingf...@linux.vnet.ibm.com
Using mem_map_lock to protect among updaters. So we can get the intact
snapshot of mem topology -- FlatView radix-tree.
Signed-off-by: Liu Ping Fan
On Wed, Aug 8, 2012 at 6:25 AM, Liu Ping Fan qemul...@gmail.com wrote:
From: Liu Ping Fan pingf...@linux.vnet.ibm.com
PhysMap contain the flatview and radix-tree view, they are snapshot
of system topology and should be consistent. With PhysMap, we can
swap the pointer when updating and
On Wed, Aug 8, 2012 at 6:25 AM, Liu Ping Fan qemul...@gmail.com wrote:
From: Liu Ping Fan pingf...@linux.vnet.ibm.com
Flatview and radix view are all under the protection of pointer.
And this make sure the change of them seem to be atomic!
The mr accessed by radix-tree leaf or flatview will
On Wed, Aug 8, 2012 at 7:34 PM, Peter Maydell peter.mayd...@linaro.org wrote:
On 8 August 2012 20:16, Blue Swirl blauwir...@gmail.com wrote:
On Wed, Aug 8, 2012 at 8:17 AM, Cornelia Huck cornelia.h...@de.ibm.com
wrote:
On Tue, 7 Aug 2012 21:00:59 +
Blue Swirl blauwir...@gmail.com wrote
On Tue, Aug 7, 2012 at 2:52 PM, Cornelia Huck cornelia.h...@de.ibm.com wrote:
Add a new virtio transport that uses channel commands to perform
virtio operations.
Add a new machine type s390-ccw that uses this virtio-ccw transport
and make it the default machine for s390.
Signed-off-by:
On Tue, Aug 7, 2012 at 2:52 PM, Cornelia Huck cornelia.h...@de.ibm.com wrote:
Provide a mechanism for qemu to provide fully virtual subchannels to
the guest. In the KVM case, this relies on the kernel's css support.
The !KVM case is not yet supported.
Signed-off-by: Cornelia Huck
Thanks, applied.
On Tue, Jul 17, 2012 at 4:31 AM, Chegu Vinod chegu_vi...@hp.com wrote:
Changes since v3:
- using bitmap_set() instead of set_bit() in numa_add() routine.
- removed call to bitmak_zero() since bitmap_new() also zeros' the bitmap.
- Rebased to the latest qemu.
On Mon, Jul 16, 2012 at 2:25 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Support for START/STOP UNIT right now is limited to CD-ROMs. This is wrong,
since removable hard disks (in the real world: SD card readers) also support
it in pretty much the same way.
I remember vaguely tuning a set of
On Fri, Jul 13, 2012 at 5:49 PM, Vasilis Liaskovitis
vasilis.liaskovi...@profitbricks.com wrote:
On Thu, Jul 12, 2012 at 08:04:56PM +, Blue Swirl wrote:
On Wed, Jul 11, 2012 at 10:31 AM, Vasilis Liaskovitis
vasilis.liaskovi...@profitbricks.com wrote:
This is v2 of the ACPI memory hotplug
On Wed, Jul 11, 2012 at 10:31 AM, Vasilis Liaskovitis
vasilis.liaskovi...@profitbricks.com wrote:
The numa_fw_cfg paravirt interface is extended to include SRAT information for
all hotplug-able dimms. There are 3 words for each hotplug-able memory slot,
denoting start address, size and node
On Wed, Jul 11, 2012 at 10:31 AM, Vasilis Liaskovitis
vasilis.liaskovi...@profitbricks.com wrote:
Each hotplug-able memory slot is a SysBusDevice. A hot-add operation for a
particular dimm creates a new MemoryRegion of the given physical address
offset, size and node proximity, and attaches it
On Wed, Jul 11, 2012 at 10:31 AM, Vasilis Liaskovitis
vasilis.liaskovi...@profitbricks.com wrote:
This is v2 of the ACPI memory hotplug prototype for x86_64 target.
I think the concept of DIMMs (what about SIMMs? SODIMMs? I liked
memslot) would be useful for most targets, but hotplugging may be
On Wed, Jul 4, 2012 at 8:05 AM, Avi Kivity a...@redhat.com wrote:
On 07/03/2012 10:06 PM, Blue Swirl wrote:
On Mon, Jul 2, 2012 at 9:43 AM, Avi Kivity a...@redhat.com wrote:
On 07/02/2012 12:30 PM, Jan Kiszka wrote:
On 2012-07-02 11:18, Michael S. Tsirkin wrote:
I've been thinking hard about
On Mon, Jul 2, 2012 at 9:43 AM, Avi Kivity a...@redhat.com wrote:
On 07/02/2012 12:30 PM, Jan Kiszka wrote:
On 2012-07-02 11:18, Michael S. Tsirkin wrote:
I've been thinking hard about Jan's patches for device
assignment. Basically while I thought it makes sense
to make all devices:
On Mon, Jul 2, 2012 at 6:06 PM, Eduardo Habkost ehabk...@redhat.com wrote:
Cc: Blue Swirl blauwir...@gmail.com
Signed-off-by: Eduardo Habkost ehabk...@redhat.com
Acked-by: Blue Swirl blauwir...@gmail.com
---
exec.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
On Mon, Jul 2, 2012 at 6:06 PM, Eduardo Habkost ehabk...@redhat.com wrote:
Cc: Blue Swirl blauwir...@gmail.com
Signed-off-by: Eduardo Habkost ehabk...@redhat.com
Acked-by: Blue Swirl blauwir...@gmail.com
---
exec.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions
On Sun, Jun 17, 2012 at 11:51 AM, Avi Kivity a...@redhat.com wrote:
On 06/17/2012 02:47 PM, Jan Kiszka wrote:
I think this should rather go into generic code.
To be honest, I put this in kvm-specific code because vl.c doesn't have
TARGET_PAGE_ALIGN. Maybe we should have machine-page_size or
On Sun, Jun 17, 2012 at 12:54 PM, Avi Kivity a...@redhat.com wrote:
On 06/17/2012 03:43 PM, Blue Swirl wrote:
On Sun, Jun 17, 2012 at 11:51 AM, Avi Kivity a...@redhat.com wrote:
On 06/17/2012 02:47 PM, Jan Kiszka wrote:
I think this should rather go into generic code.
To be honest, I put
...@suse.de
Cc: David Gibson da...@gibson.dropbear.id.au
Cc: qemu-ppc qemu-...@nongnu.org
Cc: Blue Swirl blauwir...@gmail.com
Cc: Guan Xuetao g...@mprc.pku.edu.cn
Cc: Max Filippov jcmvb...@gmail.com
Cc: Avi Kivity a...@redhat.com
Cc: Marcelo Tosatti mtosa...@redhat.com
Cc: Jan Kiszka jan.kis
On Mon, Mar 5, 2012 at 15:17, Avi Kivity a...@redhat.com wrote:
On 03/05/2012 05:15 PM, Anthony Liguori wrote:
The other alternative is to s/target_phys_addr_t/uint64_t/ in the memory
API. I think 32-on-32 is quite rare these days, so it wouldn't be much
of a performance issue.
I think
On Mon, Feb 13, 2012 at 10:16, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-02-11 16:25, Blue Swirl wrote:
On Fri, Feb 10, 2012 at 18:31, Jan Kiszka jan.kis...@siemens.com wrote:
This enables acceleration for MMIO-based TPR registers accesses of
32-bit Windows guest systems. It is mostly
On Fri, Feb 10, 2012 at 18:31, Jan Kiszka jan.kis...@siemens.com wrote:
As we have thread-local cpu_single_env now and KVM uses exactly one
thread per VCPU, we can drop the cpu_single_env updates from the loop
and initialize this variable only once during setup.
I don't think this is correct.
On Sat, Feb 11, 2012 at 10:06, Jan Kiszka jan.kis...@web.de wrote:
On 2012-02-11 11:02, Blue Swirl wrote:
On Fri, Feb 10, 2012 at 18:31, Jan Kiszka jan.kis...@siemens.com wrote:
As we have thread-local cpu_single_env now and KVM uses exactly one
thread per VCPU, we can drop the cpu_single_env
On Sat, Feb 11, 2012 at 12:43, Jan Kiszka jan.kis...@web.de wrote:
On 2012-02-11 12:49, Andreas Färber wrote:
Am 11.02.2012 12:25, schrieb Blue Swirl:
I think using cpu_single_env is an indication of a problem, like poor
code, layering violation or poor API (vmport). What is your use case?
I
On Sat, Feb 11, 2012 at 14:00, Jan Kiszka jan.kis...@web.de wrote:
On 2012-02-11 14:54, Blue Swirl wrote:
On Sat, Feb 11, 2012 at 12:43, Jan Kiszka jan.kis...@web.de wrote:
On 2012-02-11 12:49, Andreas Färber wrote:
Am 11.02.2012 12:25, schrieb Blue Swirl:
I think using cpu_single_env
On Fri, Feb 10, 2012 at 18:31, Jan Kiszka jan.kis...@siemens.com wrote:
In order to perform critical manipulations on the VM state in the
context of a VCPU, specifically code patching, stopping and resuming of
all VCPUs may be necessary. resume_all_vcpus is already compatible, now
enable
On Fri, Feb 10, 2012 at 18:31, Jan Kiszka jan.kis...@siemens.com wrote:
This will allow the APIC core to file a TPR access report. Depending on
the accelerator and kernel irqchip mode, it will either be delivered
right away or queued for later reporting.
In TCG mode, we can restart the
On Fri, Feb 10, 2012 at 18:31, Jan Kiszka jan.kis...@siemens.com wrote:
This enables acceleration for MMIO-based TPR registers accesses of
32-bit Windows guest systems. It is mostly useful with KVM enabled,
either on older Intel CPUs (without flexpriority feature, can also be
manually disabled
On Fri, Dec 9, 2011 at 07:52, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-12-09 08:45, Jan Kiszka wrote:
On 2011-12-08 22:16, Blue Swirl wrote:
On Thu, Dec 8, 2011 at 11:52, Jan Kiszka jan.kis...@siemens.com wrote:
This introduces the alternative APIC backend which makes use of KVM's
On Sat, Dec 10, 2011 at 12:28, Jan Kiszka jan.kis...@web.de wrote:
From: Jan Kiszka jan.kis...@siemens.com
When the HPET enters legacy mode, the IRQ output of the PIT is
suppressed and replaced by the HPET timer 0. But the current code to
emulate this was broken in many ways. It reset the PIT
On Sat, Dec 10, 2011 at 12:28, Jan Kiszka jan.kis...@web.de wrote:
This is a small preparatory series to allow the introduction of the KVM
in-kernel PIT. Of course, it is also a fix for the various bugs in the
related PIT/HPET code. See patches for details.
Jan Kiszka (2):
hpet:
On Sat, Dec 10, 2011 at 15:51, Jan Kiszka jan.kis...@web.de wrote:
On 2011-12-10 16:49, Blue Swirl wrote:
+ISADevice *pit_init(int base, qemu_irq irq)
Please retain this function in pc.h, or even better, introduce i8254.h.
No concerns about i8254.h, but this function does not qualify
On Sat, Dec 10, 2011 at 15:58, Jan Kiszka jan.kis...@web.de wrote:
On 2011-12-10 16:40, Blue Swirl wrote:
On Fri, Dec 9, 2011 at 07:52, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-12-09 08:45, Jan Kiszka wrote:
On 2011-12-08 22:16, Blue Swirl wrote:
On Thu, Dec 8, 2011 at 11:52, Jan
On Sat, Dec 10, 2011 at 16:03, Jan Kiszka jan.kis...@web.de wrote:
On 2011-12-10 16:54, Blue Swirl wrote:
On Sat, Dec 10, 2011 at 15:51, Jan Kiszka jan.kis...@web.de wrote:
On 2011-12-10 16:49, Blue Swirl wrote:
+ISADevice *pit_init(int base, qemu_irq irq)
Please retain this function
On Sat, Dec 10, 2011 at 16:29, Jan Kiszka jan.kis...@web.de wrote:
On 2011-12-10 17:26, Blue Swirl wrote:
On Sat, Dec 10, 2011 at 16:03, Jan Kiszka jan.kis...@web.de wrote:
On 2011-12-10 16:54, Blue Swirl wrote:
On Sat, Dec 10, 2011 at 15:51, Jan Kiszka jan.kis...@web.de wrote:
On 2011-12-10
On Thu, Dec 8, 2011 at 11:52, Jan Kiszka jan.kis...@siemens.com wrote:
This introduces the alternative APIC backend which makes use of KVM's
in-kernel device model. External NMI injection via LINT1 is emulated by
checking the current state of the in-kernel APIC, only injecting a NMI
into the
On Thu, Dec 8, 2011 at 11:52, Jan Kiszka jan.kis...@siemens.com wrote:
Changes in v4:
- rebased of current uq/master
- fixed stupid bugs that broke bisectability and user space irqchip mode
- integrated NMI-over-LINT1 injection logic
I had comments to one patch, others look fine.
Overall,
On Sun, Dec 4, 2011 at 16:35, Avi Kivity a...@redhat.com wrote:
On 12/04/2011 05:19 PM, Jan Kiszka wrote:
In the sense that kernel-apic is just an accelerated apic. From the
guest point of view, there's no difference, and that should be reflected
in the device model.
That was my goal
On Wed, Aug 24, 2011 at 9:38 PM, Alexander Graf ag...@suse.de wrote:
On LinuxCon I had a nice chat with Linus on what he thinks kvm-tool
would be doing and what he expects from it. Basically he wants a
small and simple tool he and other developers can run to try out and
see if the kernel they
On Tue, Aug 23, 2011 at 10:16 PM, Alexander Graf ag...@suse.de wrote:
On LinuxCon I had a nice chat with Linus on what he thinks kvm-tool
would be doing and what he expects from it. Basically he wants a
small and simple tool he and other developers can run to try out and
see if the kernel they
On Mon, Jul 25, 2011 at 1:09 PM, Avi Kivity a...@redhat.com wrote:
On 07/25/2011 01:04 PM, Alexander Graf wrote:
On 25.07.2011, at 12:02, Avi Kivity wrote:
On 07/25/2011 12:56 PM, Alexander Graf wrote:
That argument can be used to block any change. You'll get used to
it in
On Mon, Jul 25, 2011 at 3:21 PM, Anthony Liguori anth...@codemonkey.ws wrote:
On 07/25/2011 07:18 AM, Avi Kivity wrote:
On 07/25/2011 03:11 PM, Anthony Liguori wrote:
On 07/25/2011 03:51 AM, Avi Kivity wrote:
qemu_malloc() is type-unsafe as it returns a void pointer. Introduce
QEMU_NEW()
On Mon, Jul 25, 2011 at 5:51 PM, Paolo Bonzini pbonz...@redhat.com wrote:
On 07/25/2011 04:23 PM, Blue Swirl wrote:
Yes. We can just make qemu_malloc use g_malloc.
It would be also possible to make g_malloc() use qemu_malloc(). That
way we could keep the tracepoints which would lose
1 - 100 of 261 matches
Mail list logo
