On Fri, Apr 27, 2012 at 02:55:48PM -0700, Jordan Justen wrote:
> On Fri, Apr 27, 2012 at 11:47, Laszlo Ersek wrote:
> > This was how I interpreted our discussion with Jordan:
> >
> > L: Shouldn't qemu & OVMF agree on GPE0?
> > J: Why? Anyway, OVMF should be correct, because all ACPI registers are
Hello Jason,
On Sat, Apr 28, 2012 at 6:43 AM, Jason Baron wrote:
> On Tue, Apr 24, 2012 at 10:42:16AM +1200, Michael Kerrisk wrote:
>> Jason,
>>
>> On Thu, Mar 8, 2012 at 6:00 AM, Jason Baron wrote:
>> > Hi,
>> >
>> > The motivation for this change was that I was looking at a way for a
>> > qem
From: Zhi Yong Wu
Signed-off-by: Zhi Yong Wu
---
block/qcow2-cluster.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index a747a88..b048821 100644
--- a/block/qcow2-cluster.c
+++ b/block/qcow2-cluster.c
@@ -538,7 +538,6 @@
From: Zhi Yong Wu
Signed-off-by: Zhi Yong Wu
---
block/qcow2-refcount.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/block/qcow2-refcount.c b/block/qcow2-refcount.c
index 812c93c..443c021 100644
--- a/block/qcow2-refcount.c
+++ b/block/qcow2-refcount.c
@@ -367,7 +36
On Tue, Apr 24, 2012 at 20:32, Eduardo Habkost wrote:
> Signed-off-by: Eduardo Habkost
> ---
> vl.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/vl.c b/vl.c
> index 1e5e593..a4f4676 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -2279,7 +2279,7 @@ int main(int argc, ch
On Thu, Apr 26, 2012 at 13:43, Andreas Färber wrote:
> Am 17.04.2012 22:45, schrieb Blue Swirl:
>> On Mon, Apr 16, 2012 at 21:47, Anthony Liguori wrote:
>>> On 04/16/2012 04:24 PM, Peter Maydell wrote:
On 16 April 2012 18:42, Anthony Liguori wrote:
>
> On 04/16/2012 12:17 PM, P
On Fri, Apr 27, 2012 at 22:29, Andreas Färber wrote:
> From: Andreas Färber
>
> Commit b72210568ef0c0fb141a01cffb71a09c4efa0364 (slirp: clean up
> conflicts with system headers) enclosed TCPOLEN_MAXSEG with an #ifdef
> TCPOPT_EOL. This broke the build on illumos, which has TCPOPT_*
> but not TCPO
Public bug reported:
Hello! I have:
virtio_ioport_write: unexpected address 0x13 value 0x1
on config:
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin
QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 3072
-smp 1 -name nata_xp -uuid da607499-1
I forgot: guest os is Windows XP Pro SP3
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/990364
Title:
virtio_ioport_write: unexpected address 0x13 value 0x1
Status in QEMU:
New
Bug description:
** Attachment added: "Mini042412-01.dmp"
https://bugs.launchpad.net/bugs/990364/+attachment/3111605/+files/Mini042412-01.dmp
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/990364
Title:
virtio_i
** Attachment added: "dmesg"
https://bugs.launchpad.net/qemu/+bug/990364/+attachment/3111622/+files/dmesg
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/990364
Title:
virtio_ioport_write: unexpec
Am 28.04.2012 10:18, schrieb Blue Swirl:
> On Fri, Apr 27, 2012 at 22:29, Andreas Färber wrote:
>> From: Andreas Färber
>>
>> Commit b72210568ef0c0fb141a01cffb71a09c4efa0364 (slirp: clean up
>> conflicts with system headers) enclosed TCPOLEN_MAXSEG with an #ifdef
>> TCPOPT_EOL. This broke the bui
On Sat, Apr 28, 2012 at 11:11, Andreas Färber wrote:
> Am 28.04.2012 10:18, schrieb Blue Swirl:
>> On Fri, Apr 27, 2012 at 22:29, Andreas Färber wrote:
>>> From: Andreas Färber
>>>
>>> Commit b72210568ef0c0fb141a01cffb71a09c4efa0364 (slirp: clean up
>>> conflicts with system headers) enclosed TC
On Mon, Apr 23, 2012 at 20:39, Stefan Weil wrote:
> Am 23.04.2012 22:13, schrieb Anthony Liguori:
>>
>> On 04/20/2012 05:03 AM, Stefan Weil wrote:
>>>
>>> These patches remove timer code which is no longer needed
>>> and try to improve the remaining code.
>>>
>>> [PATCH 1/5] qemu-timer: Remove red
On Fri, Apr 27, 2012 at 11:59, Peter Maydell wrote:
> Hi; this is a small target-arm pullreq intended to go in before the
> hardfreeze. It's got the final part of the QOM subclassing work from
> Andreas plus a minor bugfix to a corner case in the BE8 handling.
> Please pull.
Thanks, pulled.
>
>
Am 28.04.2012 10:14, schrieb Blue Swirl:
> On Thu, Apr 26, 2012 at 13:43, Andreas Färber wrote:
>> Am 17.04.2012 22:45, schrieb Blue Swirl:
>>> On Mon, Apr 16, 2012 at 21:47, Anthony Liguori
>>> wrote:
On 04/16/2012 04:24 PM, Peter Maydell wrote:
> On 16 April 2012 18:42, Anthony Liguor
On Wed, Apr 25, 2012 at 22:15, Andreas Färber wrote:
> Hello,
>
> Since shortly before 1.0 the build on Mac OS X host is broken due to a type
> conflict for uint16 between SoftFloat and system headers. The conflict stems
> from SoftFloat using int for uint16 (i.e., 32 bits) whereas Apple wants 16
On Thu, Apr 26, 2012 at 09:57, Andreas Färber wrote:
> Fixes the build when combined with the drop of darwin-user.
> Enthusiasts can still try building it using --enable-bsd-user.
>
> Signed-off-by: Andreas Färber
> Cc: Bernhard Walle
Thanks, applied.
> ---
> configure | 2 +-
> 1 files ch
On Fri, Apr 27, 2012 at 15:02, Stefan Weil wrote:
> This patch fixes a build regression with MinGW which was introduced by
> commit 7c7db75576bd5a31508208f153c5aada64b2c8df.
>
> The 3rd argument of g_main_context_query must point to a gint value.
> Using a pointer to an uint32_t value is wrong.
>
On Sun, Apr 22, 2012 at 15:35, Blue Swirl wrote:
> Move TLB handling and softmmu code load helpers to cputlb.c,
> compile only for softmmu targets.
>
> Signed-off-by: Blue Swirl
> ---
> Makefile.target | 2 +-
> cputlb.c | 362
> cp
On Sat, Apr 28, 2012 at 11:42, Andreas Färber wrote:
> Am 28.04.2012 10:14, schrieb Blue Swirl:
>> On Thu, Apr 26, 2012 at 13:43, Andreas Färber wrote:
>>> Am 17.04.2012 22:45, schrieb Blue Swirl:
On Mon, Apr 16, 2012 at 21:47, Anthony Liguori
wrote:
> On 04/16/2012 04:24 PM, Pete
Valgrind reports lots of memory leaks. Three of them which occur
very often are fixed here.
[PATCH 1/3] qdev: Fix memory leak in function set_pci_devfn
[PATCH 2/3] qom: Fix memory leak in function container_get
[PATCH 3/3] hw/pc_sysfw: Fix memory leak
Regards,
Stefan Weil
Valgrind reported this memory leak which occured a few times.
Test scenario:
qemu-system-i386 (no arguments), only BIOS started, terminate with
monitor command (quit).
Signed-off-by: Stefan Weil
---
hw/pc_sysfw.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/hw/pc_
Valgrind reported this memory leak which occured very often.
Test scenario:
qemu-system-i386 (no arguments), only BIOS started, terminate with
monitor command (quit).
Signed-off-by: Stefan Weil
---
hw/qdev-properties.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/hw
Valgrind reported this memory leak which occured very often.
Test scenario:
qemu-system-i386 (no arguments), only BIOS started, terminate with
monitor command (quit).
Signed-off-by: Stefan Weil
---
qom/container.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/qom/co
Am 28.04.2012 14:20, schrieb Stefan Weil:
> Valgrind reported this memory leak which occured very often.
>
> Test scenario:
>
> qemu-system-i386 (no arguments), only BIOS started, terminate with
> monitor command (quit).
>
> Signed-off-by: Stefan Weil
> ---
> hw/qdev-properties.c |1 +
> 1
Valgrind reported this memory leak which occured very often.
Test scenario:
qemu-system-i386 (no arguments), only BIOS started, terminate with
monitor command (quit).
v2:
Use error_free instead of g_free (hint from Andreas Färber, thanks).
Signed-off-by: Stefan Weil
---
hw/qdev-properties.c |
Am 28.04.2012 13:48, schrieb Blue Swirl:
> On Sun, Apr 22, 2012 at 15:35, Blue Swirl wrote:
>> diff --git a/cputlb.c b/cputlb.c
>> new file mode 100644
>> index 000..b7d8f07
>> --- /dev/null
>> +++ b/cputlb.c
[...]
>> +void tlb_reset_dirty_range(CPUTLBEntry *tlb_entry, uintptr_t start,
>> +
Am 28.04.2012 14:24, schrieb Andreas Färber:
Am 28.04.2012 14:20, schrieb Stefan Weil:
Valgrind reported this memory leak which occured very often.
Test scenario:
qemu-system-i386 (no arguments), only BIOS started, terminate with
monitor command (quit).
Signed-off-by: Stefan Weil
---
hw
Am 28.04.2012 14:32, schrieb Stefan Weil:
> Valgrind reported this memory leak which occured very often.
>
> Test scenario:
>
> qemu-system-i386 (no arguments), only BIOS started, terminate with
> monitor command (quit).
>
> v2:
> Use error_free instead of g_free (hint from Andreas Färber, thank
Am 28.04.2012 14:20, schrieb Stefan Weil:
> Valgrind reported this memory leak which occured very often.
>
> Test scenario:
>
> qemu-system-i386 (no arguments), only BIOS started, terminate with
> monitor command (quit).
>
> Signed-off-by: Stefan Weil
Reviewed-by: Andreas Färber
/-F
--
SUS
Am 28.04.2012 14:20, schrieb Stefan Weil:
> Valgrind reported this memory leak which occured a few times.
>
> Test scenario:
>
> qemu-system-i386 (no arguments), only BIOS started, terminate with
> monitor command (quit).
>
> Signed-off-by: Stefan Weil
Reviewed-by: Andreas Färber
/-F
--
SU
List,
Please find a patch to fix scsi_cmd_xfer_mode() so that qemu will use the
correct transfer direction for SCSI-GENERIC devices for the opcodes
UNMAP
WRITE_SAME_16
ATA_PASSTHROUGH
Without this patch, any recent linux guest kernels (3.x) will panic if qemu are
presenting a scsi-generic dev
scsi_cmd_xfer_mode() is used to specify the xfer direction for SCSI commands
that come in from the guest.
If the direction is set incorrectly this will eventually cause QEMU to
kernel-panic the guest.
Add UNMAP/WRITESAME16/ATAPASSTHROUGH as commands that send data to the device.
Without this ch
Il 27/04/2012 18:52, Igor Mitsyanko ha scritto:
>>>
>> The other block device models use a property "drive" for connecting to a
>> block backend, usually via DEFINE_BLOCK_PROPERTIES(). Why is it
>> necessary for sd.c to be different?
>>
>
> SD card is not an instance of TYPE_DEVICE, we cant set a
Il 27/04/2012 17:50, Igor Mitsyanko ha scritto:
> Boolean property "eject" could be used to query if virtual media is inserted
> into
> SD card object, or to deattach BlockDriverState from SD card object.
All this is already available in the BlockDriverState object; the eject
monitor command does
Il 28/04/2012 15:49, Ronnie Sahlberg ha scritto:
> scsi_cmd_xfer_mode() is used to specify the xfer direction for SCSI commands
> that come in from the guest.
> If the direction is set incorrectly this will eventually cause QEMU to
> kernel-panic the guest.
>
> Add UNMAP/WRITESAME16/ATAPASSTHROU
Il 27/04/2012 17:02, Stefan Weil ha scritto:
> diff --git a/main-loop.c b/main-loop.c
> index 0457bf2..24cf540 100644
> --- a/main-loop.c
> +++ b/main-loop.c
> @@ -410,6 +410,7 @@ static int os_host_main_loop_wait(uint32_t timeout)
> int ret, i;
> PollingEntry *pe;
> WaitObjects *w
Il 28/04/2012 03:45, Zhi Yong Wu ha scritto:
>> > It's based on qemu-iotests, so the structure is familiar but uses
>> > sg3-utils to send SCSI commands instead of qemu-io.
> I think that those tests should be ran in guest, qemu-iotests has been
> merged into QEMU upstream, and those tests in it ar
On Sat, Apr 28, 2012 at 10:34 PM, Paolo Bonzini wrote:
> Il 28/04/2012 03:45, Zhi Yong Wu ha scritto:
>>> > It's based on qemu-iotests, so the structure is familiar but uses
>>> > sg3-utils to send SCSI commands instead of qemu-io.
>> I think that those tests should be ran in guest, qemu-iotests h
Am 28.04.2012 16:34, schrieb Paolo Bonzini:
Il 27/04/2012 17:02, Stefan Weil ha scritto:
diff --git a/main-loop.c b/main-loop.c
index 0457bf2..24cf540 100644
--- a/main-loop.c
+++ b/main-loop.c
@@ -410,6 +410,7 @@ static int os_host_main_loop_wait(uint32_t timeout)
int ret, i;
PollingEntry *pe;
List, Paolo,
Please find a patch that plugs libiscsi as a possible target for SCSI-GENERIC,
allowing a guest passthrough access to talk to the remote iscsi devices
directly.
When specifying a -drive that uses iscsi:// as well as setting if=scsi this
passes all SCSI commands straight to iscsi a
Update scsi-generic to allow passthrough of SG_IO scsi commands
to iscsi devices too in addition to the real scsi-generic devices.
Implement both bdrv_ioctl() and bdrv_aio_ioctl() in the iscsi backend,
emulate the SG_IO ioctl and pass the SCSI commands across to the
iscsi target.
This allows end-
SYS_OPEN is already defined in stdio.h of MinGW-w64,
therefore the compiler complains when building for w64.
Adding the prefix TARGET_ avoids that macro redefinition.
xtensa-semi.c also uses the same prefix (but mixed case macros
TARGET_SYS_xxx instead of TARGET_SYS_XXX).
Signed-off-by: Stefan We
On 28 April 2012 16:07, Stefan Weil wrote:
> SYS_OPEN is already defined in stdio.h of MinGW-w64,
> therefore the compiler complains when building for w64.
>
> Adding the prefix TARGET_ avoids that macro redefinition.
> xtensa-semi.c also uses the same prefix (but mixed case macros
> TARGET_SYS_xx
qemu-devel mail:
http://article.gmane.org/gmane.comp.emulators.qemu/148378
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/988125
Title:
Generated smb.conf needs to declare state directory
Status in
Sent a patch to qemu-devel,
http://article.gmane.org/gmane.comp.emulators.qemu/148378
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/988128
Title:
smbd crashes when called with "smb ports = 0"
Stat
Wrong link, sorry. This is the right one:
http://article.gmane.org/gmane.comp.emulators.qemu/148286/
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/988125
Title:
Generated smb.conf needs to declare
The default case in function spin_read should never be reached,
therefore the old code used assert(0) to abort QEMU.
This does not work when QEMU is compiled with macro NDEBUG defined.
In this case (and also when the compiler does not know that assert
never returns), there is a compiler warning be
Il 28/04/2012 16:53, Zhi Yong Wu ha scritto:
>> > Yes, we can run these in qemu-test if Anthony adds sg_utils to qemu-jeos.
> qemu-test means qemu-iotest? jeos is Just Enough Operating System?
http://git.qemu.org/ has both qemu-test and qemu-jeos.
Paolo
Il 27/04/2012 22:21, Michael Roth ha scritto:
> Some of these were being carried as part of Paolo's realize series due to some
> conflicts, but that looks to be targetted for 1.2 now, and there's a QMP
> visitor bug and a small issue with String visitor that were caught by the test
> infrastructure
On 28 April 2012 16:38, Peter Maydell wrote:
> On 28 April 2012 16:07, Stefan Weil wrote:
>> SYS_OPEN is already defined in stdio.h of MinGW-w64,
>> therefore the compiler complains when building for w64.
>>
>> Adding the prefix TARGET_ avoids that macro redefinition.
>> xtensa-semi.c also uses t
Am 28.04.2012 17:52, schrieb Stefan Weil:
> The default case in function spin_read should never be reached,
> therefore the old code used assert(0) to abort QEMU.
>
> This does not work when QEMU is compiled with macro NDEBUG defined.
> In this case (and also when the compiler does not know that a
Am 27.04.2012 22:21, schrieb Michael Roth:
> Currently string-output-visitor formats floats as %g, which is nice in
> that trailing 0's are automatically truncated, but otherwise this causes
> some issues:
>
> - it 6 uses significant figures instead of 6 decimal places, which
"it uses 6 signific
On Sat, Apr 28, 2012 at 11:52 PM, Paolo Bonzini wrote:
> Il 28/04/2012 16:53, Zhi Yong Wu ha scritto:
>>> > Yes, we can run these in qemu-test if Anthony adds sg_utils to qemu-jeos.
>> qemu-test means qemu-iotest? jeos is Just Enough Operating System?
>
> http://git.qemu.org/ has both qemu-test an
Am 27.04.2012 16:23, schrieb Stefan Hajnoczi:
> The new Python tracetool implementation works great but does not run on older
> Python installations. This series takes us back to the happy days of Python
> 2.4, which was released in 2004.
>
> As a result tracetool should now work again on Mac OS
Patch 1 has been applied to prep-up branch by Andreas
Patch 5 has been applied to master by malc
Ping.
Hervé
Hervé Poussineau a écrit :
Hi,
Patches 1 to 3 implement the pc87312 Super I/O chip. This patch has
been tested on PReP emulation and on IBM 40p (not yet committed).
Missing part is dyn
Am 28.04.2012 20:11, schrieb Hervé Poussineau:
> Patch 1 has been applied to prep-up branch by Andreas
> Patch 5 has been applied to master by malc
>
> Ping.
v2 series is on my radar for the 1.1 PULL, but I still wasn't happy with
the pc87312 patch, so I'd prefer to defer that to 1.2.
Andreas
>
Am 14.04.2012 22:48, schrieb Hervé Poussineau:
> Register is one byte-wide (as per specification), so there is no need to
> specify endianness.
The region was 4 bytes before, now it's 1. What happens when a 4-byte
read is attempted at that address? Do we need to specify the valid
widths for the M
Initially, vga_get_text_resolution returns a text resolution of 1 x 1
(vga register values are 0).
This is visible during MIPS Malta boot with SDL. It also occurs with the
i386 or x86_64 system emulation when it runs in single step mode:
QEMU changes the size of the SDL window to the smallest pos
Am 14.04.2012 22:51, schrieb Hervé Poussineau:
> Speaker init has been added in 506b7ddf889312659b36c667f7ae17bc9e909418,
> but audio subsystem init was missing.
>
> Signed-off-by: Hervé Poussineau
Thanks, applied to prep-up:
http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/prep-up
And
Andreas Färber a écrit :
Am 14.04.2012 22:48, schrieb Hervé Poussineau:
Register is one byte-wide (as per specification), so there is no need to
specify endianness.
The region was 4 bytes before, now it's 1. What happens when a 4-byte
read is attempted at that address? Do we need to specify t
On Sat, Apr 28, 2012 at 00:08, Gleb Natapov wrote:
> On Fri, Apr 27, 2012 at 02:55:48PM -0700, Jordan Justen wrote:
>> But, if qemu could be changed,
>> could it be made to match the PIIX4 datasheet?
>>
> We try not to change QEMU in non backwards compatible way. We can
> implement PMBA and start
Hi
I have been comparing the compression achieved by various encoding schemes
in the following two scenarios :
a) Using the -vnc option with qemu
b) Creating a vnc server inside the guest
The vnc viewer I am using is xtightvnc. My guest is gentoo OS and my qemu
version is 0.13.0
I have observed
Hi,
I know there exists nested KVM in the kernel tree such that a KVM
hypervisor can run inside a guest.
Now I am wondering if it is possible to load the kvm module in a qemu
VM (-no-kvm). So I started a qemu VM using the following command
qemu-system-x86_64 -hda os.img -no-kvm -cpu qemu64,+vmx
65 matches
Mail list logo
