Brad Campbell | 1 Sep 02:19 2010

[resend]Crashing early in XP i386 guest install with a virtio block driver enabled.

Resent as I've not seen a trace of the first one in 12 hours..

I'm running git (as of 5 minutes ago) on an AMD Phenom 97xx. Debian stable, 64 bit self compiled kernel.

I've got qemu-system-x86_64 symlinked to qemu

My minimal test case is ...
qemu -drive if=virtio,file=xp_base.qcow2 -cdrom XP.iso -boot d

XP gets half way though loading the storage drivers and errors with
"An unexpected error (769) occurred at
line 5218 in d:\xpsp\base\boot\setup\setup.c.
Press any key to continue"

This error appears to not be terminal as you can press a key and move on, but it only happens with 
the virtio block driver configured. It is reproducible using a vanilla XP iso.

I've tried it with raw/qcow2/vmdk images and it bombs in the same place.

Interestingly enough, if file=/dev/null then it continues on until it realises it can't go any 
further as there is no hard disk it can see.

I first encountered this with the current qemu-kvm head, but it's reproducible completely with the 
current vanilla git qemu and kvm switched off.

I'd guess it's hardly on the radar of stuff to fix but while I was toying with a self-contained XP 
guest disk with the virtio drivers installed I bumped up against it and I thought someone might want 
to know about it.

Regards,
(Continue reading)

Hao, Xudong | 1 Sep 02:51 2010
Picon

RE: [PATCH] hw/ivshmem.c don't check for negative values on unsigned data types

