Re: [Qemu-devel] [PATCH] Wire g_new() and friends to the qemu_malloc() family

[Blue Swirl]

On Fri, Aug 19, 2011 at 3:22 PM, Avi Kivity  wrote:
> On 08/18/2011 09:54 PM, Peter Maydell wrote:
>>
>> On 18 August 2011 18:48, Avi Kivity  wrote:
>> >  +static GMemVTable gmemvtable = {
>> >  +    .malloc = qemu_malloc,
>> >  +    .realloc = qemu_realloc,
>> >  +    .free = qemu_free,
>> >  +};
>> >  +
>> >  +/**
>> >  + * qemu_malloc_init: initialize memory management
>> >  + */
>> >  +void qemu_malloc_init(void)
>> >  +{
>> >  +    g_mem_set_vtable(&gmemvtable);
>> >  +}
>>
>> Does this mean you can now safely allocate with g_malloc
>> and free with qemu_free, or is mixing the two APIs like that
>> still a no-no ?
>
> You can, but I'd forbid it.  Mixing layers can only lead to tears later on.
>
> Best would be to convert qemu_malloc()s to g_new()s and g_malloc()s to
> reduce confusion.

Also plain malloc() and friends, except in tracing back end for obvious reasons.

>> (I'm thinking about a situation where you might use a glib utility
>> function that returned g_malloc'd memory and want to pass that back
>> to your caller without having to either copy to qemu_malloc'd memory
>> or require your caller to care about the distinction.)
>>
>
> Changing ownership of memory is rare, I hope.
>
> --
> I have a truly marvellous patch that fixes the bug which this
> signature is too narrow to contain.
>
>

Re: [Qemu-devel] sparc32_dma: correctly initialize ledma base address

[Blue Swirl]

On Sat, Aug 20, 2011 at 5:04 AM, Bob Breuer  wrote:
> Mark Cave-Ayland wrote:
>> On 15/08/11 16:38, Bob Breuer wrote:
>>
>>> Depends on the rom.  The SS-5 rom always sets it correctly, whereas the
>>> SS-20 rom only sets it when you do "boot net".  Also, this is just the
>>> top 8 bits of the address.  The DMA2 documentation[1] for E_BASE_ADDR
>>> states that these upper address bits default to 0xff, even though it
>>> seems to incorrectly define it as bits 7:0 in the register instead of
>>> 31:24.
>>
>> Nice one - looks like I missed this when reading the documentation. At
>> least the choice of default address now makes sense.
>
> It might also make sense to modify the dma address calculations to use
> only the top 8 bits from ledma.  Not sure if anything will care about
> that though.

But both ibiblio doc for MACIO and Sun4M System Architecture manual
specify low bits 7:0.

>>> If you follow Artyom's blog, at [2] it was assumed that the bogus dbri
>>> device was the culprit (which is also why I went down the path of
>>> implementing the dbri device), when in reality, the selftest failure
>>> was preventing "boot net" from running and fixing the ledma register
>>> settings.
>>
>> Okay - I think I see ;)  In that case, I'd say this patch should be
>> applied if Blue hasn't already done it (*sigh* I really miss the git web
>> interface on qemu.org).

I haven't applied the patches because OpenBIOS still can't boot due to
the SCSI commits and I'd like to get that resolved first. I think ESP
driver in OpenBIOS is buggy this time.

> http://repo.or.cz/w/qemu.git  might be the next best thing, not sure if
> there is a mirroring delay with it or not.

Right, the web interface situation annoys me too.

Re: [Qemu-devel] Compilation error of coroutine-win32.c with gcc version 3.4.5 (mingw-vista special r3)

[Stefan Weil]

Am 16.08.2011 20:50, schrieb Paolo Bonzini:

On 08/16/2011 05:45 AM, Stefan Hajnoczi wrote:

Roy,
This stack trace does not reveal much.

Is there any MinGW gcc user that has successfully built and run
qemu.git?


I would be surprised if Stefan Weil hasn't.


How did you know that?


Which version/architecture of Windows and which MinGW
version?


QEMU currently only supports 32 bit Windows executables
which work on any current Windows version version
(XP and later, 32 and 64 bit).

I use latest MinGW from http://www.mingw.org/ (native compilation
on Windows) and Debian cross compilations. Those are available
from http://qemu.weilnetz.de/w32/.

Re: [Qemu-devel] [Bug 826363] Re: qemu-img convert does not work with vdi files

[Stefan Weil]

Am 17.08.2011 18:44, schrieb Stefan Hajnoczi:
On Wed, Aug 17, 2011 at 5:29 PM, Stefan Hajnoczi  
wrote:
On Tue, Aug 16, 2011 at 7:07 PM, Steve Si <826...@bugs.launchpad.net> 
wrote:

I got binaries from http://homepage3.nifty.com/takeda-toshiya/

tested under Win 7 64-bit as User=Administrator

qemu10.6 - works  makes  16/08/2011  18:43 3,096,481,792 
test.raw
qemu11.1 - works  makes  16/08/2011  18:43 3,096,481,792 
test.raw

qemu12.1 - crashes !
qemu12.2 - crashes !
qemu12.5 - error while writing


I think this crash->error transition is explained by:

commit 8cef921d18025b4ce4e749eed391308033fee232
Author: TeLeMan 
Date:   Mon Feb 8 16:20:00 2010 +0800

   qemu-img: use the heap instead of the huge stack array for win32

But we still don't know why you are getting the write error.  It would
be fairly easy to find that out by building QEMU from source and
adding fprintf() where the write fails - print out the error code and
sector number.


The current code only supports images (any format) with less than
4 GiB (maybe even less than 2 GiB).

This limitation is caused by the usage of function ftruncate to create
the destination file. ftruncate takes a long (32 bit) parameter.

Linux code also uses ftruncate to create files of a certain size.
This is not a good solution. Extract from the man page:

"However, some non-native file systems do not permit truncate() and
ftruncate() to be used to extend a file beyond its current length:
a notable example on Linux is VFAT."

Re: [Qemu-devel] [Bug 826363] Re: qemu-img convert does not work with vdi files

[Michael Tokarev]

On 20.08.2011 12:50, Stefan Weil wrote:
[]
> Linux code also uses ftruncate to create files of a certain size.
> This is not a good solution. Extract from the man page:
> 
> "However, some non-native file systems do not permit truncate() and
> ftruncate() to be used to extend a file beyond its current length:
> a notable example on Linux is VFAT."

Actually it works now in VFAT too.

/mjt

[Qemu-devel] [PATCH] w32: Fix qemu_ftruncate64

[Stefan Weil]

SetFilePointer returns INVALID_SET_FILE_POINTER when it fails.
In addition, GetLastError must be checked.

The first call of SetFilePointer did not use INVALID_SET_FILE_POINTER,
the second call used wrong error handling.

Signed-off-by: Stefan Weil 
---
 block/raw-win32.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/block/raw-win32.c b/block/raw-win32.c
