04.05.2014 05:45, Fam Zheng wrote:
On Fri, 05/02 15:40, Michael Tokarev wrote:
Current Makefile system allows using foo.o-cflags variables to store
object-specific CFLAGS. Convert some usages of old syntax
(using QEMU_CFLAGS += construct) to the new syntax.
Thanks for doing this! Two minor
On 2014-04-29 11:46, Gerd Hoffmann wrote:
From: Cole Robinson crobi...@redhat.com
Try kicking off a rhel5 text install over serial, the text menu navigation
is all messed up, and some of the kernel boot messages are randomly
corrupted.
Drop use of a pty and just use vte infrastructure for
From: Gaowei gao.gao...@huawei.com
In Xen platform, after using upstream qemu, the all of pci devices will show
hotplug in the windows guest. In this situation, the windows guest may occur
blue screen when VM' user click the icon of VGA card for trying unplug VGA card.
However, we don't hope VM's
Hi, all
Cc'ing Michael S. Tsirkin for adding his two files: acpi_extract.py/
acpi_extract_preprocess.py.
Best regards,
-Gonglei
-Original Message-
From: Gonglei (Arei)
Sent: Sunday, May 04, 2014 5:25 PM
To: qemu-devel@nongnu.org; xen-de...@lists.xen.org
Cc:
On Thu, 05/01 16:54, Stefan Hajnoczi wrote:
Implement .bdrv_detach/attach_aio_context() interfaces to propagate
detach/attach to BDRVVmdkState-extents[].file. The block layer takes
care of -file and -backing_hd but doesn't know about our extents
BlockDriverStates, which is also part of the
On 2014-04-30 20:23, Kevin Wolf wrote:
Use the same function as bdrv_open() for determining what the right
flags for bs-file are. Without doing this, a reopen means that
bs-file loses BDRV_O_CACHE_WB or BDRV_O_UNMAP if bs doesn't have it as
well.
Signed-off-by: Kevin Wolf kw...@redhat.com
On Thu, 05/01 16:54, Stefan Hajnoczi wrote:
Implement .bdrv_detach/attach_aio_context() interfaces to propagate
detach/attach to BDRVVmdkState-extents[].file. The block layer takes
care of -file and -backing_hd but doesn't know about our extents
BlockDriverStates, which is also part of the
On 04/29/2014 07:40 PM, Alexander Graf wrote:
On 29.04.14 05:17, Alexey Kardashevskiy wrote:
Recently a check for maximum supported MSIX vectors number has been
added. However the check always assumed that MSIX is the only case
and failed on devices which have MSI but do not have MSIX such
On Thu, 05/01 16:54, Stefan Hajnoczi wrote:
The curl block driver uses fd handlers, timers, and BHs. The fd
handlers and timers are managed on behalf of libcurl, which controls
them using callback functions that the block driver implements.
The simplest way to implement
On Thu, 05/01 16:54, Stefan Hajnoczi wrote:
@@ -152,51 +132,53 @@ static void do_get_id_cmd(VirtIOBlockDataPlane *s,
complete_request_early(s, elem, inhdr, VIRTIO_BLK_S_OK);
}
-static int do_rdwr_cmd(VirtIOBlockDataPlane *s, bool read,
- struct iovec *iov,
Am 04.05.2014 um 12:28 schrieb Alexey Kardashevskiy a...@ozlabs.ru:
On 04/29/2014 07:40 PM, Alexander Graf wrote:
On 29.04.14 05:17, Alexey Kardashevskiy wrote:
Recently a check for maximum supported MSIX vectors number has been
added. However the check always assumed that MSIX is the
On 03/14/2014 03:18 PM, Alexey Kardashevskiy wrote:
This initial problem came form libvirt - it does not preserve
the device order when running QEMU. So it is easy to get source QEMU with:
-device spapr-vscsi,id=scsi1,reg=0x2000 -device
spapr-vscsi,id=scsi0,reg=0x3000
and destination QEMU
At the moment XICS does not support interrupts reuse so sPAPR PHB
implements this. sPAPRPHBState holds array of 32 spapr_pci_msi to
describe PCI config address, first MSI and number of MSIs. Once
allocated for a device, QEMU tries reusing this config until the number
of MSIs changes.
Existing
Add support for the TIMER block on the EFM32GG.
Signed-off-by: Rabin Vincent ra...@rab.in
---
hw/timer/Makefile.objs | 1 +
hw/timer/efm32-timer.c | 204 +
2 files changed, 205 insertions(+)
create mode 100644 hw/timer/efm32-timer.c
diff --git
Add support for the UART block on the EFM32GG.
Signed-off-by: Rabin Vincent ra...@rab.in
---
hw/char/Makefile.objs | 1 +
hw/char/efm32-uart.c | 217 ++
2 files changed, 218 insertions(+)
create mode 100644 hw/char/efm32-uart.c
diff --git
Add support for the EFM32GG990 MCU and its development board
EFM32GG-DK3750. This is a Cortex-M3 platform supported
by mainline Linux.
Signed-off-by: Rabin Vincent ra...@rab.in
---
default-configs/arm-softmmu.mak | 1 +
hw/arm/Makefile.objs| 1 +
hw/arm/efm32.c |
On 05/04/2014 04:35 AM, Jan Kiszka wrote:
On 2014-04-29 11:46, Gerd Hoffmann wrote:
From: Cole Robinson crobi...@redhat.com
Try kicking off a rhel5 text install over serial, the text menu navigation
is all messed up, and some of the kernel boot messages are randomly
corrupted.
Drop use of
On 2014-05-04 19:07, Cole Robinson wrote:
On 05/04/2014 04:35 AM, Jan Kiszka wrote:
On 2014-04-29 11:46, Gerd Hoffmann wrote:
From: Cole Robinson crobi...@redhat.com
Try kicking off a rhel5 text install over serial, the text menu navigation
is all messed up, and some of the kernel boot
On Thu, May 01, 2014 at 03:54:57PM +0100, Peter Maydell wrote:
Nothing earthshattering here, but it does have the patch which
actually lets us boot an emulated AArch64 CPU on a board...
Hi Peter,
I have real aarch64 hardware, and I'm trying to find a version of
qemu-system-aarch64 which will
On 2014-05-04 20:25, Jan Kiszka wrote:
On 2014-05-04 19:07, Cole Robinson wrote:
On 05/04/2014 04:35 AM, Jan Kiszka wrote:
On 2014-04-29 11:46, Gerd Hoffmann wrote:
From: Cole Robinson crobi...@redhat.com
Try kicking off a rhel5 text install over serial, the text menu navigation
is all
On 4 May 2014 19:30, Richard W.M. Jones rjo...@redhat.com wrote:
I have real aarch64 hardware, and I'm trying to find a version of
qemu-system-aarch64 which will boot a KVM guest in some form.
Upstream qemu fails with a bizarre thread-local storage problem (yes,
I've patched glibc to fix the
On Sun, May 04, 2014 at 07:48:38PM +0100, Peter Maydell wrote:
On 4 May 2014 19:30, Richard W.M. Jones rjo...@redhat.com wrote:
I have real aarch64 hardware, and I'm trying to find a version of
qemu-system-aarch64 which will boot a KVM guest in some form.
Upstream qemu fails with a
I think this problem comes from my environment adding -fPIE.
In any case, without that flag it doesn't crash in qemu (it
kernel panics instead ..)
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog:
On 4 May 2014 19:58, Richard W.M. Jones rjo...@redhat.com wrote:
On Sun, May 04, 2014 at 07:48:38PM +0100, Peter Maydell wrote:
On 4 May 2014 19:30, Richard W.M. Jones rjo...@redhat.com wrote:
I have real aarch64 hardware, and I'm trying to find a version of
qemu-system-aarch64 which will
On Sun, May 04, 2014 at 08:36:20PM +0100, Peter Maydell wrote:
OK, so you have a kernel (possibly just kernel config) problem
here -- this means QEMU got EPERM trying to open /dev/kvm.
Yes for some reason it was 0600. I set it to 0666.
This isn't going to work for aarch64 at the moment
On 4 May 2014 20:45, Richard W.M. Jones rjo...@redhat.com wrote:
On Sun, May 04, 2014 at 08:36:20PM +0100, Peter Maydell wrote:
OK, so you have a kernel (possibly just kernel config) problem
here -- this means QEMU got EPERM trying to open /dev/kvm.
Yes for some reason it was 0600. I set it
On Fri, May 02, 2014 at 10:29:33PM +0200, Stefan Weil wrote:
This fixes a warning from the static code analysis (smatch).
Signed-off-by: Stefan Weil s...@weilnetz.de
---
hw/mips/mips_fulong2e.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/mips/mips_fulong2e.c
Il 04/05/2014 15:56, Alexey Kardashevskiy ha scritto:
On 03/14/2014 03:18 PM, Alexey Kardashevskiy wrote:
This initial problem came form libvirt - it does not preserve
the device order when running QEMU. So it is easy to get source QEMU with:
-device spapr-vscsi,id=scsi1,reg=0x2000 -device
On 02/05/14 22:26, Olivier Danet wrote:
On 29/04/2014 13:16, Gerd Hoffmann wrote:
Hi,
+[Q_KEY_CODE_META_R]= 122,
+[Q_KEY_CODE_COMPOSE] = 67,
};
This mapping does not look good on some details.
COPY, FIND and CUT does not match the standard :
Hi,
Am 04.05.2014 17:52, schrieb Rabin Vincent:
Add support for the EFM32GG990 MCU and its development board
EFM32GG-DK3750. This is a Cortex-M3 platform supported
by mainline Linux.
Signed-off-by: Rabin Vincent ra...@rab.in
---
default-configs/arm-softmmu.mak | 1 +
Hi Joe,
Sorry for the delay with this - have had quite a lot on recently. Just
to reiterate what I mentioned above, can you rebuild with pixman as a
git submodule and see if that makes a difference? Otherwise configure
may pick up a different (older) version of pixman on the system which
may have
On 05/05/2014 07:52 AM, Paolo Bonzini wrote:
Il 04/05/2014 15:56, Alexey Kardashevskiy ha scritto:
On 03/14/2014 03:18 PM, Alexey Kardashevskiy wrote:
This initial problem came form libvirt - it does not preserve
the device order when running QEMU. So it is easy to get source QEMU with:
On Thu, 04/10 10:47, Fam Zheng wrote:
v18: Address reviewing comments from Jeff and Eric. Rebased to current master.
Side by side diff from v17: http://bit.ly/1oO2Fvt
Ping?
Fam
[01/15] block: Add BlockOpType enum
Add Jeff's reviewed-by.
[02/15]
33 matches
Mail list logo
