On 23.09.2010, at 07:25, Leo B wrote:
> Hi I would like to know the status of these issues in Qemu 0.13
>
> 1.I saw that as recently as this year there was work being done on
> Completeing Big Real Mode Emulation which should help old OS to run such as
> Windows1.01-Windows 98 so my question
On Sep 22, 2010, at 19:56, ext Pham Van Thiet wrote:
> I try to find them on meego.gitorious.org/qemu-maemo but I didn't find them.
> Can
> you send the links to me?
Just clone the git repository and build qemu. Since it is more a development
branch than a staging branch against upstream al
Hi I would like to know the status of these issues in Qemu 0.13
1.I saw that as recently as this year there was work being done on
Completeing Big Real Mode Emulation which should help old OS to run such as
Windows1.01-Windows 98 so my question is is this support complete now do
these OS run on Qe
Following up on this one, I'd like to know whether there is any
pending issue preventing rbd from being included upstream.
Thanks,
Yehuda
On Tue, Aug 3, 2010 at 1:14 PM, Christian Brunner wrote:
> On Tue, Aug 03, 2010 at 12:37:18AM +0400, malc wrote:
>>
>> Thare are whitespace issues in this pat
Public bug reported:
When doing the regression tests for Python 3.1.2 with Qemu 0.12.5, (Linux
version 2.6.26-2-686 (Debian 2.6.26-25lenny1)),
gcc (Debian 4.3.2-1.1) 4.3.2, Python compiled from sources within qemu,
3 math tests fail, apparently because the floating point unit is buggy. Qmeu
was
On Tue, 2010-09-21 at 18:11 +0200, Michael S. Tsirkin wrote:
I've put up a wiki page with a kvm networking todo list,
mainly to avoid effort duplication, but also in the hope
to draw attention to what I think we should try addressing
in KVM:
http://www.linux-kvm.org/page/NetworkingTodo
This pa
Thanks, applied.
On Tue, Sep 21, 2010 at 8:27 PM, Stefan Weil wrote:
> By moving the definition of GCC_ATTR and GCC_FMT_ATTR
> from audio_int.h to qemu-common.h these macros are
> now generally available for further patches which add
> the gcc format attribute.
>
> Newer gcc versions support form
Public bug reported:
I export my Linux webcam to KVM using the switches "-usb -usbdevice
host:046d:0929". The XP guest sees the webcam and the drivers install,
but the camera only shows a black image. When I open the camera in
Windows Explorer, it says "0 images" and a black image, while on a real
During a hotplug, the netdev might be removed before the
connected virtio device. When this happens, the guest might
be running cleanup operations that can trigger a segfault in
qemu. Avoid one set of these by checking whether the peer
device is present before trying to do tap operations.
Signed
On 09/22/2010 02:33 PM, Peter Lemenkov wrote:
Signed-off-by: Peter Lemenkov
---
block/blkverify.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/block/blkverify.c b/block/blkverify.c
index 4202685..033eab2 100644
--- a/block/blkverify.c
+++ b/block/blkverify.c
@@ -58
On Wed, Sep 22, 2010 at 7:33 PM, Peter Lemenkov wrote:
> Signed-off-by: Peter Lemenkov
> ---
> block/blkverify.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/block/blkverify.c b/block/blkverify.c
> index 4202685..033eab2 100644
> --- a/block/blkverify.c
> +++ b/
On 17.09.2010 15:27, Anthony Liguori wrote:
> On 09/17/2010 01:50 AM, Mathias Krause wrote:
>> Am 16.09.2010 19:20 schrieb Anthony Liguori:
>>
>>> Instead of using FILE, I'd suggest using a BlockDriver to read and write
>>> the data.
>>>
>> I'll fix that as soon as I figured how to use thi
Signed-off-by: Peter Lemenkov
---
block/blkverify.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/block/blkverify.c b/block/blkverify.c
index 4202685..033eab2 100644
--- a/block/blkverify.c
+++ b/block/blkverify.c
@@ -58,7 +58,7 @@ static void blkverify_err(BlkverifyAI
On 09/22/2010 01:56 PM, Stefan Weil wrote:
./hw/sd.c: In function ‘sd_init’:
./hw/sd.c:443: error: implicit declaration of function ‘qemu_blockalign’
./hw/sd.c:443: error: nested extern declaration of ‘qemu_blockalign’
./hw/sd.c:443: error: assignment makes pointer from integer without a cast
Cc
./hw/sd.c: In function ‘sd_init’:
./hw/sd.c:443: error: implicit declaration of function ‘qemu_blockalign’
./hw/sd.c:443: error: nested extern declaration of ‘qemu_blockalign’
./hw/sd.c:443: error: assignment makes pointer from integer without a cast
Cc: Christoph Hellwig
Cc: Kevin Wolf
Signed-o
On 09/22/2010 01:20 PM, Leszek Urbanski wrote:
<4c9a3faf.9090...@codemonkey.ws>; from Anthony Liguori on Wed, Sep 22, 2010 at
12:41:03 -0500
Is the guest kernel vanilla 2.6.32.22 or is it a distro kernel? If the
later, what distro?
The difference in the two invocations is that with the -
<4c9a3faf.9090...@codemonkey.ws>; from Anthony Liguori on Wed, Sep 22, 2010 at
12:41:03 -0500
> Is the guest kernel vanilla 2.6.32.22 or is it a distro kernel? If the
> later, what distro?
>
> The difference in the two invocations is that with the -device syntax,
> you're getting offload feat
On 09/22/2010 12:18 PM, Leszek Urbanski wrote:
Hi,
This is a qemu-kvm (i.e. not qemu) bug report. I've been told on IRC (#kvm)
that this bug report should go to this list anyway.
host and guest kernel: 2.6.32.22
arch: amd64
qemu-kvm: 0.12.5 and 0.13.0-rc1
How to reproduce: copy a large (few h
On Tue, Sep 21, 2010 at 7:06 PM, Anthony Liguori wrote:
> On 09/21/2010 01:32 PM, Blue Swirl wrote:
>>
>> On Mon, Sep 20, 2010 at 8:21 PM, Anthony Liguori
>> wrote:
>>
>>>
>>> On 09/20/2010 03:03 PM, Blue Swirl wrote:
>>>
On Mon, Sep 20, 2010 at 6:41 PM, Blue Swirl
wrote:
>>>
Hi,
This is a qemu-kvm (i.e. not qemu) bug report. I've been told on IRC (#kvm)
that this bug report should go to this list anyway.
host and guest kernel: 2.6.32.22
arch: amd64
qemu-kvm: 0.12.5 and 0.13.0-rc1
How to reproduce: copy a large (few hundred MB) file to an NFS mount
(guest is the cli
On Wed, Sep 22, 2010 at 1:40 PM, Paolo Bonzini wrote:
> On 09/21/2010 08:32 PM, Blue Swirl wrote:
>>
>> Sort of, gnulib needs some configuration before use. I made some hacks
>> to avoid that and also suppressed warnings by overriding QEMU_CFLAGS,
>> but it's getting ugly.
>>
>> Actually, there's
Thanks your answer,
I try to find them on meego.gitorious.org/qemu-maemo but I didn't find them.
Can
you send the links to me?
Best regard,
Pham Van Thiet,
- Thư gốc
Từ: "juha.riihim...@nokia.com"
Đến: btc...@yahoo.com
Cc: qemu-devel@nongnu.org
Gửi ngày: 12:44:23, Thứ Tư, 22 tháng
On 09/22/2010 10:27 AM, malc wrote:
If someone was willing to put in the effort, I'd be very supportive of moving
QEMU to autotools.
And i'll be against it.
I'd prefer to wait to have this flame war until after someone expresses
realistic interesting in such an effort.
Suffice to
On Wed, 22 Sep 2010, Paolo Bonzini wrote:
> On 09/22/2010 05:27 PM, malc wrote:
> > On Wed, 22 Sep 2010, Anthony Liguori wrote:
> > > If someone was willing to put in the effort, I'd be very supportive of
> > > moving
> > > QEMU to autotools.
> >
> > And i'll be against it.
>
> This somehow does
On 09/22/2010 05:27 PM, malc wrote:
On Wed, 22 Sep 2010, Anthony Liguori wrote:
If someone was willing to put in the effort, I'd be very supportive of moving
QEMU to autotools.
And i'll be against it.
This somehow doesn't surprise me.
Anyway, what do you think about the idea of making the c
On 09/22/2010 10:03 AM, Luiz Capitulino wrote:
On Wed, 22 Sep 2010 08:18:10 -0500
Anthony Liguori wrote:
On 09/22/2010 07:32 AM, Markus Armbruster wrote:
[...]
I can't see why we must have a dogmatic "thou shalt not use anything but
QMP to implement HMP commands, ever" rule.
On Wed, 22 Sep 2010, Anthony Liguori wrote:
> On 09/22/2010 08:40 AM, Paolo Bonzini wrote:
> > On 09/21/2010 08:32 PM, Blue Swirl wrote:
> > > Sort of, gnulib needs some configuration before use. I made some hacks
> > > to avoid that and also suppressed warnings by overriding QEMU_CFLAGS,
> > > bu
On Wed, 22 Sep 2010 08:18:10 -0500
Anthony Liguori wrote:
> On 09/22/2010 07:32 AM, Markus Armbruster wrote:
[...]
> > I can't see why we must have a dogmatic "thou shalt not use anything but
> > QMP to implement HMP commands, ever" rule.
I based most of my ideas on what Anthony has described
On 09/22/2010 03:42 PM, Anthony Liguori wrote:
If someone was willing to put in the effort, I'd be very supportive of
moving QEMU to autotools.
For 0.14 it would be a nice start to convert the command line to
something more autoconfy (e.g. MAKE= instead of --make=).
Paolo
On 09/22/2010 08:40 AM, Paolo Bonzini wrote:
On 09/21/2010 08:32 PM, Blue Swirl wrote:
Sort of, gnulib needs some configuration before use. I made some hacks
to avoid that and also suppressed warnings by overriding QEMU_CFLAGS,
but it's getting ugly.
Actually, there's no 'configure' in gnulib H
On 09/21/2010 08:32 PM, Blue Swirl wrote:
Sort of, gnulib needs some configuration before use. I made some hacks
to avoid that and also suppressed warnings by overriding QEMU_CFLAGS,
but it's getting ugly.
Actually, there's no 'configure' in gnulib HEAD even though
docs/INSTALL mentions that. St
On 09/21/2010 08:32 PM, Blue Swirl wrote:
Sort of, gnulib needs some configuration before use. I made some hacks
to avoid that and also suppressed warnings by overriding QEMU_CFLAGS,
but it's getting ugly.
Actually, there's no 'configure' in gnulib HEAD even though
docs/INSTALL mentions that. St
On 09/22/2010 07:32 AM, Markus Armbruster wrote:
Luiz Capitulino writes:
Hi there,
I was working on a detailed writeup about monitor's internals so that I could
get some guidance regarding monitor's internal design, but after today's call
I realized that we should discuss the general desi
Luiz Capitulino writes:
> Hi there,
>
> I was working on a detailed writeup about monitor's internals so that I could
> get some guidance regarding monitor's internal design, but after today's call
> I realized that we should discuss the general design first.
>
> I think we have two options: the
On Wed, Sep 15, 2010 at 02:38:19PM +0900, Isaku Yamahata wrote:
> This patch implements helper functions for pcie aer capability
> which will be used later.
>
> Signed-off-by: Isaku Yamahata
> ---
> Changes v2 -> v3:
> - split out from pcie.[ch] to pcie_aer.[ch] to make the files sorter.
> - embe
On Wed, Sep 15, 2010 at 02:38:24PM +0900, Isaku Yamahata wrote:
> glue to pcie_abp monitor command.
>
> Signed-off-by: Isaku Yamahata
Let's make the name a bit more descriptive, ok?
Also: this seems related to pci_plug/pci_unplug
commands Anthony proposed.
These could work generally for pci and
On Wed, Sep 15, 2010 at 02:38:21PM +0900, Isaku Yamahata wrote:
> pcie root port.
>
> Signed-off-by: Isaku Yamahata
> ---
> Changes v2 -> v3:
> - compilation adjustment.
so this is a specific intel root port, lets
name file and rotines appropriately.
> ---
> Makefile.objs |2 +-
> hw/pcie
On Wed, Sep 15, 2010 at 02:38:23PM +0900, Isaku Yamahata wrote:
> pcie switch downstream port.
>
> Signed-off-by: Isaku Yamahata
> ---
> Changes v2 -> v3:
> - compilation adjustment.
Same comments as for upstream apply here.
> ---
> Makefile.objs|1 +
> hw/pcie_downstream.c | 218
On Wed, Sep 15, 2010 at 02:38:22PM +0900, Isaku Yamahata wrote:
> pci express switch upstream port.
>
> Signed-off-by: Isaku Yamahata
> ---
> Changes v2 -> v3:
> - compilation adjustment.
This is in fact a specific upstream port, isn't it?
If so rename all PCIE names here to specific port model
On Fri, 17 Sep 2010, Blue Swirl wrote:
> On Fri, Sep 17, 2010 at 11:15 AM, wrote:
> > From: Anthony PERARD
> >
> > Open and bind event channels; map ioreq and buffered ioreq rings.
>
> In general, because of CPUState accesses and cpu_in/out use, this
> looks like CPU code, specifically x86. Cou
40 matches
Mail list logo