index e47cfe0..b7dd357 100644
--- a/block/raw-win32.c
+++ b/block/raw-win32.c
@@ -41,6 +41,7 @@ typedef struct BDRVRawState {
 int qemu_ftruncate64(int fd, int64_t length)
 {
 LARGE_INTEGER li;
+DWORD dw;
 LONG high;
 HANDLE h;
 BOOL res;
@@ -53,12 +54,15 @@ int qemu_ftruncate64(int fd, int64_t length)
 /* get current position, ftruncate do not change position */
 li.HighPart = 0;
 li.LowPart = SetFilePointer (h, 0, &li.HighPart, FILE_CURRENT);
-if (li.LowPart == 0xUL && GetLastError() != NO_ERROR)
+if (li.LowPart == INVALID_SET_FILE_POINTER && GetLastError() != NO_ERROR) {
return -1;
+}
 
 high = length >> 32;
-if (!SetFilePointer(h, (DWORD) length, &high, FILE_BEGIN))
+dw = SetFilePointer(h, (DWORD) length, &high, FILE_BEGIN);
+if (dw == INVALID_SET_FILE_POINTER && GetLastError() != NO_ERROR) {
return -1;
+}
 res = SetEndOfFile(h);
 
 /* back to old position */
-- 
1.7.2.5

Re: [Qemu-devel] [Bug 826363] Re: qemu-img convert does not work with vdi files

[Stefan Weil]

Am 20.08.2011 10:50, schrieb Stefan Weil:

Am 17.08.2011 18:44, schrieb Stefan Hajnoczi:
On Wed, Aug 17, 2011 at 5:29 PM, Stefan Hajnoczi  
wrote:
On Tue, Aug 16, 2011 at 7:07 PM, Steve Si 
<826...@bugs.launchpad.net> wrote:

I got binaries from http://homepage3.nifty.com/takeda-toshiya/

tested under Win 7 64-bit as User=Administrator

qemu10.6 - works  makes  16/08/2011  18:43 3,096,481,792 
test.raw
qemu11.1 - works  makes  16/08/2011  18:43 3,096,481,792 
test.raw

qemu12.1 - crashes !
qemu12.2 - crashes !
qemu12.5 - error while writing


I think this crash->error transition is explained by:

commit 8cef921d18025b4ce4e749eed391308033fee232
Author: TeLeMan 
Date:   Mon Feb 8 16:20:00 2010 +0800

   qemu-img: use the heap instead of the huge stack array for win32

But we still don't know why you are getting the write error.  It would
be fairly easy to find that out by building QEMU from source and
adding fprintf() where the write fails - print out the error code and
sector number.


The current code only supports images (any format) with less than
4 GiB (maybe even less than 2 GiB).

This limitation is caused by the usage of function ftruncate to create
the destination file. ftruncate takes a long (32 bit) parameter.


I did not notice that ftruncate is mapped to qemu_ftruncate64, so my
analysis was not correct. The implementation of qemu_ftruncate64
was buggy. It's fixed now, and working binaries are available from
http://qemu.weilnetz.de/w32/2011-08-20/.

Re: [Qemu-devel] [PATCH] w32: Fix qemu_ftruncate64

[Stefan Weil]

Am 20.08.2011 12:10, schrieb Stefan Weil:

SetFilePointer returns INVALID_SET_FILE_POINTER when it fails.
In addition, GetLastError must be checked.

The first call of SetFilePointer did not use INVALID_SET_FILE_POINTER,
the second call used wrong error handling.

Signed-off-by: Stefan Weil
---
  block/raw-win32.c |8 ++--
  1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/block/raw-win32.c b/block/raw-win32.c
index e47cfe0..b7dd357 100644
--- a/block/raw-win32.c
+++ b/block/raw-win32.c
@@ -41,6 +41,7 @@ typedef struct BDRVRawState {
  int qemu_ftruncate64(int fd, int64_t length)
  {
  LARGE_INTEGER li;
+DWORD dw;
  LONG high;
  HANDLE h;
  BOOL res;
@@ -53,12 +54,15 @@ int qemu_ftruncate64(int fd, int64_t length)
  /* get current position, ftruncate do not change position */
  li.HighPart = 0;
  li.LowPart = SetFilePointer (h, 0,&li.HighPart, FILE_CURRENT);
-if (li.LowPart == 0xUL&&  GetLastError() != NO_ERROR)
+if (li.LowPart == INVALID_SET_FILE_POINTER&&  GetLastError() != NO_ERROR) {
return -1;
+}

  high = length>>  32;
-if (!SetFilePointer(h, (DWORD) length,&high, FILE_BEGIN))
+dw = SetFilePointer(h, (DWORD) length,&high, FILE_BEGIN);
+if (dw == INVALID_SET_FILE_POINTER&&  GetLastError() != NO_ERROR) {
return -1;
+}
  res = SetEndOfFile(h);

  /* back to old position */


This is a bug fix, please apply it to git master and stable-0.15.

Thanks,
Stefan W.

[Qemu-devel] [Bug 817012] Re: compile error in QEMU 0.15.0-rc0

[Stefan Weil]

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/817012

Title:
  compile error in QEMU 0.15.0-rc0

Status in QEMU:
  Fix Released

Bug description:
  QEMU 0.15.0-rc0: Cross compiling on Fedora 14 for Windows is not
  possible:

  mkdir -p ~/source/mingw
  cd ~/source/mingw
  wget 
http://download-mirror.savannah.gnu.org/releases/qemu/qemu-0.15.0-rc0.tar.gz
  tar xzvf qemu-0.15.0-rc0.tar.gz
  cd qemu-0.15.0-rc0
  export PATH=/usr/i686-pc-mingw32/sys-root/mingw/bin:$PATH
  ./configure --cross-prefix="i686-pc-mingw32-" --prefix="/tmp/qemuinstall/" 
  make
  ...
CCmigration.o
  migration.c: In function 'migrate_print_status':
  migration.c:191:25: warning: format '%I64u' expects type 'unsigned int', but 
argument 4 has type 'int64_t'
  migration.c:193:25: warning: format '%I64u' expects type 'unsigned int', but 
argument 4 has type 'int64_t'
  migration.c:195:25: warning: format '%I64u' expects type 'unsigned int', but 
argument 4 has type 'int64_t'
  migration.c: In function 'migrate_put_status':
  migration.c:223:32: warning: format '%I64d' expects type 'int', but argument 
2 has type 'uint64_t'
  migration.c:223:32: warning: format '%I64d' expects type 'int', but argument 
3 has type 'uint64_t'
  migration.c:223:32: warning: format '%I64d' expects type 'int', but argument 
4 has type 'uint64_t'
CCmigration-tcp.o
CCqemu-char.o
  qemu-char.c: In function 'qemu_chr_open_win_con':
  qemu-char.c:1801:68: error: 'chr' undeclared (first use in this function)
  qemu-char.c:1801:68: note: each undeclared identifier is reported only once 
for each function it appears in
  qemu-char.c:1801:5: error: too many arguments to function 
'qemu_chr_open_win_file'
  qemu-char.c:1785:25: note: declared here
  qemu-char.c:1801:5: warning: return makes integer from pointer without a cast
  qemu-char.c: In function 'qemu_chr_open_win_file_out':
  qemu-char.c:1815:5: error: too many arguments to function 
'qemu_chr_open_win_file'
  qemu-char.c:1785:25: note: declared here
  qemu-char.c:1815:5: warning: return makes integer from pointer without a cast
  make: *** [qemu-char.o] Error 1

  For further details please see http://qemu-
  buch.de/d/QEMU_unter_Microsoft_Windows#Cross-Compilation_unter_Linux

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/817012/+subscriptions

[Qemu-devel] [Bug 826363] Re: qemu-img convert does not work with vdi files

[Stefan Weil]

A patch is available here:
http://patchwork.ozlabs.org/patch/110762/

** Changed in: qemu
   Status: New => Fix Committed

** Changed in: qemu
 Assignee: (unassigned) => Stefan Weil (ubuntu-weilnetz)

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/826363

Title:
  qemu-img convert does not work with vdi files

Status in QEMU:
  Fix Committed

Bug description:
  qemu-img.exe convert -O raw  myfile.vdi zz.raw

  reports 'error while writing' both in 0.15.0 and Beta rc2
  v0.11.1 works fine on same file. myfile.vdi is 3.9GB made by VirtualBox.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/826363/+subscriptions

Re: [Qemu-devel] [Help]: How to setup a VM based on kernel source code.

[Zhi Yong Wu]

On Fri, Aug 19, 2011 at 9:14 PM, Stefan Hajnoczi  wrote:
> On Fri, Aug 19, 2011 at 10:58 AM, Zhi Yong Wu  wrote:
>> I have met one scenario; currently i want to set up a VM based on
>> latest kernel tree; but i  only have latest kernel source code and
>> compiled it on one fedora 15 workstation. To achieve the objective,
>> what actions should i take next step? use -kernel -initrd options?
>> other ways?
>
> You can build a kernel with all drivers (e.g. virtio-net, virtio-blk)
> compiled in and then boot using -kernel and -append.  I find that
> simplest.
I tried this method, and it seemed to not work.:)

>
> Stefan
>



-- 
Regards,

Zhi Yong Wu

[Qemu-devel] [PATCH] pcnet: fix wrong opaque (broken by bd8d6f7cadb6ace98c779135217a4ed7b5fccc23)

[Hervé Poussineau]

Signed-off-by: Hervé Poussineau 
---
 hw/pcnet-pci.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/pcnet-pci.c b/hw/pcnet-pci.c
index 13d9380..51e1320 100644
--- a/hw/pcnet-pci.c
+++ b/hw/pcnet-pci.c
@@ -290,10 +290,10 @@ static int pci_pcnet_init(PCIDevice *pci_dev)
 pci_conf[PCI_MAX_LAT] = 0xff;
 
 /* Handler for memory-mapped I/O */
-memory_region_init_io(&d->state.mmio, &pcnet_mmio_ops, d, "pcnet-mmio",
+memory_region_init_io(&d->state.mmio, &pcnet_mmio_ops, s, "pcnet-mmio",
   PCNET_PNPMMIO_SIZE);
 
-memory_region_init_io(&d->io_bar, &pcnet_io_ops, d, "pcnet-io",
+memory_region_init_io(&d->io_bar, &pcnet_io_ops, s, "pcnet-io",
   PCNET_IOPORT_SIZE);
 pci_register_bar(pci_dev, 0, PCI_BASE_ADDRESS_SPACE_IO, &d->io_bar);
 
-- 
1.7.5.4

[Qemu-devel] [RFC 1/6] isa: rename isa_bus_new to isa_bus_bridge_init

[Hervé Poussineau]

Signed-off-by: Hervé Poussineau 
---
 hw/isa-bus.c   |2 +-
 hw/isa.h   |2 +-
 hw/mips_jazz.c |2 +-
 hw/mips_r4k.c  |2 +-
 hw/pc_piix.c   |2 +-
 hw/piix4.c |2 +-
 hw/piix_pci.c  |2 +-
 hw/ppc_prep.c  |2 +-
 hw/sun4u.c |2 +-
 hw/vt82c686.c  |2 +-
 10 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/hw/isa-bus.c b/hw/isa-bus.c
index 2765543..21b4b51 100644
--- a/hw/isa-bus.c
+++ b/hw/isa-bus.c
@@ -38,7 +38,7 @@ static struct BusInfo isa_bus_info = {
 .get_fw_dev_path = isabus_get_fw_dev_path,
 };
 
-ISABus *isa_bus_new(DeviceState *dev)
+ISABus *isa_bus_bridge_init(DeviceState *dev)
 {
 if (isabus) {
 fprintf(stderr, "Can't create a second ISA bus\n");
diff --git a/hw/isa.h b/hw/isa.h
index f1f2181..d6938f1 100644
--- a/hw/isa.h
+++ b/hw/isa.h
@@ -25,7 +25,7 @@ struct ISADeviceInfo {
 isa_qdev_initfn init;
 };
 
-ISABus *isa_bus_new(DeviceState *dev);
+ISABus *isa_bus_bridge_init(DeviceState *dev);
 void isa_bus_irqs(qemu_irq *irqs);
 qemu_irq isa_get_irq(int isairq);
 void isa_init_irq(ISADevice *dev, qemu_irq *p, int isairq);
diff --git a/hw/mips_jazz.c b/hw/mips_jazz.c
index f6ab6dc..7da78ca 100644
--- a/hw/mips_jazz.c
+++ b/hw/mips_jazz.c
@@ -180,7 +180,7 @@ void mips_jazz_init (ram_addr_t ram_size,
 
 /* ISA devices */
 i8259 = i8259_init(env->irq[4]);
-isa_bus_new(NULL);
+isa_bus_bridge_init(NULL);
 isa_bus_irqs(i8259);
 cpu_exit_irq = qemu_allocate_irqs(cpu_request_exit, NULL, 1);
 DMA_init(0, cpu_exit_irq);
diff --git a/hw/mips_r4k.c b/hw/mips_r4k.c
index 2834a46..f0db92b 100644
--- a/hw/mips_r4k.c
+++ b/hw/mips_r4k.c
@@ -265,7 +265,7 @@ void mips_r4k_init (ram_addr_t ram_size,
 
 /* The PIC is attached to the MIPS CPU INT0 pin */
 i8259 = i8259_init(env->irq[2]);
-isa_bus_new(NULL);
+isa_bus_bridge_init(NULL);
 isa_bus_irqs(i8259);
 
 rtc_init(2000, NULL);
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 7dd5008..d8f285c 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -134,7 +134,7 @@ static void pc_init1(MemoryRegion *system_memory,
 } else {
 pci_bus = NULL;
 i440fx_state = NULL;
-isa_bus_new(NULL);
+isa_bus_bridge_init(NULL);
 }
 isa_bus_irqs(isa_irq);
 
diff --git a/hw/piix4.c b/hw/piix4.c
index 9590e7b..984de8b 100644
--- a/hw/piix4.c
+++ b/hw/piix4.c
@@ -87,7 +87,7 @@ static int piix4_initfn(PCIDevice *dev)
 {
 PIIX4State *d = DO_UPCAST(PIIX4State, dev, dev);
 
-isa_bus_new(&d->dev.qdev);
+isa_bus_bridge_init(&d->dev.qdev);
 piix4_dev = &d->dev;
 qemu_register_reset(piix4_reset, d);
 return 0;
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index 28a3ee2..0b56553 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -447,7 +447,7 @@ static int piix3_initfn(PCIDevice *dev)
 {
 PIIX3State *d = DO_UPCAST(PIIX3State, dev, dev);
 
-isa_bus_new(&d->dev.qdev);
+isa_bus_bridge_init(&d->dev.qdev);
 qemu_register_reset(piix3_reset, d);
 return 0;
 }
diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c
index 38d8573..620b69f 100644
--- a/hw/ppc_prep.c
+++ b/hw/ppc_prep.c
@@ -651,7 +651,7 @@ static void ppc_prep_init (ram_addr_t ram_size,
 i8259 = i8259_init(first_cpu->irq_inputs[PPC6xx_INPUT_INT]);
 pci_bus = pci_prep_init(i8259, get_system_memory(), get_system_io());
 /* Hmm, prep has no pci-isa bridge ??? */
-isa_bus_new(NULL);
+isa_bus_bridge_init(NULL);
 isa_bus_irqs(i8259);
 //pci_bus = i440fx_init();
 /* Register 8 MB of ISA IO space (needed for non-contiguous map) */
diff --git a/hw/sun4u.c b/hw/sun4u.c
index 7b2d0b1..7e5a7e1 100644
--- a/hw/sun4u.c
+++ b/hw/sun4u.c
@@ -544,7 +544,7 @@ pci_ebus_init1(PCIDevice *pci_dev)
 {
 EbusState *s = DO_UPCAST(EbusState, pci_dev, pci_dev);
 
-isa_bus_new(&pci_dev->qdev);
+isa_bus_bridge_init(&pci_dev->qdev);
 
 pci_dev->config[0x04] = 0x06; // command = bus master, pci mem
 pci_dev->config[0x05] = 0x00;
diff --git a/hw/vt82c686.c b/hw/vt82c686.c
index 5c973ed..25430d7 100644
--- a/hw/vt82c686.c
+++ b/hw/vt82c686.c
@@ -490,7 +490,7 @@ static int vt82c686b_initfn(PCIDevice *d)
 uint8_t *wmask;
 int i;
 
-isa_bus_new(&d->qdev);
+isa_bus_bridge_init(&d->qdev);
 
 pci_conf = d->config;
 pci_config_set_prog_interface(pci_conf, 0x0);
-- 
1.7.5.4

[Qemu-devel] [RFC 3/6] isa: add isa_address_space() method

[Hervé Poussineau]

Signed-off-by: Hervé Poussineau 
---
 hw/isa-bus.c |   24 
 hw/isa.h |2 ++
 2 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/hw/isa-bus.c b/hw/isa-bus.c
index 4757ff9..2bc384a 100644
--- a/hw/isa-bus.c
+++ b/hw/isa-bus.c
@@ -20,10 +20,12 @@
 #include "monitor.h"
 #include "sysbus.h"
 #include "isa.h"
+#include "exec-memory.h"
 
 static ISABus *isabus;
 target_phys_addr_t isa_mem_base = 0;
 static qemu_irq *isa_bus_default_irqs;
+static MemoryRegion *isa_bus_default_mem;
 
 static void isabus_dev_print(Monitor *mon, DeviceState *dev, int indent);
 static char *isabus_get_fw_dev_path(DeviceState *dev);
@@ -48,9 +50,23 @@ static qemu_irq isa_bus_default_get_irq(ISABus *bus, int 
isairq)
 return isa_bus_default_irqs[isairq];
 }
 
+static MemoryRegion *isa_bus_default_get_address_space(ISABus *bus)
+{
+if (!isa_bus_default_mem) {
+/* First call to this method, initialize memory region */
+isa_bus_default_mem = (MemoryRegion 
*)qemu_malloc(sizeof(MemoryRegion));
+memory_region_init(isa_bus_default_mem, "isa-memory", 0x0010);
+memory_region_add_subregion(get_system_memory(),
+isa_mem_base,
+isa_bus_default_mem);
+}
+return isa_bus_default_mem;
+}
+
 static ISABusOps isa_bus_default_ops = {
 .set_irqs = isa_bus_default_set_irqs,
 .get_irq = isa_bus_default_get_irq,
+.get_address_space = isa_bus_default_get_address_space,
 };
 
 ISABus *isa_bus_bridge_init(DeviceState *dev)
@@ -102,6 +118,14 @@ qemu_irq isa_get_irq(int isairq)
 return isabus->ops->get_irq(isabus, isairq);
 }
 
+MemoryRegion *isa_address_space(void)
+{
+if (!isabus || !isabus->ops->get_address_space) {
+hw_error("Tried to get isa address space with no isa bus present.");
+}
+return isabus->ops->get_address_space(isabus);
+}
+
 void isa_init_irq(ISADevice *dev, qemu_irq *p, int isairq)
 {
 assert(dev->nirqs < ARRAY_SIZE(dev->isairq));
diff --git a/hw/isa.h b/hw/isa.h
index 8c1583f..19c4720 100644
--- a/hw/isa.h
+++ b/hw/isa.h
@@ -36,6 +36,7 @@ struct ISABus {
 struct ISABusOps {
 void (*set_irqs)(ISABus *bus, qemu_irq *irqs);
 qemu_irq (*get_irq)(ISABus *bus, int isairq);
+MemoryRegion *(*get_address_space)(ISABus *bus);
 };
 
 ISABus *isa_bus_bridge_init(DeviceState *dev);
@@ -43,6 +44,7 @@ ISABus *isa_bus_bridge_init(DeviceState *dev);
 void isa_bus_new(ISABus *bus, ISABusOps *ops, DeviceState *host);
 void isa_bus_irqs(qemu_irq *irqs);
 qemu_irq isa_get_irq(int isairq);
+MemoryRegion *isa_address_space(void);
 void isa_init_irq(ISADevice *dev, qemu_irq *p, int isairq);
 void isa_init_ioport(ISADevice *dev, uint16_t ioport);
 void isa_init_ioport_range(ISADevice *dev, uint16_t start, uint16_t length);
-- 
1.7.5.4

[Qemu-devel] [RFC 0/6] ISA bus improvements

[Hervé Poussineau]

Following patches aim to change ISA bus to a first-citizen class in Qemu.

They add ISA bus ops (like for scsi and usb buses), and use them to
remove the infamous isa_mem_base variable, which can't be changed after
startup.

Last two patches convert two ISA bridges to the new API. ISA bridges
used in MIPS/Malta and MIPS/fulong2e are not converted (yet).

Once all callers are converted, most of the work will be done to
support architectures with multiple ISA buses

Hervé Poussineau (6):
  isa: rename isa_bus_new to isa_bus_bridge_init
  isa: rework ISA bus internals, and add ISA bus ops structure
  isa: add isa_address_space() method
  vga: use isa_address_space() method
  isa: improve bus implementation of PIIX3 bridge
  isa: improve bus implementation of ebus bridge

 hw/cirrus_vga.c |4 +-
 hw/isa-bus.c|   86 ++
 hw/isa.h|   19 +++-
 hw/mips_jazz.c  |2 +-
 hw/mips_r4k.c   |2 +-
 hw/pc_piix.c|4 +-
 hw/piix4.c  |2 +-
 hw/piix_pci.c   |   23 ++-
 hw/ppc_prep.c   |2 +-
 hw/sun4u.c  |   39 
 hw/vga-isa.c|4 +-
 hw/vga.c|4 +-
 hw/vt82c686.c   |2 +-
 13 files changed, 158 insertions(+), 35 deletions(-)

-- 
1.7.5.4

[Qemu-devel] [RFC 5/6] isa: improve bus implementation of PIIX3 bridge

[Hervé Poussineau]

Signed-off-by: Hervé Poussineau 
---
 hw/pc_piix.c  |2 +-
 hw/piix_pci.c |   23 ++-
 2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index d8f285c..af45a13 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -135,8 +135,8 @@ static void pc_init1(MemoryRegion *system_memory,
 pci_bus = NULL;
 i440fx_state = NULL;
 isa_bus_bridge_init(NULL);
+isa_bus_irqs(i8259);
 }
-isa_bus_irqs(isa_irq);
 
 pc_register_ferr_irq(isa_get_irq(13));
 
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index 0b56553..4be1dcd 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -30,6 +30,7 @@
 #include "sysbus.h"
 #include "range.h"
 #include "xen.h"
+#include "exec-memory.h"
 
 /*
  * I440FX chipset data sheet.
@@ -45,6 +46,7 @@ typedef PCIHostState I440FXState;
 
 typedef struct PIIX3State {
 PCIDevice dev;
+ISABus bus;
 
 /*
  * bitmap to track pic levels.
@@ -443,11 +445,30 @@ static const VMStateDescription vmstate_piix3 = {
 }
 };
 
+static qemu_irq piix3_bus_get_irq(ISABus *bus, int isairq)
+{
+PIIX3State *d = container_of(bus, PIIX3State, bus);
+if (isairq < 0 || isairq >= PIIX_NUM_PIC_IRQS) {
+hw_error("isa irq %d invalid", isairq);
+}
+return d->pic[isairq];
+}
+
+static MemoryRegion *piix3_bus_get_address_space(ISABus *bus)
+{
+return get_system_memory();
+}
+
+static ISABusOps piix3_bus_ops = {
+.get_irq = piix3_bus_get_irq,
+.get_address_space = piix3_bus_get_address_space,
+};
+
 static int piix3_initfn(PCIDevice *dev)
 {
 PIIX3State *d = DO_UPCAST(PIIX3State, dev, dev);
 
-isa_bus_bridge_init(&d->dev.qdev);
+isa_bus_new(&d->bus, &piix3_bus_ops, &dev->qdev);
 qemu_register_reset(piix3_reset, d);
 return 0;
 }
-- 
1.7.5.4

[Qemu-devel] [RFC 4/6] vga: use isa_address_space() method

[Hervé Poussineau]

Signed-off-by: Hervé Poussineau 
---
 hw/cirrus_vga.c |4 ++--
 hw/vga-isa.c|4 ++--
 hw/vga.c|4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index b489309..ebc4aec 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
@@ -2856,8 +2856,8 @@ static void cirrus_init_common(CirrusVGAState * s, int 
device_id, int is_pci)
 memory_region_init_io(&s->low_mem, &cirrus_vga_mem_ops, s,
   "cirrus-low-memory", 0x2);
 memory_region_add_subregion(&s->low_mem_container, 0, &s->low_mem);
-memory_region_add_subregion_overlap(get_system_memory(),
-isa_mem_base + 0x000a,
+memory_region_add_subregion_overlap(isa_address_space(),
+0x000a,
 &s->low_mem_container,
 1);
 memory_region_set_coalescing(&s->low_mem);
diff --git a/hw/vga-isa.c b/hw/vga-isa.c
index fef7f58..bbbf643 100644
--- a/hw/vga-isa.c
+++ b/hw/vga-isa.c
@@ -51,8 +51,8 @@ static int vga_initfn(ISADevice *dev)
 
 vga_common_init(s, VGA_RAM_SIZE);
 vga_io_memory = vga_init_io(s);
-memory_region_add_subregion_overlap(get_system_memory(),
-isa_mem_base + 0x000a,
+memory_region_add_subregion_overlap(isa_address_space(),
+0x000a,
 vga_io_memory, 1);
 memory_region_set_coalescing(vga_io_memory);
 isa_init_ioport(dev, 0x3c0);
diff --git a/hw/vga.c b/hw/vga.c
index 33dc478..0d4b5c2 100644
--- a/hw/vga.c
+++ b/hw/vga.c
@@ -2250,8 +2250,8 @@ void vga_init(VGACommonState *s)
 s->bank_offset = 0;
 
 vga_io_memory = vga_init_io(s);
-memory_region_add_subregion_overlap(get_system_memory(),
-isa_mem_base + 0x000a,
+memory_region_add_subregion_overlap(isa_address_space(),
+0x000a,
 vga_io_memory,
 1);
 memory_region_set_coalescing(vga_io_memory);
-- 
1.7.5.4

[Qemu-devel] [RFC 2/6] isa: rework ISA bus internals, and add ISA bus ops structure

[Hervé Poussineau]

This allows future implementations of real pci-isa bridges
or EISA bus emulation

Signed-off-by: Hervé Poussineau 
---
 hw/isa-bus.c |   60 ++---
 hw/isa.h |   15 ++
 2 files changed, 63 insertions(+), 12 deletions(-)

diff --git a/hw/isa-bus.c b/hw/isa-bus.c
index 21b4b51..4757ff9 100644
--- a/hw/isa-bus.c
+++ b/hw/isa-bus.c
@@ -21,12 +21,9 @@
 #include "sysbus.h"
 #include "isa.h"
 
-struct ISABus {
-BusState qbus;
-qemu_irq *irqs;
-};
 static ISABus *isabus;
 target_phys_addr_t isa_mem_base = 0;
+static qemu_irq *isa_bus_default_irqs;
 
 static void isabus_dev_print(Monitor *mon, DeviceState *dev, int indent);
 static char *isabus_get_fw_dev_path(DeviceState *dev);
@@ -38,6 +35,24 @@ static struct BusInfo isa_bus_info = {
 .get_fw_dev_path = isabus_get_fw_dev_path,
 };
 
+static void isa_bus_default_set_irqs(ISABus *bus, qemu_irq *irqs)
+{
+isa_bus_default_irqs = irqs;
+}
+
+static qemu_irq isa_bus_default_get_irq(ISABus *bus, int isairq)
+{
+if (isairq < 0 || isairq > 15) {
+hw_error("isa irq %d invalid", isairq);
+}
+return isa_bus_default_irqs[isairq];
+}
+
+static ISABusOps isa_bus_default_ops = {
+.set_irqs = isa_bus_default_set_irqs,
+.get_irq = isa_bus_default_get_irq,
+};
+
 ISABus *isa_bus_bridge_init(DeviceState *dev)
 {
 if (isabus) {
@@ -48,14 +63,29 @@ ISABus *isa_bus_bridge_init(DeviceState *dev)
 dev = qdev_create(NULL, "isabus-bridge");
 qdev_init_nofail(dev);
 }
-
-isabus = FROM_QBUS(ISABus, qbus_create(&isa_bus_info, dev, NULL));
+else {
+isabus = FROM_QBUS(ISABus, qbus_create(&isa_bus_info, dev, NULL));
+isabus->ops = &isa_bus_default_ops;
+}
 return isabus;
 }
 
+void isa_bus_new(ISABus *bus, ISABusOps *ops, DeviceState *host)
+{
+if (isabus) {
+hw_error("Can't create a second ISA bus");
+}
+qbus_create_inplace(&bus->qbus, &isa_bus_info, host, NULL);
+bus->ops = ops;
+isabus = bus;
+}
+
 void isa_bus_irqs(qemu_irq *irqs)
 {
-isabus->irqs = irqs;
+if (!isabus || !isabus->ops->set_irqs) {
+hw_error("Tried to set isa irqs with no isa bus present.");
+}
+isabus->ops->set_irqs(isabus, irqs);
 }
 
 /*
@@ -66,10 +96,10 @@ void isa_bus_irqs(qemu_irq *irqs)
  */
 qemu_irq isa_get_irq(int isairq)
 {
-if (isairq < 0 || isairq > 15) {
-hw_error("isa irq %d invalid", isairq);
+if (!isabus || !isabus->ops->get_irq) {
+hw_error("ISA bus invalid");
 }
-return isabus->irqs[isairq];
+return isabus->ops->get_irq(isabus, isairq);
 }
 
 void isa_init_irq(ISADevice *dev, qemu_irq *p, int isairq)
@@ -169,9 +199,15 @@ static void isabus_dev_print(Monitor *mon, DeviceState 
*dev, int indent)
 }
 }
 
+typedef struct {
+SysBusDevice busdev;
+ISABus bus;
+} ISABridgeSysBusState;
+
 static int isabus_bridge_init(SysBusDevice *dev)
 {
-/* nothing */
+ISABridgeSysBusState *isa = FROM_SYSBUS(ISABridgeSysBusState, dev);
+isa_bus_new(&isa->bus, &isa_bus_default_ops, &dev->qdev);
 return 0;
 }
 
@@ -179,7 +215,7 @@ static SysBusDeviceInfo isabus_bridge_info = {
 .init = isabus_bridge_init,
 .qdev.name  = "isabus-bridge",
 .qdev.fw_name  = "isa",
-.qdev.size  = sizeof(SysBusDevice),
+.qdev.size  = sizeof(ISABridgeSysBusState),
 .qdev.no_user = 1,
 };
 
diff --git a/hw/isa.h b/hw/isa.h
index d6938f1..8c1583f 100644
--- a/hw/isa.h
+++ b/hw/isa.h
@@ -8,6 +8,7 @@
 #include "qdev.h"
 
 typedef struct ISABus ISABus;
+typedef struct ISABusOps ISABusOps;
 typedef struct ISADevice ISADevice;
 typedef struct ISADeviceInfo ISADeviceInfo;
 
@@ -25,7 +26,21 @@ struct ISADeviceInfo {
 isa_qdev_initfn init;
 };
 
+/* isa-bus.c */
+
+struct ISABus {
+BusState qbus;
+ISABusOps *ops;
+};
+
+struct ISABusOps {
+void (*set_irqs)(ISABus *bus, qemu_irq *irqs);
+qemu_irq (*get_irq)(ISABus *bus, int isairq);
+};
+
 ISABus *isa_bus_bridge_init(DeviceState *dev);
+
+void isa_bus_new(ISABus *bus, ISABusOps *ops, DeviceState *host);
 void isa_bus_irqs(qemu_irq *irqs);
 qemu_irq isa_get_irq(int isairq);
 void isa_init_irq(ISADevice *dev, qemu_irq *p, int isairq);
-- 
1.7.5.4

[Qemu-devel] [RFC 6/6] isa: improve bus implementation of ebus bridge

[Hervé Poussineau]

Signed-off-by: Hervé Poussineau 
---
 hw/sun4u.c |   39 ---
 1 files changed, 32 insertions(+), 7 deletions(-)

diff --git a/hw/sun4u.c b/hw/sun4u.c
index 7e5a7e1..898541e 100644
--- a/hw/sun4u.c
+++ b/hw/sun4u.c
@@ -38,6 +38,7 @@
 #include "loader.h"
 #include "elf.h"
 #include "blockdev.h"
+#include "exec-memory.h"
 
 //#define DEBUG_IRQ
 //#define DEBUG_EBUS
@@ -93,6 +94,9 @@ struct hwdef {
 
 typedef struct EbusState {
 PCIDevice pci_dev;
+ISABus bus;
+MemoryRegion isa_mem_space;
+qemu_irq *isa_irq;
 MemoryRegion bar0;
 MemoryRegion bar1;
 } EbusState;
@@ -532,19 +536,40 @@ static void dummy_isa_irq_handler(void *opaque, int n, 
int level)
 static void
 pci_ebus_init(PCIBus *bus, int devfn)
 {
-qemu_irq *isa_irq;
-
 pci_create_simple(bus, devfn, "ebus");
-isa_irq = qemu_allocate_irqs(dummy_isa_irq_handler, NULL, 16);
-isa_bus_irqs(isa_irq);
 }
 
+static qemu_irq pci_ebus_get_irq(ISABus *bus, int isairq)
+{
+EbusState *s = container_of(bus, EbusState, bus);
+if (isairq < 0 || isairq >= 16) {
+hw_error("isa irq %d invalid", isairq);
+}
+return s->isa_irq[isairq];
+}
+
+static MemoryRegion *pci_ebus_get_address_space(ISABus *bus)
+{
+EbusState *s = container_of(bus, EbusState, bus);
+return &s->isa_mem_space;
+}
+
+static ISABusOps pci_ebus_ops = {
+.get_irq = pci_ebus_get_irq,
+.get_address_space = pci_ebus_get_address_space,
+};
+
 static int
 pci_ebus_init1(PCIDevice *pci_dev)
 {
 EbusState *s = DO_UPCAST(EbusState, pci_dev, pci_dev);
 
-isa_bus_bridge_init(&pci_dev->qdev);
+isa_bus_new(&s->bus, &pci_ebus_ops, &pci_dev->qdev);
+memory_region_init(&s->isa_mem_space, "isa-memory", 0x0010);
+memory_region_add_subregion(get_system_memory(),
+APB_PCI_IO_BASE,
+&s->isa_mem_space);
+s->isa_irq = qemu_allocate_irqs(dummy_isa_irq_handler, NULL, 16);
 
 pci_dev->config[0x04] = 0x06; // command = bus master, pci mem
 pci_dev->config[0x05] = 0x00;
@@ -759,12 +784,12 @@ static void sun4uv_init(ram_addr_t RAM_size,
 irq = qemu_allocate_irqs(cpu_set_irq, env, MAX_PILS);
 pci_bus = pci_apb_init(APB_SPECIAL_BASE, APB_MEM_BASE, irq, &pci_bus2,
&pci_bus3);
-isa_mem_base = APB_PCI_IO_BASE;
-pci_vga_init(pci_bus);
 
 // XXX Should be pci_bus3
 pci_ebus_init(pci_bus, -1);
 
+pci_vga_init(pci_bus);
+
 i = 0;
 if (hwdef->console_serial_base) {
 serial_mm_init(hwdef->console_serial_base, 0, NULL, 115200,
-- 
1.7.5.4

Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings

[Alex Williamson]

We had an extremely productive VFIO BoF on Monday.  Here's my attempt to
capture the plan that I think we agreed to:

We need to address both the description and enforcement of device
groups.  Groups are formed any time the iommu does not have resolution
between a set of devices.  On x86, this typically happens when a
PCI-to-PCI bridge exists between the set of devices and the iommu.  For
Power, partitionable endpoints define a group.  Grouping information
needs to be exposed for both userspace and kernel internal usage.  This
will be a sysfs attribute setup by the iommu drivers.  Perhaps:

# cat /sys/devices/pci:00/:00:19.0/iommu_group
42

(I use a PCI example here, but attribute should not be PCI specific)

>From there we have a few options.  In the BoF we discussed a model where
binding a device to vfio creates a /dev/vfio$GROUP character device
file.  This "group" fd provides provides dma mapping ioctls as well as
ioctls to enumerate and return a "device" fd for each attached member of
the group (similar to KVM_CREATE_VCPU).  We enforce grouping by
returning an error on open() of the group fd if there are members of the
group not bound to the vfio driver.  Each device fd would then support a
similar set of ioctls and mapping (mmio/pio/config) interface as current
vfio, except for the obvious domain and dma ioctls superseded by the
group fd.

Another valid model might be that /dev/vfio/$GROUP is created for all
groups when the vfio module is loaded.  The group fd would allow open()
and some set of iommu querying and device enumeration ioctls, but would
error on dma mapping and retrieving device fds until all of the group
devices are bound to the vfio driver.

In either case, the uiommu interface is removed entirely since dma
mapping is done via the group fd.  As necessary in the future, we can
define a more high performance dma mapping interface for streaming dma
via the group fd.  I expect we'll also include architecture specific
group ioctls to describe features and capabilities of the iommu.  The
group fd will need to prevent concurrent open()s to maintain a 1:1 group
to userspace process ownership model.

Also on the table is supporting non-PCI devices with vfio.  To do this,
we need to generalize the read/write/mmap and irq eventfd interfaces.
We could keep the same model of segmenting the device fd address space,
perhaps adding ioctls to define the segment offset bit position or we
could split each region into it's own fd (VFIO_GET_PCI_BAR_FD(0),
VFIO_GET_PCI_CONFIG_FD(), VFIO_GET_MMIO_FD(3)), though we're already
suffering some degree of fd bloat (group fd, device fd(s), interrupt
event fd(s), per resource fd, etc).  For interrupts we can overload
VFIO_SET_IRQ_EVENTFD to be either PCI INTx or non-PCI irq (do non-PCI
devices support MSI?).

For qemu, these changes imply we'd only support a model where we have a
1:1 group to iommu domain.  The current vfio driver could probably
become vfio-pci as we might end up with more target specific vfio
drivers for non-pci.  PCI should be able to maintain a simple -device
vfio-pci,host=bb:dd.f to enable hotplug of individual devices.  We'll
need to come up with extra options when we need to expose groups to
guest for pvdma.

Hope that captures it, feel free to jump in with corrections and
suggestions.  Thanks,

Alex

[Qemu-devel] [Bug 816370] Re: compile error in QEMU 0.15.0-rc0 and 0.15.0-rc1

[Malte Starostik]

Hi,

I stubled over the same issue on Gentoo Linux today, and the easy
fix/workaround is to pass --extra-cflags=-I. to configure.  Maybe -I.
should just be added to QEMU_CFLAGS by default, before any possible
other include paths aded by configure.

Cheers,
Malte

** Bug watch added: Gentoo Bugzilla #379871
   http://bugs.gentoo.org/show_bug.cgi?id=379871

** Also affects: gentoo via
   http://bugs.gentoo.org/show_bug.cgi?id=379871
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/816370

Title:
  compile error in QEMU 0.15.0-rc0 and  0.15.0-rc1

Status in QEMU:
  New
Status in Gentoo Linux:
  Unknown

Bug description:
  I've tryed to compile QEMU 0.15.0-rc0 on Ubuntu 10.10 „Maverick
  Meerkat“ but I get an error (For further details please see http
  ://qemu-buch.de/d/Installation#Quellen_kompilieren ).

  ./configure --prefix=/usr --enable-spice  
--audio-card-list=ac97,es1370,sb16,adlib,gus,cs4231a
  make

GEN   config-host.h
GEN   trace.h
GEN   qemu-options.def
GEN   qapi-generated/qga-qapi-types.h
GEN   qapi-generated/qga-qapi-visit.h
GEN   qapi-generated/qga-qmp-marshal.c
CCqapi/qapi-visit-core.o
  In file included from qapi/qapi-visit-core.c:14:
  ./qapi/qapi-visit-core.h:31: error: expected declaration specifiers or ‘...’ 
before ‘Error’
  ./qapi/qapi-visit-core.h:32: error: expected declaration specifiers or ‘...’ 
before ‘Error’
  ./qapi/qapi-visit-core.h:34: error: expected declaration specifiers or ‘...’ 
before ‘Error’
  ./qapi/qapi-visit-core.h:35: error: expected declaration specifiers or ‘...’ 
before ‘Error’
  ./qapi/qapi-visit-core.h:36: error: expected declaration specifiers or ‘...’ 
before ‘Error’
  ./qapi/qapi-visit-core.h:39: error: expected declaration specifiers or ‘...’ 
before ‘Error’
  ./qapi/qapi-visit-core.h:41: error: expected declaration specifiers or ‘...’ 
before ‘Error’
  ./qapi/qapi-visit-core.h:42: error: expected declaration specifiers or ‘...’ 
before ‘Error’
  ./qapi/qapi-visit-core.h:43: error: expected declaration specifiers or ‘...’ 
before ‘Error’
  ./qapi/qapi-visit-core.h:45: error: expected declaration specifiers or ‘...’ 
before ‘Error’
  ./qapi/qapi-visit-core.h:49: error: expected declaration specifiers or ‘...’ 
before ‘Error’
  ./qapi/qapi-visit-core.h:50: error: expected declaration specifiers or ‘...’ 
before ‘Error’
  ./qapi/qapi-visit-core.h:53: error: expected declaration specifiers or ‘...’ 
before ‘Error’
  ./qapi/qapi-visit-core.h:54: error: expected declaration specifiers or ‘...’ 
before ‘Error’
  ./qapi/qapi-visit-core.h:58: error: expected declaration specifiers or ‘...’ 
before ‘Error’
  ./qapi/qapi-visit-core.h:59: error: expected declaration specifiers or ‘...’ 
before ‘Error’
  ./qapi/qapi-visit-core.h:61: error: expected declaration specifiers or ‘...’ 
before ‘Error’
  ./qapi/qapi-visit-core.h:62: error: expected declaration specifiers or ‘...’ 
before ‘Error’
  ./qapi/qapi-visit-core.h:63: error: expected declaration specifiers or ‘...’ 
before ‘Error’
  ./qapi/qapi-visit-core.h:64: error: expected declaration specifiers or ‘...’ 
before ‘Error’
  ./qapi/qapi-visit-core.h:65: error: expected declaration specifiers or ‘...’ 
before ‘Error’
  ./qapi/qapi-visit-core.h:67: error: expected declaration specifiers or ‘...’ 
before ‘Error’
  ./qapi/qapi-visit-core.h:68: error: expected declaration specifiers or ‘...’ 
before ‘Error’
  ./qapi/qapi-visit-core.h:70: error: expected declaration specifiers or ‘...’ 
before ‘Error’
  ./qapi/qapi-visit-core.h:71: error: expected declaration specifiers or ‘...’ 
before ‘Error’
  ./qapi/qapi-visit-core.h:72: error: expected declaration specifiers or ‘...’ 
before ‘Error’
  ./qapi/qapi-visit-core.h:73: error: expected declaration specifiers or ‘...’ 
before ‘Error’
  ./qapi/qapi-visit-core.h:74: error: expected declaration specifiers or ‘...’ 
before ‘Error’
  qapi/qapi-visit-core.c:17: error: expected declaration specifiers or ‘...’ 
before ‘Error’
  qapi/qapi-visit-core.c: In function ‘visit_start_handle’:
  qapi/qapi-visit-core.c:19: warning: implicit declaration of function 
‘error_is_set’
  qapi/qapi-visit-core.c:19: warning: nested extern declaration of 
‘error_is_set’
  qapi/qapi-visit-core.c:19: error: ‘errp’ undeclared (first use in this 
function)
  qapi/qapi-visit-core.c:19: error: (Each undeclared identifier is reported 
only once
  qapi/qapi-visit-core.c:19: error: for each function it appears in.)
  qapi/qapi-visit-core.c:20: error: too many arguments to function 
‘v->start_handle’
  qapi/qapi-visit-core.c: At top level:
  qapi/qapi-visit-core.c:24: error: expected declaration specifiers or ‘...’ 
before ‘Error’
  qapi/qapi-visit-core.c: In function ‘visit_end_handle’:
  qapi/qapi-visit-core.c:26: error: ‘errp’ undeclared (first use in this 
function)
  qapi/qapi-visit-core.c:27: error: too many arguments to function 
‘v-

[Qemu-devel] [Bug 826363] Re: qemu-img convert does not work with vdi files

[Steve Si]

If someone could give me a link to a compiled binary, I will test this -
thanks.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/826363

Title:
  qemu-img convert does not work with vdi files

Status in QEMU:
  Fix Committed

Bug description:
  qemu-img.exe convert -O raw  myfile.vdi zz.raw

  reports 'error while writing' both in 0.15.0 and Beta rc2
  v0.11.1 works fine on same file. myfile.vdi is 3.9GB made by VirtualBox.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/826363/+subscriptions

Re: [Qemu-devel] [PATCH] introduce environment variables for all qemu-user options

[Yann Dirson]

This patch will be useful, but there is a security problem in its
current form.  The qemu-user-static package installs binfmt-misc
entries with "flags: OC", which makes the binary honor setuid bits.

Regardless of whether it is a good idea or not, the envvars ought to
be ignored in such a case.  Some clever checks using getresuid(), or
just geteuid() and getuid() when getresuid() is not available, surely
have to done.  There is probably some existing code for this in other
programs...

Best regards,
-- 
Yann

[Qemu-devel] [Bug 816370] Re: compile error in QEMU 0.15.0-rc0 and 0.15.0-rc1

[Bug Watch Updater]

Launchpad has imported 5 comments from the remote bug at
http://bugs.gentoo.org/show_bug.cgi?id=379871.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.


On 2011-08-19T14:57:18+00:00 Mattsch wrote:

It appears app-emulation/qemu-kvm-0.15.0 does not compile at all:

qapi/qmp-input-visitor.c:229: error: ‘errp’ undeclared (first use in this 
function)
qapi/qmp-input-visitor.c:229: error: too many arguments to function 
‘qmp_input_type_str’
qapi/qmp-input-visitor.c: At top level:
qapi/qmp-input-visitor.c:250: error: expected declaration specifiers or ‘...’ 
before ‘Error’
qapi/qmp-input-visitor.c:263: error: expected declaration specifiers or ‘...’ 
before ‘Error’
make: *** [qapi/qmp-input-visitor.o] Error 1
rm extboot.img vapic.o multiboot.o extboot.o linuxboot.raw linuxboot.img 
vapic.raw vapic.img multiboot.raw extboot.raw multiboot.img linuxboot.o
emake failed
 * ERROR: app-emulation/qemu-kvm-0.15.0 failed (compile phase):
 *   emake failed
 * 
 * Call stack:
 * ebuild.sh, line   56:  Called src_compile
 *   environment, line 3504:  Called _eapi2_src_compile
 * ebuild.sh, line  665:  Called die
 * The specific snippet of code:
 *  emake || die "emake failed"

Reproducible: Always



emerge -av qemu-kvm

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild U ~] app-emulation/qemu-kvm-0.15.0 [0.14.1-r2] USE="aio alsa 
bluetooth curl jpeg ncurses png sasl sdl spice ssl threads vhost-net -brltty 
-debug -esd -fdt -hardened -nss% -pulseaudio -qemu-ifup -rbd -vde -xattr% -xen" 
QEMU_SOFTMMU_TARGETS="i386 x86_64 -arm -cris -m68k -microblaze -mips -mips64 
-mips64el -mipsel -ppc -ppc64 -ppcemb -sh4 -sh4eb -sparc -sparc64" 
QEMU_USER_TARGETS="i386 x86_64 -alpha -arm -armeb -cris -m68k -microblaze -mips 
-mipsel -ppc -ppc64 -ppc64abi32 -sh4 -sh4eb -sparc -sparc32plus -sparc64" 0 kB  
  

emerge --info 
Portage 2.1.10.3 (default/linux/amd64/10.0, gcc-4.4.5, glibc-2.12.2-r0, 
3.0.3-gentoo x86_64)
=
System uname: 
Linux-3.0.3-gentoo-x86_64-Intel-R-_Core-TM-2_Duo_CPU_T9400_@_2.53GHz-with-gentoo-2.0.3
Timestamp of tree: Fri, 19 Aug 2011 13:15:01 +
app-shells/bash:  4.1_p9
dev-java/java-config: 2.1.11-r3
dev-lang/python:  2.7.1-r1, 3.1.3-r1
dev-util/cmake:   2.8.4-r1
dev-util/pkgconfig:   0.26
sys-apps/baselayout:  2.0.3
sys-apps/openrc:  0.8.3-r1
sys-apps/sandbox: 2.4
sys-devel/autoconf:   2.13, 2.68
sys-devel/automake:   1.9.6-r3, 1.10.3, 1.11.1
sys-devel/binutils:   2.20.1-r1
sys-devel/gcc:4.4.5
sys-devel/gcc-config: 1.4.1-r1
sys-devel/libtool:2.4-r1
sys-devel/make:   3.82
sys-kernel/linux-headers: 2.6.36.1 (virtual/os-headers)
sys-libs/glibc:   2.12.2
Repositories: gentoo sunrise x-portage
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="*"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=core2 -O2 -pipe -fomit-frame-pointer"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt 
/usr/share/openvpn/easy-rsa"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ 
/etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release 
/etc/php/apache2-php5.2/ext-active/ /etc/php/apache2-php5.3/ext-active/ 
/etc/php/cgi-php5.2/ext-active/ /etc/php/cgi-php5.3/ext-active/ 
/etc/php/cli-php5.2/ext-active/ /etc/php/cli-php5.3/ext-active/ 
/etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-march=core2 -O2 -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="assume-digests binpkg-logs distlocks ebuild-locks fixlafiles 
fixpackages news parallel-fetch protect-owned sandbox sfperms strict 
unknown-features-warn unmerge-logs unmerge-orphans userfetch"
FFLAGS=""
GENTOO_MIRRORS="http://portage.home http://gentoo.cites.uiuc.edu/pub/gentoo/ 
http://gentoo.mirrors.easynews.com/linux/gentoo/ 
http://mirror.phy.olemiss.edu/mirror/gentoo";
LANG="en_US.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
LINGUAS="en ru"
MAKEOPTS="-j6"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress 
--force --whole-file --delete --stats --timeout=180 --exclude=/distfiles 
--exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/var/lib/layman/sunrise /usr/local/portage"
SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage"
USE="X a52 aac acl acpi adns alsa amd64 apache2 audiofile avi bcmath bdf berkdb 
bluetooth bzip2 cairo calendar caps cdda cdr chardet cjk clamav cli consolekit 
cracklib crypt css ctype cups curl curlwrappers cxx dbus declarative 
device-mapper dga directfb dri dts dvb dvd dvd

Re: [Qemu-devel] [PULL] slirp: Fix issues with -mms-bitfields

[Stefan Weil]

Am 15.08.2011 08:39, schrieb Jan Kiszka:
The following changes since commit 
3b6ffe50300f13240e1b46420ad05da1116df410:


hw/scsi-bus.c: Fix use of uninitialised variable (2011-08-14 19:34:25 
+)


are available in the git repository at:
git://git.kiszka.org/qemu.git queues/slirp

Jan Kiszka (1):
slirp: Fix bit field types in IP header structs

slirp/ip.h | 8 
slirp/tcp.h | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)

---

slirp: Fix bit field types in IP header structs

-mms-bitfields prevents that the bitfields in current IP header structs
are packed into a single byte as it is required. Fix this by using
uint8_t as backing type.

Signed-off-by: Jan Kiszka 
---
slirp/ip.h | 8 
slirp/tcp.h | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/slirp/ip.h b/slirp/ip.h
index 48ea38e..72dbe9a 100644
--- a/slirp/ip.h
+++ b/slirp/ip.h
@@ -74,10 +74,10 @@ typedef uint32_t n_long; /* long as received from 
the net */

*/
struct ip {
#ifdef HOST_WORDS_BIGENDIAN
- u_int ip_v:4, /* version */
+ uint8_t ip_v:4, /* version */
ip_hl:4; /* header length */
#else
- u_int ip_hl:4, /* header length */
+ uint8_t ip_hl:4, /* header length */
ip_v:4; /* version */
#endif
uint8_t ip_tos; /* type of service */
@@ -140,10 +140,10 @@ struct ip_timestamp {
uint8_t ipt_len; /* size of structure (variable) */
uint8_t ipt_ptr; /* index of current entry */
#ifdef HOST_WORDS_BIGENDIAN
- u_int ipt_oflw:4, /* overflow counter */
+ uint8_t ipt_oflw:4, /* overflow counter */
ipt_flg:4; /* flags, see below */
#else
- u_int ipt_flg:4, /* flags, see below */
+ uint8_t ipt_flg:4, /* flags, see below */
ipt_oflw:4; /* overflow counter */
#endif
union ipt_timestamp {
diff --git a/slirp/tcp.h b/slirp/tcp.h
index 9d06836..b3817cb 100644
--- a/slirp/tcp.h
+++ b/slirp/tcp.h
@@ -51,10 +51,10 @@ struct tcphdr {
tcp_seq th_seq; /* sequence number */
tcp_seq th_ack; /* acknowledgement number */
#ifdef HOST_WORDS_BIGENDIAN
- u_int th_off:4, /* data offset */
+ uint8_t th_off:4, /* data offset */
th_x2:4; /* (unused) */
#else
- u_int th_x2:4, /* (unused) */
+ uint8_t th_x2:4, /* (unused) */
th_off:4; /* data offset */
#endif
uint8_t th_flags;


Tested-by: Stefan Weil 

There remain some issues with other packed structs
which are obviously no longer packed with -mms-bitfields,
for example those from bt.h, but slirp looks good with
this patch.

I used pahole (thanks Blue Swirl for this hint) and codiff
to investigate and compare the structs with and without
-mms-bitfields:

* create qemu.exe (or any binary which you want)
* convert it to elf format using objcopy -Oelf32-i386
  (or the cross variant)
* apply pahole -a to the resulting elf file
  (without -a some structs are missing)

Cheers,
Stefan W.

Re: [Qemu-devel] [RFC 6/6] isa: improve bus implementation of ebus bridge

[Richard Henderson]

On 08/20/2011 07:56 AM, Hervé Poussineau wrote:
> +memory_region_init(&s->isa_mem_space, "isa-memory", 0x0010);
> +memory_region_add_subregion(get_system_memory(),
> +APB_PCI_IO_BASE,
> +&s->isa_mem_space);

You should be passing on, or adding this subregion to, the PCI
memory region.  Unfortunately, apb_pci.c hasn't been converted
to the new api yet...


r~

[Qemu-devel] TCG slowdown

[Edgar E. Iglesias]

Lately, my TCG emulated machines have been running terribly slow.
Like a factor 3 or 4 slower, hardly usable.

I bisected it to this:

commit d5ab9713d2d4037fd56b0a26c8d4dc11cf09
Author: Jan Kiszka 
Date:   Tue Aug 2 16:10:21 2011 +0200

Avoid allocating TCG resources in non-TCG mode

Do not allocate TCG-only resources like the translation buffer when
running over KVM or XEN. Saves a "few" bytes in the qemu address space
and is also conceptually cleaner.

Signed-off-by: Jan Kiszka 
Signed-off-by: Anthony Liguori 


It turns out that the init of the tb cache is now moved to before ram_size
gets it's default value. And because the default tb cache size, if no
-tb-size option is given, is based on the ram_size it is now zero..

Cheers

Re: [Qemu-devel] The reason behind block linking constraint?

[Rob Landley]

On 08/18/2011 04:31 AM, Max Filippov wrote:
>> Hi, all
>>
>>  I am trying to figure out why QEMU put some constraints on block
>> linking (chaining). Take x86 as an example, there are two places
>> put constraints on block linking, gen_goto_tb and cpu_exec.
>>
>> - gen_goto_tb (target-i386/translate.c) ---
>>  /* NOTE: we handle the case where the TB spans two pages here */
>>  if ((pc & TARGET_PAGE_MASK) == (tb->pc & TARGET_PAGE_MASK) ||
>>  (pc & TARGET_PAGE_MASK) == ((s->pc - 1) & TARGET_PAGE_MASK))  {
>>  /* jump to same page: we can use a direct jump */
>>  tcg_gen_goto_tb(tb_num);
>>  gen_jmp_im(eip);
>>  tcg_gen_exit_tb((tcg_target_long)tb + tb_num);
>>  } else {
>>  /* jump to another page: currently not optimized */
>>  gen_jmp_im(eip);
>>  gen_eob(s);
>>  }
>> ---
>>
>> --- cpu_exec (cpu-exec.c) -
>>  /* see if we can patch the calling TB. When the TB
>> spans two pages, we cannot safely do a direct
>> jump. */
>>  if (next_tb != 0 && tb->page_addr[1] == -1) {
>>  tb_add_jump((TranslationBlock *)(next_tb & ~3), next_tb & 3, tb);
>>  }
>> ---
>>
>>  Is it just because we cannot optimize block linking which crosses page
>> boundary, or there are some correctness/safety issues should be considered?
> 
> If we link a TB with another TB from the different page, then the
> second TB may disappear when the memory mapping changes and the
> subsequent direct jump from the first TB will crash qemu.
> 
> I guess that this usually does not happen in usermode, because the
> guest would not modify executable code memory mapping. However I
> suppose that this is also possible.

Dynamic linking modifies guest code, requiring the page to be
retranslated.  With lazy binding this can happen at any time, and
without PIE executables this can happen to just about any executable page.

Rob

Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions

[Rob Landley]

On 08/17/2011 03:46 PM, Bryce Lanham wrote:
> These patches greatly expand Motorola 68k emulation within qemu, and are what 
> I used as a basis for my
> Google Summer of Code project to add NeXT hardware support to QEMU.

Can I get these patches as a tarball or a git tree or something?  Trying
to fish them out of either thunderbird of the web archive is a bit
tricky, and I'd very much like to test them.

Also, it looks like you're adding NeXT target support.  What would be
involved in adding simple Amiga, Atari, or ancient macintosh support
that Linux could boot on?  (I.E. I'm interested in Linux system
emulation of non-coldfire m68k.  So far that means "use aranym".)

Thanks,

Rob

Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions

[Rob Landley]

On 08/18/2011 06:12 AM, François Revol wrote:
> Le -10/01/-28163 20:59, Laurent Vivier a écrit :
>> Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a écrit :
>>> On 08/17/2011 03:46 PM, Bryce Lanham wrote:
 These patches greatly expand Motorola 68k emulation within qemu, and
 are what I used as a basis for my
 Google Summer of Code project to add NeXT hardware support to QEMU.
>>>
>>> Please don't crap flood the list with a series of 100 patches.
>>>
>>> Split things into logical chunks such that a series can be reasonably
>>> reviewed and applied.
>>
>> And I'm not sure this series of patches is ready for inclusion in qemu
>> mainline as it should break existing m68k emulation...
>>
>> Bryce, you should only post your patches, refering to the repository on
>> which they apply, i.e. git://gitorious.org/qemu-m68k/qemu-m68k.git ,
>> master branch.
>>
> 
> Btw, are you planning on merging it back someday?
> 
> François.

I note that I pulled that this morning, did "./configure
--disable-werror --target-list=m68k-softmmu", and then ran make, which
generated 4 header files and considered itself done.

I.E. m68k system emulation doesn't seem to be building in that tree.

Rob

Re: [Qemu-devel] Serial port on virtual machines

[Rob Landley]

On 08/18/2011 10:00 AM, bala suru wrote:
> Hi,
> 
> I'm running VM on kvm-qemu hyper visor . I need to access the serail
> port on the VM ,
> I tried the sample code to read/write com port but I get port error when
> ever I tried write something to the port(dev/ttyS0) .
> 
> the same code work fine on the normal OS .. is it the same way  as
> normal OS for accessing the serial port in vms ..?

I'm using a serial console in my system images.  Download any the
system-image tarballs at:

  http://landley.net/aboriginal/downloads/binaries/

Then use the "./run-emulator.sh" scripts, which should give you a serial
console in the emulated Linux system connected to qemu's stdin/stdout.
The qemu command line is in that script.

Rb

Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions

[Rob Landley]

On 08/18/2011 02:42 PM, Natalia Portillo wrote:
> Hi Laurent,
> 
> El 18/08/2011, a las 15:02, Laurent Vivier escribió:
> 
>>  
>>
>> Le 18 août 2011 à 13:12, "François Revol" > > a écrit :
>>
>> > Le -10/01/-28163 20:59, Laurent Vivier a écrit :
>> > > Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a écrit :
>> > >> On 08/17/2011 03:46 PM, Bryce Lanham wrote:
>> > >>> These patches greatly expand Motorola 68k emulation within qemu,
>> and are what I used as a basis for my
>> > >>> Google Summer of Code project to add NeXT hardware support to QEMU.
>> > >>
>> > >> Please don't crap flood the list with a series of 100 patches.
>> > >>
>> > >> Split things into logical chunks such that a series can be
>> reasonably
>> > >> reviewed and applied.
>> > >
>> > > And I'm not sure this series of patches is ready for inclusion in
>> qemu
>> > > mainline as it should break existing m68k emulation...
>> > >
>> > > Bryce, you should only post your patches, refering to the
>> repository on
>> > > which they apply, i.e. git://gitorious.org/qemu-m68k/qemu-m68k.git ,
>> > > master branch.
>> > >
>> >
>> > Btw, are you planning on merging it back someday?
>> >
>>
>>  
>>
>> Yes... when it will work correctly.
>>
>>  
>>
>> I have at least, to rework 680x0 FPU part (80bit fpu) to not break the
>> existing one (64bit fpu).
>> I have to check modified instructions don't break existing m68k emulation.
> 
> Maybe Bryce can help you

I have a build system that builds the same simple Linux system for a
dozen different targets (uClibc 0.9.32, Linux 3.0, busybox 1.19.0,
binutils 2.17, gcc 4.2.1, make 3.81), boots them all under qemu the same
way, and either interactively use them or can automatically build the
whole of Linux From Scratch under them (either with a fully native
toolchain or with distcc calling out to the cross compiler to speed
things up).

I would very much like to test m68k.  I've been building m68k system
images forever (the kernel's some atari variant donated to the project
by a user), but have only been able to test them a couple times under
aranym, not under qemu.

Web page:
  http://landley.net/aboriginal

Prebuilt binary system images for use with qemu:
  http://landley.net/aboriginal/downloads/binaries

>> Currently, I'm trying to port some parts of BasiliskII into Qemu to be
>> able to boot MacOS 7.6.
> 
> Why are you planning to port a hack instead of making a full machine
> emulation?

Yay machine emulation.  If qemu comes up with an m68k system emulation
that has a chance of running Linux, please let me know...

Rob

Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions

[Laurent Vivier]

Le samedi 20 août 2011 à 15:57 -0500, Rob Landley a écrit :
> On 08/18/2011 06:12 AM, François Revol wrote:
> > Le -10/01/-28163 20:59, Laurent Vivier a écrit :
> >> Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a écrit :
> >>> On 08/17/2011 03:46 PM, Bryce Lanham wrote:
>  These patches greatly expand Motorola 68k emulation within qemu, and
>  are what I used as a basis for my
>  Google Summer of Code project to add NeXT hardware support to QEMU.
> >>>
> >>> Please don't crap flood the list with a series of 100 patches.
> >>>
> >>> Split things into logical chunks such that a series can be reasonably
> >>> reviewed and applied.
> >>
> >> And I'm not sure this series of patches is ready for inclusion in qemu
> >> mainline as it should break existing m68k emulation...
> >>
> >> Bryce, you should only post your patches, refering to the repository on
> >> which they apply, i.e. git://gitorious.org/qemu-m68k/qemu-m68k.git ,
> >> master branch.
> >>
> > 
> > Btw, are you planning on merging it back someday?
> > 
> > François.
> 
> I note that I pulled that this morning, did "./configure
> --disable-werror --target-list=m68k-softmmu", and then ran make, which
> generated 4 header files and considered itself done.
> 
> I.E. m68k system emulation doesn't seem to be building in that tree.

first off all, this branch is only able to build m68k-linux-user qemu/,
then try:

cd qemu
mkdir build-test
cd build-test
../configure --disable-werror --target-list=m68k-softmmu
make

and let me know what happens...

Regards,
Laurent

Re: [Qemu-devel] [Help]: How to setup a VM based on kernel source code.

[Rob Landley]

On 08/19/2011 04:58 AM, Zhi Yong Wu wrote:
> HI,
> 
> I have met one scenario; currently i want to set up a VM based on
> latest kernel tree; but i  only have latest kernel source code and
> compiled it on one fedora 15 workstation. To achieve the objective,
> what actions should i take next step? use -kernel -initrd options?
> other ways?
> 
> If you have this experience, pls give me one hand. thanks.

I've done this, the project is at http://landley.net/aboriginal

It a big bash script that:

A) downloads source code
B) builds a cross compiler (for any of a dozen targets)
C) builds a new root filesystem and kernel
E) packages it up into a system image qemu can boot.

The system images include shell scripts that invoke qemu with the
appropriate command line arguments.

You can download the build scritps here:

  http://landley.net/aboriginal/downloads

You can download prebuilt binary tarballs for each supported target here:

  http://landley.net/aboriginal/downloads/binaries

What you probably want to do is grab something like
system-image-armv5l.tar.bz2, extract it, "./run-emulator.sh" (which
should give you a shell prompt inside the emulator, type "exit" when
done), and then once you're happy it works for you look at the
run-emulator.sh script to see how it's invoking qemu, then look at the
build scripts to see how it's compiling everything.  (There's no make
magic or python or anything in there, it's all just bash scripts.)

Each of those system images has the relevant config files used to build
the kernel, uClibc, and busybox in the /usr/src directory.

A few years ago I wrote up a giant lump of documentation here:

  http://landley.net/aboriginal/downloads/presentation.pdf

I'm putting together a 1.0.3 release with Linux 3.0, busybox 1.19.0, and
uClibc 0.9.32 this weekend.  If you don't want to wait for the release,
go to http;//landley.net/hg/aboriginal and click on one of the download
links near the top to get a tarball of the current build scripts from
source control.

Rob

Re: [Qemu-devel] How can I understand iotlb (IOMMU)

[Rob Landley]

On 02/20/2011 09:15 PM, wang sheng wrote:
> I can't understand CPUState's  iotlb field , Why we need iotlb ?

A memory management unit (MMU) translates virtual to physical addresses
using page tables.  Page tables are a tree structure are stored in
memory, and can get REALLY BIG.  If the chip had to go out to physical
memory and walk the page tables each time it needed to translate a
virtual address to a physical address, it would perform 3-4 MMU memory
accesses for each access an instruction tried to make that needed
translating.

So the chip has a "Translation Lookaside Buffer", which is an address
cache that records the virtual->physical mappings for the last few pages
it had to look up.  Each TLB entry has the virtual and physical start
addreses, the length of the chunk of memory this represents, and the
permission flags (can I read, can I write, can I execute) that apply to
that memory (as seen through that mapping).  Each virtual instruction
checks the TLB first to see if it has that virtual address lookup
cached, just like it checks the L1 and L2 caches to see if the data is
there before going out to physical memory for it.

When the CPU tries to call a virtual address it hasn't got a TLB entry
for (or has one with the wrong permissions), it generates a "soft page
fault" which calls an interrupt handler to deal with it.  The handler
can resolve the fault by picking an existing TLB entry to discard (to
make room), walking the page tables in physical memory to look up the
virtual->physical mapping (and possibly do fixups on the page tables
like allocating a new page of physical memory if there isn't currently
one assigned; this happens for sparse mappings, copy on write,
swapping...), loading the new TLB entry from the page tables, and then
returning from the interrupt to let the program proceed.  Or it can kill
the program (with a signal) if it made an illegal access.  (The program
can set up a signal handler, normal unix semantics apply.  I think this
is "SIGBUS".)

The Linux kernel actually reserves one or two TLB entries for itself,
using a "huge page".  This is one giant TLB entry (the length field is a
gigabyte or two long) that maps all the kernel's memory to a big linear
range of physical addresses containing the kernel's code and the
kernel's data.  When the CPU goes into userspace it removes the
read/write/execute bits for these entries (so attempts to dereference
those addresses will generate a page fault), but keeps the TLB entry in
place.  Then when you make a system call, it can just switch the access
back on and the kernel data is still cached.

Note that cache entries attach to TLB entries.  If you flush the TLB,
you flush the L1 cache too.  (Note: having a TLB entry doesn't mean you
have the data in L1 or L2 cache.  Normal sized TLB entries are page
sized, I.E. 4k, and cache lines are much smaller (64 bytes or 128 bytes
is fairly common), so one TLB entry may cover 32 cache lines.  But if
the TLB entry isn't there you need to do multiple physical memory
lookups to descend through the page table tree to find it, each costing
hundreds or even thousands of cycles of latency.  When you flush a TLB
entry its cache lines get flushed back and discarded too, because the
CPU no longer knows where they live without the TLB entry.)

When you switch page tables (schedule a process), you flush the TLB
entries belonging to the old page table, which means flushing the cache.
 Huge amounts of modern performance optimization involve TLB and cache
management, only flushing what you actually NEED to and keeping the rest
around if you can to avoid reloading it.  (I.E. defer TLB flushing in
case this process swaps back to the other one quickly.  If you can keep
around cached data you currently can't access in this context because
these page tables have no mapping for it, you don't have to load it back
in when you switch back to the other context that CAN access it.)

Rob

Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions

[Rob Landley]

On 08/19/2011 03:55 AM, François Revol wrote:
> Le 19/08/2011 04:14, Natalia Portillo a écrit :
>> Hi,
>>
> 
> [...]
> (no need to quote the full thread!)
> 

 He worked on emulating an abandoned, strange, difficult to get, and
 undocumented hardware, using your 111 patches, and finished it
 before the wholy more experienced MESS team.
>>>
>>> The next-cube emulation is really working ?
>>
>> Yes, it is, absolutely.
> 
> Cool I need to add this target to my Haiku port... where are the docs
> for the boot process ?
> 
> 
>> Why are you planning to port a hack instead of making a full machine
>> emulation?
>
> Because I'm lazy and dumb: the work is already done, I like
> cut'n'paste.

 Yeah, you said it!
 The work is already done, we have all the hardware emulation that
 Basilisk substitutes for hacks.
>>>
>>> I'm not sure of that... no MMU emulation, no Nubus, no ethernet card, no
>>> video card, no SWIM, no SCSI, ... useless with a patched ROM.
>>
>> Macs do not have videocards :p, only the Mac II and we're not forced
>> to emulate that one.
>> SWIM is a piece of cake that can be even implemented without ICs, just
>> some logical arrays.
>> NuBus is not required for almost anything, only the video card uses
>> it, and it's present only on the Mac II, a stub will suffice to make
>> Toolbox be happy.
>> Most m68k didn't include a network card, third party ones are stock
>> chips (probably almost all are NE2000, 3COM and PCNET), and Apple
>> integrated ones are also stock, easy to do :p
> 
> NIC isn't really necessary at first, those things don't netboot anyway,
> do they ?

The hardware I'm interested in is:

A) CPU with MMU (FPU is nice but optional)
B) At least 256k ram,
C) Serial port
D) Three hard drives (IDE, SCSI, etc.)
E) Hardware clock
F) Network card (for distcc)

One of the goals of mmy project is to replace cross comiling with native
compiling, and that's the set of hardware I need to get a reasonably
convenient native development environment running under the emulator.

Rob

Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions

[Rob Landley]

On 08/19/2011 03:08 PM, Anthony Liguori wrote:
> On 08/19/2011 11:07 AM, Laurent Vivier wrote:
>>
>>
>>
>>
>>
>> Le 19 août 2011 à 17:52, Natalia Portillo  a écrit :
>>
>>>
>>> El 19/08/2011, a las 09:55, François Revol escribió:
>> [snip]
 Release early, release often :p
>>>
>>> +1Ok, Ok, I think all m68k core can be submitted except some bitfield
>>> operations and fpu instructions.
>>
>> Just need to know how Anthony and Paul want I proceed...
> 
> Well let's step back here for a minute.
> 
> The most important problem to solve is for someone to maintain whatever
> is in the tree consistently (and incrementally) improving what we have.

I dunno about maintain and improve, but if an m68k board emulation
starts working I can regression test it against Linux system images and
make puppy eyes at people when it breaks.  (Plus the occasional monkey
patch offering The Wrong Fix to motivate people. :)

> Laurent, if you want to take over m68k and Paul doesn't object, I'm all
> for it.  But that doesn't mean that I want to see 400 commits of stuff
> that only half works.  I'd like to see a systematic approach to either
> picking a platform and making it robust or fixing what's there already.

I would very much like something capable of booting m68k Linux,
specifically
http://landley.net/aboriginal/downloads/binaries/old/1.0.1/system-image-m68k.tar.bz2

(The kernel in that tarball is randomish, I think some defconfig for
atari, but the root filesystem was tested under ananym and worked.)

I'm in the process of building a Linux 3.0, uClibc 0.9.32, busybox
1.19.0 variant which should be ready tomorrow-ish, if that would be a
better testing base.  I'm probably basing it on the atari_defconfig in
the 3.0 kernel unless somebody has a better idea.  (In case I need to
fish out aranym again.)

Rob

Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions

[Rob Landley]

On 08/18/2011 03:51 PM, Laurent Vivier wrote:
> Le jeudi 18 août 2011 à 21:13 +0100, Natalia Portillo a écrit :
>> Hi Laurent,
>>
>> El 18/08/2011, a las 20:57, Laurent Vivier escribió:
>>
>>> Le jeudi 18 août 2011 à 20:42 +0100, Natalia Portillo a écrit :
 Hi Laurent,
>>>
>>> Hi Natalia,
>>>
 El 18/08/2011, a las 15:02, Laurent Vivier escribió:

>
>
>
> Le 18 août 2011 à 13:12, "François Revol"  a écrit : 
>
>> Le -10/01/-28163 20:59, Laurent Vivier a écrit : 
>>> Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a
> écrit : 
 On 08/17/2011 03:46 PM, Bryce Lanham wrote: 
> These patches greatly expand Motorola 68k emulation within
> qemu, and are what I used as a basis for my 
> Google Summer of Code project to add NeXT hardware support to
> QEMU. 

 Please don't crap flood the list with a series of 100 patches. 

 Split things into logical chunks such that a series can be
> reasonably 
 reviewed and applied. 
>>>
>>> And I'm not sure this series of patches is ready for inclusion
> in qemu 
>>> mainline as it should break existing m68k emulation... 
>>>
>>> Bryce, you should only post your patches, refering to the
> repository on 
>>> which they apply, i.e.
> git://gitorious.org/qemu-m68k/qemu-m68k.git , 
>>> master branch. 
>>>
>>
>> Btw, are you planning on merging it back someday? 
>>
>
>
> Yes... when it will work correctly.
>
>
> I have at least, to rework 680x0 FPU part (80bit fpu) to not break
> the existing one (64bit fpu).
> I have to check modified instructions don't break existing m68k
> emulation.


 Maybe Bryce can help you
>>>
>>> I don't know if he is courageous enough to review and push 111
>>> patches ;-)
>>
>> He worked on emulating an abandoned, strange, difficult to get, and 
>> undocumented hardware, using your 111 patches, and finished it before the 
>> wholy more experienced MESS team.
> 
> The next-cube emulation is really working ?
> 
>> He is! xD
> 
> There is no problem for me, he can do...
> 
> Currently, I'm trying to port some parts of BasiliskII into Qemu to
> be able to boot MacOS 7.6.


 Why are you planning to port a hack instead of making a full machine
 emulation?
>>>
>>> Because I'm lazy and dumb: the work is already done, I like cut'n'paste.
>>
>> Yeah, you said it!
>> The work is already done, we have all the hardware emulation that Basilisk 
>> substitutes for hacks.
> 
> I'm not sure of that... no MMU emulation, no Nubus, no ethernet card, no
> video card, no SWIM, no SCSI, ... useless with a patched ROM.
> 
> You know, nights are not long enough...
> 
>> We only lack the 68k cpu (oh! your patches!!!) and the glue :p
> 
> this part is not working well as well ... gcc cannot compile linux
> kernel, some demos fail in gtk-demo, ...

I got gcc 4.2.1 with binutils 2.17 to compile the m68k Linux kernel
(including 3.0).

This kind of regression testing of each new release on various platforms
is what I've been doing for the ones I've got working for years now.
I'd love to add m68k to it (heck, I've got infrastructure to do nightly
builds from upstream -git of the kernel and uClibc and auto-bisect
breakage that prevented dropbear and strace from building natively under
the result; I admit I haven't put in the effort to follow up on the
result yet).

But all i've been able to say so far is 'I got it to compile", I can't
_run_ it on qemu.  (And my aranym setup keeps bit rotting, and hasn't
got the right kind of console anyway...)

Rob

Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions

[Rob Landley]

On 08/20/2011 04:16 PM, Laurent Vivier wrote:
> Le samedi 20 août 2011 à 15:57 -0500, Rob Landley a écrit :
>> On 08/18/2011 06:12 AM, François Revol wrote:
>>> Le -10/01/-28163 20:59, Laurent Vivier a écrit :
 Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a écrit :
> On 08/17/2011 03:46 PM, Bryce Lanham wrote:
>> These patches greatly expand Motorola 68k emulation within qemu, and
>> are what I used as a basis for my
>> Google Summer of Code project to add NeXT hardware support to QEMU.
>
> Please don't crap flood the list with a series of 100 patches.
>
> Split things into logical chunks such that a series can be reasonably
> reviewed and applied.

 And I'm not sure this series of patches is ready for inclusion in qemu
 mainline as it should break existing m68k emulation...

 Bryce, you should only post your patches, refering to the repository on
 which they apply, i.e. git://gitorious.org/qemu-m68k/qemu-m68k.git ,
 master branch.

>>>
>>> Btw, are you planning on merging it back someday?
>>>
>>> François.
>>
>> I note that I pulled that this morning, did "./configure
>> --disable-werror --target-list=m68k-softmmu", and then ran make, which
>> generated 4 header files and considered itself done.
>>
>> I.E. m68k system emulation doesn't seem to be building in that tree.
> 
> first off all, this branch is only able to build m68k-linux-user qemu/,
> then try:
> 
> cd qemu
> mkdir build-test
> cd build-test
> ../configure --disable-werror --target-list=m68k-softmmu
> make
> 
> and let me know what happens...

It complained about config-devices.mak not being there... then built for
a while until it died with:

qapi-generated/qga-qapi-types.c:19:28: error: qga-qapi-visit.h: No such
file or directory

Rob

Re: [Qemu-devel] [PATCH] Improvements to libtool support.

[Brad]

On 13/08/11 8:30 PM, Brad wrote:

Improvements to the libtool support in QEMU. Replace hard coded
libtool in the infrastructure with $(LIBTOOL) and allow
overriding the libtool binary used via the configure
script.

Signed-off-by: Brad Smith


Alon?


---
  Makefile.objs  |2 +-
  configure  |5 ++---
  libcacard/Makefile |   10 +-
  rules.mak  |2 +-
  4 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/Makefile.objs b/Makefile.objs
index 16eef38..6c0be08 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -369,7 +369,7 @@ trace-dtrace.lo: trace-dtrace.dtrace
@echo "missing libtool. please install and rerun configure."; exit 1
  else
  trace-dtrace.lo: trace-dtrace.dtrace
-   $(call quiet-command,libtool --mode=compile --tag=CC dtrace -o $@ -G -s $<, 
"  lt GEN trace-dtrace.o")
+   $(call quiet-command,$(LIBTOOL) --mode=compile --tag=CC dtrace -o $@ -G -s $<, 
"  lt GEN trace-dtrace.o")
  endif

  simpletrace.o: simpletrace.c $(GENERATED_HEADERS)
diff --git a/configure b/configure
index 6c77067..eb7497b 100755
--- a/configure
+++ b/configure
@@ -224,6 +224,7 @@ cc="${CC-${cross_prefix}gcc}"
  ar="${AR-${cross_prefix}ar}"
  objcopy="${OBJCOPY-${cross_prefix}objcopy}"
  ld="${LD-${cross_prefix}ld}"
+libtool="${LIBTOOL-${cross_prefix}libtool}"
  strip="${STRIP-${cross_prefix}strip}"
  windres="${WINDRES-${cross_prefix}windres}"
  pkg_config="${PKG_CONFIG-${cross_prefix}pkg-config}"
@@ -1341,10 +1342,8 @@ fi
  ##
  # libtool probe

-if ! has libtool; then
+if ! has $libtool; then
  libtool=
-else
-libtool=libtool
  fi

  ##
diff --git a/libcacard/Makefile b/libcacard/Makefile
index fe9747a..56dc974 100644
--- a/libcacard/Makefile
+++ b/libcacard/Makefile
@@ -37,7 +37,7 @@ install-libcacard:
@echo "libtool is missing, please install and rerun configure"; exit 1
  else
  libcacard.la: $(libcacard.lib-y) $(QEMU_OBJS_LIB)
-   $(call quiet-command,libtool --mode=link --quiet --tag=CC $(CC) $(libcacard_libs) 
-lrt -rpath $(libdir) -o $@ $^,"  lt LINK $@")
+   $(call quiet-command,$(LIBTOOL) --mode=link --quiet --tag=CC $(CC) 
$(libcacard_libs) -lrt -rpath $(libdir) -o $@ $^,"  lt LINK $@")

  libcacard.pc: $(libcacard_srcpath)/libcacard.pc.in
sed -e 's|@LIBDIR@|$(libdir)|' \
@@ -53,10 +53,10 @@ install-libcacard: libcacard.pc libcacard.la vscclient
$(INSTALL_DIR) "$(DESTDIR)$(libdir)/pkgconfig"
$(INSTALL_DIR) "$(DESTDIR)$(libcacard_includedir)"
$(INSTALL_DIR) "$(DESTDIR)$(bindir)"
-   libtool --mode=install $(INSTALL_PROG) vscclient "$(DESTDIR)$(bindir)"
-   libtool --mode=install $(INSTALL_DATA) libcacard.la 
"$(DESTDIR)$(libdir)"
-   libtool --mode=install $(INSTALL_DATA) libcacard.pc 
"$(DESTDIR)$(libdir)/pkgconfig"
+   $(LIBTOOL) --mode=install $(INSTALL_PROG) vscclient 
"$(DESTDIR)$(bindir)"
+   $(LIBTOOL) --mode=install $(INSTALL_DATA) libcacard.la 
"$(DESTDIR)$(libdir)"
+   $(LIBTOOL) --mode=install $(INSTALL_DATA) libcacard.pc 
"$(DESTDIR)$(libdir)/pkgconfig"
for inc in *.h; do \
-   libtool --mode=install $(INSTALL_DATA) $(libcacard_srcpath)/$$inc 
"$(DESTDIR)$(libcacard_includedir)"; \
+   $(LIBTOOL) --mode=install $(INSTALL_DATA) $(libcacard_srcpath)/$$inc 
"$(DESTDIR)$(libcacard_includedir)"; \
done
  endif
diff --git a/rules.mak b/rules.mak
index 1a2622c..884d421 100644
--- a/rules.mak
+++ b/rules.mak
@@ -22,7 +22,7 @@ ifeq ($(LIBTOOL),)
@echo "missing libtool. please install and rerun configure"; exit 1
  else
  %.lo: %.c
-   $(call quiet-command,libtool --mode=compile --quiet --tag=CC $(CC) $(QEMU_INCLUDES) 
$(QEMU_CFLAGS) $(QEMU_DGFLAGS) $(CFLAGS) -c -o $@ $<,"  lt CC $@")
+   $(call quiet-command,$(LIBTOOL) --mode=compile --quiet --tag=CC $(CC) 
$(QEMU_INCLUDES) $(QEMU_CFLAGS) $(QEMU_DGFLAGS) $(CFLAGS) -c -o $@ $<,"  lt CC 
$@")
  endif

  %.o: %.S



--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [Qemu-devel] TCG slowdown

[Jan Kiszka]

On 2011-08-20 13:51, Edgar E. Iglesias wrote:
> Lately, my TCG emulated machines have been running terribly slow.
> Like a factor 3 or 4 slower, hardly usable.
> 
> I bisected it to this:
> 
> commit d5ab9713d2d4037fd56b0a26c8d4dc11cf09
> Author: Jan Kiszka 
> Date:   Tue Aug 2 16:10:21 2011 +0200
> 
> Avoid allocating TCG resources in non-TCG mode
> 
> Do not allocate TCG-only resources like the translation buffer when
> running over KVM or XEN. Saves a "few" bytes in the qemu address space
> and is also conceptually cleaner.
> 
> Signed-off-by: Jan Kiszka 
> Signed-off-by: Anthony Liguori 
> 
> 
> It turns out that the init of the tb cache is now moved to before ram_size
> gets it's default value. And because the default tb cache size, if no
> -tb-size option is given, is based on the ram_size it is now zero..

Yes, already stumbled over that regression myself. See
http://thread.gmane.org/gmane.comp.emulators.qemu/113547

Jan



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions

[Rob Landley]

On 08/20/2011 04:16 PM, Laurent Vivier wrote:
>> I.E. m68k system emulation doesn't seem to be building in that tree.
> 
> first off all, this branch is only able to build m68k-linux-user qemu/,
> then try:
> 
> cd qemu
> mkdir build-test
> cd build-test
> ../configure --disable-werror --target-list=m68k-softmmu
> make
> 
> and let me know what happens...

Ahem, helps to do that in the right tree.  (That test was in current
vanilla -git.)

It built fine.  No new board targets, but I'll see if I can find time to
fiddle with it.

Thanks,

Rob

Re: [Qemu-devel] TCG slowdown

[Edgar E. Iglesias]

On Sat, Aug 20, 2011 at 03:37:09PM -0700, Jan Kiszka wrote:
> On 2011-08-20 13:51, Edgar E. Iglesias wrote:
> > Lately, my TCG emulated machines have been running terribly slow.
> > Like a factor 3 or 4 slower, hardly usable.
> > 
> > I bisected it to this:
> > 
> > commit d5ab9713d2d4037fd56b0a26c8d4dc11cf09
> > Author: Jan Kiszka 
> > Date:   Tue Aug 2 16:10:21 2011 +0200
> > 
> > Avoid allocating TCG resources in non-TCG mode
> > 
> > Do not allocate TCG-only resources like the translation buffer when
> > running over KVM or XEN. Saves a "few" bytes in the qemu address space
> > and is also conceptually cleaner.
> > 
> > Signed-off-by: Jan Kiszka 
> > Signed-off-by: Anthony Liguori 
> > 
> > 
> > It turns out that the init of the tb cache is now moved to before ram_size
> > gets it's default value. And because the default tb cache size, if no
> > -tb-size option is given, is based on the ram_size it is now zero..
> 
> Yes, already stumbled over that regression myself. See
> http://thread.gmane.org/gmane.comp.emulators.qemu/113547

OK, thanks. I've pushed your fix.

Cheers

Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions

[Natalia Portillo]

Hi,

El 20/08/2011, a las 21:55, Rob Landley escribió:

> On 08/17/2011 03:46 PM, Bryce Lanham wrote:
>> These patches greatly expand Motorola 68k emulation within qemu, and are 
>> what I used as a basis for my
>> Google Summer of Code project to add NeXT hardware support to QEMU.
> 
> Can I get these patches as a tarball or a git tree or something?  Trying
> to fish them out of either thunderbird of the web archive is a bit
> tricky, and I'd very much like to test them.
> 
> Also, it looks like you're adding NeXT target support.  What would be
> involved in adding simple Amiga

You would need to add (or copy/paste from UAE) all the Amiga custom chips, the 
Zorro bus, and implement the MMU (currently is anything but finished in 
Laurent's words)

> , Atari,

You would need to add (or copy/paste from Aranym) all the Atari Falcon 
not-so-custom chips, and implement the MMU.

> or ancient macintosh support

Most of the hardware (but a few required ones like SWIM) is already in QEMU, 
you need to glue everything, make Toolbox be VERY happy about its environment, 
make Mac OS boot so it can second-boot Linux (the direct-booter is so buggy it 
may introduce phantom bugs on the emulation) and implement the MMU.

> that Linux could boot on?  (I.E. I'm interested in Linux system
> emulation of non-coldfire m68k.  So far that means "use aranym".)

Linux requires the MMU and an almost complete hardware emulation.
Standard m68k emulations (UAE, Aranym and specially BasiliskII) try to patch 
the OS to work.

Indeed BasiliskII is anything but a real macintosh emulator, as it patches 
heavily the Toolbox and Mac OS (that's why Linux and A/UX will never work on it)

> Thanks,
> 
> Rob
> 

Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions

[Rob Landley]

On 08/20/2011 04:16 PM, Laurent Vivier wrote:
> Le samedi 20 août 2011 à 15:57 -0500, Rob Landley a écrit :
>> On 08/18/2011 06:12 AM, François Revol wrote:
>>> Le -10/01/-28163 20:59, Laurent Vivier a écrit :
 Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a écrit :
> On 08/17/2011 03:46 PM, Bryce Lanham wrote:
>> These patches greatly expand Motorola 68k emulation within qemu, and
>> are what I used as a basis for my
>> Google Summer of Code project to add NeXT hardware support to QEMU.
>
> Please don't crap flood the list with a series of 100 patches.
>
> Split things into logical chunks such that a series can be reasonably
> reviewed and applied.

 And I'm not sure this series of patches is ready for inclusion in qemu
 mainline as it should break existing m68k emulation...

 Bryce, you should only post your patches, refering to the repository on
 which they apply, i.e. git://gitorious.org/qemu-m68k/qemu-m68k.git ,
 master branch.

>>>
>>> Btw, are you planning on merging it back someday?
>>>
>>> François.
>>
>> I note that I pulled that this morning, did "./configure
>> --disable-werror --target-list=m68k-softmmu", and then ran make, which
>> generated 4 header files and considered itself done.
>>
>> I.E. m68k system emulation doesn't seem to be building in that tree.
> 
> first off all, this branch is only able to build m68k-linux-user qemu/,
> then try:
> 
> cd qemu
> mkdir build-test
> cd build-test
> ../configure --disable-werror --target-list=m68k-softmmu
> make
> 
> and let me know what happens...

Hmmm, there is a q800 target I hadn't noticed.  I built the
mac_defconfig target and did -kernel vmlinux on that with -nographic and
-append "console=/dev/ttyS0", and it went:

(qemu) QEMU 0.15.50 monitor - type 'help' for more information
(qemu) qemu: fatal: Illegal instruction: 7f45 @ 
D0 = fffb   A0 = 0021b24c   F0 =  c000
D1 =    A1 = 002c16fe   F1 =  c000
D2 = 002c002c   A2 = 1000   F2 =  c000
D3 = 17b82700   A3 = 002d8eb0   F3 =  c000
D4 =    A4 =    F4 =  c000
D5 =    A5 =    F5 =  c000
D6 =    A6 =    F6 =  c000
D7 =    A7 = 103c   F7 =  c000
PC =    SR = 2700 - Aborted

This sound at all familiar?  (Is there a different kernel file I should
be using?  There's no arch/m68k/boot or arch/m68k/mac/boot I could find.
 Or is q800 not entirely there?)

Thanks,

Rob

Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions

[Rob Landley]

On 08/20/2011 06:17 PM, Natalia Portillo wrote:
>> or ancient macintosh support
> 
> Most of the hardware (but a few required ones like SWIM) is already
> in QEMU, you need to glue everything, make Toolbox be VERY happy
> about its environment, make Mac OS boot so it can second-boot Linux
> (the direct-booter is so buggy it may introduce phantom bugs on the
> emulation) and implement the MMU.

I haven't got a copy of ancient MacOS.

Why is the direct booter buggy?  I'm happy to track down and isolate
phantom bugs, either in the kernel or in qemu.  (One nice thing about
emulators is you can get deterministic regression tests reasonably
easily. :)

How do I _use_ the direct booter, anyway?  I built mac_defconfig in 3.0
but it only gave me a vmlinux, which faulted on the instruction at
address 0.  I tried m68k-objdump -O binary vmlinux vmlinux.bin but that
wouldnt' bot at all (qemu -kernel refused to load it).

>> that Linux could boot on?  (I.E. I'm interested in Linux system 
>> emulation of non-coldfire m68k.  So far that means "use aranym".)
> 
> Linux requires the MMU and an almost complete hardware emulation. 
> Standard m68k emulations (UAE, Aranym and specially BasiliskII) try
> to patch the OS to work.

That's kinda sad.  Is there a web page anywhere that elaborates on this?

> Indeed BasiliskII is anything but a real macintosh emulator, as it
> patches heavily the Toolbox and Mac OS (that's why Linux and A/UX
> will never work on it)

I believe toolbox is the ancient mac bios, correct?  Does Linux need/use
it at all?

Rob

Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions

[Natalia Portillo]

El 21/08/2011, a las 00:42, Rob Landley escribió:

> On 08/20/2011 06:17 PM, Natalia Portillo wrote:
>>> or ancient macintosh support
>> 
>> Most of the hardware (but a few required ones like SWIM) is already
>> in QEMU, you need to glue everything, make Toolbox be VERY happy
>> about its environment, make Mac OS boot so it can second-boot Linux
>> (the direct-booter is so buggy it may introduce phantom bugs on the
>> emulation) and implement the MMU.
> 
> I haven't got a copy of ancient MacOS.
> 
> Why is the direct booter buggy?  I'm happy to track down and isolate
> phantom bugs, either in the kernel or in qemu.  (One nice thing about
> emulators is you can get deterministic regression tests reasonably
> easily. :)
> 
> How do I _use_ the direct booter, anyway?  I built mac_defconfig in 3.0
> but it only gave me a vmlinux, which faulted on the instruction at
> address 0.  I tried m68k-objdump -O binary vmlinux vmlinux.bin but that
> wouldnt' bot at all (qemu -kernel refused to load it).
> 
>>> that Linux could boot on?  (I.E. I'm interested in Linux system 
>>> emulation of non-coldfire m68k.  So far that means "use aranym".)
>> 
>> Linux requires the MMU and an almost complete hardware emulation. 
>> Standard m68k emulations (UAE, Aranym and specially BasiliskII) try
>> to patch the OS to work.
> 
> That's kinda sad.  Is there a web page anywhere that elaborates on this?

It is a known thing that Linux requires MMU, it appears on the installation 
guide of all m68k distros.
On how and how much they patch the OS, check their sources.

>> Indeed BasiliskII is anything but a real macintosh emulator, as it
>> patches heavily the Toolbox and Mac OS (that's why Linux and A/UX
>> will never work on it)
> 
> I believe toolbox is the ancient mac bios, correct?  Does Linux need/use
> it at all?

Yes and no to both.
Mac OS is a really complex operating system where everything is divided in 
little pieces that can be loaded individually and independently (the Grand 
Unified Model, the reason why resource forks exist).
Toolbox is the most important part, the one that resides inside the ROM chip, 
provides the specific model drivers (and in the II models, loads the video 
driver from the NuBus card), and loads the rest of the system from the System 
file inside MacOS.

It does not expect a boot loader, it's the OS itself, indeed in an specific 
model the whole OS is contained in ROM.

There is a table for OS functions that can be made to point to ROM (implemented 
on Toolbox) or in RAM (System file, bug or functionality updates).

BasiliskII patches that table inserting their own functions (for example, the 
floppy driver is "enhanced" to provide access to the host disk images, instead 
of calling to the SWIM chip that will manage the floppy drive in a real 
macintosh).

The Linux bootloader is nothing more than a Mac OS application that loads the 
Linux kernel and gives it access to the full RAM, where it can (and as you see 
in the compatibility list, does not so well) access to the whole Macintosh 
hardware bypassing both Toolbox and System.

Not long ago some people discovered a way to substitute the System file (RAM 
portion of the OS) so the Toolbox loads directly a Linux kernel. This is buggy 
for a lot of reasons (that was never the intended way, in-ROM drivers may be 
too buggy, so on).

Apple UNIX (A/UX) on the other way provides a full System file (corresponding 
to Mac OS 7) and then loads its kernel, retaining the original table in memory 
for Mac OS applications compatibility and the GUI (yeah, while it's a UNIX and 
contains X11, native applications can be made that while being A/UX ones, use, 
calls and depend, on the Toolbox and System functions :D)

So unless an emulation is complete enough to make the Toolbox happily load a 
System file, it cannot be called a Macintosh emulator.
It will be merely a custom-hardware-emulator capable of running Mac OS 
(BasiliskII) or Linux-m68k (nothing implemented right now).

Saying this of pure memory, BasiliskII patches (and so, does not emulate them 
really) the following devices: floppy (calls host disk images, not a floppy 
emulated device, whatever if the image is an hdd, floppy, or cd, it appears as 
a floppy to the OS), SCSI (there is no scsi emulated at all, the driver is 
patched to call to host ASPI devices), framebuffer (any combination is 
available independently of the Toolbox's expected one), NuBus (not present or 
patched at all), sound (not DAC at all), network (again, no network card at 
all), graphics accelerators (none emulated, requires NuBus), filesystem code 
(to make the host folder appear in desktop).

Btw, vMac is more loyal to real hardware emulation.

And the hardware, and the whole Toolbox and System are heavily documented up to 
II machines in the Inside Macintosh Volumes.

> Rob

[Qemu-devel] buildbot failure in qemu on default_x86_64_fedora16

[qemu]

The Buildbot has detected a new failure on builder default_x86_64_fedora16 
while building qemu.
Full details are available at:
 http://buildbot.b1-systems.de/qemu/builders/default_x86_64_fedora16/builds/0

Buildbot URL: http://buildbot.b1-systems.de/qemu/

Buildslave for this Build: kraxel_fedora16

Build Reason: The Nightly scheduler named 'nightly_default' triggered this build
Build Source Stamp: [branch master] HEAD
Blamelist: 

BUILD FAILED: failed git

sincerely,
 -The Buildbot

Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions

[Rob Landley]

On 08/20/2011 07:23 PM, Natalia Portillo wrote:
>>> Linux requires the MMU and an almost complete hardware emulation.
>>>  Standard m68k emulations (UAE, Aranym and specially BasiliskII)
>>> try to patch the OS to work.
>> 
>> That's kinda sad.  Is there a web page anywhere that elaborates on
>> this?
> 
> It is a known thing that Linux requires MMU, it appears on the
> installation guide of all m68k distros. On how and how much they
> patch the OS, check their sources.

Actually coldfire was nommu and thus m68k was one of the first nommu
platforms.  But what I was talking about was patching the OS.

The aranym patches (that i saw) were adding new virtual device drivers.
 (A bit like virtio, only different implementations.)

>>> Indeed BasiliskII is anything but a real macintosh emulator, as
>>> it patches heavily the Toolbox and Mac OS (that's why Linux and
>>> A/UX will never work on it)
>> 
>> I believe toolbox is the ancient mac bios, correct?  Does Linux
>> need/use it at all?
> 
> Yes and no to both. Mac OS is a really complex operating system where
> everything is divided in little pieces that can be loaded
> individually and independently (the Grand Unified Model, the reason
> why resource forks exist). Toolbox is the most important part, the
> one that resides inside the ROM chip, provides the specific model
> drivers (and in the II models, loads the video driver from the NuBus
> card), and loads the rest of the system from the System file inside
> MacOS.

CP/M got split into the BIOS and BDOS halves when Imsai asked Digital
Research to give them a driver pack they could tailor to their
non-Altair hardware, and then the other half could be board-independent.

This seems similarly relevant?

> It does not expect a boot loader, it's the OS itself, indeed in an
> specific model the whole OS is contained in ROM.
> 
> There is a table for OS functions that can be made to point to ROM
> (implemented on Toolbox) or in RAM (System file, bug or functionality
> updates).

Linux is an OS.  It generally doesn't call much out of PC bios or
openfirmware and so on after it boots up.  You're saying m68k is different?

> BasiliskII patches that table inserting their own functions (for
> example, the floppy driver is "enhanced" to provide access to the
> host disk images, instead of calling to the SWIM chip that will
> manage the floppy drive in a real macintosh).

I'm not even building the floppy driver in my kernel .config.  Does
Linux really have to use this table instead of having actual drivers
that run the chips?  (You're saying Linux calls the apple bios to access
devices?)

> The Linux bootloader is nothing more than a Mac OS application that
> loads the Linux kernel and gives it access to the full RAM, where it
> can (and as you see in the compatibility list, does not so well)
> access to the whole Macintosh hardware bypassing both Toolbox and
> System.

Real hardware needs bootloaders, yes.  Read hardware tends to use uboot
and grub and so on depending on your platform.

On qemu, we have the -kernel option that loads a kernel image into the
emulator's ram, and jumps to its entry point.

> Not long ago some people discovered a way to substitute the System
> file (RAM portion of the OS) so the Toolbox loads directly a Linux
> kernel. This is buggy for a lot of reasons (that was never the
> intended way, in-ROM drivers may be too buggy, so on).

Or you can go "qemu -kernel" so it can call load_elf() or similar.

> Apple UNIX (A/UX) on the other way provides a full System file
> (corresponding to Mac OS 7) and then loads its kernel, retaining the
> original table in memory for Mac OS applications compatibility and
> the GUI (yeah, while it's a UNIX and contains X11, native
> applications can be made that while being A/UX ones, use, calls and
> depend, on the Toolbox and System functions :D)
> 
> So unless an emulation is complete enough to make the Toolbox happily
> load a System file, it cannot be called a Macintosh emulator. It will
> be merely a custom-hardware-emulator capable of running Mac OS
> (BasiliskII) or Linux-m68k (nothing implemented right now).

I'm looking for an emulator capable of running Linux-m68k, yes.

> Saying this of pure memory, BasiliskII patches (and so, does not
> emulate them really) the following devices: floppy (calls host disk
> images, not a floppy emulated device, whatever if the image is an
> hdd, floppy, or cd, it appears as a floppy to the OS),

Linux can loopback mount floppy images, so all I really need is an
arbitrary block device that's big and reasonably well performing.  SCSI
works.

> SCSI (there is
> no scsi emulated at all, the driver is patched to call to host ASPI
> devices),

Linux has drivers for rather a lot of scsi chips, we just need to map it
at the right location for the driver to find it.

> framebuffer (any combination is available independently of
> the Toolbox's expected one),

I'm using a serial console on all the other targets.

> NuBus (not present

Re: [Qemu-devel] [RFC PATCH v4 3/5] separate migration bitmap

[Umesh Deshpande]

On 08/19/2011 08:51 AM, Paolo Bonzini wrote:

On 08/16/2011 08:56 PM, Umesh Deshpande wrote:
@@ -2128,8 +2132,61 @@ void 
cpu_physical_memory_reset_dirty(ram_addr_t start, ram_addr_t end,

   start1, length);
 }
 }
+
 }

+void migration_bitmap_reset_dirty(ram_addr_t start, ram_addr_t end,
+  int dirty_flags)
+{
+unsigned long length, start1;
+
+start &= TARGET_PAGE_MASK;
+end = TARGET_PAGE_ALIGN(end);
+
+length = end - start;
+if (length == 0) {
+return;
+}
+
+migration_bitmap_mask_dirty_range(start, length, dirty_flags);
+
+/* we modify the TLB cache so that the dirty bit will be set again
+   when accessing the range */


The comment does not apply here, and the code below can also be safely 
deleted.



+start1 = (unsigned long)qemu_safe_ram_ptr(start);
+/* Check that we don't span multiple blocks - this breaks the
+   address comparisons below.  */
+if ((unsigned long)qemu_safe_ram_ptr(end - 1) - start1
+!= (end - 1) - start) {
+abort();
+}
+}
+
+void sync_migration_bitmap(ram_addr_t start, ram_addr_t end)
+{
+unsigned long length, len, i;
+ram_addr_t addr;
+start &= TARGET_PAGE_MASK;
+end = TARGET_PAGE_ALIGN(end);
+
+length = end - start;
+if (length == 0) {
+return;
+}
+
+len = length >> TARGET_PAGE_BITS;
+for (i = 0; i < len; i++) {
+addr = i << TARGET_PAGE_BITS;
+if (cpu_physical_memory_get_dirty(addr, 
MIGRATION_DIRTY_FLAG)) {

+migration_bitmap_set_dirty(addr);
+cpu_physical_memory_reset_dirty(addr, addr + 
TARGET_PAGE_SIZE,

+MIGRATION_DIRTY_FLAG);


This should be run under the iothread lock.  Pay attention to avoiding 
lock inversion: the I/O thread always takes the iothread lock outside 
and the ramlist lock within, so the migration thread must do the same.


BTW, I think this code in the migration thread patch also needs the 
iothread lock:



if (stage < 0) {
cpu_physical_memory_set_dirty_tracking(0);
return 0;
}

if (cpu_physical_sync_dirty_bitmap(0, TARGET_PHYS_ADDR_MAX) != 0) {
qemu_file_set_error(f);
return 0;
}

Callers of above code snippets (sync_migration_bitmap etc.) are holding 
the iothread mutex. It has been made sure that the original qemu dirty 
bitmap is only accessed when holding the mutex.


Finally, here:


/* Make sure all dirty bits are set */
QLIST_FOREACH(block, &ram_list.blocks, next) {
for (addr = block->offset; addr < block->offset + 
block->length;

 addr += TARGET_PAGE_SIZE) {
if (!migration_bitmap_get_dirty(addr,
   
MIGRATION_DIRTY_FLAG)) {

migration_bitmap_set_dirty(addr);
}
}
}



... you can skip the get_dirty operation since we are not interested 
in other flags than the migration flag for the migration-specific bitmap.

okay

Thanks
Umesh

Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions

[Natalia Portillo]

El 21/08/2011, a las 01:50, Rob Landley escribió:

> On 08/20/2011 07:23 PM, Natalia Portillo wrote:
 Linux requires the MMU and an almost complete hardware emulation.
 Standard m68k emulations (UAE, Aranym and specially BasiliskII)
 try to patch the OS to work.
>>> 
>>> That's kinda sad.  Is there a web page anywhere that elaborates on
>>> this?
>> 
>> It is a known thing that Linux requires MMU, it appears on the
>> installation guide of all m68k distros. On how and how much they
>> patch the OS, check their sources.
> 
> Actually coldfire was nommu and thus m68k was one of the first nommu
> platforms.  But what I was talking about was patching the OS.
> 
> The aranym patches (that i saw) were adding new virtual device drivers.
> (A bit like virtio, only different implementations.)
> 
 Indeed BasiliskII is anything but a real macintosh emulator, as
 it patches heavily the Toolbox and Mac OS (that's why Linux and
 A/UX will never work on it)
>>> 
>>> I believe toolbox is the ancient mac bios, correct?  Does Linux
>>> need/use it at all?
>> 
>> Yes and no to both. Mac OS is a really complex operating system where
>> everything is divided in little pieces that can be loaded
>> individually and independently (the Grand Unified Model, the reason
>> why resource forks exist). Toolbox is the most important part, the
>> one that resides inside the ROM chip, provides the specific model
>> drivers (and in the II models, loads the video driver from the NuBus
>> card), and loads the rest of the system from the System file inside
>> MacOS.
> 
> CP/M got split into the BIOS and BDOS halves when Imsai asked Digital
> Research to give them a driver pack they could tailor to their
> non-Altair hardware, and then the other half could be board-independent.
> 
> This seems similarly relevant?

No, CP/M's BIOS just initializes the hardware.
BDOS contains the drivers.

PC BIOS do the same.

Toolbox initializes the drivers, contains the HAL, the kernel, the resource 
fork manager, the window manager, the mouse pointer, the quickdraw functions.
It's like having Windows 3.1 in ROM and the explorer.exe on disk.

>> It does not expect a boot loader, it's the OS itself, indeed in an
>> specific model the whole OS is contained in ROM.
>> 
>> There is a table for OS functions that can be made to point to ROM
>> (implemented on Toolbox) or in RAM (System file, bug or functionality
>> updates).
> 
> Linux is an OS.  It generally doesn't call much out of PC bios or
> openfirmware and so on after it boots up.  You're saying m68k is different?

Yes, Mac OS must load Linux, not a bootloader.
If Mac OS don't work, your chances of getting Linux to work (on a REAL 
macintosh emulator) are close to 0.

>> BasiliskII patches that table inserting their own functions (for
>> example, the floppy driver is "enhanced" to provide access to the
>> host disk images, instead of calling to the SWIM chip that will
>> manage the floppy drive in a real macintosh).
> 
> I'm not even building the floppy driver in my kernel .config.  Does
> Linux really have to use this table instead of having actual drivers
> that run the chips?  (You're saying Linux calls the apple bios to access
> devices?)

Read it again, on Basilisk, Linux will find no storage device at all, no video 
device, no serial device, no nothing :p

>> The Linux bootloader is nothing more than a Mac OS application that
>> loads the Linux kernel and gives it access to the full RAM, where it
>> can (and as you see in the compatibility list, does not so well)
>> access to the whole Macintosh hardware bypassing both Toolbox and
>> System.
> 
> Real hardware needs bootloaders, yes.  Read hardware tends to use uboot
> and grub and so on depending on your platform.
> 
> On qemu, we have the -kernel option that loads a kernel image into the
> emulator's ram, and jumps to its entry point.

That isn't so simple in Macs

>> Not long ago some people discovered a way to substitute the System
>> file (RAM portion of the OS) so the Toolbox loads directly a Linux
>> kernel. This is buggy for a lot of reasons (that was never the
>> intended way, in-ROM drivers may be too buggy, so on).
> 
> Or you can go "qemu -kernel" so it can call load_elf() or similar.
> 
>> Apple UNIX (A/UX) on the other way provides a full System file
>> (corresponding to Mac OS 7) and then loads its kernel, retaining the
>> original table in memory for Mac OS applications compatibility and
>> the GUI (yeah, while it's a UNIX and contains X11, native
>> applications can be made that while being A/UX ones, use, calls and
>> depend, on the Toolbox and System functions :D)
>> 
>> So unless an emulation is complete enough to make the Toolbox happily
>> load a System file, it cannot be called a Macintosh emulator. It will
>> be merely a custom-hardware-emulator capable of running Mac OS
>> (BasiliskII) or Linux-m68k (nothing implemented right now).
> 
> I'm looking for an emulator capable of running Linux-m68k, yes.

So t

Re: [Qemu-devel] [PATCH] Wire g_new() and friends to the qemu_malloc() family

[Anthony Liguori]

On 08/20/2011 01:59 AM, Blue Swirl wrote:

On Fri, Aug 19, 2011 at 3:22 PM, Avi Kivity  wrote:

On 08/18/2011 09:54 PM, Peter Maydell wrote:


On 18 August 2011 18:48, Avi Kivitywrote:

  +static GMemVTable gmemvtable = {
  +.malloc = qemu_malloc,
  +.realloc = qemu_realloc,
  +.free = qemu_free,
  +};
  +
  +/**
  + * qemu_malloc_init: initialize memory management
  + */
  +void qemu_malloc_init(void)
  +{
  +g_mem_set_vtable(&gmemvtable);
  +}


Does this mean you can now safely allocate with g_malloc
and free with qemu_free, or is mixing the two APIs like that
still a no-no ?


You can, but I'd forbid it.  Mixing layers can only lead to tears later on.

Best would be to convert qemu_malloc()s to g_new()s and g_malloc()s to
reduce confusion.


Also plain malloc() and friends, except in tracing back end for obvious reasons.


sed script:

s:qemu_mallocz\( *\)(:g_malloc0\1\(:g
s:qemu_malloc\( *\)(:g_malloc\1\(:g
s:qemu_free\( *\)(:g_free\1\(:g
s:qemu_strdup\( *\)(:g_strdup\1\(:g
s:qemu_strndup\( *\)(:g_strndup\1\(:g

It takes a little build magic too to make sure everything has access to 
glib.


The patch is way too large to post.  Please speak now if you have an 
objection otherwise I'll commit in a couple days.


http://repo.or.cz/w/qemu/aliguori.git/commit/5cc99cedb46b3916dae8a565d5ffc5fb2f2e9bd6

If anyone wants to try it out first.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH] Wire g_new() and friends to the qemu_malloc() family

[Anthony Liguori]

On 08/18/2011 12:48 PM, Avi Kivity wrote:

This makes the tracing infrastructure available to users of g_new().

Signed-off-by: Avi Kivity


Here's my version, adapted to a world with no qemu_malloc.

Regards,

Anthony Liguori


---
  qemu-common.h |1 +
  qemu-malloc.c |   15 +++
  vl.c  |1 +
  3 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/qemu-common.h b/qemu-common.h
index 74d5c4b..fbe2de0 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -180,6 +180,7 @@ const char *path(const char *pathname);
  #define qemu_isascii(c)   isascii((unsigned char)(c))
  #define qemu_toascii(c)   toascii((unsigned char)(c))

+void qemu_malloc_init(void);
  void *qemu_oom_check(void *ptr);
  void *qemu_malloc(size_t size);
  void *qemu_realloc(void *ptr, size_t size);
diff --git a/qemu-malloc.c b/qemu-malloc.c
index b9b3851..8b0c1ec 100644
--- a/qemu-malloc.c
+++ b/qemu-malloc.c
@@ -24,6 +24,21 @@
  #include "qemu-common.h"
  #include "trace.h"
  #include
+#include
+
+static GMemVTable gmemvtable = {
+.malloc = qemu_malloc,
+.realloc = qemu_realloc,
+.free = qemu_free,
+};
+
+/**
+ * qemu_malloc_init: initialize memory management
+ */
+void qemu_malloc_init(void)
+{
+g_mem_set_vtable(&gmemvtable);
+}

  void qemu_free(void *ptr)
  {
diff --git a/vl.c b/vl.c
index c714127..7c4f8da 100644
--- a/vl.c
+++ b/vl.c
@@ -2106,6 +2106,7 @@ int main(int argc, char **argv, char **envp)

  atexit(qemu_run_exit_notifiers);
  error_set_progname(argv[0]);
+qemu_malloc_init();

  init_clocks();



>From fd639107f8ee2a489a9010e007cc3181732b1f06 Mon Sep 17 00:00:00 2001
From: Anthony Liguori 
Date: Sat, 20 Aug 2011 22:38:31 -0500
Subject: [PATCH] Add trace points for g_malloc/g_free functions

Derived from a patch submitted by Avi Kivity.

Signed-off-by: Anthony Liguori 
---
 vl.c |   27 +++
 1 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/vl.c b/vl.c
index e9e14a6..c98961c 100644
--- a/vl.c
+++ b/vl.c
@@ -2075,6 +2075,26 @@ static const QEMUOption *lookup_opt(int argc, char **argv,
 return popt;
 }
 
+static gpointer malloc_and_trace(gsize n_bytes)
+{
+void *ptr = malloc(n_bytes);
+trace_qemu_malloc(n_bytes, ptr);
+return ptr;
+}
+
+static gpointer realloc_and_trace(gpointer mem, gsize n_bytes)
+{
+void *ptr = realloc(mem, n_bytes);
+trace_qemu_realloc(mem, n_bytes, ptr);
+return ptr;
+}
+
+static void free_and_trace(gpointer mem)
+{
+trace_qemu_free(mem);
+free(mem);
+}
+
 int main(int argc, char **argv, char **envp)
 {
 const char *gdbstub_dev = NULL;
@@ -2103,10 +2123,17 @@ int main(int argc, char **argv, char **envp)
 const char *trace_file = NULL;
 const char *log_mask = NULL;
 const char *log_file = NULL;
+GMemVTable mem_trace = {
+.malloc = malloc_and_trace,
+.realloc = realloc_and_trace,
+.free = free_and_trace,
+};
 
 atexit(qemu_run_exit_notifiers);
 error_set_progname(argv[0]);
 
+g_mem_set_vtable(&mem_trace);
+
 init_clocks();
 
 qemu_cache_utils_init(envp);
-- 
1.7.4.1

[Qemu-devel] [Bug 739088] Re: I/O errors after "Save/Restore"

[Yongjie Ren]

this issue occurred again. So reopen this bug.
I use upstream kvm.git ef7c782ea and qemu-kvm.git 44755ea36.
The host is rhel6.1 with lastest kvm and qemu-kvm installed, and its file 
system type is ext4.
here's the dmesg info in rhel5u5 guest after being restored.
-log--
hda: status error: status=0x00 { }
ide: failed opcode was: unknown
hda: drive not ready for command
hda: status error: status=0x00 { }
ide: failed opcode was: unknown
hda: drive not ready for command
hda: status error: status=0x00 { }
ide: failed opcode was: unknown
hda: drive not ready for command
hda: status error: status=0x00 { }
ide: failed opcode was: unknown
hda: drive not ready for command
ide0: reset: master: error (0x00?)
hda: status error: status=0x00 { }
ide: failed opcode was: unknown
hda: drive not ready for command
hda: status error: status=0x00 { }
ide: failed opcode was: unknown
hda: drive not ready for command
hda: status error: status=0x00 { }
ide: failed opcode was: unknown
hda: drive not ready for command
hda: status error: status=0x00 { }
ide: failed opcode was: unknown
hda: drive not ready for command
ide0: reset: master: error (0x00?)
end_request: I/O error, dev hda, sector 32991
end_request: I/O error, dev hda, sector 32999
end_request: I/O error, dev hda, sector 33007
end_request: I/O error, dev hda, sector 4465351
Buffer I/O error on device hda1, logical block 558161
Aborting journal on device hda1.
lost page write due to I/O error on hda1
end_request: I/O error, dev hda, sector 4465359
Buffer I/O error on device hda1, logical block 558162
lost page write due to I/O error on hda1
end_request: I/O error, dev hda, sector 13447
Buffer I/O error on device hda1, logical block 1673
lost page write due to I/O error on hda1
__journal_remove_journal_head: freeing b_committed_data
journal commit I/O error
ext3_abort called.
EXT3-fs error (device hda1): ext3_journal_start_sb: Detected aborted journal
Remounting filesystem read-only

** Project changed: qemu => qemu-kvm

** Changed in: qemu-kvm
   Status: Fix Released => New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/739088

Title:
  I/O errors after "Save/Restore"

Status in qemu-kvm:
  New

Bug description:
  qemu-kvm commit: b73357ecd2b14c057134cb71d29447b5b988c516
  ( Author: Marcelo Tosatti Date:   Wed Mar 16 
17:04:16 2011 -0300)
  kvm commit: a72e315c509376bbd1e121219c3ad9f23973923f

  After restoring from saved img, some I/O errors appear in dmesg and
  file system is read-only.  I'm sure that the  guest runs normally
  before saving. See the pictures attached in detail.

  Reproduce steps:
  
  1.create a guest:
qemu-img create -b /share/xvs/img/app/ia32e_SMP.img -f qcow2 
/root/test0320.img
qemu-system-x86_64  -m 256  -net 
nic,macaddr=00:16:3e:06:8a:08,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup 
-hda /root/test0320.img
  2.save the guest: 
on qemu monitor: migrate "exec:dd of=/root/test-save.img"
  3.quit from qemu: 
"q" command on qemu monitor
  4.restore from img just saved:
qemu-system-x86_64  -m 256  -net 
nic,macaddr=00:16:3e:06:8a:08,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup 
-incoming=/roo/test-save.img
  5.see dmesg in restored guest, you'll find some I/O errors. And run some
  commands such as "ps", "touch","reboot" and so on. Then some I/O errors 
appear.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu-kvm/+bug/739088/+subscriptions