Hao, Xudong wrote:
> Jes.Sorensen <at> redhat.com wrote:
>> From: Jes Sorensen <Jes.Sorensen <at> redhat.com>
>> 
>> There is no need to check for dest < 0 or vector >= 0 as both are
>> uint16_t. 
>> 
>> This should fix problems with broken build with aggressive compiler
>> flags. Reported by Xudong Hao <xudong.hao <at> intel.com>
>> 
>> Signed-off-by: Jes Sorensen <Jes.Sorensen <at> redhat.com> ---
>>  hw/ivshmem.c |    4 ++--
>>  1 files changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/hw/ivshmem.c b/hw/ivshmem.c
>> index bbb5cba..afebbc3 100644
>> --- a/hw/ivshmem.c
>> +++ b/hw/ivshmem.c
>>  <at>  <at>  -199,13 +199,13  <at>  <at>  static void ivshmem_io_writel(void *opaque,
>> target_phys_addr_t addr, 
>> 
>>          case DOORBELL:
>>              /* check that dest VM ID is reasonable */
>> -            if ((dest < 0) || (dest > s->max_peer)) {
>> +            if (dest > s->max_peer) {
>>                  IVSHMEM_DPRINTF("Invalid destination VM ID (%d)\n",
>>                  dest); break;
>>              }
>> 
>>              /* check doorbell range */
(Continue reading)

Cam Macdonell | 1 Sep 05:53 2010
Picon
Picon

Re: [PATCH] hw/ivshmem.c don't check for negative values on unsigned data types

On Mon, Aug 30, 2010 at 4:31 AM,  <Jes.Sorensen <at> redhat.com> wrote:
> From: Jes Sorensen <Jes.Sorensen <at> redhat.com>
>
> There is no need to check for dest < 0 or vector >= 0 as both are
> uint16_t.
>
> This should fix problems with broken build with aggressive compiler
> flags. Reported by Xudong Hao <xudong.hao <at> intel.com>
>
> Signed-off-by: Jes Sorensen <Jes.Sorensen <at> redhat.com>
> ---
>  hw/ivshmem.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hw/ivshmem.c b/hw/ivshmem.c
> index bbb5cba..afebbc3 100644
> --- a/hw/ivshmem.c
> +++ b/hw/ivshmem.c
>  <at>  <at>  -199,13 +199,13  <at>  <at>  static void ivshmem_io_writel(void *opaque, target_phys_addr_t addr,
>
>         case DOORBELL:
>             /* check that dest VM ID is reasonable */
> -            if ((dest < 0) || (dest > s->max_peer)) {
> +            if (dest > s->max_peer) {
>                 IVSHMEM_DPRINTF("Invalid destination VM ID (%d)\n", dest);
>                 break;
>             }
>
>             /* check doorbell range */
> -            if ((vector >= 0) && (vector < s->peers[dest].nb_eventfds)) {
(Continue reading)

Cam Macdonell | 1 Sep 05:56 2010
Picon
Picon

Re: [PATCH] hw/ivshmem.c don't check for negative values on unsigned data types

On Tue, Aug 31, 2010 at 6:51 PM, Hao, Xudong <xudong.hao <at> intel.com> wrote:
> Hao, Xudong wrote:
>> Jes.Sorensen <at> redhat.com wrote:
>>> From: Jes Sorensen <Jes.Sorensen <at> redhat.com>
>>>
>>> There is no need to check for dest < 0 or vector >= 0 as both are
>>> uint16_t.
>>>
>>> This should fix problems with broken build with aggressive compiler
>>> flags. Reported by Xudong Hao <xudong.hao <at> intel.com>
>>>
>>> Signed-off-by: Jes Sorensen <Jes.Sorensen <at> redhat.com> ---
>>>  hw/ivshmem.c |    4 ++--
>>>  1 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/hw/ivshmem.c b/hw/ivshmem.c
>>> index bbb5cba..afebbc3 100644
>>> --- a/hw/ivshmem.c
>>> +++ b/hw/ivshmem.c
>>>  <at>  <at>  -199,13 +199,13  <at>  <at>  static void ivshmem_io_writel(void *opaque,
>>> target_phys_addr_t addr,
>>>
>>>          case DOORBELL:
>>>              /* check that dest VM ID is reasonable */
>>> -            if ((dest < 0) || (dest > s->max_peer)) {
>>> +            if (dest > s->max_peer) {
>>>                  IVSHMEM_DPRINTF("Invalid destination VM ID (%d)\n",
>>>                  dest); break;
>>>              }
>>>
(Continue reading)

Cam Macdonell | 1 Sep 06:00 2010
Picon
Picon

Re: [PATCH] hw/ivshmem.c don't check for negative values on unsigned data types

On Tue, Aug 31, 2010 at 9:56 PM, Cam Macdonell <cam <at> cs.ualberta.ca> wrote:
> On Tue, Aug 31, 2010 at 6:51 PM, Hao, Xudong <xudong.hao <at> intel.com> wrote:
>> Hao, Xudong wrote:
>>> Jes.Sorensen <at> redhat.com wrote:
>>>> From: Jes Sorensen <Jes.Sorensen <at> redhat.com>
>>>>
>>>> There is no need to check for dest < 0 or vector >= 0 as both are
>>>> uint16_t.
>>>>
>>>> This should fix problems with broken build with aggressive compiler
>>>> flags. Reported by Xudong Hao <xudong.hao <at> intel.com>
>>>>
>>>> Signed-off-by: Jes Sorensen <Jes.Sorensen <at> redhat.com> ---
>>>>  hw/ivshmem.c |    4 ++--
>>>>  1 files changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/hw/ivshmem.c b/hw/ivshmem.c
>>>> index bbb5cba..afebbc3 100644
>>>> --- a/hw/ivshmem.c
>>>> +++ b/hw/ivshmem.c
>>>>  <at>  <at>  -199,13 +199,13  <at>  <at>  static void ivshmem_io_writel(void *opaque,
>>>> target_phys_addr_t addr,
>>>>
>>>>          case DOORBELL:
>>>>              /* check that dest VM ID is reasonable */
>>>> -            if ((dest < 0) || (dest > s->max_peer)) {
>>>> +            if (dest > s->max_peer) {
>>>>                  IVSHMEM_DPRINTF("Invalid destination VM ID (%d)\n",
>>>>                  dest); break;
>>>>              }
(Continue reading)

Stefan Hajnoczi | 1 Sep 08:18 2010
Picon

Re: Re: [PATCH 01/14] trace: Add trace-events file for declaring trace events

On Tue, Aug 31, 2010 at 7:00 PM, Blue Swirl <blauwirbel <at> gmail.com> wrote:
> On Tue, Aug 31, 2010 at 8:46 AM, Stefan Hajnoczi <stefanha <at> gmail.com> wrote:
>> On Mon, Aug 30, 2010 at 10:01 PM, Blue Swirl <blauwirbel <at> gmail.com> wrote:
>>> On Mon, Aug 30, 2010 at 8:42 PM, Blue Swirl <blauwirbel <at> gmail.com> wrote:
>>>> On Mon, Aug 30, 2010 at 8:10 PM, malc <av1474 <at> comtv.ru> wrote:
>>>>> On Mon, 30 Aug 2010, Blue Swirl wrote:
>>>>>
>>>>>> On Mon, Aug 30, 2010 at 1:27 PM, Stefan Hajnoczi
>>>>>> <stefanha <at> linux.vnet.ibm.com> wrote:
>>>>>> > This patch introduces the trace-events file where trace events can be
>>>>>> > declared like so:
>>>>>> >
>>>>>> > qemu_malloc(size_t size) "size %zu"
>>>>>> > qemu_free(void *ptr) "ptr %p"
>>>>>> >
>>>>>> > These trace event declarations are processed by a new tool called
>>>>>> > tracetool to generate code for the trace events.  Trace event
>>>>>> > declarations are independent of the backend tracing system (LTTng User
>>>>>> > Space Tracing, ftrace markers, DTrace).
>>>>>>
>>>>>> I think the tool does not work if 'sh' is not 'bash'. For example, on
>>>>>> OpenBSD I got:
>>>>>
>>>>> Well, it does work with ash.
>>>>>
>>>>>>
>>>>>> config-host.mak is out-of-date, running configure
>>>>>>
>>>>>> Error: invalid trace backend
>>>>>> Please choose a supported trace backend.
(Continue reading)

Stefan Hajnoczi | 1 Sep 08:21 2010
Picon

Re: [PATCH 5/5] virtio-net: Switch default to new bottom half TX handler for iothread

On Tue, Aug 31, 2010 at 11:32 PM, Alex Williamson
<alex.williamson <at> redhat.com> wrote:
> On Tue, 2010-08-31 at 23:25 +0300, Michael S. Tsirkin wrote:
>> On Fri, Aug 27, 2010 at 04:37:45PM -0600, Alex Williamson wrote:
>> > The bottom half handler shows big improvements over the timer
>> > with few downsides, default to it when the iothread is enabled.
>> >
>> > Using the following tests, with the guest and host connected
>> > via tap+bridge:
>> >
>> > guest> netperf -t TCP_STREAM -H $HOST
>> > host> netperf -t TCP_STREAM -H $GUEST
>> > guest> netperf -t UDP_STREAM -H $HOST
>> > host> netperf -t UDP_STREAM -H $GUEST
>> > guest> netperf -t TCP_RR -H $HOST
>> >
>> > Results: base throughput, exits/throughput ->
>> >                    patched throughput, exits/throughput
>> >
>> > --enable-io-thread
>> > TCP guest->host 2737.77, 47.82  -> 6767.09, 29.15 = 247%, 61%
>> > TCP host->guest 2231.33, 74.00  -> 4125.80, 67.61 = 185%, 91%
>> > UDP guest->host 6281.68, 14.66  -> 12569.27, 1.98 = 200%, 14%
>> > UDP host->guest 275.91,  289.22 -> 264.80, 293.53 = 96%, 101%
>> > interations/s   1949.65, 82.97  -> 7417.56, 84.31 = 380%, 102%
>> >
>> > No --enable-io-thread
>> > TCP guest->host 3041.57, 55.11 -> 1038.93, 517.57 = 34%, 939%
>> > TCP host->guest 2416.03, 76.67 -> 5655.92, 55.52  = 234%, 72%
>> > UDP guest->host 12255.82, 6.11 -> 7775.87, 31.32  = 63%, 513%
(Continue reading)

Avi Kivity | 1 Sep 09:41 2010
Picon

Re: [RFC] KVM: PPC: Add level based interrupt logic

  On 08/31/2010 01:07 PM, Alexander Graf wrote:
> KVM on PowerPC used to have completely broken interrupt logic. Usually,
> interrupts work by having a PIC that pulls a line up/down, so the CPU knows
> that an interrupt is active. This line stays active until some action is
> done to the PIC to release the line.
>
> On KVM for PPC, we just checked if there was an interrupt pending and pulled
> a line in the kernel module. We never released it though, hoping that kernel
> space would just declare an interrupt as released when injected - which is
> wrong.
>
> To fix this, we need to completely redesign the interrupt injection logic.
> Whenever an interrupt line gets triggered, we need to notify kernel space
> that the line is up. Whenever it gets released, we do the same. This way
> we can assure that the interrupt state is always known to kernel space.
>
> This fixes random stalls in KVM guests on PowerPC that were waiting for
> an interrupt while everyone else thought they received it already.

This is more or less equivalent to KVM_IRQ_LINE.

--

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Gerd Hoffmann | 1 Sep 10:45 2010
Picon

Re: [RfC PATCH] spice: add qxl device

   Hi,

>> Signed-off-by: Gerd Hoffmann<kraxel <at> redhat.com>
>
> I've taken a quick look and have a few questions.
>
> Does this work without libspice (I think no)?

Correct, it needs libspice.  Even in case you'll use qxl with sdl/vnc 
libspice is needed to do the rendering.

> Why does spice need to perform arbitrary gpa -> hva conversions?
> Shouldn't everything happen within video ram?

Hmm, guess I should write up docs/qxl.txt explaining a few concepts.

QXL uses memory slots for addressing.  The guest specifies the address 
of some object (command, command data such as bitmaps, surfaces, ...) 
using a slot+offset tuple.

Memory slots are created by the guest.  qxl checks the request.  The 
allowed memory range covers the two pci slots at the moment.  If the 
checks pass qxl informs the spice server about the new slot and the 
location in qemu's address space so spice server can follow those 
references when parsing the qxl commands.

In a few places qxl needs to look at the commands itself, then it needs 
to do the memory slot lookup as well of course.  qxl_phys2virt does 
that, maybe I should rename that to qxl_memslot_lookup() or something 
simliar to make more clear what it actually does.
(Continue reading)

Michael S. Tsirkin | 1 Sep 10:47 2010
Picon

Re: [PATCH 5/5] virtio-net: Switch default to new bottom half TX handler for iothread

On Tue, Aug 31, 2010 at 04:32:54PM -0600, Alex Williamson wrote:
> On Tue, 2010-08-31 at 23:25 +0300, Michael S. Tsirkin wrote:
> > On Fri, Aug 27, 2010 at 04:37:45PM -0600, Alex Williamson wrote:
> > > The bottom half handler shows big improvements over the timer
> > > with few downsides, default to it when the iothread is enabled.
> > > 
> > > Using the following tests, with the guest and host connected
> > > via tap+bridge:
> > > 
> > > guest> netperf -t TCP_STREAM -H $HOST
> > > host> netperf -t TCP_STREAM -H $GUEST
> > > guest> netperf -t UDP_STREAM -H $HOST
> > > host> netperf -t UDP_STREAM -H $GUEST
> > > guest> netperf -t TCP_RR -H $HOST
> > > 
> > > Results: base throughput, exits/throughput ->
> > >                    patched throughput, exits/throughput
> > > 
> > > --enable-io-thread
> > > TCP guest->host 2737.77, 47.82  -> 6767.09, 29.15 = 247%, 61%
> > > TCP host->guest 2231.33, 74.00  -> 4125.80, 67.61 = 185%, 91%
> > > UDP guest->host 6281.68, 14.66  -> 12569.27, 1.98 = 200%, 14%
> > > UDP host->guest 275.91,  289.22 -> 264.80, 293.53 = 96%, 101%
> > > interations/s   1949.65, 82.97  -> 7417.56, 84.31 = 380%, 102%
> > > 
> > > No --enable-io-thread
> > > TCP guest->host 3041.57, 55.11 -> 1038.93, 517.57 = 34%, 939%
> > > TCP host->guest 2416.03, 76.67 -> 5655.92, 55.52  = 234%, 72%
> > > UDP guest->host 12255.82, 6.11 -> 7775.87, 31.32  = 63%, 513%
> > > UDP host->guest 587.92, 245.95 -> 611.88, 239.92  = 104%, 98%
(Continue reading)


Gmane