Re: [Qemu-devel] --disable-gfx-check still wants SDL.h?
On Wed, Mar 12, 2008 at 07:24:54PM -0700, David Barrett wrote: > Is it possible to compile/run qemu on a system that does not have SDL? ./configure --disable-sdl --disable-gfx-check Carlo
Re: [Qemu-devel] Re: [PATCH] e1000: fix endianness issues
On Wed, 2008-03-12 at 23:07 +0100, Aurelien Jarno wrote: > > We finally found the problem with rtl8139 emulation. The byteswapping > depending on the target was not done for all registers. The 8139too > driver was able to cope with that, but not the 8139cp. In his patch > Hollis addressed the issue by byteswapping accesses to all registers, > but depending the host endianness (cpu_to_ and _to_cpu functions) > instead of the target endianness. This was working correctly in his > case, as he tested it on both big endian target and hosts. > > Byte swapping does not depend on host endianness nor target endianness > but on the path from the CPU to the device, which is currently and > *wrongly* implemented in Qemu as a byteswap on big endian targets. > This > has to be fixed by providing a layer modeling the endianness. It has > to > maintain a bus network/tree, so it can invert the endianness of all > the > devices behind a PCI host controller or a PCI bridge. It also has to > be > dynamic, as some chipsets (e.g. gt64xxx) have a configurable bit that > can be changed at runtime to control the endianness. > > Before it is implemented correctly, please find attached two patches > to > fix the rtl8139 and e1000 emulations on big endian hosts and big > endian > targets, using the current and *wrong* Qemu implementation with regard > to endianness. Hopefully that works as all the systems we support > happen > to do the same thing. Thanks for pursuing this Aurelien. Although patches that replace cpu_to_* with TARGET_WORDS_BIGENDIAN usage make me cringe, these patches do indeed seem to fix BE/BE host/target behavior right now. -- Hollis Blanchard IBM Linux Technology Center
[Qemu-devel] --disable-gfx-check still wants SDL.h?
Is it possible to compile/run qemu on a system that does not have SDL?
I assumed this is what --disable-gfx-check does, but it's still giving
me errors (below). The specific error ("The error log from compiling
the libSDL test is") sounds like it's compiling some sort of test -- is
there any way to disable test compilation?
-david
root:/tmp/qemu-0.9.1# ./configure --disable-gfx-check
./configure: pkg-config: command not found
Install prefix/usr/local
BIOS directory/usr/local/share/qemu
binary directory /usr/local/bin
Manual directory /usr/local/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path /tmp/qemu-0.9.1
C compilergcc
Host C compiler gcc
make make
install install
host CPU i386
host big endian no
target list i386-linux-user arm-linux-user armeb-linux-user
sparc-linux-user sparc64-linux-user sparc32plus-linux-user
mips-linux-user mipsel-linux-user m68k-linux-user alpha-linux-user
sh4-linux-user sh4eb-linux-user ppc-linux-user ppc64-linux-user
ppc64abi32-linux-user x86_64-linux-user cris-linux-user i386-softmmu
sparc-softmmu x86_64-softmmu mips-softmmu mipsel-softmmu mips64-softmmu
mips64el-softmmu arm-softmmu ppc-softmmu ppcemb-softmmu ppc64-softmmu
m68k-softmmu sh4-softmmu sh4eb-softmmu cris-softmmu
gprof enabled no
profiler no
static build no
-Werror enabled no
SDL support no
mingw32 support no
Adlib support no
CoreAudio support no
ALSA support no
DSound supportno
FMOD support no
OSS support yes
VNC TLS support no
kqemu support yes
Documentation yes
The error log from compiling the libSDL test is:
/tmp/qemu-conf-12652-8745-10418.c:1: SDL.h: No such file or directory
root:/tmp/qemu-0.9.1#
Re: [Qemu-devel] [PATCH] mipsnet incorrect device ID fix
On Thu, Mar 13, 2008 at 01:18:46AM +, Paul Brook wrote: > > That's the '&' which is wrong here. The string can be accessed with > > *((uint32_t *)devid). So you can simply use: > > > > ret = le32_to_cpu(*((uint32_t *)devid)) > > No you can't. Even ignoring the aliasing violation, devid might not be > sufficiently aligned. > Oops you are right, I have been troubled by the original code. As suggested by Paul on IRC, the best is most probably to hardcode the hex values and put the string on a comment. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net
Re: [Qemu-devel] [4/6] ds1225y nvram: Fix some bugs
On Mon, Mar 03, 2008 at 11:45:28AM +0100, Hervé Poussineau wrote:
> Attached files fixes some problems with nvram emulation:
> - whole nvram was erased in some conditions
> - fix out of range accesses
> - improve speed by keeping contents in memory
>
> Sorry to not provide a patch for ds1225y.c, but it contains mixed
> line-endings and my diff/patch tools doesn't like that.
I have fixed the line-terminators in the CVS. Please find below the
diff, with inline comments.
> diff --git a/hw/ds1225y.c b/hw/ds1225y.c
> index 2b3f02e..a0c52a8 100644
> --- a/hw/ds1225y.c
> +++ b/hw/ds1225y.c
> @@ -1,8 +1,8 @@
> /*
> * QEMU NVRAM emulation for DS1225Y chip
> - *
> - * Copyright (c) 2007 Hervé Poussineau
> - *
> + *
> + * Copyright (c) 2007-2008 Hervé Poussineau
> + *
> * Permission is hereby granted, free of charge, to any person obtaining a
> copy
> * of this software and associated documentation files (the "Software"), to
> deal
> * in the Software without restriction, including without limitation the
> rights
> @@ -26,98 +26,167 @@
> #include "mips.h"
> #include "nvram.h"
>
> -typedef enum
> -{
> -none = 0,
> -readmode,
> -writemode,
> -} nvram_open_mode;
> +//#define DEBUG_NVRAM
>
> -struct ds1225y_t
> +typedef struct ds1225y_t
> {
> target_phys_addr_t mem_base;
> uint32_t capacity;
> -const char *filename;
> QEMUFile *file;
> -nvram_open_mode open_mode;
> -};
> +uint8_t *contents;
> +uint8_t protection;
> +} ds1225y_t;
>
> -static int ds1225y_set_to_mode(ds1225y_t *NVRAM, nvram_open_mode mode, const
> char *filemode)
> -{
> -if (NVRAM->open_mode != mode)
> -{
> -if (NVRAM->file)
> -qemu_fclose(NVRAM->file);
> -NVRAM->file = qemu_fopen(NVRAM->filename, filemode);
> -NVRAM->open_mode = mode;
> -}
> -return (NVRAM->file != NULL);
> -}
>
> static uint32_t nvram_readb (void *opaque, target_phys_addr_t addr)
> {
> -ds1225y_t *NVRAM = opaque;
> +ds1225y_t *s = opaque;
> int64_t pos;
> +uint32_t val;
> +
> +pos = addr - s->mem_base;
> +if (pos >= s->capacity)
> +pos -= s->capacity;
>
> -pos = addr - NVRAM->mem_base;
> -if (addr >= NVRAM->capacity)
> -addr -= NVRAM->capacity;
> +val = s->contents[pos];
>
> -if (!ds1225y_set_to_mode(NVRAM, readmode, "rb"))
> -return 0;
> -qemu_fseek(NVRAM->file, pos, SEEK_SET);
> -return (uint32_t)qemu_get_byte(NVRAM->file);
> +#ifdef DEBUG_NVRAM
> +printf("nvram: read 0x%x at " TARGET_FMT_lx "\n", val, addr);
> +#endif
> +return val;
> +}
> +
> +static uint32_t nvram_readw (void *opaque, target_phys_addr_t addr)
> +{
> +uint32_t v;
> +v = nvram_readb(opaque, addr);
> +v |= nvram_readb(opaque, addr + 1) << 8;
> +return v;
> }
>
> -static void nvram_writeb (void *opaque, target_phys_addr_t addr, uint32_t
> value)
> +static uint32_t nvram_readl (void *opaque, target_phys_addr_t addr)
> {
> -ds1225y_t *NVRAM = opaque;
> +uint32_t v;
> +v = nvram_readb(opaque, addr);
> +v |= nvram_readb(opaque, addr + 1) << 8;
> +v |= nvram_readb(opaque, addr + 2) << 16;
> +v |= nvram_readb(opaque, addr + 3) << 24;
> +return v;
> +}
> +
> +static void nvram_writeb (void *opaque, target_phys_addr_t addr, uint32_t
> val)
> +{
> +ds1225y_t *s = opaque;
> int64_t pos;
>
> -pos = addr - NVRAM->mem_base;
> -if (ds1225y_set_to_mode(NVRAM, writemode, "wb"))
> -{
> -qemu_fseek(NVRAM->file, pos, SEEK_SET);
> -qemu_put_byte(NVRAM->file, (int)value);
> +#ifdef DEBUG_NVRAM
> +printf("nvram: write 0x%x at " TARGET_FMT_lx "\n", val, addr);
> +#endif
> +
> +pos = addr - s->mem_base;
> +s->contents[pos] = val & 0xff;
> +if (s->file) {
> +qemu_fseek(s->file, pos, SEEK_SET);
> +qemu_put_byte(s->file, (int)val);
> +qemu_fflush(s->file);
> }
> }
>
> +static void nvram_writew (void *opaque, target_phys_addr_t addr, uint32_t
> val)
> +{
> +nvram_writeb(opaque, addr, val & 0xff);
> +nvram_writeb(opaque, addr + 1, (val >> 8) & 0xff);
> +}
> +
> +static void nvram_writel (void *opaque, target_phys_addr_t addr, uint32_t
> val)
> +{
> +nvram_writeb(opaque, addr, val & 0xff);
> +nvram_writeb(opaque, addr + 1, (val >> 8) & 0xff);
> +nvram_writeb(opaque, addr + 2, (val >> 16) & 0xff);
> +nvram_writeb(opaque, addr + 3, (val >> 24) & 0xff);
> +}
> +
> +static void nvram_writeb_protected (void *opaque, target_phys_addr_t addr,
> uint32_t val)
> +{
> +ds1225y_t *s = opaque;
> +
> +if (s->protection != 7) {
> +#ifdef DEBUG_NVRAM
> +printf("nvram: prevent write of 0x%x at " TARGET_FMT_lx "\n", val, addr);
> +#endif
> +return;
> +}
> +
> +nvram_writeb(opaque, addr - s->capacity, val);
> +}
> +
> +static void nvram_writew_protected (void *opaque, target_phys_addr_t addr,
> uint32_t val)
> +{
> +nvram_writeb_protected(opaque, addr, val & 0xff);
>
[Qemu-devel] qemu/hw ds1225y.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Aurelien Jarno 08/03/13 01:19:15 Modified files: hw : ds1225y.c Log message: Convert from DOS to UNIX format, no code change. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ds1225y.c?cvsroot=qemu&r1=1.3&r2=1.4
Re: [Qemu-devel] [PATCH] mipsnet incorrect device ID fix
> That's the '&' which is wrong here. The string can be accessed with > *((uint32_t *)devid). So you can simply use: > > ret = le32_to_cpu(*((uint32_t *)devid)) No you can't. Even ignoring the aliasing violation, devid might not be sufficiently aligned. Paul
Re: [Qemu-devel] [PATCH] mipsnet incorrect device ID fix
On Fri, Feb 22, 2008 at 06:16:25AM +0530, Vijay Kumar wrote:
> The mipsnet device returns wrong values for device ID, since it returns
> the contents of the pointer rather that the contents of the device ID
> string. Also the contents of the string is returned such that the order
> is host endianess dependent. The patch fixes both these issues.
>
> Signed-off-by: Vijay Kumar B. <[EMAIL PROTECTED]>
>
> --- qemu-orig/hw/mipsnet.c2007-12-27 11:18:52.0 +0530
> +++ qemu-mod/hw/mipsnet.c 2008-02-20 20:23:44.0 +0530
> @@ -101,6 +101,19 @@
> mipsnet_update_irq(s);
> }
>
> +static uint32_t bytes_to_int32(const unsigned char *arr)
> +{
> +int i;
> +uint32_t ret = 0;
> +int nbytes = sizeof(int32_t);
> +
> +for (i = 0; i < nbytes; i++) {
> + ret = ret << 8 | arr[nbytes - 1 - i];
> +}
> +
> +return ret;
> +}
Why not use le32_to_cpu() which does the same, but in an optimized way?
> static uint32_t mipsnet_ioport_read(void *opaque, uint32_t addr)
> {
> MIPSnetState *s = opaque;
> @@ -110,10 +123,10 @@
> addr &= 0x3f;
> switch (addr) {
> case MIPSNET_DEV_ID:
> - ret = *((uint32_t *)&devid);
> + ret = bytes_to_int32(devid);
That's the '&' which is wrong here. The string can be accessed with
*((uint32_t *)devid). So you can simply use:
ret = le32_to_cpu(*((uint32_t *)devid))
> break;
> case MIPSNET_DEV_ID + 4:
> - ret = *((uint32_t *)(&devid + 4));
> + ret = bytes_to_int32(devid + 4);
ret = le32_to_cpu(*((uint32_t *)devid + 4));
> break;
> case MIPSNET_BUSY:
> ret = s->busy;
>
>
>
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
[Qemu-devel] [PATCH] Fix sci irq set when acpi timer about to wrap
>From 498f162fc9d9fb897c756273c481101a44a220de Mon Sep 17 00:00:00 2001
From: Dor Laor <[EMAIL PROTECTED]>
Date: Thu, 13 Mar 2008 00:11:41 +0200
Subject: [PATCH] Fix sci irq set when acpi timer about to wrap.
The acpi timer should generate sci irq when enabled and
when bit 23 of the timer counter toogles.
It fixes time reading by the performance counter api of windows guest.
Signed-off-by: Yaniv Kamay <[EMAIL PROTECTED]>
Signed-off-by: Dor Laor <[EMAIL PROTECTED]>
---
qemu/hw/acpi.c | 81
+--
1 files changed, 43 insertions(+), 38 deletions(-)
diff --git a/qemu/hw/acpi.c b/qemu/hw/acpi.c
index e44c8b5..8c47969 100644
--- a/qemu/hw/acpi.c
+++ b/qemu/hw/acpi.c
@@ -53,12 +53,15 @@ typedef struct PIIX4PMState {
uint8_t smb_data[32];
uint8_t smb_index;
qemu_irq irq;
+int64_t pmtmr;
} PIIX4PMState;
#define RTC_EN (1 << 10)
#define PWRBTN_EN (1 << 8)
#define GBL_EN (1 << 5)
#define TMROF_EN (1 << 0)
+#define TIMER_OVERFLOW_CNT (1 << 23)
+#define TIMER_MASK 0xffLL
#define SCI_EN (1 << 0)
@@ -77,47 +80,58 @@ typedef struct PIIX4PMState {
PIIX4PMState *pm_state;
+static void update_pmtmr(PIIX4PMState *s)
+{
+int64_t pmtmr;
+
+pmtmr = muldiv64(qemu_get_clock(vm_clock), PM_FREQ, ticks_per_sec)
& TIMER_MASK;
+
+if (!(s->pmsts & TMROF_EN)) {
+if ((pmtmr ^ s->pmtmr) & TIMER_OVERFLOW_CNT) {
+s->pmsts |= TMROF_EN;
+if (s->pmen & TMROF_EN)
+qemu_set_irq(s->irq, 1);
+} else {
+/* Calculate when the timer will neet to set the overflow
bit again */
+uint64_t delta = TIMER_OVERFLOW_CNT - (pmtmr &
(TIMER_OVERFLOW_CNT - 1));
+
+delta = muldiv64(delta, ticks_per_sec, PM_FREQ);
+qemu_mod_timer(s->tmr_timer, qemu_get_clock(vm_clock) +
delta);
+}
+}
+
+s->pmtmr = pmtmr;
+}
+
static uint32_t get_pmtmr(PIIX4PMState *s)
{
-uint32_t d;
-d = muldiv64(qemu_get_clock(vm_clock), PM_FREQ, ticks_per_sec);
-return d & 0xff;
+ update_pmtmr(s);
+ return s->pmtmr & TIMER_MASK;
}
+
static int get_pmsts(PIIX4PMState *s)
{
-int64_t d;
-int pmsts;
-pmsts = s->pmsts;
-d = muldiv64(qemu_get_clock(vm_clock), PM_FREQ, ticks_per_sec);
-if (d >= s->tmr_overflow_time)
-s->pmsts |= TMROF_EN;
-return pmsts;
+/* Just increase the accurancy by double computing the timer value
*/
+update_pmtmr(s);
+
+return s->pmsts;
}
static void pm_update_sci(PIIX4PMState *s)
{
-int sci_level, pmsts;
-int64_t expire_time;
-
-pmsts = get_pmsts(s);
-sci_level = (((pmsts & s->pmen) &
- (RTC_EN | PWRBTN_EN | GBL_EN | TMROF_EN)) != 0);
-qemu_set_irq(s->irq, sci_level);
-/* schedule a timer interruption if needed */
-if ((s->pmen & TMROF_EN) && !(pmsts & TMROF_EN)) {
-expire_time = muldiv64(s->tmr_overflow_time, ticks_per_sec,
PM_FREQ);
-qemu_mod_timer(s->tmr_timer, expire_time);
-s->tmr_overflow_time += 0x80;
-} else {
-qemu_del_timer(s->tmr_timer);
-}
+int sci_level;
+
+sci_level = (((s->pmsts & s->pmen) &
+ (RTC_EN | PWRBTN_EN | GBL_EN | TMROF_EN)) != 0);
+if (!sci_level)
+qemu_set_irq(s->irq, sci_level);
}
static void pm_tmr_timer(void *opaque)
{
PIIX4PMState *s = opaque;
-pm_update_sci(s);
+update_pmtmr(s);
}
static void pm_ioport_writew(void *opaque, uint32_t addr, uint32_t val)
@@ -126,18 +140,9 @@ static void pm_ioport_writew(void *opaque, uint32_t
addr, uint32_t val)
addr &= 0x3f;
switch(addr) {
case 0x00:
-{
-int64_t d;
-int pmsts;
-pmsts = get_pmsts(s);
-if (pmsts & val & TMROF_EN) {
-/* if TMRSTS is reset, then compute the new overflow
time */
-d = muldiv64(qemu_get_clock(vm_clock), PM_FREQ,
ticks_per_sec);
-s->tmr_overflow_time = (d + 0x80LL) & ~0x7fLL;
-}
-s->pmsts &= ~val;
-pm_update_sci(s);
-}
+s->pmsts &= ~val;
+update_pmtmr(s);
+pm_update_sci(s);
break;
case 0x02:
s->pmen = val;
--
1.5.4.1
0001-Fix-sci-irq-set-when-acpi-timer-about-to-wrap.patch
Description: application/mbox
Re: [Qemu-devel] Re: [PATCH] e1000: fix endianness issues
On Wed, Mar 12, 2008 at 03:38:55PM +0100, Aurelien Jarno wrote:
> On Wed, Mar 12, 2008 at 08:52:00AM -0500, Hollis Blanchard wrote:
> > On Tue, 2008-03-11 at 23:49 +0100, Aurelien Jarno wrote:
> > > On Sat, Mar 08, 2008 at 11:08:48AM -0600, Hollis Blanchard wrote:
> > > > On Sat, 2008-03-08 at 14:59 +0100, Aurelien Jarno wrote:
> > > > > On Fri, Mar 07, 2008 at 11:23:51AM -0600, Hollis Blanchard wrote:
> > > > > > Below is a patch I'm using to fix rtl8139.c for PowerPC/PowerPC
> > > > > > target/host combination. It works enough for the target to send a
> > > > > > DHCP
> > > > > > request and get a response from slirp, but other unrelated bugs
> > > > > > prevent
> > > > > > me from testing it more thoroughly. (I'm only sending it now at
> > > > > > Aurelien's request.) Other code that I know is broken (because I've
> > > > > > tried to use it) include isa_mmio.c and pci_host.h, but I don't have
> > > > > > patches for these at this time.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > Fix endianness conversion in rtl8139.c.
> > > > > >
> > > > > > PCI data is always in LE format, so convert from LE at the
> > > > > > interface to
> > > > > > "qemu endianness" internally, then convert again on the way back
> > > > > > out.
> > > > > >
> > > > > > Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]>
> > > > > >
> > > > > > diff --git a/qemu/hw/rtl8139.c b/qemu/hw/rtl8139.c
> > > > > > --- a/qemu/hw/rtl8139.c
> > > > > > +++ b/qemu/hw/rtl8139.c
> > >
> > > [snip]
> > >
> > > > > > @@ -3091,12 +3067,12 @@ static void rtl8139_mmio_writeb(void *op
> > > > > >
> > > > > > static void rtl8139_mmio_writew(void *opaque, target_phys_addr_t
> > > > > > addr, uint32_t val)
> > > > > > {
> > > > > > -rtl8139_io_writew(opaque, addr & 0xFF, val);
> > > > > > +rtl8139_io_writew(opaque, addr & 0xFF, le16_to_cpu(val));
> > > > > > }
> > > > > >
> > > > > > static void rtl8139_mmio_writel(void *opaque, target_phys_addr_t
> > > > > > addr, uint32_t val)
> > > > > > {
> > > > > > -rtl8139_io_writel(opaque, addr & 0xFF, val);
> > > > > > +rtl8139_io_writel(opaque, addr & 0xFF, le32_to_cpu(val));
> > > > > > }
> > > > > >
> > > > > > static uint32_t rtl8139_mmio_readb(void *opaque,
> > > > > > target_phys_addr_t addr)
> > > > > > @@ -3106,12 +3082,12 @@ static uint32_t rtl8139_mmio_readb(void
> > > > > >
> > > > > > static uint32_t rtl8139_mmio_readw(void *opaque,
> > > > > > target_phys_addr_t addr)
> > > > > > {
> > > > > > -return rtl8139_io_readw(opaque, addr & 0xFF);
> > > > > > +return cpu_to_le16(rtl8139_io_readw(opaque, addr & 0xFF));
> > > > > > }
> > > > > >
> > > > > > static uint32_t rtl8139_mmio_readl(void *opaque,
> > > > > > target_phys_addr_t addr)
> > > > > > {
> > > > > > -return rtl8139_io_readl(opaque, addr & 0xFF);
> > > > > > +return cpu_to_le32(rtl8139_io_readl(opaque, addr & 0xFF));
> > > > > > }
> > > > > >
> > > > >
> > > > > Are those changes really necessary? The rtl8139 emulation works
> > > > > correctly on a big endian host (tested with an i386 target). This part
> > > > > of the patch would probably break it. Unless the Linux driver only
> > > > > does
> > > > > byte accesses, which are not changed by this patch.
> > >
> > > I have tested this part of the patch on a big endian host (PowerPC), and
> > > I confirm it breaks the rtl8139 emulation (tested on i386 and mipsel
> > > targets).
> >
> > OK, I will do some regression testing too before I submit a patch for
> > inclusion.
> >
> > > > Hmm, yes, there is a problem with this patch. In the "touching many
> > > > 1-byte registers as a single 4-byte access" change to rtl8139_io_readl()
> > > > above, we made sure that the result was LE. What we should have done is
> > > > make it host-endianness like all the other return values from
> > > > rtl8139_io_readl(). Then in rtl8139_mmio_readl(), we know we must swap
> > > > host->LE.
> > > >
> > > > I don't know why rtl8139 would work today with LE/BE target/host, but if
> > > > it does, it must be due to swapping in another layer, because this patch
> > > > is the right thing to do here. If qemu currently swaps 5 times and that
> > > > comes out the same as swapping once, we still need to fix it... :)
> > >
> > > I hope the discussion on IRC last week-end convinced you that you don't
> > > need to swap the value depending on the host endianness.
> >
> > Absolutely not! At least, not with the current qemu design.
> >
> > > For those who
> > > haven't followed the discussion, qemu does memory accesses with a couple
> > > (address, value). The addresses and values are always stored in host
> > > endianness, and this does not need to be swapped depending on the host.
> > > It may have to be swapped depending on the target, if the value is
> > > swapped on the real hardware (bus connected backward, chipset, etc.)
> > >
> > > Thanks to Paul Brook for all the explanations.
> >
> > The scheme Paul outlined (but hasn't
[Qemu-devel] qemu/tcg README
CVSROOT:/sources/qemu Module name:qemu Changes by: Aurelien Jarno 08/03/12 21:40:02 Modified files: tcg: README Log message: TCG README fixes (Stuart Brady) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/README?cvsroot=qemu&r1=1.3&r2=1.4
[Qemu-devel] vmwarevga regression (broken with two Linux and FreeBSD guests)
Hmm. Looks like the latest vmwarevga commits broke *ix/xorg guests. I tested the 2008-03-11 cvs snapshot with sidux-2008-01-200803010113-nyx_pre1-kde-lite-i386.iso (debian sid based Linux livecd) and FreeSBIE-2.0.1-RELEASE.iso (FreeBSD based livecd), on sidux xorg said: (WW) INVALID MEM ALLOCATION b: 0xf000 e: 0xf07f correcting and the xserver display was garbage, and on FreeSBIE xorg didn't even start, showing a similar complaint. (both with Driver "vmware" in xorg.conf) Do the latest commits need a bios update maybe? Anyway, a 2008-03-02 snapshot works (now committed as FreeBSD qemu-devel port), at least for these two guests (I don't have a windows guest here atm.) FreeSBIE even was able to attach ed0 (the default ne2kpci nic) as well as the emulated es1370 soundcard, which didn't work previously when using vmwarevga. Just thought I'd mention... :) Juergen
[Qemu-devel] [PATCH] TCG README fixes
Hi, The included patch fixes a few glitches in the TCG README file. Please apply. Cheers, -- Stuart Brady diff -urN qemu-orig/tcg/README qemu-new/tcg/README --- qemu-orig/tcg/README2008-02-04 11:21:46.0 + +++ qemu-new/tcg/README 2008-03-12 19:50:19.0 + @@ -223,10 +223,10 @@ t0=t1%t2 (unsigned). Undefined behavior if division by zero. -* and_i32/i64 t0, t1, t2 - * Logical +* and_i32/i64 t0, t1, t2 + t0=t1&t2 * or_i32/i64 t0, t1, t2 @@ -237,8 +237,6 @@ t0=t1^t2 -* shl_i32/i64 t0, t1, t2 - * Shifts * shl_i32/i64 t0, t1, t2
[Qemu-devel] [PATCH] implement sysrq for the pl011
Implement sysrq for the pl011. This was tested on
the ARM Versatile AB + kernel.org 2.6.X kernel.
Signed-off-by: Jason Wessel <[EMAIL PROTECTED]>
---
hw/pl011.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
--- a/hw/pl011.c
+++ b/hw/pl011.c
@@ -208,7 +208,24 @@ static void pl011_receive(void *opaque,
static void pl011_event(void *opaque, int event)
{
-/* ??? Should probably implement break. */
+if (event == CHR_EVENT_BREAK) {
+pl011_state *s = (pl011_state *)opaque;
+int slot;
+
+slot = s->read_pos + s->read_count;
+if (slot >= 16)
+slot -= 16;
+s->read_fifo[slot] = 0x400;
+s->read_count++;
+s->flags &= ~PL011_FLAG_RXFE;
+if (s->cr & 0x10 || s->read_count == 16) {
+s->flags |= PL011_FLAG_RXFF;
+}
+if (s->read_count == s->read_trigger) {
+s->int_level |= PL011_INT_RX;
+pl011_update(s);
+}
+}
}
static CPUReadMemoryFunc *pl011_readfn[] = {
Re: [Qemu-devel] Re: [PATCH] e1000: fix endianness issues
On Wed, Mar 12, 2008 at 08:52:00AM -0500, Hollis Blanchard wrote:
> On Tue, 2008-03-11 at 23:49 +0100, Aurelien Jarno wrote:
> > On Sat, Mar 08, 2008 at 11:08:48AM -0600, Hollis Blanchard wrote:
> > > On Sat, 2008-03-08 at 14:59 +0100, Aurelien Jarno wrote:
> > > > On Fri, Mar 07, 2008 at 11:23:51AM -0600, Hollis Blanchard wrote:
> > > > > Below is a patch I'm using to fix rtl8139.c for PowerPC/PowerPC
> > > > > target/host combination. It works enough for the target to send a DHCP
> > > > > request and get a response from slirp, but other unrelated bugs
> > > > > prevent
> > > > > me from testing it more thoroughly. (I'm only sending it now at
> > > > > Aurelien's request.) Other code that I know is broken (because I've
> > > > > tried to use it) include isa_mmio.c and pci_host.h, but I don't have
> > > > > patches for these at this time.
> > > >
> > > >
> > > >
> > > >
> > > > > Fix endianness conversion in rtl8139.c.
> > > > >
> > > > > PCI data is always in LE format, so convert from LE at the interface
> > > > > to
> > > > > "qemu endianness" internally, then convert again on the way back out.
> > > > >
> > > > > Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]>
> > > > >
> > > > > diff --git a/qemu/hw/rtl8139.c b/qemu/hw/rtl8139.c
> > > > > --- a/qemu/hw/rtl8139.c
> > > > > +++ b/qemu/hw/rtl8139.c
> >
> > [snip]
> >
> > > > > @@ -3091,12 +3067,12 @@ static void rtl8139_mmio_writeb(void *op
> > > > >
> > > > > static void rtl8139_mmio_writew(void *opaque, target_phys_addr_t
> > > > > addr, uint32_t val)
> > > > > {
> > > > > -rtl8139_io_writew(opaque, addr & 0xFF, val);
> > > > > +rtl8139_io_writew(opaque, addr & 0xFF, le16_to_cpu(val));
> > > > > }
> > > > >
> > > > > static void rtl8139_mmio_writel(void *opaque, target_phys_addr_t
> > > > > addr, uint32_t val)
> > > > > {
> > > > > -rtl8139_io_writel(opaque, addr & 0xFF, val);
> > > > > +rtl8139_io_writel(opaque, addr & 0xFF, le32_to_cpu(val));
> > > > > }
> > > > >
> > > > > static uint32_t rtl8139_mmio_readb(void *opaque, target_phys_addr_t
> > > > > addr)
> > > > > @@ -3106,12 +3082,12 @@ static uint32_t rtl8139_mmio_readb(void
> > > > >
> > > > > static uint32_t rtl8139_mmio_readw(void *opaque, target_phys_addr_t
> > > > > addr)
> > > > > {
> > > > > -return rtl8139_io_readw(opaque, addr & 0xFF);
> > > > > +return cpu_to_le16(rtl8139_io_readw(opaque, addr & 0xFF));
> > > > > }
> > > > >
> > > > > static uint32_t rtl8139_mmio_readl(void *opaque, target_phys_addr_t
> > > > > addr)
> > > > > {
> > > > > -return rtl8139_io_readl(opaque, addr & 0xFF);
> > > > > +return cpu_to_le32(rtl8139_io_readl(opaque, addr & 0xFF));
> > > > > }
> > > > >
> > > >
> > > > Are those changes really necessary? The rtl8139 emulation works
> > > > correctly on a big endian host (tested with an i386 target). This part
> > > > of the patch would probably break it. Unless the Linux driver only does
> > > > byte accesses, which are not changed by this patch.
> >
> > I have tested this part of the patch on a big endian host (PowerPC), and
> > I confirm it breaks the rtl8139 emulation (tested on i386 and mipsel
> > targets).
>
> OK, I will do some regression testing too before I submit a patch for
> inclusion.
>
> > > Hmm, yes, there is a problem with this patch. In the "touching many
> > > 1-byte registers as a single 4-byte access" change to rtl8139_io_readl()
> > > above, we made sure that the result was LE. What we should have done is
> > > make it host-endianness like all the other return values from
> > > rtl8139_io_readl(). Then in rtl8139_mmio_readl(), we know we must swap
> > > host->LE.
> > >
> > > I don't know why rtl8139 would work today with LE/BE target/host, but if
> > > it does, it must be due to swapping in another layer, because this patch
> > > is the right thing to do here. If qemu currently swaps 5 times and that
> > > comes out the same as swapping once, we still need to fix it... :)
> >
> > I hope the discussion on IRC last week-end convinced you that you don't
> > need to swap the value depending on the host endianness.
>
> Absolutely not! At least, not with the current qemu design.
>
> > For those who
> > haven't followed the discussion, qemu does memory accesses with a couple
> > (address, value). The addresses and values are always stored in host
> > endianness, and this does not need to be swapped depending on the host.
> > It may have to be swapped depending on the target, if the value is
> > swapped on the real hardware (bus connected backward, chipset, etc.)
> >
> > Thanks to Paul Brook for all the explanations.
>
> The scheme Paul outlined (but hasn't actually proposed as far as I've
> seen) involved an end-to-end overhaul of endianness manipulations in
> qemu, removing byte swapping from some device emulation and adding some
> to bus layers. I still don't understand his entire idea, and I think
> some prototype code will be needed to see it. Until/unless
Re: [Qemu-devel] [PATCH] x86 Multiboot support (extended)
Alexander Graf wrote: On Mar 12, 2008, at 5:57 AM, Anthony Liguori wrote: Aurelien Jarno wrote: On Thu, Jan 31, 2008 at 06:31:09PM +0100, Alexander Graf wrote: Is it really necessary to have *that much* assembly code within hw/pc.c? I would rather see multiboot support as a small image generated from C and/or assembly code, loaded either with -hda or with a new option having the same effect. This code could read the NVRAM to get the variables it needs. Better yet to package it as an option ROM and eliminate all the boot sector hacks. Better yet to package all kernel loading hacks in your option ROM and eliminate the bootsector hacks. Mind to do it? ;-). It's on my TODO, just not very high at the moment. Regards, Anthony Liguori Alex
Re: [Qemu-devel] Re: [PATCH] e1000: fix endianness issues
On Tue, 2008-03-11 at 23:49 +0100, Aurelien Jarno wrote:
> On Sat, Mar 08, 2008 at 11:08:48AM -0600, Hollis Blanchard wrote:
> > On Sat, 2008-03-08 at 14:59 +0100, Aurelien Jarno wrote:
> > > On Fri, Mar 07, 2008 at 11:23:51AM -0600, Hollis Blanchard wrote:
> > > > Below is a patch I'm using to fix rtl8139.c for PowerPC/PowerPC
> > > > target/host combination. It works enough for the target to send a DHCP
> > > > request and get a response from slirp, but other unrelated bugs prevent
> > > > me from testing it more thoroughly. (I'm only sending it now at
> > > > Aurelien's request.) Other code that I know is broken (because I've
> > > > tried to use it) include isa_mmio.c and pci_host.h, but I don't have
> > > > patches for these at this time.
> > >
> > >
> > >
> > >
> > > > Fix endianness conversion in rtl8139.c.
> > > >
> > > > PCI data is always in LE format, so convert from LE at the interface to
> > > > "qemu endianness" internally, then convert again on the way back out.
> > > >
> > > > Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]>
> > > >
> > > > diff --git a/qemu/hw/rtl8139.c b/qemu/hw/rtl8139.c
> > > > --- a/qemu/hw/rtl8139.c
> > > > +++ b/qemu/hw/rtl8139.c
>
> [snip]
>
> > > > @@ -3091,12 +3067,12 @@ static void rtl8139_mmio_writeb(void *op
> > > >
> > > > static void rtl8139_mmio_writew(void *opaque, target_phys_addr_t addr,
> > > > uint32_t val)
> > > > {
> > > > -rtl8139_io_writew(opaque, addr & 0xFF, val);
> > > > +rtl8139_io_writew(opaque, addr & 0xFF, le16_to_cpu(val));
> > > > }
> > > >
> > > > static void rtl8139_mmio_writel(void *opaque, target_phys_addr_t addr,
> > > > uint32_t val)
> > > > {
> > > > -rtl8139_io_writel(opaque, addr & 0xFF, val);
> > > > +rtl8139_io_writel(opaque, addr & 0xFF, le32_to_cpu(val));
> > > > }
> > > >
> > > > static uint32_t rtl8139_mmio_readb(void *opaque, target_phys_addr_t
> > > > addr)
> > > > @@ -3106,12 +3082,12 @@ static uint32_t rtl8139_mmio_readb(void
> > > >
> > > > static uint32_t rtl8139_mmio_readw(void *opaque, target_phys_addr_t
> > > > addr)
> > > > {
> > > > -return rtl8139_io_readw(opaque, addr & 0xFF);
> > > > +return cpu_to_le16(rtl8139_io_readw(opaque, addr & 0xFF));
> > > > }
> > > >
> > > > static uint32_t rtl8139_mmio_readl(void *opaque, target_phys_addr_t
> > > > addr)
> > > > {
> > > > -return rtl8139_io_readl(opaque, addr & 0xFF);
> > > > +return cpu_to_le32(rtl8139_io_readl(opaque, addr & 0xFF));
> > > > }
> > > >
> > >
> > > Are those changes really necessary? The rtl8139 emulation works
> > > correctly on a big endian host (tested with an i386 target). This part
> > > of the patch would probably break it. Unless the Linux driver only does
> > > byte accesses, which are not changed by this patch.
>
> I have tested this part of the patch on a big endian host (PowerPC), and
> I confirm it breaks the rtl8139 emulation (tested on i386 and mipsel
> targets).
OK, I will do some regression testing too before I submit a patch for
inclusion.
> > Hmm, yes, there is a problem with this patch. In the "touching many
> > 1-byte registers as a single 4-byte access" change to rtl8139_io_readl()
> > above, we made sure that the result was LE. What we should have done is
> > make it host-endianness like all the other return values from
> > rtl8139_io_readl(). Then in rtl8139_mmio_readl(), we know we must swap
> > host->LE.
> >
> > I don't know why rtl8139 would work today with LE/BE target/host, but if
> > it does, it must be due to swapping in another layer, because this patch
> > is the right thing to do here. If qemu currently swaps 5 times and that
> > comes out the same as swapping once, we still need to fix it... :)
>
> I hope the discussion on IRC last week-end convinced you that you don't
> need to swap the value depending on the host endianness.
Absolutely not! At least, not with the current qemu design.
> For those who
> haven't followed the discussion, qemu does memory accesses with a couple
> (address, value). The addresses and values are always stored in host
> endianness, and this does not need to be swapped depending on the host.
> It may have to be swapped depending on the target, if the value is
> swapped on the real hardware (bus connected backward, chipset, etc.)
>
> Thanks to Paul Brook for all the explanations.
The scheme Paul outlined (but hasn't actually proposed as far as I've
seen) involved an end-to-end overhaul of endianness manipulations in
qemu, removing byte swapping from some device emulation and adding some
to bus layers. I still don't understand his entire idea, and I think
some prototype code will be needed to see it. Until/unless that is
implemented, we will continue to require swapping in the device
emulation.
> Basically that means that one part of my e1000 part is actually correct,
> while the other is correct in the case of the MIPS Malta machine, but
> may be wrong for other targets/machines. I am therefore planning to
Re: [Qemu-devel] [PATCH] x86 Multiboot support (extended)
On Mar 12, 2008, at 5:57 AM, Anthony Liguori wrote: Aurelien Jarno wrote: On Thu, Jan 31, 2008 at 06:31:09PM +0100, Alexander Graf wrote: Is it really necessary to have *that much* assembly code within hw/ pc.c? I would rather see multiboot support as a small image generated from C and/or assembly code, loaded either with -hda or with a new option having the same effect. This code could read the NVRAM to get the variables it needs. Better yet to package it as an option ROM and eliminate all the boot sector hacks. Better yet to package all kernel loading hacks in your option ROM and eliminate the bootsector hacks. Mind to do it? ;-). Alex
Re: [Qemu-devel] [PATCH] x86 Multiboot support (extended)
On Mar 12, 2008, at 12:44 AM, Aurelien Jarno wrote:
On Thu, Jan 31, 2008 at 06:31:09PM +0100, Alexander Graf wrote:
On Jan 31, 2008, at 10:58 AM, Kevin Wolf wrote:
Hi,
I like this idea. When I just tried to load my multiboot kernel it
failed, though, because of the following piece of code:
+// XXX: multiboot header may be within the first 8192 bytes,
but header
+// is only the first 1024
+
+// Ok, let's see if it is a multiboot image
+for(i=0; i<(256 - 12); i+=4) { // the header is 12x32bit long
+if(ldl_p(header+i) == 0x1BADB002) {
I wonder if there is any reason why you didn't just replace the 1024
by
8192 in load_linux but added an XXX. Would this cause any problems I
missed? With this change and replacing 256 by 8192 in the above code
it
works for my kernel, too.
Anyway, I think the for condition should be i < 4 * (256 - 12), even
without changing the 1024.
This version should fix the long header issue. I made the linux
loader
fetch the first 8kb as header, so multiboot can search through all
necessary data.
I also implemented module parameters. Kevin needed this to boot a
homebrew kernel. You can now pass commandline parameters to the
multiboot modules by adding them after the filename, seperated
through a
space. This is the very same approach grub takes.
To boot a xen kernel you would give a command line like this:
qemu -hda image -kernel xen -initrd "vmlinux-xen root=/dev/
hda,initrd-
xen"
This way the vmlinux module gets the command line parameter "root=/
dev/
hda".
diff --git a/elf_ops.h b/elf_ops.h
index 6126565..ab5fd7b 100644
--- a/elf_ops.h
+++ b/elf_ops.h
@@ -156,6 +156,10 @@ static int glue(load_elf, SZ)(int fd, int64_t
virt_to_phys_addend,
}
if (ELF_MACHINE != ehdr.e_machine)
+#if (ELF_MACHINE == EM_X86_64) && !CONFIG_USER_ONLY
+ /* x86_64 systems can run i386 code as well */
+ if(ehdr.e_machine != EM_386)
+#endif
goto fail;
if (pentry)
diff --git a/hw/pc.c b/hw/pc.c
index b4f0db7..4c5ee94 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -480,6 +480,416 @@ static long get_file_size(FILE *f)
return size;
}
+/* Generate an initial boot sector which sets state and jump to
+ a specified vector */
+static void generate_bootsect_multiboot(uint32_t mh_entry_addr,
uint32_t bootinfo)
+{
+uint8_t bootsect[512], *p, *pgdt, *pmmaploop;
+uint32_t ip;
+int i;
+int hda;
+int mmaploop;
+
+hda = drive_get_index(IF_IDE, 0, 0);
+if (hda == -1) {
+ fprintf(stderr, "A disk image must be given for 'hda' when
booting "
+ "a Multiboot kernel\n");
+ exit(1);
+}
+
+memset(bootsect, 0, sizeof(bootsect));
+
+/* Copy the MSDOS partition table if possible */
+bdrv_read(drives_table[hda].bdrv, 0, bootsect, 1);
+
+/* Make sure we have a partition signature */
+bootsect[510] = 0x55;
+bootsect[511] = 0xaa;
+
+/* Actual code */
+p = bootsect;
+*p++ = 0xfa;/* CLI */
+*p++ = 0xfc;/* CLD */
+
+// 660f01152800 lgdt[0x28]
+*p++ = 0x66;/* 32-bit operand size */
+*p++ = 0x67;/* 32-bit addr size */
+*p++ = 0x0f;/* LGDT [0x128] */
+*p++ = 0x01;
+*p++ = 0x15;
+pgdt=p; /* we calculate the gdt position later */
+p+=4;
+
+/* Initialize multiboot mmap structs using the 0x15(e820) */
+*p++ = 0x31;/* XOR BX,BX */
+*p++ = 0xdb;
+
+*p++ = 0x66;/* 32-bit operand size */
+*p++ = 0x67;/* 32-bit addr size */
+*p++ = 0xbf;/* MOV EDI,0x9004 */
+*p++ = 0x04;
+*p++ = 0x90;
+*p++ = 0x00;
+*p++ = 0x00;
+
+pmmaploop = p;
+*p++ = 0x66;/* 32-bit operand size */
+*p++ = 0x67;/* 32-bit addr size */
+*p++ = 0xb8;/* MOV EAX,0x20 */
+*p++ = 0x20;
+*p++ = 0x00;
+*p++ = 0x00;
+*p++ = 0x00;
+
+*p++ = 0x66;/* 32-bit operand size */
+*p++ = 0x67;/* 32-bit addr size */
+*p++ = 0x89;/* MOV -4(EDI),EAX */
+*p++ = 0x47;
+*p++ = 0xfc;
+
+*p++ = 0x66;/* 32-bit operand size */
+*p++ = 0x67;/* 32-bit addr size */
+*p++ = 0xb8;/* MOV EAX,0xe820 */
+*p++ = 0x20;
+*p++ = 0xe8;
+*p++ = 0x00;
+*p++ = 0x00;
+
+*p++ = 0x66;/* 32-bit operand size */
+*p++ = 0x67;/* 32-bit addr size */
+*p++ = 0xba;/* MOV EDX,0x534d4150 */
+*p++ = 0x50;
+*p++ = 0x41;
+*p++ = 0x4d;
+*p++ = 0x53;
+
+*p++ = 0x66;/* 32-bit operand size */
+*p++ = 0x67;/* 32-bit addr size */
+*p++ = 0xb9;/* MOV ECX,0x20 */
+*p++ = 0x20;
+*p++ = 0x00;
+*p++ = 0x00;
+*p++ = 0x00;
+
+*p++ = 0xcd;/* INT 0x15
