headers
Filip Navara | 7 Sep 2010 18:36
Picon

[PATCH] RFC: TCG constant propagation.

Add support for constant propagation to TCG. This has to be paired with the liveness
analysis to remove the dead code. Not all possible operations are covered, but the
most common ones are. This improves the code generation for several ARM instructions,
like MVN (immediate), and it may help other targets as well.
---
 tcg/tcg.c |  164 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 164 insertions(+), 0 deletions(-)

diff --git a/tcg/tcg.c b/tcg/tcg.c
index 4cb5934..10b6a99 100644
--- a/tcg/tcg.c
+++ b/tcg/tcg.c
 <at>  <at>  -1025,7 +1025,169  <at>  <at>  void tcg_add_target_add_op_defs(const TCGTargetOpDef *tdefs)
 #endif
         tdefs++;
     }
+}
+
+static void tcg_const_analysis(TCGContext *s)
+{
+    int nb_cargs, nb_iargs, nb_oargs, dest, src, src2, del_args, i;
+    TCGArg *args;
+    uint16_t op;
+    uint16_t *opc_ptr;
+    const TCGOpDef *def;
+    uint8_t *const_temps;
+    tcg_target_ulong *temp_values;
+    tcg_target_ulong val, mask;
+    tcg_target_ulong dest_val, src_val, src2_val;
+
(Continue reading)

Permalink | Reply | 9 comments |
headers
Brad Campbell | 1 Sep 2010 02:19

[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)

Permalink | Reply | 0 comments |
headers
Hao, Xudong | 1 Sep 2010 02:51
Picon
Favicon

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)

Permalink | Reply | 2 comments |
headers
Cam Macdonell | 1 Sep 2010 05:53
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)

Permalink | Reply | 0 comments |
headers
Cam Macdonell | 1 Sep 2010 05:56
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)

Permalink | Reply | 1 comment |
headers
Cam Macdonell | 1 Sep 2010 06:00
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)

Permalink | Reply | 0 comments |
headers
Stefan Hajnoczi | 1 Sep 2010 08:18
Picon
Gravatar

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)

Permalink | Reply | 1 comment |
headers
Avi Kivity | 1 Sep 2010 09:41
Picon
Favicon

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.
Permalink | Reply | 8 comments |
headers
Gerd Hoffmann | 1 Sep 2010 10:45
Picon
Favicon

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)

Permalink | Reply | 0 comments |
headers
Alexander Graf | 1 Sep 2010 11:38
Picon

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


On 01.09.2010, at 09:41, Avi Kivity wrote:

> 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.

My question was if you think the internal C interface is generic enough or if it needs a lot more magic for x86
anyways :).

Alex
(Continue reading)

Permalink | Reply | 7 comments |

Gmane