On Sun, Feb 3, 2013 at 2:10 PM, Pandarathil, Vijaymohan R
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 device encounters an err
On Sun, Feb 3, 2013 at 2:10 PM, Pandarathil, Vijaymohan R
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
>
> - When the device
On Tue, Jan 29, 2013 at 1:50 PM, Jason Wang wrote:
> On 01/26/2013 03:13 AM, Blue Swirl wrote:
>> On Fri, Jan 25, 2013 at 10:35 AM, Jason Wang wrote:
>>> This patch introduce a new bit - enabled in TAPState which tracks whether a
>>> specific queue/fd is enabled. T
On Fri, Jan 25, 2013 at 10:35 AM, Jason Wang 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 calls
> platform
>
On Wed, Jan 9, 2013 at 6:26 AM, Pandarathil, Vijaymohan R
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 encounters an error, th
On Fri, Jan 4, 2013 at 3:37 PM, Eduardo Habkost 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
> kvm_check_feature
On Fri, Jan 4, 2013 at 2:52 PM, Eduardo Habkost 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
> fb92045843). It doesn't mak
On Fri, Jan 4, 2013 at 2:52 PM, Eduardo Habkost 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 variable (that'
On Fri, Jan 4, 2013 at 5:12 AM, Jason Wang wrote:
> On 12/29/2012 01:52 AM, Blue Swirl wrote:
>> On Fri, Dec 28, 2012 at 10:32 AM, Jason Wang wrote:
>>> This patch implements both userspace and vhost support for multiple queue
>>> virtio-net (VIRTIO_NET_F_MQ). Thi
On Fri, Dec 28, 2012 at 10:31 AM, Jason Wang 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 and place their
On Fri, Dec 28, 2012 at 10:32 AM, Jason Wang 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
> ---
> hw/virtio-net.c | 318
> +
On Fri, Nov 2, 2012 at 5:38 AM, Xudong Hao wrote:
> Enable 64 bits bar emulation.
>
> Signed-off-by: Xudong Hao
> ---
> hw/kvm/pci-assign.c | 18 --
> 1 files changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/hw/kvm/pci-assign.c b/hw/kvm/pci-assign.c
> index 05b93d9..f
Pass around CPUState instead of using global cpu_single_env.
Signed-off-by: Blue Swirl
---
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
--- a/target-i386/kvm.c
On Thu, Oct 18, 2012 at 12:33 PM, Avi Kivity 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 Wed, Oct 10, 2012 at 3:07 PM, Peter Maydell wrote:
> From: Christoffer Dall
>
> Add basic support for KVM on ARM architecture.
>
> Signed-off-by: Christoffer Dall
> [PMM: Minor tweaks and code cleanup, switch to ONE_REG]
> Signed-off-by: Peter Maydell
> ---
> hw/arm_pic.c | 28
On Tue, Oct 9, 2012 at 5:04 PM, Vasilis Liaskovitis
wrote:
> Hi,
>
> sorry for the delayed answer.
>
> On Sat, Sep 29, 2012 at 11:13:04AM +0000, Blue Swirl wrote:
>> >
>> > The "-dimm" option is supposed to specify the dimm/memory layout, and not
&g
On Fri, Oct 5, 2012 at 5:33 PM, Alex Williamson
wrote:
> On Fri, 2012-10-05 at 17:22 +0000, Blue Swirl wrote:
>> On Fri, Oct 5, 2012 at 5:11 PM, Alex Williamson
>> wrote:
>> > On Fri, 2012-10-05 at 16:54 +, Blue Swirl wrote:
>> >> On Wed, Sep 26, 2012 at 5
On Fri, Oct 5, 2012 at 5:11 PM, Alex Williamson
wrote:
> On Fri, 2012-10-05 at 16:54 +0000, Blue Swirl wrote:
>> On Wed, Sep 26, 2012 at 5:19 PM, Alex Williamson
>> wrote:
>> > +
>> > +typedef struct QEMU_PACKED VFIOIRQSetFD {
>> > +struct
On Mon, Oct 1, 2012 at 4:20 PM, Anthony Liguori wrote:
> Jan Kiszka 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 support turns out to be unavailable at
>>
On Mon, Sep 24, 2012 at 3:27 PM, Vasilis Liaskovitis
wrote:
> On Sat, Sep 22, 2012 at 02:15:28PM +0000, Blue Swirl wrote:
>> > +
>> > +/* Function to configure memory offsets of hotpluggable dimms */
>> > +
>> > +target_phys_addr_
On Mon, Sep 24, 2012 at 10:42 AM, Vasilis Liaskovitis
wrote:
> On Sat, Sep 22, 2012 at 01:46:57PM +0000, Blue Swirl wrote:
>> On Fri, Sep 21, 2012 at 11:17 AM, Vasilis Liaskovitis
>> wrote:
>> > Example:
>> > "-dimm id=dimm0,size=512M,node=0,populated=of
On Fri, Sep 21, 2012 at 11:17 AM, Vasilis Liaskovitis
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 id=name,size=sz,node=pxm,populated=on|off"
>
> T
On Fri, Sep 21, 2012 at 11:17 AM, Vasilis Liaskovitis
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, otherwise its physical address will b
On Fri, Sep 21, 2012 at 11:17 AM, Vasilis Liaskovitis
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 from these registers.
>
> An ACPI ho
On Fri, Sep 21, 2012 at 11:17 AM, Vasilis Liaskovitis
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 dimm,base=0,id=dimm0,size=512M,node=0,populated=off
That wou
On Sat, Sep 22, 2012 at 12:13 AM, Don Slutz 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 for missing bra
On Thu, Sep 20, 2012 at 5:43 AM, Gerd Hoffmann 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 bu
On Tue, Sep 18, 2012 at 9:51 AM, Gerd Hoffmann 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
> Signed-off-by: Gerd Hoffmann
> ---
> hw/vga-pci.c |
On Sat, Sep 8, 2012 at 12:13 PM, Alexander Graf wrote:
>
>
> On 08.09.2012, at 12:16, Blue Swirl wrote:
>
>> On Sat, Sep 8, 2012 at 9:28 AM, Alexander Graf wrote:
>>>
>>>
>>> On 08.09.2012, at 10:06, Blue Swirl wrote:
>>>
>>>>
On Sat, Sep 8, 2012 at 9:28 AM, Alexander Graf wrote:
>
>
> On 08.09.2012, at 10:06, Blue Swirl wrote:
>
>> On Thu, Sep 6, 2012 at 8:44 AM, Avi Kivity wrote:
>>> On 09/05/2012 10:04 PM, Blue Swirl wrote:
>>>>
>>>> Reinventing a disass
On Thu, Sep 6, 2012 at 8:44 AM, Avi Kivity 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 instructi
On Thu, Sep 6, 2012 at 4:06 PM, Andreas Färber 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
>>> in qe
On Thu, Sep 6, 2012 at 3:42 AM, Alexander Graf wrote:
>
> On 05.09.2012, at 15:38, Blue Swirl wrote:
>
>> On Wed, Sep 5, 2012 at 7:22 PM, Anthony Liguori
>> wrote:
>>> Blue Swirl writes:
>>>
>>>> On Wed, Sep 5, 2012 at 3:41 PM, Ant
On Wed, Sep 5, 2012 at 7:24 PM, Eric Blake 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 c
On Wed, Sep 5, 2012 at 7:22 PM, Anthony Liguori wrote:
> Blue Swirl writes:
>
>> On Wed, Sep 5, 2012 at 3:41 PM, Anthony Liguori
>> wrote:
>>> Avi Kivity writes:
>>>
>>>> On 09/05/2012 12:00 AM, Anthony Liguori wrote:
>>>>>&
On Tue, Sep 4, 2012 at 9:28 PM, Michael S. Tsirkin wrote:
> On Tue, Sep 04, 2012 at 07:27:32PM +0000, Blue Swirl wrote:
>> On Tue, Sep 4, 2012 at 8:32 AM, Avi Kivity wrote:
>> > On 09/03/2012 10:32 PM, Blue Swirl wrote:
>> >> On Mon, Sep 3, 2012 at 4:14 PM, Avi
On Wed, Sep 5, 2012 at 3:41 PM, Anthony Liguori wrote:
> Avi Kivity 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 we've
asked folks
On Tue, Sep 4, 2012 at 8:32 AM, Avi Kivity wrote:
> On 09/03/2012 10:32 PM, Blue Swirl wrote:
>> On Mon, Sep 3, 2012 at 4:14 PM, Avi Kivity wrote:
>>> On 08/29/2012 11:27 AM, Markus Armbruster wrote:
>>>>
>>>> I don't see a point in ma
On Mon, Sep 3, 2012 at 4:14 PM, Avi Kivity 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 avoiding.
>
>
On Tue, Aug 28, 2012 at 9:51 PM, Anthony Liguori wrote:
> Blue Swirl writes:
>
>> On Tue, Aug 28, 2012 at 7:31 PM, Anthony Liguori
>> wrote:
>>> Blue Swirl writes:
>>>
>>>> On Tue, Aug 28, 2012 at 5:28 PM, Michael S. Tsirkin
>>>>
On Tue, Aug 28, 2012 at 7:31 PM, Anthony Liguori wrote:
> Blue Swirl writes:
>
>> On Tue, Aug 28, 2012 at 5:28 PM, Michael S. Tsirkin wrote:
>>> On Tue, Aug 28, 2012 at 05:01:55PM +, Blue Swirl wrote:
>>>> On Tue, Aug 28, 2012 at 7:35 AM, Michael Tokarev
On Tue, Aug 28, 2012 at 5:28 PM, Michael S. Tsirkin wrote:
> On Tue, Aug 28, 2012 at 05:01:55PM +0000, Blue Swirl wrote:
>> On Tue, Aug 28, 2012 at 7:35 AM, Michael Tokarev wrote:
>> > On 27.08.2012 22:56, Blue Swirl wrote:
>> > []
>> >>> +s
On Tue, Aug 28, 2012 at 5:22 PM, Michael S. Tsirkin wrote:
> On Tue, Aug 28, 2012 at 05:05:25PM +0000, Blue Swirl wrote:
>> > +static bool _kvm_pv_eoi_disabled;
>>
>> NACK. I find your lack of compliance disturbing.
>
> Compliance with what? Could you please add
On Tue, Aug 28, 2012 at 1:22 PM, Michael S. Tsirkin 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.
> Enable for 1.1
>
On Tue, Aug 28, 2012 at 7:35 AM, Michael Tokarev 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
On Mon, Aug 27, 2012 at 7:24 PM, Michael S. Tsirkin wrote:
> On Mon, Aug 27, 2012 at 07:12:27PM +0000, Blue Swirl wrote:
>> On Mon, Aug 27, 2012 at 7:06 PM, Michael S. Tsirkin wrote:
>> > On Mon, Aug 27, 2012 at 06:58:29PM +, Blue Swirl wrote:
>> >> On Mon, Aug
On Mon, Aug 27, 2012 at 7:06 PM, Michael S. Tsirkin wrote:
> On Mon, Aug 27, 2012 at 06:58:29PM +0000, Blue Swirl wrote:
>> On Mon, Aug 27, 2012 at 12:20 PM, Michael S. Tsirkin wrote:
>> > In preparation for adding PV EOI support, disable PV EOI by default for
>> >
On Mon, Aug 27, 2012 at 7:01 PM, Michael S. Tsirkin wrote:
> On Mon, Aug 27, 2012 at 06:56:38PM +0000, Blue Swirl wrote:
>> > +static uint32_t slow_bar_readb(void *opaque, target_phys_addr_t addr)
>> > +{
>> > +AssignedDevRegion *d = opaque;
>> > +
On Mon, Aug 27, 2012 at 12:20 PM, Michael S. Tsirkin 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.
> Enable for 1.1
On Wed, Aug 22, 2012 at 7:30 AM, Wen Congyang wrote:
> At 08/09/2012 03:01 AM, Blue Swirl Wrote:
>> On Wed, Aug 8, 2012 at 2:47 AM, Wen Congyang 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
oifd support I've proposed
>>> > for KVM enable 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 vers
On Mon, Aug 13, 2012 at 8:35 AM, Nicholas A. Bellinger
wrote:
> From: Stefan Hajnoczi
>
> 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 id=vhost-scsi0,wwpn=...,tpgt=123
>
> The virtio-scsi emulated device wi
On Mon, Aug 13, 2012 at 8:35 AM, Nicholas A. Bellinger
wrote:
> From: Nicholas Bellinger
>
> This is required to get past the following assert with:
>
> commit 1523ed9e1d46b0b54540049d491475ccac7e6421
> Author: Jan Kiszka
> Date: Thu May 17 10:32:39 2012 -0300
>
> virtio/vhost: Add support
On Thu, Aug 9, 2012 at 7:28 AM, liu ping fan wrote:
> On Thu, Aug 9, 2012 at 3:17 AM, Blue Swirl wrote:
>> On Wed, Aug 8, 2012 at 6:25 AM, Liu Ping Fan wrote:
>>> From: Liu Ping Fan
>>>
>>> Using mem_map_lock to protect among updaters. So we can get the
On Wed, Aug 8, 2012 at 7:34 PM, Peter Maydell wrote:
> On 8 August 2012 20:16, Blue Swirl wrote:
>> On Wed, Aug 8, 2012 at 8:17 AM, Cornelia Huck
>> wrote:
>>> On Tue, 7 Aug 2012 21:00:59 +
>>> Blue Swirl wrote:
>>>> Please use more descr
On Wed, Aug 8, 2012 at 6:25 AM, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> 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 be reclaimed
> after the prev PhysMap no
On Wed, Aug 8, 2012 at 6:25 AM, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> 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 achieve the atomic.
>
> Signed-off-by: Liu Ping
On Wed, Aug 8, 2012 at 6:25 AM, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> 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
> ---
> exec.c |3 +++
> memory.c | 22 +++
On Wed, Aug 8, 2012 at 8:17 AM, Cornelia Huck wrote:
> On Tue, 7 Aug 2012 21:00:59 +
> Blue Swirl wrote:
>
>
>> > diff --git a/hw/s390x/css.c b/hw/s390x/css.c
>> > new file mode 100644
>> > index 000..7941c44
>> > --- /dev/nu
On Wed, Aug 8, 2012 at 8:28 AM, Cornelia Huck wrote:
> On Tue, 7 Aug 2012 20:47:22 +
> Blue Swirl wrote:
>
>
>> > diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
>> > new file mode 100644
>> > index 000..8a90c3a
>> > --- /dev/nu
On Wed, Aug 8, 2012 at 2:47 AM, Wen Congyang 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 according to pan
On Tue, Aug 7, 2012 at 2:52 PM, Cornelia Huck 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
> ---
> hw/s390x/Makefile.objs
On Tue, Aug 7, 2012 at 2:52 PM, Cornelia Huck 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: Cornelia Huck
> ---
>
Thanks, applied.
On Tue, Jul 17, 2012 at 4:31 AM, Chegu Vinod 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.
>
> Changes since v2:
>
On Mon, Jul 16, 2012 at 2:25 PM, Paolo Bonzini 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 large SCSI hard
On Fri, Jul 13, 2012 at 5:49 PM, Vasilis Liaskovitis
wrote:
> On Thu, Jul 12, 2012 at 08:04:56PM +0000, Blue Swirl wrote:
>> On Wed, Jul 11, 2012 at 10:31 AM, Vasilis Liaskovitis
>> wrote:
>> > This is v2 of the ACPI memory hotplug prototype for x86_64 target.
>>
&
On Wed, Jul 11, 2012 at 10:31 AM, Vasilis Liaskovitis
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
limited to x86 only. It would be nic
On Wed, Jul 11, 2012 at 10:31 AM, Vasilis Liaskovitis
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 to main system memory as a
> sub_r
On Wed, Jul 11, 2012 at 10:31 AM, Vasilis Liaskovitis
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 proximity. The new info is appended
On Wed, Jul 4, 2012 at 8:05 AM, Avi Kivity wrote:
> On 07/03/2012 10:06 PM, Blue Swirl wrote:
>> On Mon, Jul 2, 2012 at 9:43 AM, Avi Kivity wrote:
>>> On 07/02/2012 12:30 PM, Jan Kiszka wrote:
>>>> On 2012-07-02 11:18, Michael S. Tsirkin wrote:
>>>>>
On Mon, Jul 2, 2012 at 6:06 PM, Eduardo Habkost wrote:
> Cc: Blue Swirl
> Signed-off-by: Eduardo Habkost
Acked-by: Blue Swirl
> ---
> exec.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/exec.c b/exec.c
> index c8bfd27
On Mon, Jul 2, 2012 at 6:06 PM, Eduardo Habkost wrote:
> Cc: Blue Swirl
> Signed-off-by: Eduardo Habkost
Acked-by: Blue Swirl
> ---
> exec.c |5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/exec.c b/exec.c
> index 8244d54..c8bfd
On Mon, Jul 2, 2012 at 9:43 AM, Avi Kivity 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: assignment an
On Sun, Jun 17, 2012 at 12:54 PM, Avi Kivity wrote:
> On 06/17/2012 03:43 PM, Blue Swirl wrote:
>> On Sun, Jun 17, 2012 at 11:51 AM, Avi Kivity wrote:
>>> On 06/17/2012 02:47 PM, Jan Kiszka wrote:
>>>>>>
>>>>>> I think this should rather go i
On Sun, Jun 17, 2012 at 11:51 AM, Avi Kivity 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
ling!) from:
> git://github.com/afaerber/qemu-cpu.git qom-cpu-common.v1
> https://github.com/afaerber/qemu-cpu/commits/qom-cpu-common.v1
>
> Regards,
> Andreas
>
> Cc: Anthony Liguori
> Cc: Paolo Bonzini
> Cc: Igor Mammedov
>
> Cc: Richard Henderson
> Cc: Peter
On Mon, Mar 5, 2012 at 15:17, Avi Kivity 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 thi
On Mon, Feb 13, 2012 at 10:16, Jan Kiszka wrote:
> On 2012-02-11 16:25, Blue Swirl wrote:
>> On Fri, Feb 10, 2012 at 18:31, Jan Kiszka wrote:
>>> This enables acceleration for MMIO-based TPR registers accesses of
>>> 32-bit Windows guest systems. It is mostly useful w
On Fri, Feb 10, 2012 at 18:31, Jan Kiszka 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 for testing) or an
On Fri, Feb 10, 2012 at 18:31, Jan Kiszka 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 triggering instruction a
On Sat, Feb 11, 2012 at 14:18, Jan Kiszka wrote:
> On 2012-02-11 15:11, Blue Swirl wrote:
>> On Sat, Feb 11, 2012 at 14:00, Jan Kiszka wrote:
>>> On 2012-02-11 14:54, Blue Swirl wrote:
>>>> On Sat, Feb 11, 2012 at 12:43, Jan Kiszka wrote:
>>>>&
On Fri, Feb 10, 2012 at 18:31, Jan Kiszka 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 pause_all_vcpus for this
On Sat, Feb 11, 2012 at 14:00, Jan Kiszka wrote:
> On 2012-02-11 14:54, Blue Swirl wrote:
>> On Sat, Feb 11, 2012 at 12:43, Jan Kiszka wrote:
>>> On 2012-02-11 12:49, Andreas Färber wrote:
>>>> Am 11.02.2012 12:25, schrieb Blue Swirl:
>>>>> I thi
On Sat, Feb 11, 2012 at 12:43, Jan Kiszka 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). Wha
On Sat, Feb 11, 2012 at 10:06, Jan Kiszka wrote:
> On 2012-02-11 11:02, Blue Swirl wrote:
>> On Fri, Feb 10, 2012 at 18:31, Jan Kiszka 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 up
On Fri, Feb 10, 2012 at 18:31, Jan Kiszka 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. Maybe you missed the
On Sat, Dec 10, 2011 at 16:29, Jan Kiszka wrote:
> On 2011-12-10 17:26, Blue Swirl wrote:
>> On Sat, Dec 10, 2011 at 16:03, Jan Kiszka wrote:
>>> On 2011-12-10 16:54, Blue Swirl wrote:
>>>> On Sat, Dec 10, 2011 at 15:51, Jan Kiszka wrote:
>>>&
On Sat, Dec 10, 2011 at 16:03, Jan Kiszka wrote:
> On 2011-12-10 16:54, Blue Swirl wrote:
>> On Sat, Dec 10, 2011 at 15:51, Jan Kiszka wrote:
>>> On 2011-12-10 16:49, Blue Swirl wrote:
>>>>>
>>>>> +ISADevice *pit_init(int base, qemu_irq irq)
>&g
On Sat, Dec 10, 2011 at 15:58, Jan Kiszka wrote:
> On 2011-12-10 16:40, Blue Swirl wrote:
>> On Fri, Dec 9, 2011 at 07:52, Jan Kiszka wrote:
>>> On 2011-12-09 08:45, Jan Kiszka wrote:
>>>> On 2011-12-08 22:16, Blue Swirl wrote:
>>>>> On Thu, Dec 8,
On Sat, Dec 10, 2011 at 15:51, Jan Kiszka 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 th
On Sat, Dec 10, 2011 at 12:28, Jan Kiszka 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: Save/restore cached RTC
On Sat, Dec 10, 2011 at 12:28, Jan Kiszka wrote:
> From: Jan Kiszka
>
> 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 state after
> re-enabling, it work
On Fri, Dec 9, 2011 at 07:52, Jan Kiszka 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 wrote:
>>>> This introduces the alternative APIC backend which makes use of KVM's
&g
On Thu, Dec 8, 2011 at 11:52, Jan Kiszka 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, string based subtype
On Thu, Dec 8, 2011 at 11:52, Jan Kiszka 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 VCPU if LINT1 is unm
On Sun, Dec 4, 2011 at 16:35, Avi Kivity 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 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 just built
On Tue, Aug 23, 2011 at 10:16 PM, Alexander Graf 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 just buil
On Mon, Jul 25, 2011 at 5:51 PM, Paolo Bonzini 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 trac
On Mon, Jul 25, 2011 at 3:21 PM, Anthony Liguori 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()
1 - 100 of 270 matches
Mail list logo
