Re: [Qemu-devel] [PATCH v1 0/4] m68k: Add basic support for the NeXTcube machine

[Natalia Portillo]

Now you've made me subscribe again to qemu-devel ;)

On 30/06/18 18:07, Bryce Lanham wrote:
> Oh hi! 
> 
> Luckily gmail brought this to the top since I don’t pay attention to the
> list. I’m away from my computer at the moment, but I had more than this
> working, including interrupts, Ethernet, and SCSI for sure.
> (https://i.imgur.com/Py0FO.png) I’d love to dive back into this now that
> 68040 support is complete and merged.
> 
> 
> On Sat, Jun 30, 2018 at 8:34 AM, Thomas Huth  > wrote:
> 
> Am Sat, 30 Jun 2018 14:17:32 +0100
> schrieb Peter Maydell  >:
> 
> > On 30 June 2018 at 14:14, Thomas Huth  > wrote:
> > > Weird... the mail was ca. 1200 lines ... that not small, but not so
> > > big that I'd expect that it would get blocked somewhere. Let's wait
> > > some more more hours, maybe the spam filter is just very slow
> > > today. If it is then still not available on the list, I'll try to
> > > send it out again.  
> > 
> > The mailing list does just occasionally randomly eat patches,
> > as far as I can tell. It's not purely a size thing.
> 
> Ok, good to know. I've just sent out patch 3/4 again, let's see how it
> goes.
> 
>  Thomas
> 
> 



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] BIOS calls in 16bit protected mode

[Natalia Portillo]

Hi Kevin,

Long time ago I read about OS/2 calling 16-bit protected mode BIOS, but the 
documentation didn't specified if this was constrained to the separate 
protected mode BIOS included by PS/2 systems or the real mode BIOS included by 
the same PS/2 systems and the whole rest of PC computers.

Regards,
Natalia Portillo

El 14/06/2012, a las 04:13, Kevin O'Connor escribió:

 Hi,
 
 I am trying to determine if there are legacy applications or operating
 systems that invoke standard BIOS real-mode interrupt handlers while
 in 16bit protected mode.  (The legacy real-mode entry points - like
 int 0x13 - not the declared 16bit protected mode entry points
 defined by the PnP and APM specs.)
 
 I am considering changes to SeaBIOS that would make 16bit protected
 mode callers much less likely to work.  (Specifically, enhancing
 SeaBIOS to use memory in the e-segment which is unlikely to be mapped
 in protected mode.)
 
 Most documents I've seen state that calling the real-mode entry points
 in protected mode will not work.  Though, I am aware that the PCI BIOS
 spec specifically requires this support for calls to int 0x1a
 ah=0xb1.
 
 The advantage of making these changes is that it will allow SeaBIOS to
 use notably less stack space and therefore be more compatible with old
 applications that call the BIOS with very little stack space.  For
 example, these changes enable DOS 1.0 to boot and run under SeaBIOS.
 
 What would really help is pointers to applications and/or program
 images that use 16bit protected mode calls to real-mode entry points.
 Specifications or documents detailing valid or invalid uses would also
 be helpful.
 
 For those that are willing to run tests, one can compare the standard
 SeaBIOS v1.7.0 image (for KVM/QEMU) at:
 
 http://git.seabios.org/downloads/get/bios.bin-1.7.0.gz
 
 to a test image with the new code at:
 
 http://git.seabios.org/downloads/get/bios.bin-test-20120613.gz
 
 Thanks,
 -Kevin
 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Qemu-devel] Add GSoC project ideas to the wiki!

[Natalia Portillo]

Hi Kevin,

Sorry for the late answer, had hardware problems recently

On 12/03/2012, at 11:36, Kevin Wolf wrote:

 Am 24.02.2012 10:19, schrieb Stefan Hajnoczi:
 This is a reminder that QEMU will apply for Google Summer of Code 2012 and we
 need project ideas and mentors.  Libvirt and kvm.ko projects are also 
 welcome!
 
 http://wiki.qemu.org/Google_Summer_of_Code_2012
 
 Please add yourself to the wiki now if you want to mentor a project
 this summer.  I will file our application next week.
 
 Natalia, I saw that you copied a few items from last year's Wiki page to
 the current one. But did you check that all of them are still valid? For
 example, we do have EHCI and xHCI in the tree for quite a while now. I
 don't think there's enough left for a GSoC project with these.

I posponed checking the status of EHCI and xHCI but had the hardware problems.

So if they're already on the tree then I will remove those from the wiki.

Regards,
Natalia Portillo

Re: [Qemu-devel] QEMU was not selected for Google Summer of Code this year

[Natalia Portillo]

Really sad news :(

On 16/03/2012, at 19:29, Stefan Hajnoczi wrote:

 Sad news - QEMU was not accepted for Google Summer of Code 2012.
 
 Students can consider other organizations in the accepted
 organizations list here:
 
 http://www.google-melange.com/gsoc/accepted_orgs/google/gsoc2012
 
 The list is currently not complete but should be finalized over the
 next few days as organizations complete their profiles.
 
 Students and mentors who wanted to participate with QEMU will be
 disappointed.  I am too but there are many factors that organizations
 are considered against, we have not received information why QEMU was
 rejected this year.

I've noted this year there are half the approved organizations than last year...

 QEMU will try again for sure next year because Google Summer of Code
 is a great program both for students and for QEMU.
 
 Stefan
 

Natalia Portllo

Re: [Qemu-devel] QEMU was not selected for Google Summer of Code this year

[Natalia Portillo]

QEMU hosted on Haiku would be interesting.

On 16/03/2012, at 22:30, Stefan Hajnoczi wrote:

 On Fri, Mar 16, 2012 at 7:44 PM, Natalia Portillo clau...@claunia.com wrote:
 Really sad news :(
 
 On 16/03/2012, at 19:29, Stefan Hajnoczi wrote:
 
 Sad news - QEMU was not accepted for Google Summer of Code 2012.
 
 Students can consider other organizations in the accepted
 organizations list here:
 
 http://www.google-melange.com/gsoc/accepted_orgs/google/gsoc2012
 
 The list is currently not complete but should be finalized over the
 next few days as organizations complete their profiles.
 
 Students and mentors who wanted to participate with QEMU will be
 disappointed.  I am too but there are many factors that organizations
 are considered against, we have not received information why QEMU was
 rejected this year.
 
 I've noted this year there are half the approved organizations than last 
 year...
 
 The list of accepted orgs is not complete yet, more will be displayed
 as they fill out their details in the http://google-melange.com/ web
 app.
 
 Stefan

Re: [Qemu-devel] QEMU PEX HW device

[Natalia Portillo]

Hi,

El 23/02/2012, a las 15:44, Shlomo Pongratz escribió:

 Hi,
 
 I want to add a new PEX HW device emulation to QEMU, but I can't find a 
 skeleton/template driver or documentation that explains how to do it.
Great! (What's a PEX HW device?)

 Are there any guidelines for this task?

Start out from an existing emulated device, from the same bus if possible (PCI, 
ISA, USB, so on), delete all code you don't need, implement your emulation.
Once you start it's pretty straightforward, function names are almost 
self-explanatory of what they do.

Regards,
Natalia Portillo

Re: [Qemu-devel] [PATCH RFC for-1.0] Update copyright info

[Natalia Portillo]

My suggestion is to put (c) 2003-2011 Fabrice and contributors until we have a 
foundation and then put (c) 2003-201x qemu foundation.

Fabrice by the european copyright laws still have copyright and ipr in any code 
he generated whatever we have changed as per the multiple contributors 
section of the european laws.
(that is unless we did a svn/git delete file.c if that file was started, or 
based on one started, by Fabrice, it's still partly (c) Fabrice even if no 
single line remains of his code)

El 02/12/2011, a las 15:11, Andreas Färber escribió:

 Gerd just reminded me that we did ship 1.0 with a 2008 copyright notice.
 
 Am 04.11.2011 18:56, schrieb Andreas Färber:
 Judging by -version output, one could get the impression that QEMU was
 last modified in 2008. Therefore extend the copyright statement to
 cover other contributors so that it can be updated to the current year.
 
 Signed-off-by: Andreas Färber afaer...@suse.de
 
 Is my text change okay, so that I should extend the patch to cover
 *-user as pointed out by Peter? Or is the change a no-go for legal or
 libvirt reasons?
 
 An alternative mentioned in this thread was:
 Copyright (c) 2003-2008 Fabrice Bellard, Copyright (c) 200x-2011 s.o.
 
 The former was intended as a short-term fix for 1.0.
 I would prefer the latter mid-term since Fabrice doesn't hold any
 copyright/IPR in the code after he left, but what year and what someone?
 
 Opinions please,
 
 Andreas
 
 ---
 vl.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/vl.c b/vl.c
 index 624da0f..47e0ae0 100644
 --- a/vl.c
 +++ b/vl.c
 @@ -1484,7 +1484,7 @@ static void main_loop(void)
 
 static void version(void)
 {
 -printf(QEMU emulator version  QEMU_VERSION QEMU_PKGVERSION , 
 Copyright (c) 2003-2008 Fabrice Bellard\n);
 +printf(QEMU emulator version  QEMU_VERSION QEMU_PKGVERSION , 
 Copyright (c) 2003-2011 Fabrice Bellard and contributors\n);
 }
 
 static void help(int exitcode)
 
 -- 
 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
 GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
 

[Qemu-devel] [Bug 883136] Re: qemu on ARM hosts aborts on startup because makecontext() always fails

[Natalia Portillo]

** Also affects: qemu
   Importance: Undecided
   Status: 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/883136

Title:
  qemu on ARM hosts aborts on startup because makecontext() always fails

Status in QEMU:
  New
Status in Linaro QEMU:
  New

Bug description:
  qemu has recently grown a coroutines implementation. There are two
  versions, one using the makecontext/setcontext/swapcontext functions
  from ucontext.h, and one falling back to implementing coroutines as
  separate glib threads. configure chooses the former if the platform
  has a makecontext().

  Unfortunately ARM eglibc provides a makecontext() which always fails
  ENOSYS, which means the configure check passes but when qemu starts it
  abort()s.

  The best fix for this is probably going to involve making the
  coroutine implementation runtime-selectable.

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

[Qemu-devel] [Bug 883133] Re: qemu on ARM hosts asserts due to code buffer/libc heap conflict

[Natalia Portillo]

** Also affects: qemu
   Importance: Undecided
   Status: 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/883133

Title:
  qemu on ARM hosts asserts due to code buffer/libc heap conflict

Status in QEMU:
  New
Status in Linaro QEMU:
  New

Bug description:
  On ARM hosts qemu (about half the time) asserts on startup:

  qemu-system-i386: malloc.c:3096: sYSMALLOc: Assertion `(old_top == 
(((mbinptr) (((char *) ((av)-bins[((1) - 1) * 2])) -
  __builtin_offsetof (struct malloc_chunk, fd  old_size == 0) || 
((unsigned long) (old_size) = (unsigned long)__builtin_offsetof (struct 
malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1))  ~((2 * 
(sizeof(size_t))) - 1)))  ((old_top)-size  0x1)  ((unsigned long)old_end 
 pagemask) == 0)' failed.

  This turns out to be because code_gen_alloc() is using mmap(MAP_FIXED)
  to map the code buffer at address 0x0100UL, which is in the area
  glibc happens to be using for its heap. This tends to make the next
  malloc() abort, although occasionally the stars align and we pass that
  and fail weirdly later on.

  I suspect we need to drop the MAP_FIXED requirement and fix the TCG code to 
cope with emitting code for longer-range
  branches for calls to host fns etc (calls/branches within the generated code 
should be ok to keep using the short-range
  branch insn I think). There is already no guarantee that the generated code 
and the host C code are within short
  branch range of each other...

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

Re: [Qemu-devel] QEMU's now on Google+

[Natalia Portillo]

We seriously miss having a logo.

El 09/11/2011, a las 15:24, Anthony Liguori escribió:

 Hi,
 
 I've created a Google+ page for QEMU[1].  You'll also notice a button on the 
 qemu.org wiki that links to the Google+ page.
 
 I'll be posting release information to this page along with any QEMU news.  
 If you find qemu-devel too busy to follow, then following the G+ page might 
 be a good option for you.
 
 I'd also like to publish a Contributor circle so that people had an easy way 
 to follow all of the various QEMU contributors on G+.  If you'd like to be 
 part of the Contributor circle, please add QEMU to one of your circles, then 
 leave a comment on [2].
 
 [1] https://plus.google.com/101344524535025574253/
 [2] https://plus.google.com/u/1/101344524535025574253/posts/MgA5ctwGNJv
 
 Regards,
 
 Anthony Liguori
 
 

Re: [Qemu-devel] Hi Natalia.. A query regarding QEMU

[Natalia Portillo]

Hi Ankit,

El 03/11/2011, a las 20:37, Ankit Verma escribió:

 Hi Natalia,
 
 I am trying to support usb connections on Android Emulator. Since
 Android Emulator is based on QEMU, i thought you could give some
 insight on how to enable usb connections for android emulator.
 
 As per the following information in google's android website -
 http://developer.android.com/guide/developing/devices/emulator.html
 
 Emulator Limitations
 
 In this release, the limitations of the emulator include:
 
 No support for USB connections
 No support for Bluetooth
 
 Can you give some insight.

First of all, while Android Emulator is based on QEMU, they have made their own 
modifications, that have not been sent to us, so it's not 100% QEMU.

What I can tell you is that Android phones/tablets are USB devices, and QEMU 
have an incomplete support for REAL USB devices with QEMU behaving as an USB 
host. But QEMU is not designed currently to work as a USB device to a real USB 
host.

If you want to code that support yourself, you'll need a virtual host 
controller implementation on the host operating system, and then implementing 
QEMU behavior as an Android device (be it USB Mass Storage Device or Android 
Debug device).

For the first part, there are some implementations, called USB-IP, that create 
a virtual host controller both on Windows and on Linux hosts, and both are 
incomplete as I write.
For the second part that has never been tried (afaik) and would be mostly 
dependent on what solution you chose for the first part (as there will never be 
a way for QEMU to talk to a real host controller as a device).

I hope this gives insight for you, and any other question I may be of help, 
feel free to ask.

BTW, I'm CCing this to the mailing list, as other people may find this 
interesting, want to contribute with their opinions, so on.

Regards,
Natalia Portillo

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

[Natalia Portillo]

El 21/08/2011, a las 11:04, Laurent Vivier escribió:

 Le samedi 20 août 2011 à 18:42 -0500, Rob Landley a écrit :
 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).
 
 For the moment, q800 is not working. 
 
 Master branch is for m68k-linux-user target.
 
 I'm working on m68k-softmmu on the macrom-branch by porting the
 basiliskII stuff.
 [Natalia: this allows me to debug the CPU by comparing traces from
 BasiliskII and traces from qemu, I've found several in supervisor mode] 

As always, at least there are not so many secret opcodes :p

 but a ROM will not be required to boot it as the bootloader has the role
 to collect information from the ROM to pass it the kernel.
 Qemu will be able to do it and boot directly the kernel (with option
 --kernel). We can cutpaste parts from the EMILE bootloader.

But bypassing the ROM in all cases is not emulating a real Macintosh,
is creating a special target for Linux that emulates the same hardware.

(Gz for your EMILE, but, buy a tripod :p)

 A real machine emulation will require a ROM. But for this part we can
 have a look to executore (https://github.com/ctm/executor).

Last time I used Executor it only emulated an OS 6 Toolbox and with a 
compatibility scarce at best.

 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?
 
 No
 
 Regards,
 Laurent
 
 

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

[Natalia Portillo]

Definitively you don't know how a Mac works, you don't want to know and you 
don't need to.

El 21/08/2011, a las 23:14, Rob Landley escribió:

 On 08/20/2011 09:02 PM, Natalia Portillo wrote:
 El 21/08/2011, a las 01:50, Rob Landley escribió:
 
 On 08/20/2011 07:23 PM, Natalia Portillo wrote:

I hate huge emails.
Anyway I can't answer a lot of things you said because of NDAs so doesn't 
matter.

 Care to suggest one?  I'm not that familiar with what's available in
 m68k land, I just know how the other dozen hardware platforms I've used
 work.

Sorry no, Google sure finds them, and, you can invent your own.

You can create your own virtual non-existent hardware (it's done extensively in 
this world) and patch Linux to boot of it inside qemu.
Or you can check for Linux's support for development boards (sure there are one 
or two) and implement it on qemu based on what Linux's source says.

And FOR GOD'S SAKE CHECK THE ** COMPATIBILITY LIST ON LINUX-M68K.

No Mac m68k suits your needs for Linux NONE NINGUNO AUCUN KEINER NESSUNO NENHUM.

Regards :p

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

[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

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 the answer to your questions is simple:

You don't want a macintosh emulator. :p

 Saying this of pure memory, BasiliskII patches (and so, does not
 emulate them

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

[Natalia Portillo]

El 19/08/2011, a las 09:55, François Revol escribió:

 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 ?

NetBSD sources :D

 
 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 ?

AFAIK, none of them did until PowerPC, and that was OpenFirmware.

 The MMU is your part I won't discuss on it.
 
 There is 040 mmu support in ARAnyM (Atari Running on Any Machine), enough to 
 run Linux, that has been backported to UAE (ARAnyM is based on the UAE core), 
 that should give some hints:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=201442
 http://www.amigaemulator.org/patches
 http://www.amigaemulator.org/bin/patches/mmu/uae-0.8.20.2-mmu.diff.gz
 (though I fixed a bug in handling TTR1 in ARAnyM)
 
 It's why I chose to go Falcon first and use ARAnyM for the 68k Haiku port.
 
 The 030 or 68551 ones are much more complex though (the 040 one has a fixed 
 table layout, others have fully configurable table size for all the 4 
 levels). The 060 one is just the 040 with some cache restrictions.
 
 I know it's not perfect, but right now, it's better than nothing.
 There is no 68k cpu emulation complete afaik, I discussed with Ray 
 Arachelian a lot on that when he was working on LisaEm.
 However emulators are live, Aranym, UAE, LisaEm, BasiliskII.
 
 qemu-m68k is quite complete to go live (when it does not break mcoldfire) 
 right now.
 Bugs are easy to be corrected by more people when they are in main than in a 
 developer's own clone.
 
 Leave your little kid go wild, it's old and big enough :p
 
 Release early, release often :p

+1

 François.

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

[Natalia Portillo]

Hi Laurent,

El 18/08/2011, a las 15:02, Laurent Vivier escribió:

  
 
 Le 18 août 2011 à 13:12, François Revol re...@free.fr 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

 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?

 Regards,
 Laurent

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

[Natalia Portillo]

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 re...@free.fr 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.

He is! xD

 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.
We only lack the 68k cpu (oh! your patches!!!) and the glue :p

Please don't port Basilisk on top of TCG, I beg to you in the name of some god 
of your own choice :(
(1000 Mb floppies patching .sony instead of implementing SCSI and SWIM, no 
ethernet controller but a working TCP/IP, oh hell, it's not a Mac, it's a 
Match!)

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

[Natalia Portillo]

Hi,

El 18/08/2011, a las 21:51, Laurent Vivier escribió:

 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 re...@free.fr 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 ?

Yes, it is, absolutely.

 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.

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
The MMU is your part I won't discuss on it.

But porting BasiliskII will not make qemu have an m68k-system, but a 
macos7-wrapper.
And that's the problem with Basilisk, that's why you cannot partition a disk, 
try MachTen, don't even think on A/UX.

If you insist, please name it basilisk2 and let Bryce (he wants to in the 
future) do the real machines (-M quadra, -M centris, -M IIcx)

 You know, nights are not long enough...

Move to North Pole, I've heard nights are six month long there ^^

 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 know it's not perfect, but right now, it's better than nothing.
There is no 68k cpu emulation complete afaik, I discussed with Ray Arachelian a 
lot on that when he was working on LisaEm.
However emulators are live, Aranym, UAE, LisaEm, BasiliskII.

qemu-m68k is quite complete to go live (when it does not break mcoldfire) right 
now.
Bugs are easy to be corrected by more people when they are in main than in a 
developer's own clone.

Leave your little kid go wild, it's old and big enough :p

 Please don't port Basilisk on top of TCG, I beg to you in the name of some 
 god of your own choice :(
 
 I believe only in Santa Claus, and it's not Christmas.
 
 (1000 Mb floppies patching .sony instead of implementing SCSI and SWIM, no 
 ethernet controller but a working TCP/IP, oh hell, it's not a Mac, it's a 
 Match!)
 
 Regards,
 Laurent
 

Re: [Qemu-devel] [RFC] PowerPC Mac OS on Qemu

[Natalia Portillo]

Please,

a) separate the patch in pieces, I suggest you checking how other patches are 
split, there have been a lot of patches today to get insight.
b) use inline signed-by patch

Regards,
Natalia Portillo

El 09/08/2011, a las 20:46, William Hahne escribió:

 Hello,
 
 I am a Google Summer of Code student working on getting PowerPC Mac OS 
 running on Qemu. While I am not finished I need to upstream what I currently 
 have before the end of Summer of Code. My patch is for OpenBIOS but I am 
 cross-posting to both Qemu and OpenBIOS mailing lists since it is useful to 
 get feedback from both.
 
 One part of the patch I am particularly concerned about is the patch to 
 arch/ppc/qemu/init.c to provide a CPU and Timebase frequency. Qemu doesn't 
 report a CPU frequency and the reported Timebase frequency is too high and 
 causes the Mac OS scheduler to break. I hard-coded values that work but this 
 seems like an unacceptable long-term solution to me. A simple test for CPU 
 frequency might be the best solution here but seems a little redundant as Mac 
 OS later runs its own test, seemingly only relying on these values during 
 initialization (I am not 100% sure of this since it crashes before reaching 
 that point.) Feedback here would be especially appreciated.
 
 Another thing to note is in drivers/adb_kbd.c. get-key-map which returns a 
 map of the current pressed keys on the keyboard just returns a dummy value. I 
 felt it was a waste of time making a full implementation when all it really 
 gets you is the ability to use keyboard shortcuts for verbose or single user 
 mode. 
 
 Other than those specific concerns I welcome general feedback on the patch, 
 since as I said I am hoping to get it in before the end of Summer of Code.
 
 Thanks,
 William Hahne
 PowerPC_Mac_OS.patch

Re: [Qemu-devel] [ANNOUNCE] QEMU 0.15.0 Release

[Natalia Portillo]

Hi,

El 08/08/2011, a las 20:16, Anthony Liguori escribió:

 Hi,
 
 On behalf of the entire QEMU team, I'm please to announce the release of QEMU 
 0.15.0.  This is the first release of the 0.15 branch and is intended for 
 production usage.

QEMU Official OS Support List on http://www.claunia.com/qemu updated to support 
the new release and its new targets.
Sorry for being 1 day late :p

 The 0.15.0 release is the product of almost 150 contributors with 1,800 
 changes, with almost 100k lines of code added.
 
 A list of changes since 0.14 is available on the QEMU wiki:
 
 http://wiki.qemu.org/ChangeLog/0.15

Great but someone forgot to explain that OpenGL support: yes on the changelog.

 You can download the release at:
 
 http://wiki.qemu.org/download/qemu-0.15.0.tar.gz
 
 I'd like to thank everyone who participated in making this release!
 

Regards,
Natalia Portillo

Re: [Qemu-devel] RFC: Qemu Guest Tools ISO

[Natalia Portillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ok you're forgetting one thing:

90% of the devices we emulate are real physical ones.
The drivers for those devices in non-opensource guests already exist, and most 
of the times prevent we distributing them (read the EULA).

I think a guest tools with binary drivers for binary platforms (Windows, 
OS/2, NeXT, DOS) is a good idea.
One with binary drivers for open-source platforms (Linux, *BSD) is really 
stupid, will create hundreds of conflicts.
One with source drivers for open-source platforms is reinventing the wheel. The 
distros and systems already take care about drivers, including even drivers for 
other VMs.

So for any kind of usefulness we need to ask Creative Labs, Intel, AMD, VMWare, 
Realtek, so on, permissions to distribute their drivers.
I'm not sure they will allow us (pretty sure the VMWare video one will not be 
allowed ever).

In the case they allow us and create the guest tools disc, we can create a 
false device that a dormant process (TSR in DOS world) hears off.
That's what VMWare does, writes in that device requesting guest tools version 
(if none installed, noone answers), and if the provided one is better informs 
the user and offers to automount it.

Regards

El 23/06/2011, a las 16:52, Avi Kivity escribió:

 On 06/23/2011 06:25 PM, Anthony Liguori wrote:
 Even building the tools would be very hard. In general if you build
 against libc version y, you cannot expect your code to work against libc
 version y-1, unless you take special measures. With other libraries the
 special measures may not even be possible.
 
 
 Good libraries provide strong ABI compatibility.
 
 Something like glib clearly documents what version of the library functions 
 are available in, if you still to responsibly common functions, ABI 
 compatibility should be much of an issue.
 
 I don't know about glib, but glibc only guarantees backward compatibility, 
 not forward compatibility.  If you build against a newer glibc, your 
 executable may not run with an older glibc, even if the symbols exist in both.
 
 See [1] which touches on the issue; I don't have a better reference.
 
 [1] ftp://ftp.kernel.org/pub/software/libs/glibc/hjl/compat/index.html
 
 -- 
 error compiling committee.c: too many arguments to function
 
 

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iF4EAREIAAYFAk4HzaQACgkQv/wfOsykIRTVoQD/SgniEhqOCIf5FIiBz7RT0GAc
g8aA4FGWdKQB6jrfbwwA/igtLCAjhCpF/lFJ6o+0dUU2r3tT+gvDdZeURG82Xr5Z
=2Z/r
-END PGP SIGNATURE-

Re: [Qemu-devel] Webcams under KVM and Linux

[Natalia Portillo]

Exactly what my webcam does is:

Takes a frame from ANY available V4L2 device (/dev/video0), caches it, and 
sends it completely to the guest before requesting any other frame.

With this way you need your host driver loaded, but you will get never a 
blackout.

What it happens is a thing commonly known in game emulators (like for example 
ePSX) as framedrop, that is, you get a slower framerate but not blackouts.

The guest sees a common USB Video Class Device webcam with no controls (this 
can be enhanced easily), so basically you cannot change any parameter.
However all the webcams I tested automatically managed that in the firmware 
with no intervention from any of the drivers (host or guest), changing white 
balance and brightness to the adequate values.

You can see it working without KVM in:
http://www.youtube.com/watch?v=_Yo9TWPDXCo
http://www.youtube.com/watch?v=fzGYvjZzx6E

The webcam emulation works with TCG (without KVM), albeit slower, enough to do 
videoconference because of the following:

Using direct connection method (USB passthrough) even when the ISO xfers and 
ECHI 2.0 are completely emulated will always find the following: the host is 
faster than the guest, so the real webcam will always be streaming faster than 
the guest can process it.
Frames are sent in pieces, and if the frame does not arrive completely from 
start to end on all pieces the guest will blackout, and continue black until it 
receives a complete frame.

With fast webcams, like 60 fps ones, this will happen so commonly that there 
will be no image at all.

You can easily see this in VMWare, Parallels or VirtualBox, all of them emulate 
ISO xfers and EHCI 2.0 and when using a webcam it's not really practical.

Framedrop prevents that. From the 60 frames sent in a second by the host, if 
the guest can process only 10, it will receive 10 complete frames, and see the 
webcam as a 10fps one.
That's atomic.

Also my patch supports, as I already said, any V4L2 device including webcams, 
DV cameras, TV tuners from any kind of interface be it Firewire, USB, PCI, 
Serial, AGP, so on.

El 29/05/2011, a las 15:03, Peter Baitz escribió:

 Hello Natalia and Andreas,
 
 Thank you for the replies and suggestions.  I will lookup V4L.  
 
 Natalia,
 
 So your patch creates a generic webcam under KVM/Qemu to allow many webcams 
 to work?
 
 My only concern is the following:   I use specific Philips webcams, and one 
 in particular has a long exposure modification that the PWC driver (Fedora 11 
 guest on Fedora 15 host) coupled with Qastrocam-G2 (v4.9) allows the 
 shutter to remain open through USB control of the LED.  If the guest 
 restorts to using a generic webcam driver, I think this would preclude 
 functionality that the native driver supports ?  
 
 Also, can you tell me - when KVM is running my guest, should the PWC webcam 
 driver be loaded and/or the /dev/video0 on the HOST (F15), versus the guest 
 (F11) ?   I am confused as to which components are supposed to be enabled or 
 disabled while running the guest webcam.   What I see is when I enable the 
 webcam USB device in KVM, it appears to disable the /dev/video0 on the host 
 an brings it up in the guest.   And the pwc driver loads and remains on both 
 host and guest.  
 
 Peter
 
 
 --- On Sun, 5/29/11, Natalia Portillo clau...@claunia.com wrote:
 
 From: Natalia Portillo clau...@claunia.com
 Subject: Re: [Qemu-devel] Webcams under KVM and Linux
 To: Andreas Färber andreas.faer...@web.de
 Cc: Peter Baitz ussenterprisencc1...@rocketmail.com, QEMU Developers 
 qemu-devel@nongnu.org
 Date: Sunday, May 29, 2011, 1:53 PM
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 More concretely search for patches sent by me.
 
 Even when EHCI is finished still is the problem of isochronous transfer not 
 working well because of timing issues on QEMU.
 
 My patches overcome the need for ISO transfer and EHCI controllers 
 completely, as well as providing an universal device to the guest that works 
 with every Windows XP, every Linux and even Mac OS X.
 
 El 29/05/2011, a las 14:37, Andreas Färber escribió:
 
  Hello,
  
  Am 29.05.2011 um 15:01 schrieb Peter Baitz:
  
  
  [...] You should notice that it is not just adding
  ISOC and USB 2.0 support, but also to prioritize the processing of isoc
  packets on a virtual environment, and to provide enough throughput for
  video streams
  
  [...] Please check the qemu-devel mailing list archive, specifically 
  regarding recent discussions about EHCI (USB 2.0). Some of those threads 
  address isochronous transfer as well.
  
  In the meantime, you could also try to assign a complete host controller 
  to the guest to get a webcam working. I tried this a while ago, though the 
  result was only moderately well working here.
  
  [...] I would indeed like to hear more about what the project is adding to 
  KVM - Qemu to allow video to work with webcams
  [...]
  I was told I could try to add a complete host controller to the guest

Re: [Qemu-devel] Webcams under KVM and Linux

[Natalia Portillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


El 30/05/2011, a las 15:56, Gerd Hoffmann escribió:

 On 05/30/11 14:50, Natalia Portillo wrote:
 Exactly what my webcam does is:
 
 Takes a frame from ANY available V4L2 device (/dev/video0), caches it,
 and sends it completely to the guest before requesting any other frame.
 
 I think you can double-buffer (i.e. let the host driver fill one buffer while 
 sending the other one to the guest).  Probably gives a slightly higher frame 
 rate, but maybe at cost of added latencies.

Indeed you can infinite-buffer it, but there is really no gain, the added 
latency makes an effective lower frame rate (total number of real frames seen 
by the guest in percentage)

 The guest sees a common USB Video Class Device webcam with no controls
 (this can be enhanced easily), so basically you cannot change any parameter.
 However all the webcams I tested automatically managed that in the
 firmware with no intervention from any of the drivers (host or guest),
 changing white balance and brightness to the adequate values.
 
 Nice.  Patches are waiting for EHCI being merged I guess?

Patches are on RFC on June 2010 ML messages.
There are some updates I did to the emulation (internal conversion from YUV2 to 
MJPEG, gives twice the framerate when the host webcam is YUV2 only) that I have 
not sent to RFC yet.

There are also some things that can be enhanced (conversion of more strange 
RAWs like OV511's, show the guest the controls of the real webcam) easily but I 
won't do that until a legal problem about the usage of my emulation code along 
with all the rest of QEMU by a commercial vendor in violation of GPL is solved.

It works really well with USB 1.1 (up to 24fps with KVM, up to 10fps with TCG), 
but your when EHCI is merged it will allow bigger resolutions easily

The most curious and interesting thing is that, while the specification says 
there can be webcams using bulk transfers (that's what mine is doing) I've seen 
NONE in wild. All do ISO.

Peter about your exact problem you may have more luck requesting that feature 
to the corresponding linux's driver maintainer.

 cheers,
  Gerd

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iF4EAREIAAYFAk3j38QACgkQv/wfOsykIRQfjAEAgrl7eaK6qD4urzZCyGWEYoL2
yaEJbHEDybANWSOAVDkBALyMIVjvVCHzSq3wVH/8fh2Hc6Yp235PrMHduUzdC7Xj
=pXPT
-END PGP SIGNATURE-

Re: [Qemu-devel] Webcams under KVM and Linux

[Natalia Portillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


El 30/05/2011, a las 21:47, Brad Hards escribió:

 On Mon, 30 May 2011 08:38:35 pm Gerd Hoffmann wrote:
 I think people are also working on camera emulation, i.e. pass any (even
 non-usb) v4l devices as usb webcam to the guest.  No idea what the
 status here is.
 I have it in early development. Its far from complete - just enough for the 
 software (e.g. cheese or uvcview on the guest) to believe that there really 
 is 
 a UVC device there and try to open it.
 
 I wasn't planning on being able to connect any V4L(2) device to the 
 emulation. 
 I was thinking more along the lines of a gstreamer output, or a fixed image, 
 or 
 a test pattern.
 
 Natalia: if possible, could you provide an overview of your work in this area?

The best should be for you to check for the patches I sent (june 2010 on the 
ML) and enhance what is left to be done.

Reinventing the wheel is non-sense.

 Brad

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iF4EAREIAAYFAk3kKpcACgkQv/wfOsykIRQ+OQEAurhvZGDv4j+ut50vT75PLF3R
KGsAEBsBkgnP1c+De68A/R3RWheXXnBFSh2BCaTZYtykdYc8jVxCS76uFLWUDqRL
=Fs+h
-END PGP SIGNATURE-

Re: [Qemu-devel] Webcams under KVM and Linux

[Natalia Portillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

More concretely search for patches sent by me.

Even when EHCI is finished still is the problem of isochronous transfer not 
working well because of timing issues on QEMU.

My patches overcome the need for ISO transfer and EHCI controllers completely, 
as well as providing an universal device to the guest that works with every 
Windows XP, every Linux and even Mac OS X.

El 29/05/2011, a las 14:37, Andreas Färber escribió:

 Hello,
 
 Am 29.05.2011 um 15:01 schrieb Peter Baitz:
 
 
 [...] You should notice that it is not just adding
 ISOC and USB 2.0 support, but also to prioritize the processing of isoc
 packets on a virtual environment, and to provide enough throughput for
 video streams
 
 [...] Please check the qemu-devel mailing list archive, specifically 
 regarding recent discussions about EHCI (USB 2.0). Some of those threads 
 address isochronous transfer as well.
 
 In the meantime, you could also try to assign a complete host controller to 
 the guest to get a webcam working. I tried this a while ago, though the 
 result was only moderately well working here.
 
 [...] I would indeed like to hear more about what the project is adding to 
 KVM - Qemu to allow video to work with webcams
 [...]
 I was told I could try to add a complete host controller to the guest, but 
 am not entirely sure I understand what that means?  Looking for specifics?  
 Is there a suggestion for doing this during install of the KVM guest, or can 
 this be done while the guest is running, or otherwise?
 
 Independent of the ongoing EHCI work, I remember a patch specifically for 
 webcams a while ago, try searching the archives for V4L.
 
 Andreas

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iF4EAREIAAYFAk3iT+QACgkQv/wfOsykIRTtxQD+KCTGZhuzrZMzmYDvY5NFO0+F
QQwdE0aYVntQWpHMG5YBAJsFT5wd7/8FxOIt3aL1lwFqXtKc9y9TrrNog95gnoVh
=n0hn
-END PGP SIGNATURE-

Re: [Qemu-devel] mouse doesn't work on guest OS

[Natalia Portillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Update to lastest Xorg and/or change mouse protocol in Xorg configuration.

The default protocol is not emulated (at all, or well enough) by QEMU and while 
it detects a mouse it does not work, lastest Ubuntu version does not show this 
problem

man xorg.conf or google it

No information on how to configure a PS/2 mouse protocol in X11 is inside the 
scope of this mailing list.

Regards,
Natalia Portillo

El 22/05/2011, a las 00:32, Brad Hards escribió:

 On Sat, 21 May 2011 09:43:57 pm Amirali Shambayati wrote:
 Hi Brad,
 Hi.
 Please don't top post (google for this if you don't understand it).
 
 Qemu starts, kernel boots and ubuntu's GUI boots. I use dmesg in
 terminal to see printks which I have put in kernel code. 
 When I wrote Does it show up in dmesg or /proc?, I meant Does the mouse 
 connection show up in dmesg output and Do you see the mouse in 
 /proc/bus/input/devices?
 
 My problem is
 that, mouse is hanged in the middle of the screen.
 I still don't understand the problem. I'm guessing you see the cursor in the 
 guest, but the host mouse isn't having any effect on that guest cursor.
 
 I need mouse to
 connect to Internet!! if anyway exists to make Internet connection
 using terminal, I won't need mouse anymore!
 I don't understand what you are doing with the mouse, but there are various 
 command line tools (dhclient, ifconfig, etc) that you may be able to use in 
 the 
 client. These are nothing to do with qemu though.
 
 I'm newbie with kernel debugging and using qemu. Your help will be so
 valuable for me.
 A clear, explicit problem description will make this a lot easier. 
 
 You still haven't answered all of my questions, and you still haven't 
 described what you've done to try to debug this problem.
 
 
 On Sat, May 21, 2011 at 5:44 AM, Brad Hards br...@frogmouth.net wrote:
 On Friday 20 May 2011 23:59:25 Amirali Shambayati wrote:
 Mouse doesn't work on guest ubuntu.
 
 You need to debug it, as if it was real hardware.
 
 But none of them worked for me. any help is appreciated.
 
 This isn't a very in-depth problem description. Remember that we can't
 see your screen.
 
 Does qemu not start? Does the kernel not boot? Does it show up in dmesg
 or /proc? Does it work in text mode but not in X (or vice versa)? Does
 it work if you use the -device (qdev) approach instead? Does it work if
 you use the monitor console to hotplug the mouse after boot instead of
 on the command line?
 
 Basically, you need to tell us what debugging you've done, and the
 results of each part of that debugging.
 
 It might also help to know which version of qemu you are using.
 
 Brad
 

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iF4EAREIAAYFAk3YpMcACgkQv/wfOsykIRTAVAD/XalIs5B9hNbCXiT6mBX3CU1a
D5nzg1XgRSOAIAMZ5+sA/2WNgkCG1WZCwwIKN4i5g4rwknlKiFixEvWH8yGaMd1p
=ttaL
-END PGP SIGNATURE-

Re: [Qemu-devel] [Bug 760976] [NEW] Nexenta 3.0.1 fails to install

[Natalia Portillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Please report to Official OS Support List.

El 14/04/2011, a las 19:03, Nigel Horne escribió:

 Public bug reported:
 
 The latest git version of qemu (commit
 420b6c317de87890e06225de6e2f8af7bf714df0) fails to boot Nexenta3.0.1. I
 don't know if this is a bug in nextenta, or in QEMU or both.
 
 You can obtain a bootable image of Nextenta from
 http://www.nexenta.org/releases/nexenta-core-
 platform_3.0.1-b134_x86.iso.zip
 
 Host: Linux/x86_64 gcc4.5 ./configure --enable-linux-aio --enable-io-
 thread --enable-kvm
 
 qemu-img create nexenta3.0.1 3G
 qemu -hda nexenta3.0.1 -cdrom nexenta-core-platform3.0.1-b134x86.iso -boot d 
 -k en-us -m 256
 
 Boots to grub OK, but when you hit install you get
 panic[cpu0]/thread=fec226c0: vmem_hash_delete(d4404690, d445abc0, 0):
 bad free.
 
 You get the same error with or without -enable-kvm
 
 ** Affects: qemu
 Importance: Undecided
 Status: 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/760976
 
 Title:
  Nexenta 3.0.1 fails to install
 
 Status in QEMU:
  New
 
 Bug description:
  The latest git version of qemu (commit
  420b6c317de87890e06225de6e2f8af7bf714df0) fails to boot Nexenta3.0.1.
  I don't know if this is a bug in nextenta, or in QEMU or both.
 
  You can obtain a bootable image of Nextenta from
  http://www.nexenta.org/releases/nexenta-core-
  platform_3.0.1-b134_x86.iso.zip
 
  Host: Linux/x86_64 gcc4.5 ./configure --enable-linux-aio --enable-io-
  thread --enable-kvm
 
  qemu-img create nexenta3.0.1 3G
  qemu -hda nexenta3.0.1 -cdrom nexenta-core-platform3.0.1-b134x86.iso -boot d 
 -k en-us -m 256
 
  Boots to grub OK, but when you hit install you get
  panic[cpu0]/thread=fec226c0: vmem_hash_delete(d4404690, d445abc0, 0):
  bad free.
 
  You get the same error with or without -enable-kvm
 

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iF4EAREIAAYFAk2nheIACgkQv/wfOsykIRRr+AD+PGFqmHGovfcG9f3a5axB2o2a
86FPUdWkuCvz84rJZ5AA/2PA9+6U0XLM7+N1mLVWLg2tlXJkP2uLI5t7gGtjVUVQ
=FcGz
-END PGP SIGNATURE-

Re: [Qemu-devel] GSoC 2011: S3 Trio, AHCI

[Natalia Portillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Roland,

El 05/04/2011, a las 14:36, Roland Elek escribió:

 Dear Qemu developers,
 
 First, I'd like to reintroduce myself, as my university and official duties 
 prevented me from being active in the community since last year. I am Roland 
 Elek, a student from Hungary, and a successful student participant of Google 
 Summer of Code 2010. This year, I would like to participate again. I know I'm 
 a bit late, but I'm still hoping to get things arranged before the deadline.
 
 Last year, I worked on AHCI emulation with Alex as my mentor. Do you think a 
 proper summer project could be proposed from what is still missing? If so, 
 can I kindly ask someone to give me some pointers to what the project needs 
 the most, and where I should look first for things to include in my proposal? 
 Also, if the idea is feasible, would there be someone who could be my mentor?

You should ask Alex himself directly.

 Last year, I was also interested in working on S3 Trio emulation. This year, 
 the same idea is on the ideas list. The hardware is pretty thoroughly 
 documented through source code and textual documentation, and I'm already 
 familiar with adding PCI devices to Qemu, so I do see a rough outline of how 
 I would implement it.
 
 However, last year, Paul Brook commented [1] that he wasn't convinced about 
 the usefulness of emulating an S3 Trio or Virge card, because of performance 
 reasons. He suggested that accelerating the 2D engine would be tricky because 
 the framebuffer is exposed to the guest. This might be just me not fully 
 understanding his point, but isn't this also the case with the Cirrus Logic 
 GD5446 card?

The 2D accelenration engine of that cards were merely an implementation of 
Windows 3.1 GDI calls, a bitblt, draw a circle, so on, over a framebuffer.
They are pretty simple and easily converted to GDI+, SDL or Cocoa, whatever 
QEMU is needing in the host to draw the framebuffer.

The idea of emulating a S3 Trio however is not to give 2D acceleration to 
guests but to have a hardware with wider support from guests.
The S3 Trio is supported by almost all known x86 guests and a good couple of 
non-x86 ones (including BeOS, Windows NT, NeXTStep).

The GDI accelerated functions were used only by Windows and only in some 
resolutions (640x480 at 16 colors mostly). The card's VESA implementation was 
2.0 (without 2D acceleration) and buggy enough to have made the manufacturer 
itself include a software implementation of VESA 3.0.

Anyway just digging again on Google shows me that the trio also accelerated YUV 
to RGB conversion (easily done, I have it in my webcam emulation) and that it 
is fully emulated by DOSBox (so their source can be used as a start) and of 
course, like past year, for VirtualPC (so emulation is possible and performance 
is not bad).

 He also suggested paravirtualization for 3D acceleration. Do you think it 
 would make a good summer project?

For this you would need to implement some kind of MPI between guest and host 
and trap the WGL/GLX/AGL calls and pass them as host WGL/GLX/AGL calls.
It is feasible but you should provide your own drivers for the guests because 
emulating the registers of a real 3D call will be simply performance-nulling.

Whatever you think is best for your abilities, apply for it on GSoC webpage.

However personally there are already two students applying for S3 and I would 
prefer everyone to have a choice so I recommend you to apply for the AHCI 
finishing or 3D virtualization, as you see fit.

Regards,
Natalia Portillo

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iF4EAREIAAYFAk2dmKcACgkQv/wfOsykIRTxTQD/QM1nKJGpLMRuCokKaoVBUYmK
94xs4L1rcbIXsxYoifwBALLZtuWZI29eP4Nz/DE55E5uX4AV3RHrcWw/ngvOPhD0
=46Q8
-END PGP SIGNATURE-

[Qemu-devel] Re: QEMU has been accepted for GSoC 2011

[Natalia Portillo]

Great notice.!

El 18/03/2011, a las 21:24, Luiz Capitulino escribió:

 Hi there,
 
 This is a small note to let you know that QEMU has been accepted as an 
 mentoring
 organization for Google Summer of Code 2011.
 
 I will be doing some admin tasks and plan to start inviting mentors in the 
 next
 week, but of course that those who wish to become mentors can apply to QEMU 
 too
 through melange.
 
 Our project page is:
 
 http://www.google-melange.com/gsoc/org/show/google/gsoc2011/qemu
 
 Thanks for all those who helped!

Re: [Qemu-devel] 68k and BeBox (was SymbianOS, MeeGO, WebOS and QEMU)

[Natalia Portillo]

Hi,

El 01/03/2011, a las 12:06, François Revol escribió:

 
 Le 1 mars 2011 à 13:02, Laurent Vivier a écrit :
 Currently the fastest ones would be BeBox, Mac68k and NeXT machines, 
 because almost all devices are already emulated, but the assembly itself, 
 firmware and CPU/FPU/MMU in case of 68k.
 
 IIRC the Mac68k hardware is quite obscure and model-dependant... 
 but EMILE and BasiliskII should say enough.
 
 They will not help you:
 - EMILE uses Mac ROM to access hardware
 - BasiliskII patches the ROM to call its internal drivers instead of
 accessing hardware.
That's what MacOS itself does.
Indeed there is a document on how Mac OS X Server boots somewhere deep in the 
Apple's support page that describe the various patching methods they use to 
boot on m68k (for A/UX), OldWorld and NewWorld machines.
Remember that the Mac ROM, is the majority of the Mac OS APIs, that may be used 
or patched in RAM depending on the Mac OS version running.

vMac however is emulating the hardware more exactly.

 
 If it can help I think I have all hardware reference manuals for m68k
 macintosh.
 
 Actually I think they used to be online until recently, but Apple revamped 
 their archived not too long ago IIRC.

For up to Mac II they are in the Inside Macintosh books, from them up to 
PowerPC you'll need to guess it, and for the cloneable systems, there is 
information in Apple Developer CDs.

Regards,
Natalia Portillo

[Qemu-devel] Re: GSoC 2011 project ideas

[Natalia Portillo]

I have added my 2010 still valid projects (all), and three more.

I also added myself as mentor for the USB projects, as I recently got 
experience on how the QEMU's USB stack works.

One of the projects I suggest, implementing USB 3.0 XHCI may need to be merged 
with clean up of Gerd's USB 2.0 EHCI emulation patches.
I think just cleaning up for mainstream the patches done by Gerd is too simple 
and fast-to-be-done for GSoC, but as it's Jan's proposition I will not merge 
them.

Jan if you agree with me, feel free to merge both projects, I'll mentor it.

Regards,
Natalia Portillo

[Qemu-devel] SymbianOS, MeeGO, WebOS and QEMU

[Natalia Portillo]

Hi all,

Last time I checked SymbianOS source repository I found references to QEMU.

Are they using QEMU for the simulator?
And for MeeGO?

May HP also be using it for WebOS?

We may propose putting their modifications upstream as a GSoC 2011 project if 
it's the case.

Regards,
Natalia Portillo

Re: [Qemu-devel] SymbianOS, MeeGO, WebOS and QEMU

[Natalia Portillo]

Hi Peter,

El 28/02/2011, a las 19:15, Peter Maydell escribió:

 On 28 February 2011 18:53, Natalia Portillo clau...@claunia.com wrote:
 Last time I checked SymbianOS source repository I found references to QEMU.
 
 Are they using QEMU for the simulator?
 And for MeeGO?
 
 May HP also be using it for WebOS?
 
 We may propose putting their modifications upstream as a GSoC 2011 project 
 if it's the case.
 
 Meego uses QEMU, yes: there's a git repo here:
 http://meego.gitorious.org/qemu-maemo
 
 Upstreaming the OMAP3 support from that tree is on my TODO list,
 but if anybody actually wants to do it as a GSOC project that's
 fine with me. (Personally I would classify it as more of a chore
 than a fun project :-))
Feel free to add it to the GSoC projects list :p

 If anybody has a proposal for an interesting ARM qemu related
 project I might be able to act as mentor for it (no promises
 at this point, though.)

I proposed on GSoC 2010 to cleanup and finish the WIP that was done on 0.9.0 
for emulation Acorn Archimedes platform.
It was going to be mentored by Paul Brook but no one took the project, so the 
proposal is still up.
I cannot mentor it as I know nothing about ARM.

Check on
http://wiki.qemu.org/Google_Summer_of_Code_2011#Enhance.2C_update_and_integrate_Acorn_Archimedes_system_emulation

Regards,
Natalia Portillo

Re: [Qemu-devel] Re: SymbianOS, MeeGO, WebOS and QEMU

[Natalia Portillo]

Hi,

El 28/02/2011, a las 22:57, François Revol escribió:

 
 Le 28 févr. 2011 à 20:54, qemu-devel-requ...@nongnu.org a écrit :
 
 I proposed on GSoC 2010 to cleanup and finish the WIP that was done on 0.9.0 
 for emulation Acorn Archimedes platform.
 It was going to be mentored by Paul Brook but no one took the project, so 
 the proposal is still up.
 I cannot mentor it as I know nothing about ARM.
 
 Check on 
 http://wiki.qemu.org/Google_Summer_of_Code_2011#Enhance.2C_update_and_integrate_Acorn_Archimedes_system_emulation
 
 Oh, interesting list there...
 
 I see someone wants BeBox support.
 I already started on this but it doesn't do much yet.
Loading Be's firmware or with a custom one?

 There are also several other 68k machines that could be fun to support once 
 the m68k branch is in shape in addition to NeXT, like Atari ST/Falcon and 
 Amiga, and there are existing emulators for those to look at.
Well, there are thousands of 68k machines, however the ones nobody emulates are 
of more interest. (Unless your Atari ST and Amiga emulation pretends to support 
things no other does, like Amiga UNIX, Apple UNIX)

 And I need 68k emulators to finish my Haiku port :-)
Interesting

Regards,
Natalia Portillo

Re: [Qemu-devel] 68k and BeBox (was SymbianOS, MeeGO, WebOS and QEMU)

[Natalia Portillo]

Hi,

 Indeed, and I'd love to get Haiku to boot on a NeXT :-)
I'd love to boot NeXTStep/m68k even on emulation.

 (Unless your Atari ST and Amiga emulation pretends to support things no 
 other does, like Amiga UNIX, Apple UNIX)
 
 Well, most of those emulators do not support the required mmu, except ARAnyM 
 (and their mmu patch was backported to UAE I think).
That's the main problem, but first of all in QEMU there is the need for 
complete pre-Coldfire 68ks, as well as the modular support for FPUs and MMU 
(Sun and Apple's Lisa)

Currently the fastest ones would be BeBox, Mac68k and NeXT machines, because 
almost all devices are already emulated, but the assembly itself, firmware and 
CPU/FPU/MMU in case of 68k.

 A/UX would be fun to run :-)
 There used to be UNIX for Atari TT also IIRC, though not sure it was ever 
 published.
There is a binary dump somewhere, I may have it.

Regards,
Natalia Portillo

Re: [Qemu-devel] GSoC 2011 project ideas

[Natalia Portillo]

Hi there,

El 23/02/2011, a las 20:42, Luiz Capitulino escribió:

 Hi there,
 
 Google will begin accepting mentoring organizations applications next week, 
 but
 we count only with three projects so far.
 
 Although there doesn't seem to exist a hard deadline associated with the ideas
 page, nor with the number of projects, we had more than 20 projects
 suggestions last year and a number of volunteering mentors.

Is there any problem to repeat previously proposed and not chosen projects?

 So, if you have a project idea and/or wish to be a mentor, please add an
 entry here:
 
 http://wiki.qemu.org/Google_Summer_of_Code_2011
 

Regards,
Natalia Portillo

[Qemu-devel] [Bug 696485] Re: BeOS5 personal edition only displays in Black and White

[Natalia Portillo]

This is not a QEMU bug.

You need to get a correct driver for the emulated hardware.

There is a Cirrus driver as well as a VESA driver in BeBits that will
work with absolutely all emulated hardware.

** Changed in: qemu
   Status: New = Invalid

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

Title:
  BeOS5 personal edition only displays in Black and White

Status in QEMU:
  Invalid

Bug description:
  I can only get the display on BeOS/x86 Personal Edition 5 to be in black and 
white.  I've tried all the -vga options.

wget http://www.bebits.com/bob/12373/BeOS4Linux.tar.gz
mkdir foo
cd foo
tar zxvf ../BeOS4Linux.tar.gz
qemu -cdrom image.be -fda floppy.img -boot a -vga std

Re: [Qemu-devel] [Bug 696485] [NEW] BeOS5 personal edition only displays in Black and White

[Natalia Portillo]

Hi,

El 02/01/2011, a las 22:28, Andreas Färber escribió:

 Am 02.01.2011 um 19:27 schrieb François Revol:
 
 I can only get the display on BeOS/x86 Personal Edition 5 to be in  
 black
 and white.  I've tried all the -vga options.
 
 wget http://www.bebits.com/bob/12373/BeOS4Linux.tar.gz
 mkdir foo
 cd foo
 tar zxvf ../BeOS4Linux.tar.gz
 qemu -cdrom image.be -fda floppy.img -boot a -vga std
 
 This is because it doesn't have any driver that supports the  
 emulated hardware, so it just switches to 16 color VGA and draws  
 from an 8bit framebuffer to the VGA bank with a grey palette.
 
 I thought the Cirrus card could be supported but it probably doesn't  
 emulate a matching chip.
 
 It might be possible to try extra drivers from http://bebits.com/browse/23
 though it'd be better to have a working setup from the official image.
 
 Later versions and Haiku use VESA though, so are unaffected and  
 should work with -vga std.
 
 Hmm, I have BeOS 5 PE working with qemu -hda ... (i.e., default VGA  
 options).
 And I'm pretty sure I didn't install special drivers.
 
 /boot/home/config/settings/kernel/drivers/vesa has:
 
 mode 800 600 16

Are you sure it's PE and not Dano?

 Andreas
 
 -- 
 You received this bug notification because you are a member of qemu-
 devel-ml, which is subscribed to QEMU.
 https://bugs.launchpad.net/bugs/696485
 
 Title:
  BeOS5 personal edition only displays in Black and White
 
 Status in QEMU:
  Invalid
 
 Bug description:
  I can only get the display on BeOS/x86 Personal Edition 5 to be in black and 
 white.  I've tried all the -vga options.
 
 wget http://www.bebits.com/bob/12373/BeOS4Linux.tar.gz
 mkdir foo
 cd foo
 tar zxvf ../BeOS4Linux.tar.gz
 qemu -cdrom image.be -fda floppy.img -boot a -vga std
 
 
 

Re: [Qemu-devel] [PATCH] Z80 emulation updated again!

[Natalia Portillo]

Hi all,

The Z80 CPU and its variants and clones are not only used in dozens of 
computers (ranging from a full range of CP/M compatible ones, and minicomputers 
mostly seen as general public as gaming devices -Amstrad, Speccy-), but also in 
hunders of embedded systems and even on Adaptec SCSI cards.

I vote for inclusion on mainstream 100%, and maybe from that code an i8080 
emulation can be easily extracted to cover the rest of 80s desktop/minis/micros 
?

Regards,
Natalia Portillo

Re: [Qemu-devel] AIX emulated on x86 host

[Natalia Portillo]

The last thing I've heard about that was long time ago when I and Jocelyn tried 
to make it work with OpenHackWare to no luck.

Anyway, right now, it does not work either, I just don't know if anyone is 
working on it.

I know that the AIX boot process is quite different (using MBR partition 
scheme, different memory maps).

Sorry but right now, Does AIX/RS6000 work on QEMU? is NO.

Regards,
Natalia Portillo

El 28/10/2010, a las 16:34, Stefan Hajnoczi escribió:

 On Wed, Oct 27, 2010 at 9:23 PM,  glen.c.bo...@esso.ca wrote:
 Sorry - first message had non-plain text by mistake. Trying again ...
 
 I have an old AIX machine (IBM RS/6000 running AIX v5.x) and it's about to
 fall apart. I would like to migrate that machine's functions onto one of
 my VMware hosts, all of which are DELL 2950 servers (x86 architecture). I
 know VMware only runs x86 architecture guests. So I am planning a Windows
 2003 Server guest, running QEMU as really the only thing it is doing and
 inside QEMU I want to run that AIX machine's functions.
 
 Fundamental question - think that will work?
 
 If the answer is YES then I need to worry about creating the PPC disk
 image, loading AIX onto it, loading my AIX applications and migrating the
 data from the old hardware to the new emulated machine. Think I'm nuts?
 Got a better alternative?
 
 I'm not aware of people doing this or whether the ppc targets
 supported by QEMU can even run AIX hardware/firmware-wise.  Perhaps
 someone has a definitive answer?
 
 Stefan
 

Re: [Qemu-devel] webcam under windows xp guest

[Natalia Portillo]

Hi,

El 29/08/2010, a las 14:34, Frans de Boer escribió:

 Hi and thanks. However, I cannot download the repository because of a
 bad HEAD.
I will someday understand GIT. It was posted on the mailing list anyway so 
just search for it.

 Is this a patch I can apply to the qemu-kvm 0.12.5 distribution?
It was done on 0.12.4-stable while 0.12.5 was git against git, so, should be.

Regards,
Natalia Portillo

Re: [Qemu-devel] Running the user emulation

[Natalia Portillo]

You can check how NetBSD does that.

NetBSD is able to run executables from other UNIXes and POSIX-compatible 
systems, including, Linux, IRIX, Darwin.
They do that with a series of syscall conversions and library substitutions.

That should be portable to use Mac OS X as host instead of NetBSD, and to run 
thru QEMU (running x86 Linux software on PowerPC Darwin)

Regards,
Natalia Portillo

El 11/08/2010, a las 10:33, C K Kashyap escribió:

 I was wondering if it would be easy to force build the user-emulation on mac 
 - as in, lets say my a.out from linux is really trivial - even statically 
 linked for that matter. All it does is, say, write hello world\n to the 
 screen - I'd imaging that write system call would be similar on mac (as far 
 as writing to stdout is concerned)  Would it be possible/easy to give it 
 a shot?
 
 
 On Wed, Aug 11, 2010 at 2:48 PM, Stefan Weil w...@mail.berlios.de wrote:
 Am 11.08.2010 11:06, schrieb C K Kashyap:
 Let me see if I understand this right -
 
 qemu loads the a.out and begins to interpret the x86 instructions in the 
 a.out and when a system call happens, it makes the call the host system  
 is that right?
 
 
 
 Right. That's the way how linux user mode emulation (for example qemu-i386) 
 works.
 See linux-user/syscall.c if you want to see more details.
 
 bsd-user and darwin-user are also supported (more or less), but darwin-user
 only supports translation of darwin/powerpc to darwin/x86 syscalls.
 It won't help you to run a linux a.out on your mac.
 
 
 
 
 On Wed, Aug 11, 2010 at 2:12 PM, Stefan Weil w...@mail.berlios.de wrote:
 Am 11.08.2010 10:31, schrieb C K Kashyap:
 Hi,
 I've built qemu on my mac osx using this config - 
 ./configure --prefix=/Users/ckk/local/ --target-list=i386-softmmu 
 x86_64-softmmu --enable-linux-user
 
 Now, I have a simple a.out built on linux - how can I run it using qemu on 
 my mac box?
 
 -- 
 Regards,
 Kashyap
 
 Hi Kashyap,
 
 you cannot run it in user mode emulation unless you replace Mac OS by Linux
 on your mac box. Linux user emulations requires a Linux host.
 
 If you have a Linux host, you would need --target-list=i386-linux-user.
 
 You can run your a.out if you run system emulation (e.g. i386-softmmu/qemu)
 and install Linux there, of course.
 
 Regards,
 Stefan
 
 
 
 -- 
 Regards,
 Kashyap
 
 
 
 
 -- 
 Regards,
 Kashyap

Re: [Qemu-devel] [PATCH] Added an option to set the VMDK adapter type

[Natalia Portillo]

Please resend it as inline code (pasted) not as an attachment.

Thanks

El 04/08/2010, a las 00:46, Aaron Mason escribió:

 Hi,
 
 Now that I have half a clue, please find attached a properly formatted
 patch for the above with a signed-off line.  Hopefully attaching it
 won't cause issues as I have winblows on this machine and can't get
 git send-email to work at this time.
 
 Regards
 0001-Added-an-option-to-set-the-VMDK-adapter-type.patch

[Qemu-devel] [TUHS QEMU] Making progress with old DG/UX virtualization. Need advice.

[Natalia Portillo]

Hi,

I've read all your posts in the QEMU mailing list and the TUHS one and I'm 
answering to both lists in a hope my mail enlights you and any other curious.

First of all, old UNIX systems (and I put my hand on the fire for DG/UX also), 
use a monolithic linked at setup/later time kernel.
That is, even if you get a driver (IDE, virtio, whatsoever), the configuration 
files, the kernel, the ramdisk, everything that lets your system boot, MUST 
HAVE BEEN BOOT from the AIC controller, the driver is hardcoded, no way to 
change it.

If you have extensive knowledge of what files a driver setup modifies on DG/UX 
specifically (knowledge from other UNIX, forget it, they are as different as 
Porsche and Ferrari motors), you can always get a new kernel with the drivers 
you need to make it boot and manually put them in your image.

In the case, you meet this requirements, and, you do it, you can then achieve 
to other problems. The DG/UX workstations are x86 machines, but nothing swears 
they are PC compatible machines, and they can have a different memory map for 
some critical device, or include critical devices never found in a PC (like an 
Intel Macintosh does for example). Just booting from a BIOS doesn't make the 
machines be the same (PowerPC Macintosh, IBM POWER workstations, Genesi 
Pegasos, are machines that boot OpenFirmware with heavily different 
configurations, devices and memory maps).

Also, you are assuming IDE is available in DG/UX just because the controller is 
present in the hardware. That hardware was also used for Windows NT. IDE 
support can be JUST FOR Windows, and the DG/UX manufacturer just decided to not 
include an IDE driver in the kernel (happened in AIX for PCs until last version 
of all, only SCSI was supported, being a hugely strange controller in PC 
worlds).

In the case you opt for making a driver (adding IDE, virtio, or other SCSI 
support) for the DG/UX need to say you need, low level knowledge of the 
hardware, low level knowledge of the operating system, a working machine (for 
sure, with the hardware available), a debug machine (almost sure also), C and 
maybe assembler knowledge. In a scale of 10, this puts the difficulty in 8 for 
most of programmers, and surely if you were one you stacked with the first 
option everyone gave you (see next sentence).

The easiest way, and the one that people answered you already in QEMU's mailing 
list (in a scale of 10 the difficulty is 6 or even 5), is creating an emulated 
device (that's the correct term, not driver) for an emulator, like QEMU, 
Bochs, VirtualBox (forget this option for VMWare, VirtualPC or Parallels) that 
adds the AIC SCSI controller you exactly need.

Why is this easiest? You don't need any DG/UX working system, you don't need to 
know how DG/UX works, you don't need to compile a kernel, copy it to your image.

You just take the Adaptec's documentation, and start coding, making a SCSI 
emulated controller, and testing it with systems you can always reinstall, 
debug, and check, until they fully work (Windows, Linux, BSD, take your choice).

And then, you just polish it until your DG/UX boots, or finds the memory map as 
a mess it doesnt like.

Finally, please stop begging on all the internet, spend that time coding the 
driver or getting the money to pay a programmer that will do.

Sincerely yours,
Natalia Portillo
Claunia.com CEO
QEMU's Official OS Support List maintainer

[Qemu-devel] Re: [TUHS QEMU] Making progress with old DG/UX virtualization. Need advice.

[Natalia Portillo]

Hi,

El 02/08/2010, a las 08:48, DG UX escribió:

 Thanks Natalia,
 
 I'll start by answering the insultive part of your answer, as my ego
 will not let me go on if I don't:
 
 I am not begging on all the internet, I am simply seeking solutions,
 help and advice, and making sure to update whoever is interested in
 the progress I am doing.
 Also, I wish to thank you for your insight and well detailed answer.
 Finally I got an explanation as to _why_ solution A will not be as
 good as solution B. That is what I call a winning argument, and I
 thank you for that.

That's why I sent you the message not because egos

 I already have people searching for Adaptec docs and programmers for
 the creation of the driver, err, emulated device.

Great, I wish you my best and offer my repository of operating systems to test 
the emulated device on as much systems as possible when it is mature enough.

 Take care,
 Adam

Natalia Portillo
Claunia.com

 On Mon, Aug 2, 2010 at 9:11 AM, Natalia Portillo clau...@claunia.com wrote:
 Hi,
 
 I've read all your posts in the QEMU mailing list and the TUHS one and I'm 
 answering to both lists in a hope my mail enlights you and any other curious.
 
 First of all, old UNIX systems (and I put my hand on the fire for DG/UX 
 also), use a monolithic linked at setup/later time kernel.
 That is, even if you get a driver (IDE, virtio, whatsoever), the 
 configuration files, the kernel, the ramdisk, everything that lets your 
 system boot, MUST HAVE BEEN BOOT from the AIC controller, the driver is 
 hardcoded, no way to change it.
 
 If you have extensive knowledge of what files a driver setup modifies on 
 DG/UX specifically (knowledge from other UNIX, forget it, they are as 
 different as Porsche and Ferrari motors), you can always get a new kernel 
 with the drivers you need to make it boot and manually put them in your 
 image.
 
 In the case, you meet this requirements, and, you do it, you can then 
 achieve to other problems. The DG/UX workstations are x86 machines, but 
 nothing swears they are PC compatible machines, and they can have a 
 different memory map for some critical device, or include critical devices 
 never found in a PC (like an Intel Macintosh does for example). Just booting 
 from a BIOS doesn't make the machines be the same (PowerPC Macintosh, IBM 
 POWER workstations, Genesi Pegasos, are machines that boot OpenFirmware with 
 heavily different configurations, devices and memory maps).
 
 Also, you are assuming IDE is available in DG/UX just because the controller 
 is present in the hardware. That hardware was also used for Windows NT. IDE 
 support can be JUST FOR Windows, and the DG/UX manufacturer just decided to 
 not include an IDE driver in the kernel (happened in AIX for PCs until last 
 version of all, only SCSI was supported, being a hugely strange controller 
 in PC worlds).
 
 In the case you opt for making a driver (adding IDE, virtio, or other SCSI 
 support) for the DG/UX need to say you need, low level knowledge of the 
 hardware, low level knowledge of the operating system, a working machine 
 (for sure, with the hardware available), a debug machine (almost sure also), 
 C and maybe assembler knowledge. In a scale of 10, this puts the difficulty 
 in 8 for most of programmers, and surely if you were one you stacked with 
 the first option everyone gave you (see next sentence).
 
 The easiest way, and the one that people answered you already in QEMU's 
 mailing list (in a scale of 10 the difficulty is 6 or even 5), is creating 
 an emulated device (that's the correct term, not driver) for an emulator, 
 like QEMU, Bochs, VirtualBox (forget this option for VMWare, VirtualPC or 
 Parallels) that adds the AIC SCSI controller you exactly need.
 
 Why is this easiest? You don't need any DG/UX working system, you don't need 
 to know how DG/UX works, you don't need to compile a kernel, copy it to your 
 image.
 
 You just take the Adaptec's documentation, and start coding, making a SCSI 
 emulated controller, and testing it with systems you can always reinstall, 
 debug, and check, until they fully work (Windows, Linux, BSD, take your 
 choice).
 
 And then, you just polish it until your DG/UX boots, or finds the memory map 
 as a mess it doesnt like.
 
 Finally, please stop begging on all the internet, spend that time coding the 
 driver or getting the money to pay a programmer that will do.
 
 Sincerely yours,
 Natalia Portillo
 Claunia.com CEO
 QEMU's Official OS Support List maintainer

Re: [Qemu-devel] [ANNOUNCE] Release 0.12.5 of QEMU

[Natalia Portillo]

El 23/07/2010, a las 17:46, Aurelien Jarno escribió:

 The QEMU team is pleased to announce the availability of the 0.12.5
 release. This is a stable release of the 0.12 series and only contains
 bug fixes since 0.12.4.
 
 It can be downloaded from Savannah at:
 
  http://download.savannah.gnu.org/releases/qemu/qemu-0.12.5.tar.gz
 
 On behalf of the QEMU team, I'd like to thank everyone who contributed
 to make this release happen!
 
 - audio/alsa: Handle SND_PCM_STATE_SETUP in alsa_poll_handler
 - block: Handle multiwrite errors only when all requests have completed
 - block: Fix early failure in multiwrite
 - vpc: Use bdrv_(p)write_sync for metadata writes
 - vmdk: Use bdrv_(p)write_sync for metadata writes
 - qcow2: Use bdrv_(p)write_sync for metadata writes
 - qcow: Use bdrv_(p)write_sync for metadata writes
 - block: Add bdrv_(p)write_sync
 - qcow2: Restore L1 entry on l2_allocate failure
 - block/vdi: Fix image opening and creation for odd disk sizes
 - block/vpc: Fix conversion from size to disk geometry
 - qcow2: Remove abort on free_clusters failure
 - vmdk: Fix COW
 - qcow2: Fix creation of large images
 - vmdk: fix double free
 - qemu-options: add documentation for stdio signal=on|off
 - target-arm : fix parallel saturated subtraction implementation
 - target-arm : fix thumb2 parallel add/sub opcode decoding
 - target-arm: fix addsub/subadd implementation
 - target-i386: fix xchg rax,r8
 - block/vvfat.c: fix warnings with _FORTIFY_SOURCE
 - audio/alsa: Spelling typo (paramters)
 - target-mips: fix DINSU instruction
 - Correct definitions for FD_CMD_SAVE and FD_CMD_RESTORE
 - qcow2: Fix corruption after error in update_refcount
 - qcow2: Fix corruption after refblock allocation
 - block: Fix multiwrite with overlapping requests
 - qcow2: Fix error handling in l2_allocate
 - qcow2: Clear L2 table cache after write error
 - ide: Fix ide_dma_cancel
 - usb-bus: fix no params
 - Avoid crash on '-usbdevice device' without parameters
 - Fix -usbdevice crash
 - Fix multiboot compilation
 - Fix missing symbols in .rel/.rela.plt sections
 - target-ppc: fix RFI by clearing some bits of MSR
 - Fix typo in balloon help
 - arm_timer: fix oneshot mode
 - arm_timer: reload timer when enabled
 - qemu-sockets: avoid strlen of NULL pointer
 - block: fix aio_flush segfaults for read-only protocols (e.g. curl)
 - virtio-blk: fix barrier support
 - block: fix sector comparism in multiwrite_req_compare
 - pci: irq_state vmstate breakage
 - qemu-img: use the heap instead of the huge stack array for win32

Great.

Official OS Support List ( http://www.claunia.com/qemu )updated.

Regards,
Natalia Portillo

Re: [Qemu-devel] FW: Qemu crashes

[Natalia Portillo]

Hi,

It seems to be a modified version of QEMU.

If it is the case you must contact the modifier or test with an unmodified 
version.

If it is not, you must provide more detailed information, like, exact qemu 
version, command line, and extended fail information as given by Windows. If 
possible, you must provide also the same guest OS image you're using.

Regards,
Natalia Portillo

El 21/07/2010, a las 17:06, capricorn 80 escribió:

 
 Can any one help me in that please.
 
 
 Hi!
 
 I am trying to run asa 802, asdm 602 with gns3. After long struggle i managed 
 to fixed every thing. But now when i run asdm the Qemu crashes.
 
 The reference is on this post -  http://www.gns3.net/phpBB/topic2349.html
 
 
 Thanks for any kind of help.
 
 
 Regards,
 

Re: [Qemu-devel] [PATCH] Disable O_DIRECT for physical CDROM/DVD drives

[Natalia Portillo]

El 20/07/2010, a las 16:17, jes.soren...@redhat.com escribió:

 From: Jes Sorensen jes.soren...@redhat.com
 
 O_DIRECT (cache=none) requires sector alignment, however the physical
 sector size of CDROM/DVD drives is 2048, as opposed to most disk
 devices which use 512. QEMU is hard coding 512 all over the place, so
 allowing O_DIRECT for CDROM/DVD devices does not work.

What about if the device is a 4096 byte/sector hard disk, a 512 byte/sector 
CD-ROM (IRIX ones), a 2048 byte/sector magnetooptical?

We should get rid of that hard codes and use real values.

 Signed-off-by: Jes Sorensen jes.soren...@redhat.com
 ---
 block/raw-posix.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)
 
 diff --git a/block/raw-posix.c b/block/raw-posix.c
 index 291699f..0ea79b6 100644
 --- a/block/raw-posix.c
 +++ b/block/raw-posix.c
 @@ -1139,6 +1139,11 @@ static int cdrom_open(BlockDriverState *bs, const char 
 *filename, int flags)
 BDRVRawState *s = bs-opaque;
 
 s-type = FTYPE_CD;
 +if (flags  BDRV_O_NOCACHE) {
 +fprintf(stderr, Disabling unsupported O_DIRECT (cache=none) for 
 +CDROM/DVD device (%s)\n, filename);
 +flags = ~BDRV_O_NOCACHE;
 +}
 
 /* open will not fail even if no CD is inserted, so add O_NONBLOCK */
 return raw_open_common(bs, filename, flags, O_NONBLOCK);
 -- 
 1.7.1.1
 
 

Re: [Qemu-devel] patching qemu 0.9.0

[Natalia Portillo]

Hi,

El 06/07/2010, a las 15:41, Bryan Wilwerding escribió:

 I have a 0.9.0 qemu package that was modified by a research project.  I would 
 like to upgrade this qemu package.  Where I can find a patch for 0.9.0 to 
 qemu 0.10 and higher?

You can use the git to obtain a patch between two snapshots, however I don't 
know the exact command line sorry.

Natalia Portillo

Re: [Qemu-devel] [Bug 477946] Re: XP guest install fails with NTFS format error

[Natalia Portillo]

It does not occur on QEMU's 0.12.3 neither 0.12.4, quick format, slow format, 
NTFS, FAT32, checked it personally.

Please fill a bug in Fedora as it must be some patch they applied.

El 05/07/2010, a las 15:48, Hanno Starling escribió:

 This problem still occurs in Fedora 13, with qemu-kvm-0.12.3
 I checked:
 yum install qemu-kvm
 ..
 Setting up Install Process
 Package 2:qemu-kvm-0.12.3-8.fc13.x86_64 already installed and latest version
 Nothing to do
 
 -- 
 XP guest install fails with NTFS format error
 https://bugs.launchpad.net/bugs/477946
 You received this bug notification because you are a member of qemu-
 devel-ml, which is subscribed to QEMU.
 
 Status in QEMU: Fix Committed
 
 Bug description:
 Ubuntu 9.10 on AMD6400X2, 2G RAM, all updates applied as of date of bug report
 Latest qemu-kvm installed (0.11)
 XP guest  install (XP Pro SP2) fails when attempting to format the install 
 partition (10G) as NTFS with the error Setup was unable to format the 
 partition. The disk may be damaged. 512M memory allocated to VM, one 
 processor allocated. No additional qemu options specified.
 
 However, can successfully format partition as FAT and complete install. 
 However, after so doing, scheduled an NTFS convert on next reboot of guest. 
 When the virtual machine was shut down and restarted, it immediately failed 
 with a 'missing NTLDR' error. This occurred before the NTFS conversion took 
 place.
 
 Deleted all VMs and associated files and rebooted. Recreated the VM and 
 retried the install. Failed on format exactly as before. Disk subsystem 
 scanned, no errors found, no hardware problems have occurred previously, this 
 is a highly stable testbed machine which has been in use for years.
 
 
 

Re: [Qemu-devel] [Bug 596106] Re: kvm to emulate 64 bit cpu on 32 bit host

[Natalia Portillo]

Paolo said:
 They do it like TCG does it, not like KVM.

You are wrong, and it's easy to check as the speed is almost native.
Having emulation would make it slow as hell.

Jamie said:
 
   VirtualPC is unable to run 64 bit guests at all even on 64 bit
   hosts
 
 Are you sure?  Microsoft provides numerous downloadable 64-bit guest
 Windows images, and VirtualPC is Microsoft's; they must be running on
 something.
 

That may be in Windows Virtual PC (that requires VT and Windows 7 
Ultimate/Professional, and is a feature of that OSes not a separate product) or 
Hyper-V (again, requires VT and is a feature of Windows 2008 Server), but not 
on the standalone Microsoft Virtual PC 2007.


It is fully possible to run 64-bit code in a 32-bit kernel, Mac OS X Leopard 
does that all the way without problems, and VMWare found how to do the trick 
with the NT kernel.

The question is not is it possible to make KVM run 64-bit code in a 32-bit 
kernel? (it is), the question is, the people in charge of KVM want to add 
this feature?.

Personally I don't believe so, neither I am on the do it side, I'm just 
saying it is technically possible.

Natalia Portillo

[Qemu-devel] [Bug 596106] Re: kvm to emulate 64 bit cpu on 32 bit host

[Natalia Portillo]

VMWare is able to do it, we should be able.

-- 
kvm to emulate 64 bit cpu on 32 bit host
https://bugs.launchpad.net/bugs/596106
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: Won't Fix

Bug description:
i wish kvm can run 64bit guest os on 32bit host just like qemu does.

Re: [Qemu-devel] [Bug 596106] Re: kvm to emulate 64 bit cpu on 32 bit host

[Natalia Portillo]

El 19/06/2010, a las 22:12, Andrew Cathrow escribió:

 
 
 
 
 - Natalia Portillo clau...@claunia.com wrote: 
  From: Natalia Portillo clau...@claunia.com
  To: qemu-devel@nongnu.org
  Sent: Saturday, June 19, 2010 9:01:04 AM GMT -05:00 US/Canada Eastern
  Subject: [Qemu-devel] [Bug 596106] Re: kvm to emulate 64 bit cpu on 32 bit 
  host
 
  VMWare is able to do it, we should be able.
 
 VMware can't do that!
 To run a 64bit guest on VMware you need 64bit hardware and VT/AMD-V
 http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=1003945

You got the point wrong, I'm talking running WITH 64 bit hardware in a 32 bit 
guest.

This is done in Mac OS X Leopard (kernel is only 32 bit) and Mac OS X Snow 
Leopard (using 32 bit kernel not 64 bit one) by VMWare, Parallels and 
VirtualBox, as well as on Windows 32 bit using VMWare (dunno about VBox and 
Parallels, VirtualPC is unable to run 64 bit guests at all even on 64 bit 
hosts), just provided of course, the hardware is 64 bit.

  
  -- 
  kvm to emulate 64 bit cpu on 32 bit host
  https://bugs.launchpad.net/bugs/596106
  You received this bug notification because you are a member of qemu-
  devel-ml, which is subscribed to QEMU.
  
  Status in QEMU: Won't Fix
  
  Bug description:
  i wish kvm can run 64bit guest os on 32bit host just like qemu does.
  
  
  
 

Re: [Qemu-devel] [RFC PATCH 1/2] USB Video Class device emulation.

[Natalia Portillo]

Hi Blue,

You're right on all things.
I'll check CODING_STYLE and do the things.

Thanks a lot.

Re: [Qemu-devel] [RFC PATCH 0/2] Add USB Video Class device emulation.

[Natalia Portillo]

Hi David,

 Attempting to try out your patches, but it's failing with the following:
 
 usb-uvc: Init called
 usb-uvc: Trying to open /dev/video0
 .usb-uvc: Device opened correctly.
 usb-uvc: Querying capabilities.
 usb-uvc: Device driver: uvcvideo
 usb-uvc: Device name: Laptop_Integrated_Webcam_0.3M
 usb-uvc: Device bus: usb-:00:1a.7-6
 usb-uvc: Driver version: 0.1.0
 usb-uvc: Device capabilities: 0x0401
 usb-uvc: Enumerating video inputs.
 usb-uvc: Setting video input to index 0
 usb-uvc: Video input correctly set.
 usb-uvc: Trying to set 320x240 MJPEG.
 qemu-system-x86_64: -device usb-uvc-webcam,device=/dev/video0: Invalid
 format.

As for now only cameras that allow MJPEG format will work.
Check your camera specifications (lsusb -v works if your real camera is UVC, 
check driver's source otherwise).
Cameras with RAW frames (YUYV and NV12 formats) do not work, yet. I'm on it.

 
 Also, I tried a PWC camera which is not a V4L2_INPUT_TYPE_CAMERA and
 noticed that video_input_index is used uninitialized in usb_uvc_initfn
It's a webcam?
Could you give me more information?
Manufacturer, model, linux's module name.

All webcams SHOULD (and MUST) implement V4L2_INPUT_TYPE_CAMERA.
Not the same for video cameras or capture devices (PAL/NTSC, DVB/ATSC).

Regards,
Natalia Portillo

Re: [Qemu-devel] [RFC PATCH 0/2] Add USB Video Class device emulation.

[Natalia Portillo]

Hi,

 Trying to guess the relevant descriptors:
 
VideoStreaming Interface Descriptor:
bLength50
bDescriptorType36
bDescriptorSubtype  5 (FRAME_UNCOMPRESSED)
bFrameIndex 3
bmCapabilities   0x00
  Still image unsupported
wWidth320
wHeight   240
dwMinBitRate   768000
dwMaxBitRate  4608000
dwMaxVideoFrameBufferSize  153600
dwDefaultFrameInterval 33
bFrameIntervalType  6
dwFrameInterval( 0)33
dwFrameInterval( 1)40
dwFrameInterval( 2)50
dwFrameInterval( 3)66
dwFrameInterval( 4)   100
dwFrameInterval( 5)   200
 
  VideoStreaming Interface Descriptor:
bLength 6
bDescriptorType36
bDescriptorSubtype 13 (COLORFORMAT)
bColorPrimaries 1 (BT.709,sRGB)
bTransferCharacteristics1 (BT.709)
bMatrixCoefficients 4 (SMPTE 170M (BT.601))
Unless there is any FRAME_MJPEG in the descriptor, the camera is as now, 
unsupported yet.
I'm working on supported cameras FRAME_UNCOMPRESSED.

 
 
 Also, I tried a PWC camera which is not a V4L2_INPUT_TYPE_CAMERA and
 noticed that video_input_index is used uninitialized in usb_uvc_initfn
 It's a webcam?
 Could you give me more information?
 Manufacturer, model, linux's module name.
 
 usb 7-1: new full speed USB device using uhci_hcd and address 3
 usb 7-1: New USB device found, idVendor=046d, idProduct=08b6
 usb 7-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
 pwc: Logitech/Cisco VT Camera webcam detected.
The only thing I'm able to found about it is that the driver is Video4Linux 1.0 
not 2.0.
Do you have manufacturer and model?
Do you have idea of that input type v4l2 defines for it?
May you give me SSH access to a machine with that cam installed to test and 
implement?

Regards,
Natalia Portillo

[Qemu-devel] [RFC PATCH 1/2] USB Video Class device emulation.

[Natalia Portillo]

Signed-off-by: Natalia Portillo clau...@claunia.com
---
 hw/usb-uvc.c | 1096 ++
 1 files changed, 1096 insertions(+), 0 deletions(-)
 create mode 100644 hw/usb-uvc.c

diff --git a/hw/usb-uvc.c b/hw/usb-uvc.c
new file mode 100644
index 000..b711f51
--- /dev/null
+++ b/hw/usb-uvc.c
@@ -0,0 +1,1096 @@
+/*
+ * USB Video Class Device emulation.
+ *
+ * Copyright (c) 2010 Claunia.com
+ * Written by Natalia Portillo nata...@claunia.com
+ *
+ * Based on hw/usb-hid.c:
+ * Copyright (c) 2005 Fabrice Bellard
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation in its version 2.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see http://www.gnu.org/licenses/.
+ *
+ */
+#include hw.h
+#include console.h
+#include usb.h
+#include qemu-error.h
+#include stdio.h
+#include fcntl.h
+#include errno.h
+// V4L2 ioctls
+#include sys/ioctl.h
+#include linux/videodev2.h
+
+#define DEBUG_UVC
+
+#ifdef DEBUG_UVC
+#define DPRINTF(fmt, ...) \
+do { printf(usb-uvc:  fmt , ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...) do {} while(0)
+#endif
+
+/* USB Video Class Request codes */
+#define USB_UVC_RC_UNDEFINED   0x00
+#define USB_UVC_SET_CUR0x01
+#define USB_UVC_GET_CUR0x81
+#define USB_UVC_GET_MIN0x82
+#define USB_UVC_GET_MAX0x83
+#define USB_UVC_GET_RES0x84
+#define USB_UVC_GET_LEN0x85
+#define USB_UVC_GET_INFO   0x86
+#define USB_UVC_GET_DEF0x87
+
+/* USB Video Class Request types */
+#define UVCSetVideoControl 0x2100
+#define UVCSetVideoStreaming   0x2200
+#define UVCGetVideoControl 0xA100
+#define UVCGetVideoStreaming   0xA200
+
+typedef struct USBUVCState {
+USBDevice dev;
+   charcurrent_input;
+   char*v4l2_device;
+} USBUVCState;
+
+static int v4l2_fd;
+static char *frame;
+static char *frame_start;
+static int frame_length;
+static int frame_id;
+static int first_bulk_packet;
+static int frame_remaining_bytes;
+static int frame_max_length;
+
+static const uint8_t qemu_uvc_dev_descriptor[] = {
+   0x12,   /*  u8 bLength; */
+   0x01,   /*  u8 bDescriptorType; Device */
+   0x00, 0x02, /*  u16 bcdUSB; v2.0 */
+   
+   0xEF,   /*  u8  bDeviceClass; */
+   0x02,   /*  u8  bDeviceSubClass; */
+   0x01,   /*  u8  bDeviceProtocol; [ low/full speeds only ] */
+   0x08,   /*  u8  bMaxPacketSize0; 8 Bytes */
+   
+   /* Vendor and product id are arbitrary.  */
+   0x00, 0x00, /*  u16 idVendor; */
+   0x00, 0x00, /*  u16 idProduct; */
+   0x00, 0x00, /*  u16 bcdDevice */
+   
+   0x01,   /*  u8  iManufacturer; */
+   0x02,   /*  u8  iProduct; */
+   0x00,   /*  u8  iSerialNumber; */
+   0x01/*  u8  bNumConfigurations; */
+};
+
+static const uint8_t qemu_uvc_config_descriptor[] = {
+   
+   /* one configuration */
+   0x09,   /*  u8  bLength; */
+   0x02,   /*  u8  bDescriptorType; Configuration */
+   0xB7, 0x00, /*  u16 wTotalLength; */
+   0x02,   /*  u8  bNumInterfaces; (2) */
+   0x01,   /*  u8  bConfigurationValue; */
+   0x00,   /*  u8  iConfiguration; */
+   0x80,   /*  u8  bmAttributes;
+Bit 7: must be set,
+6: Self-powered,
+5: Remote wakeup,
+4..0: resvd */
+   0xFA,   /*  u8  MaxPower; */
+   
+   /* interface association */
+   0x08,   /*  u8  ifa_bLength; */
+   0x0B,   /*  u8  ifa_bDescriptorType; Interface Association */
+   0x00,   /*  u8  ifa_bFirstInterface; */
+   0x02,   /*  u8  ifa_bInterfaceCount; */
+   0x0E,   /*  u8  ifa_bFunctionClass; CC_VIDEO */
+   0x03,   /*  u8  ifa_bFunctionSubClass; 
SS_VIDEO_INTERFACE_COLLECTION */
+   0x00,   /*  u8  ifa_bFunctionProtocol; unused */
+   0x02,   /*  u8  ifa_iFunction; */
+   
+   /* video control interface */
+   0x09,   /*  u8  if_bLength; */
+   0x04,   /*  u8  if_bDescriptorType; Interface */
+   0x00,   /*  u8  if_bInterfaceNumber; */
+   0x00,   /*  u8  if_bAlternateSetting; */
+   0x01,   /*  u8  if_bNumEndpoints; */
+   0x0E,   /*  u8  if_bInterfaceClass; CC_VIDEO

[Qemu-devel] [RFC PATCH 2/2] Adds device to Makefile.

[Natalia Portillo]

Signed-off-by: Natalia Portillo clau...@claunia.com
---
 Makefile.objs |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/Makefile.objs b/Makefile.objs
index 110f8fd..1535b61 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -70,6 +70,7 @@ common-obj-y += scsi-disk.o cdrom.o
 common-obj-y += scsi-generic.o scsi-bus.o
 common-obj-y += usb.o usb-hub.o usb-$(HOST_USB).o usb-hid.o usb-msd.o 
usb-wacom.o
 common-obj-y += usb-serial.o usb-net.o usb-bus.o
+common-obj-$(CONFIG_LINUX) += usb-uvc.o
 common-obj-$(CONFIG_SSI) += ssi.o
 common-obj-$(CONFIG_SSI_SD) += ssi-sd.o
 common-obj-$(CONFIG_SD) += sd.o
-- 

[Qemu-devel] [RFC PATCH 0/2] Add USB Video Class device emulation.

[Natalia Portillo]

Hi,

This currently adds an emulated USB webcam compliant with USB Video Class 
Specification 1.0a.

It only works on Linux guests and feeds the emulated device using a Video4Linux 
2 host device, as long as it supports 320x240 MJPEG format.

This is a Request for Comments as surely code needs some cleaning or style.

You can see it working here:
http://www.youtube.com/watch?v=fzGYvjZzx6E with Linux guest
http://www.youtube.com/watch?v=_Yo9TWPDXCo with Windows XP Home guest

To add the device use -device usb-uvc-webcam,device=path to v4l2 device

Regards,
Natalia Portillo

[Qemu-devel] [Bug 588693] [NEW] CD-ROM devices always return a one session, one track TOC

[Natalia Portillo]

Public bug reported:

CD-ROM devices always return a one session, one track TOC, no matter if
it is using ioctl's with the host or DMG images (both able of having
multi track, multi session discs).

** Affects: qemu
 Importance: Undecided
 Assignee: Natalia Portillo (claunia)
 Status: In Progress

** Changed in: qemu
 Assignee: (unassigned) = Natalia Portillo (claunia)

-- 
CD-ROM devices always return a one session, one track TOC
https://bugs.launchpad.net/bugs/588693
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: In Progress

Bug description:
CD-ROM devices always return a one session, one track TOC, no matter if it is 
using ioctl's with the host or DMG images (both able of having multi track, 
multi session discs).

[Qemu-devel] [Bug 588693] Re: CD-ROM devices always return a one session, one track TOC

[Natalia Portillo]

(P.S.: This bug prevents BeOS boot)

** Changed in: qemu
   Status: New = In Progress

-- 
CD-ROM devices always return a one session, one track TOC
https://bugs.launchpad.net/bugs/588693
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: In Progress

Bug description:
CD-ROM devices always return a one session, one track TOC, no matter if it is 
using ioctl's with the host or DMG images (both able of having multi track, 
multi session discs).

[Qemu-devel] [Bug 547227] Re: qemu-system-m68k does not accept notw %d instruction

[Natalia Portillo]

As of QEMU 0.12.3, it only emulates ColdFire processors.

Coldfire no longer implement notw, only notl instruction, so this
behaviour is expected.

** Changed in: qemu
   Status: New = Invalid

-- 
qemu-system-m68k does not accept notw %d instruction
https://bugs.launchpad.net/bugs/547227
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: Invalid

Bug description:
The notw and notb instructions does not work with latest version of 
qemu-system-m68k. I've tried both 0.12.3 and the latest git version compiled 
about an hour ago, both running on Arch Linux. The executable fails with the 
following output:
 qemu-system-m68k -nographic -M an5206 -kernel test.elf
qemu: fatal: Illegal instruction: 4640 @ 0006
D0 =    A0 =    F0 =  (   0)
D1 =    A1 =    F1 =  (   0)
D2 =    A2 =    F2 =  (   0)
D3 =    A3 =    F3 =  (   0)
D4 =    A4 =    F4 =  (   0)
D5 =    A5 =    F5 =  (   0)
D6 =    A6 =    F6 =  (   0)
D7 =    A7 =    F7 =  (   0)
PC =    SR = 2700 - FPRESULT =0
zsh: abort  qemu-system-m68k -nographic -M an5206 -kernel test.elf

I've attached the test.elf file, which produces the bug. It contains the 
following:
 m68k-elf-objdump -m 68000 -D test.elf  
test.elf: file format elf32-m68k
Disassembly of section .text:
 start:
   0:   4e71nop
   2:   4e71nop
   4:   4e71nop
   6:   4640notw %d0
0008 loop:
   8:   6000 fffe   braw 8 loop

It works when removing the not instruction. There might be other non-working 
instructions, I've only tested a few.
Hope you'll get the bug fixed. Thanks.

[Qemu-devel] [Bug 566882] Re: better sparc64 support

[Natalia Portillo]

This is not a bug.

** Changed in: qemu
   Status: New = Invalid

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

Status in QEMU: Invalid

Bug description:
Need better sparc64 platform support. Currently booting debian 5.0.4 sparc is 
not possible.

On http://wiki.qemu.org/Main_Page there is no donation site available. Is it 
possible to vote for a specific purpose for donation, like purchase a cheap 
machine which help you for porting purposes?
Possible machines are sparc64 (ultra 5 and 10 and sun blade are currently cheap 
on ebay), alpha and powerpc.

[Qemu-devel] [Bug 588688] Re: Hard disk images are supporting ATAPI commands. They should fail.

[Natalia Portillo]

** Changed in: qemu
 Assignee: (unassigned) = Natalia Portillo (claunia)

** Changed in: qemu
   Status: New = In Progress

-- 
Hard disk images are supporting ATAPI commands. They should fail.
https://bugs.launchpad.net/bugs/588688
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: In Progress

Bug description:
When using a hard disk image (qcow, qcow2, vdi, vmdk, bochs), the emulated 
device can be a CD-ROM and support ATAPI commands.

These commands fails in real hard disks and these images are not prepared to 
handle optical disk formats, they should fail also.

Only images able to handle that formats (dmg, raw, host) should work with ATAPI 
commands and CD-ROM devices.

[Qemu-devel] [Bug 534973] Re: qemu-system-ppc segfaults when booting from Debian lenny netinst image

[Natalia Portillo]

I confirm this is happening in QEMU 0.12.4.

** Changed in: qemu
   Status: New = Confirmed

-- 
qemu-system-ppc segfaults when booting from Debian lenny netinst image
https://bugs.launchpad.net/bugs/534973
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: Confirmed

Bug description:
I get a segfault from qemu-system-ppc when booting from the Debian lenny 
netinst image. I'm using QEMU 0.12.3. The host machine (on which QEMU was 
compiled) is:

[ianse...@zebra]~$ uname -a
Linux zebra 2.6.31-20-generic #57-Ubuntu SMP Mon Feb 8 09:02:26 UTC 2010 x86_64 
GNU/Linux

A gdb trace is below. Any other info I can provide?

[ianse...@zebra]~$ gdb --args ~/packages/qemu/bin/qemu-system-ppc -hda 
debian-lenny-powerpc.img -cdrom debian-504-powerpc-netinst.iso -boot d
GNU gdb (GDB) 7.0-ubuntu
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from 
/home/iansealy/packages/qemu-0.12.3/bin/qemu-system-ppc...done.
(gdb) run
Starting program: /home/iansealy/packages/qemu-0.12.3/bin/qemu-system-ppc -hda 
debian-lenny-powerpc.img -cdrom debian-504-powerpc-netinst.iso -boot d
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffe77e2910 (LWP 9230)]

Program received signal SIGUSR2, User defined signal 2.
0x00553c81 in check_regs (s=0xcb6f40) at 
/home/iansealy/src/qemu-0.12.3/tcg/tcg.c:1296
1296if (ts-val_type == TEMP_VAL_REG 
(gdb) bt
#0  0x00553c81 in check_regs (s=0xcb6f40) at 
/home/iansealy/src/qemu-0.12.3/tcg/tcg.c:1296
#1  0x00555aee in tcg_gen_code_common (s=0xcb6f40, 
gen_code_buf=0x417f4db0 A\213ntH\213݁ü\005, search_pc=-1)
at /home/iansealy/src/qemu-0.12.3/tcg/tcg.c:1994
#2  0x00555b2a in tcg_gen_code (s=0xcb6f40, gen_code_buf=0x417f4db0 
A\213ntH\213݁ü\005) at /home/iansealy/src/qemu-0.12.3/tcg/tcg.c:2017
#3  0x00513f09 in cpu_ppc_gen_code (env=0xcf81d0, tb=0x71afdd00, 
gen_code_size_ptr=0x7fffdd80)
at /home/iansealy/src/qemu-0.12.3/translate-all.c:120
#4  0x0050e011 in tb_gen_code (env=0xcf81d0, pc=3223273620, cs_base=0, 
flags=0, cflags=0) at /home/iansealy/src/qemu-0.12.3/exec.c:899
#5  0x005147c2 in tb_find_slow (pc=3223273620, cs_base=0, flags=0) at 
/home/iansealy/src/qemu-0.12.3/cpu-exec.c:164
#6  0x005148c8 in tb_find_fast () at 
/home/iansealy/src/qemu-0.12.3/cpu-exec.c:185
#7  0x00514c0f in cpu_ppc_exec (env1=0xcf81d0) at 
/home/iansealy/src/qemu-0.12.3/cpu-exec.c:582
#8  0x0040c7ce in qemu_cpu_exec (env=0xcf81d0) at 
/home/iansealy/src/qemu-0.12.3/vl.c:4021
#9  0x0040c8b3 in tcg_cpu_exec () at 
/home/iansealy/src/qemu-0.12.3/vl.c:4050
#10 0x0040cb81 in main_loop () at 
/home/iansealy/src/qemu-0.12.3/vl.c:4168
#11 0x004107de in main (argc=7, argv=0x7fffe2c8, 
envp=0x7fffe308) at /home/iansealy/src/qemu-0.12.3/vl.c:6125
(gdb) c
Continuing.
[Thread 0x7fffe77e2910 (LWP 9230) exited]

Program received signal SIGSEGV, Segmentation fault.
0x00442961 in bmdma_readb (opaque=0xd278c8, addr=1793) at 
/home/iansealy/src/qemu-0.12.3/hw/ide/cmd646.c:91
91  val = pci_dev-dev.config[MRDMODE];
(gdb) bt
#0  0x00442961 in bmdma_readb (opaque=0xd278c8, addr=1793) at 
/home/iansealy/src/qemu-0.12.3/hw/ide/cmd646.c:91
#1  0x004a87b4 in ioport_read (index=0, address=1793) at ioport.c:67
#2  0x004a8c15 in cpu_inb (addr=1793) at ioport.c:216
#3  0x004261b2 in isa_mmio_readb (opaque=0x0, addr=1793) at 
/home/iansealy/src/qemu-0.12.3/hw/isa_mmio.c:56
#4  0x005728f8 in io_readb (physaddr=1793, addr=4276688641, 
retaddr=0x40ded3dd) at /home/iansealy/src/qemu-0.12.3/softmmu_template.h:68
#5  0x005729b4 in __ldb_mmu (addr=4276688641, mmu_idx=1) at 
/home/iansealy/src/qemu-0.12.3/softmmu_template.h:103
#6  0x40ded3de in ?? ()
#7  0x7fffddf0 in ?? ()
#8  0x005147d9 in tb_find_slow (pc=Cannot access memory at address 
0xfee90fbd
) at /home/iansealy/src/qemu-0.12.3/cpu-exec.c:168
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) c
Continuing.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.

[Qemu-devel] [Bug 586175] Re: Windows XP/2003 doesn't boot

[Natalia Portillo]

I don't have any problem using TCG.

Tested with Windows XP Home Update in 0.12.4 and Windows 2003 Enterprise
Server in 0.12.3.

-- 
Windows XP/2003 doesn't boot
https://bugs.launchpad.net/bugs/586175
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New
Status in Fedora: Unknown

Bug description:
Hello everyone,

my qemu doesn't boot any Windows XP/2003 installations if I try to boot the 
image.
If I boot the install cd first, it's boot manager counts down and triggers the 
boot on it's own. That's kinda stupid.

I'm using libvirt, but even by a simple
 qemu-kvm -drive file=image.img,media=disk,if=ide,boot=on
it won't boot. Qemu hangs at the message Booting from Hard Disk...

I'm using qemu-kvm-0.12.4 with SeaBIOS 0.5.1 on Gentoo (No-Multilib and AMD64). 
It's a server, that means I'm using VNC as the primary graphic output but i 
don't think it should be an issue.

Re: [Qemu-devel] Inquiry about qemu for Motorola 68360

[Natalia Portillo]

While QEMU does indeed works for x86 Windows, current QEMU's m68k architecture 
does not included that specific Motorola chip.

El 23/05/2010, a las 05:28, hadi motamedi escribió:

 Dear All
 Do you have qemu emulator for Motorola 68360 emulation on x86 Windows 
 platform?
 Thank you in advance
 

Re: [Qemu-devel] Inquiry about qemu for Motorola 68360

[Natalia Portillo]

qemu-system-m68k -cpu ?

El 23/05/2010, a las 08:47, hadi motamedi escribió:

 
 
 
 While QEMU does indeed works for x86 Windows, current QEMU's m68k 
 architecture does not included that specific Motorola chip.
 Thank you for your reply. Can you please let me know which Motorola chips are 
 being currently supported?
 
 

Re: [Qemu-devel] Problems changing dvdrom iso during execution

[Natalia Portillo]

Have you tried any other operating system or kernel revision?

I have just changed the iso with change ide1-cd0 command in Windows XP Upgrade 
(it asks to insert a previous Windows CD and then reinsert the XP one) without 
any kind of problem, in QEMU 0.12.4.

El 21/05/2010, a las 20:42, Adnan Khaleel escribió:

 Tried that, still the same. 
 
 My current workaround is to mount all the DVD iso files as separate hard 
 disks and mount those. This worked but its a workaround at best. Not sure 
 what I'd do if ever had to access more then 3 dvd's at a time - which I doubt 
 should happen anytime soon.
 
 
 From: David S. Ahern [mailto:daah...@cisco.com]
 To: ad...@khaleel.us
 Cc: Qemu-devel@nongnu.org
 Sent: Fri, 21 May 2010 13:47:00 -0500
 Subject: Re: [Qemu-devel] Problems changing dvdrom iso during execution
 
 
 
 On 05/21/2010 10:10 AM, Adnan Khaleel wrote:
  So do you have any idea whats causing the problem? Is there any other
  way I can mount a dvd in Qemu?
  
  Adnan
 
 have you tried ejecting the cd in the guest before changing the file in
 the monitor?
 
 David

Re: [Qemu-devel] Problems changing dvdrom iso during execution

[Natalia Portillo]

Would you please test on SLES11 with another kernel revision?

Possible, with various one, both lower and upper?

El 22/05/2010, a las 00:45, Adnan Khaleel escribió:

 It works in ubuntu 9.10. When I mount the CDROM the first time it mounts 
 fine. After I change the iso file and mount, it spits out a bunch of messages 
 but it does mount the drive. I think this problem might be specific to 
 sles11. 
 
 
 
 
 
 On May 21, 2010, at 5:37 PM, Natalia Portillo clau...@claunia.com wrote:
 
 Have you tried any other operating system or kernel revision?
 
 I have just changed the iso with change ide1-cd0 command in Windows XP 
 Upgrade (it asks to insert a previous Windows CD and then reinsert the XP 
 one) without any kind of problem, in QEMU 0.12.4.
 
 El 21/05/2010, a las 20:42, Adnan Khaleel escribió:
 
 Tried that, still the same. 
 
 My current workaround is to mount all the DVD iso files as separate hard 
 disks and mount those. This worked but its a workaround at best. Not sure 
 what I'd do if ever had to access more then 3 dvd's at a time - which I 
 doubt should happen anytime soon.
 
 
 From: David S. Ahern [mailto:daah...@cisco.com]
 To: ad...@khaleel.us
 Cc: Qemu-devel@nongnu.org
 Sent: Fri, 21 May 2010 13:47:00 -0500
 Subject: Re: [Qemu-devel] Problems changing dvdrom iso during execution
 
 
 
 On 05/21/2010 10:10 AM, Adnan Khaleel wrote:
  So do you have any idea whats causing the problem? Is there any other
  way I can mount a dvd in Qemu?
  
  Adnan
 
 have you tried ejecting the cd in the guest before changing the file in
 the monitor?
 
 David
 

Re: [Qemu-devel] [RFC] Bug Day - June 1st, 2010

[Natalia Portillo]

Hi,

 There have been reports of several legacy OSes being unable to install
 or boot in the newer qemu while working in the older one.  They're
 probably not in the OS Support List though.  Are they effectively
 uninteresting for the purpose of the 0.13 release?
 
 
 For the Bug Day, anything is interesting IMHO.  My main interest is to get as 
 many people involved in testing and bug fixing as possible.  If folks are 
 interested in testing specific things like unusual or older OSes, I'm happy 
 to see it!

Well the idea is not only about unusual or older OSes.
That list detected bugs and regressions appearing in usual and new OSes (for 
example the infamous SeaBIOS problem with Windows 9x and mouse also affects 
freshly and new OpenSuSE Linux 11.2).

Re: [Qemu-devel] [RFC] Bug Day - June 1st, 2010

[Natalia Portillo]

Hi,

 There are a couple of.
 
 The majority of them are because SeaBIOS not behaving like real hardware 
 should and must do.
 
 If you know any OS that's not in the OS Support List and is broken please 
 commit.
 
 If something is broken, please file a bug against it.  The OS Support List is 
 a very useful resource but we still need bugs to actually work on fixing the 
 problems.
The OS Support List clearly specifies that in case of a fail, bug, or non 
working case, a bug should be filled, so I think, using the OS Support List 
includes bugs in Launchpad, however the reverse is not true.

[Qemu-devel] [Bug 521994] Re: Windows 98 doesn't detect mouse on qemu and SeaBIOS.

[Natalia Portillo]

I confirm this same bug appears in Windows 95, Windows Me and several
XFree86 and X.Org versions, as well as DOS based Microsoft Mouse
drivers.

-- 
Windows 98 doesn't detect mouse on qemu and SeaBIOS.
https://bugs.launchpad.net/bugs/521994
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: Confirmed

Bug description:
A windows 98 guest doesn't detect mouse on recent qemu. I bisected and the 
result is

fd646122418ecefcde228d43821d07da79dd99bb is the first bad commit
commit fd646122418ecefcde228d43821d07da79dd99bb
Author: Anthony Liguori aligu...@us.ibm.com
Date:   Fri Oct 30 09:06:09 2009 -0500

Switch pc bios from pc-bios to seabios

SeaBIOS is a port of pc-bios to GCC.  Besides using a more modern tool 
chain,
SeaBIOS introduces a number of new features including PMM support, better
BEV and BCV support, and better PnP support.

Signed-off-by: Anthony Liguori aligu...@us.ibm.com

I got following messages with DEBUG_BIOS

Start bios (version 0.5.1-20100111_132716-squirrel.codemonkey.ws)
Ram Size=0x0800 (0x high)
CPU Mhz=2271
Found 1 cpu(s) max supported 1 cpu(s)
PIIX3/PIIX4 init: elcr=00 0c
PCI: bus=0 devfn=0x00: vendor_id=0x8086 device_id=0x1237
PCI: bus=0 devfn=0x08: vendor_id=0x8086 device_id=0x7000
PCI: bus=0 devfn=0x09: vendor_id=0x8086 device_id=0x7010
region 4: 0xc000
PCI: bus=0 devfn=0x0b: vendor_id=0x8086 device_id=0x7113
PCI: bus=0 devfn=0x10: vendor_id=0x1013 device_id=0x00b8
region 0: 0xe000
region 1: 0xe200
region 6: 0xe201
MP table addr=0x000f89b0 MPC table addr=0x000f89c0 size=224
SMBIOS ptr=0x000f8990 table=0x07fffef0
ACPI tables: RSDP=0x000f8960 RSDT=0x07ffde30
Scan for VGA option rom
Running option rom at c000:0003
VGABios $Id$
Turning on vga console
Starting SeaBIOS (version 0.5.1-20100111_132716-squirrel.codemonkey.ws)

Found 0 lpt ports
Found 0 serial ports
ATA controller 0 at 1f0/3f4/c000 (irq 14 dev 9)
ATA controller 1 at 170/374/c008 (irq 15 dev 9)
ps2 irq but no data.
ata0-0: PCHS=812/16/63 translation=none LCHS=812/16/63
ata0-1: PCHS=1152/16/56 translation=none LCHS=1024/16/56
ps2_recvbyte timeout
keyboard initialized
Scan for option roms
Returned 53248 bytes of ZoneHigh
e820 map has 6 items:
  0:  - 0009f400 = 1
  1: 0009f400 - 000a = 2
  2: 000f - 0010 = 2
  3: 0010 - 07ffd000 = 1
  4: 07ffd000 - 0800 = 2
  5: fffc - 0001 = 2
enter handle_19:
  NULL
Booting from Hard Disk...
Booting from :7c00
pnp call arg1=5
pnp call arg1=0
ps2_recvbyte timeout
ps2_recvbyte timeout
ps2_recvbyte timeout
ps2_recvbyte timeout

Re: [Qemu-devel] [RFC] Bug Day - June 1st, 2010

[Natalia Portillo]

Hi,

 - We'll try to migrate as many confirmable bugs from the Source Forge tracker 
 to Launchpad.
I think that part of the bug day should also include retesting OSes that appear 
in OS Support List as having bug and confirming if the bug is still present and 
if it's in Launchpad or not.

Re: [Qemu-devel] [RFC] Bug Day - June 1st, 2010

[Natalia Portillo]

El 19/05/2010, a las 02:45, Jamie Lokier escribió:

 Natalia Portillo wrote:
 Hi,
 
 - We'll try to migrate as many confirmable bugs from the Source Forge 
 tracker to Launchpad.
 I think that part of the bug day should also include retesting OSes that 
 appear in OS Support List as having bug and confirming if the bug is still 
 present and if it's in Launchpad or not.
 
 There have been reports of several legacy OSes being unable to install
 or boot in the newer qemu while working in the older one.  They're
 probably not in the OS Support List though.  Are they effectively
 uninteresting for the purpose of the 0.13 release?
There are a couple of.

The majority of them are because SeaBIOS not behaving like real hardware should 
and must do.

If you know any OS that's not in the OS Support List and is broken please 
commit.

 Unfortunately I doubt I will have time to participate in the Bug Day.
 
 Thanks,
 -- Jamie
 

Re: [Qemu-devel] Re: Webcam solution for QEMU

[Natalia Portillo]

Hello Arnon,
Hola Albert,

Wouldn't be easier to implement a custom video capture device?
You can always emulate a simple one, like (to say) OV511 webcam, and feed that 
emulated device with video taken from any V4L2/DirectShow/BDA supported device 
(real host webcam).

I think this way, timing issues will not arise, and will support indeed any 
webcam or video capture device (tuners) past, present, and future.

Of course not to say video will come with a little lag to the guest but that 
lag will be a lot less than the timing lag connecting host-guest devices in a 
more directly way.

That's just my 2 euro cent.

Natalia Portillo

El 09/05/2010, a las 15:59, Arnon Gilboa escribió:

 Hello Albert,
 
 First of all, I have done nothing in the qemu project for more than two years 
 now. My last contribution to qemu were some usb 1.1 uhci/ohci patches for 
 very basic support of webcams and other isochronous devices (accepted), and a 
 preliminary patch for usb 2.0 ehci (rejected due to high res timer 
 requirement). If I remember it correctly the usb 1.1 worked reasonably on 
 several webcams (mostly old ones, usb 1.1) and with low frames-per-second 
 rate.
 
 I guess since then there were some significant changes in the qemu usb code, 
 so I cannot really answer your questions. Anyway, in the following week or 
 two I will try to catch up with qemu current usb status and update you if I 
 have any insight.
 
 Forwarding your message to qemu-devel, so you may get some smarter answers.
 Best Regards,
 Arnon
 
 Albert Orriols Puig wrote:
 
 Hi Arnon,
 
 I'm Albert Orriols-Puig, an assistant professor at La Salle -- Ramon Llull 
 University (in Spain). Recently, we have started using a virtualization 
 solution based on Open Suse + KVM + QEMU. Currently we have some machines 
 that use this software and host two Windows operating systems: WinXP and 
 Win7. The machines work quite well, that is, we have a quite good 
 performance in both guest OS.
 
 One of the key aspects that we need is to give support to webcams, since our 
 users usually employ skype or similar software to make phone calls. However, 
 we have realized that QEMU does not give direct support for webcams. We have 
 searched for different patches, and found yours, which enables transfers in 
 redirected host USB devices.
 
 We have tried your patch in a machine with the two aforementioned hosts and 
 a couple of logitech webcams. We have realized that the guest OS detected 
 the existence of a webcam, but could not show the images of these webcams. 
 In the WinXP system, the image was in black. In the Win7, he detected the 
 webcam but didn't allow using it since an error popped up indicating that 
 the webcam was blocked by another application. We have searched for other 
 patches that may help us, but we were not successful.
 
 So, I'm contacting you to ask you a couple of questions. First, in the patch 
 notes it is mentioned that the system worked for some USB 1.1 and USB 2.0 
 cameras on XP. Do you remember some of the specific webcams that you tried 
 and worked? If so, could you tell me the models and any tweak you needed to 
 do in the guest OS side to make them work? It would be great if we could 
 make this work even if we have to adapt to particular webcams.
 
 The second question is about the state of the progress on the support of 
 devices in QEMU. I've seen in some forums that there are some people 
 (including you ;)) working on QEMU to give support to different devices. Do 
 you know if there will be new releases to support USB devices in a short 
 time? We are specially interested in webcams, but we would also need other 
 devices as well.
 
 Let me thank you in advance for the time spend on reading this email!
 
 
 Best,
 
 Albert Orriols-Puig, PhD
 La Salle -- Universitat Ramon Llull
 email: aorri...@gmail.com
 web: http://www.albertorriols.net http://www.albertorriols.net/
 
 
 
 
 
 

Re: [Qemu-devel] [ANNOUNCE] Release 0.12.4 of QEMU

[Natalia Portillo]

El 07/05/2010, a las 14:54, Anthony Liguori escribió:

 The QEMU team is pleased to announce the availability of the 0.12.4
 release.  This is a stable release of the 0.12 series and only contains bug 
 fixes since 0.12.3.
 
 It can be downloaded from Savannah at:
 
 http://download.savannah.gnu.org/releases/qemu/qemu-0.12.4.tar.gz

Added to OS Support List

Re: [Qemu-devel] QEMU OS support site

[Natalia Portillo]

That's because I was debugging some code, but it should be silent now.

Sorry for the inconveniences it may have caused you.

El 17/04/2010, a las 09:05, Andrea Canciani escribió:

 On the website http://www.claunia.com/qemu/ the pages contain log
 information from php complaining that
 
 Deprecated: Function split() is deprecated in
 /Users/claunia/Sites/www.claunia.com/qemu/include/query.php on line
 88
 
 Even if the content is actually available, this makes the page much
 less readable
 http://it.php.net/manual/en/function.split.php contains suggestions
 for replacing this function with alternatives (which in some cases
 might even be faster).
 Keep up the good job and thank you
 Andrea Canciani
 
 

Re: [Qemu-devel] GSoC projects about AHCI and S3 Trio

[Natalia Portillo]

Hi,

El 30/03/2010, a las 01:55, Alexander Graf escribió:


Hi Roland,


On 30.03.2010, at 01:52, Roland Elek wrote:


Dear Qemu developers,

I am a university student from Hungary interested in contributing  
to Qemu through Google Summer of Code.
I am interested in emulation, and two projects from the ideas page  
in particular. One of them is AHCI emulation.
Can I kindly ask you what were the hardest points that made the  
project get a high difficulty rating, so that I
could determine whether to apply for it or not? At a first glance,  
I think that AHCI code from VirtualBox OSE

would be a good place to start. What do you think?


I looked at the AHCI code from vbox some time ago and deemed it  
unreadable. It's probably easier to go with the spec and implement  
it from there.


Nevertheless, if you're good at reading C++ that code might come in  
handy. Just don't expect to be able to take any of it over to  
Qemu :-). Coding styles between the two projects differ a lot.


The hard part is that it's a reasonably complex piece of hardware  
that needs to be emulated. The high ranking was basically to show  
people that we need someone with serious skills and eagerness to  
work on it :-). If you're a quick learner the skills part shouldn't  
be too hard. The eagerness and ambition part is the really important  
one.


A quick search through the mailing list archives showed that the  
other topic, the S3 Trio, has been around for
some time now. DOSBox has support for it, and is open source, so I  
think we could build upon that.


Yep. On IRC there's also someone called jai who wanted to look  
into that as well. Mind to coordinate with him?




I'm the one that proposed the S3 Trio/Virge idea.
The greatest thing about this card is that almost every operating  
system has or had a driver for it, and has also been used in non-x86  
machines extensively.


If you need testing or getting information from a real working card (I  
have a couple of them, all for x86 unfortuneately) just mail me.


Regards,
Natalia Portillo

Re: [Qemu-devel] BeOS R5 boot failure

[Natalia Portillo]

El 23/03/2010, a las 10:07, François Revol escribió:

I've been trying for some time to get an old BeOS R5 image to boot,  
but

it seems it doesn't like QEMU's IDE controller:

Trying /dev/disk/ide/ata/0/master/0/raw
IDE PCI -- find_devices: intel 82371SB (PIIX3) chipset
IDE PCI -- find_devices: controller supports DMA
IDE ATA -- configure_device: selected dma mode bad,
disable dma for this device
IDE ATA -- get_bios_driveinfo: ata/0/0 match bios drive 0x80
found boot device: /dev/disk/ide/ata/0/master/0/raw
IDE PCI -- find_devices: intel 82371SB (PIIX3) chipset
IDE PCI -- find_devices: controller supports DMA
IDE ATA -- configure_device: selected dma mode bad,
disable dma for this device
IDE ATA -- get_bios_driveinfo: ata/0/0 match bios drive 0x80
IDE PCI -- find_devices: intel 82371SB (PIIX3) chipset
IDE PCI -- find_devices: controller supports DMA
IDE ATA -- configure_device: selected dma mode bad,
disable dma for this device
IDE ATA -- get_bios_driveinfo: ata/0/0 match bios drive 0x80
warning: fs blocks fa000 larger than device blocks 0
bad super block
KERNEL PANIC: was unable to mount /dev/disk/ide/ata/0/master/0/0_0  
type

bfs on /boot


Anyone has a clue ?


It's a known bug but nobody knows or has time to apply a solution.

Bochs had the same bug and corrected it about November 2009, maybe  
checking their commit will make light to correct QEMU.



It seems VirtualBox has the same issue. Older versions (ZETA) seem to
work fine, but they have a totally different IDE subsystem.


VirtualPC had the same fail also.
Zeta however is not an older version but a newer one.
Considering Zeta is a non-authorized hack, who knows what have they  
changed.

The bug is present on BeOS R3, R4, R4.5 and R5.


The warning suggest the block device is seen as having a size of 0,
though oddly it seems to be able to read from it since it gets the  
size

of the BFS in the superblock...

I've rebuilt with DEBUG_IDE and put a log here:
http://revolf.free.fr/beos/qemu-beosr5-bad-ide-20100323.log

Note disabling DMA in the boot menu (space bar, Select safe mode
options) doesn't help either...
Use F1 at boot to get serial output.

The image is available here:
http://bebits.com/app/2680
(BeOS R5 Personal Edition for Linux)

François.

[Qemu-devel] PS/2 mouse emulation problems

[Natalia Portillo]

Ok so in resume we have the following PS/2 mouse bugs:

NeXTStep and OpenStep PS/2 driver receives no movement at all from the  
mouse (Darwin PS/2 driver seems to be made from scratch so no helpful  
here).

MS-DOS Mouse driver hangs the whole machine.
Windows Me Setup mouse driver receives no movement at all from the  
mouse.
Old XFree86 PS/2 mouse driver receives no movement at all from  
standard protocols (PS/2, IMPS/2) or random movements (Microsoft).

Hydrogen OS mouse driver does not work.

While the NeXTStep PS/2 bug is known from QEMU 0.7.0 (which used Bochs  
BIOS), the other ones are new (as far as I know) so they may be or may  
not be caused by SeaBIOS.

Re: [Qemu-devel] SeaBIOS error with Nextstep bootloader

[Natalia Portillo]

Hi,


These floppy images are failing because they spin waiting for a
keypress with irqs disabled, and SeaBIOS doesn't enable irqs in the
handlers being called (same issue seen on d090723b.zip image
reported by Roy).

I've put a test image with a workaround for the issue at:

http://linuxtogo.org/~kevin/SeaBIOS/test/bios.bin-0.5.1-debug-20100311

See below for the patch I used - I'm still researching it, but the
image can be used for testing.


I tested only with NeXTStep 3.3 booting from hard disk and it worked.

I'll test the rest today but considering the PS/2 mouse emulation is  
not working (there is a bug in it that prevents NeXTStep PS/2 mouse  
driver and old X11 PS/2 mouse drivers working).


But for now, it boots up to the GUI flawlessly.

Re: [Qemu-devel] Summer of Code 2010

[Natalia Portillo]

I've expanded my suggestions to the new template with description :p

El 10/03/2010, a las 20:11, Luiz Capitulino escribió:


On Tue, 9 Mar 2010 15:55:39 +
Natalia Portillo clau...@claunia.com wrote:


http://wiki.qemu.org/Google_Summer_of_Code_2010

This is a start.


Thanks a lot Natalia, I've edited the whole page and created a common
template for all projects.

I will talk more about this in a separate email.

Re: [Qemu-devel] Regression: more 0.12 regression (SeaBIOS related?)

[Natalia Portillo]

*NeXTStep/OpenStep bootloader hangs (Darwin not tested but may be also).
*ScanDisk does not receive keypresses (any at all).
*Windows Me's DOS Microsoft Mouse driver hangs the machine.
*PS/2 mouse not working under Windows Me installation.
*Windows Me blue screens after installation.
A good couple of XFree86 versions do not work as expected with PS/2  
mouse (mouse moves randomly, clicks randomly or is dead at all),  
tested with all PS/2 protocol variants.
qemu-system-sparc64 does a segment violation if you enable Realtek  
RTL8139.


These of course do not have anything to do (but the scandisk one) with  
SeaBIOS, however I marked with * the ones that can be a BIOS conflict.


El 08/03/2010, a las 02:04, Roy Tam escribió:


Hi all,

I found some regression bugs that seems relate to SeaBIOS and I hope
we can add back booting with Bochs BIOS in git so that we can further
testing that the bug is in SeaBIOS or in QEMU 0.12.
Following list is the regression that I encountered and which works  
in 0.11.1:


- Windows NT 3.51/4.0 freezes when booting to first stage setup, after
switch screen to 80x50 text mode
- freeze after pressing Enter when booting PC/MS-DOS  1.10 - 1.25
- freeze when booting Enhanced DR-DOS 7.01.08 WIP (23.7.2009) (
http://www.drdosprojects.de/cgi-bin/download.cgi/d090723b.zip )
- can't type correctly in GW-BASIC from DOS 2.0 - 3.31
- keyboard input is ignored when booting Korean edition of MS-DOS 6.20
- can't type correctly in FreeDOS/V (Ver 0138,
http://homepage1.nifty.com/bible/dos/fdos0138.lzh ), getting Illegal
Instruction error when you type something in short period.
- after the termination of qbasic run session, you can't press a key
to go back to editor in press a key to continue prompt, you have to
type something not just press a key. When I modify the program and
press Shift-F5 to start the program, after execution and then exit
qbasic, Shift key modifier still activating, instead of deactivated
after I release Shift key.

If you have another (seems to be SeaBIOS related) 0.12 regression,
please post it here.

Best regards,
Roy

Re: [Qemu-devel] Summer of Code 2010

[Natalia Portillo]

Nice :-). I'd love to mentor. We have a lot of open things to do in  
the PPC space, but I could just as well use help with finally  
getting x86 Mac OS X guest support upstream ;-).


So who's sending out the actual project application? I'd feel odd if  
I'd do it.


I hope that with native EFI and Mac's memory space, not just a PCI PC  
booting a hacked OS X (we do not want Apple to see QEMU as a piracy  
movement, watching what happened to Psystar)

Re: [Qemu-devel] Summer of Code 2010

[Natalia Portillo]

Qemu towards what xnu expects -- that's what I called Mac's memory  
space.


Of course is not only memory, the SMU, TPM module, anything it will  
search for without hacking.


(If you need testing comment me I have every x86 versions that is  
outside of Apple and nVidia, and hardware access to all in-sell  
Macintosh models)


El 09/03/2010, a las 15:46, Alexander Graf escribió:



On 09.03.2010, at 16:44, Natalia Portillo wrote:



Nice :-). I'd love to mentor. We have a lot of open things to do  
in the PPC space, but I could just as well use help with finally  
getting x86 Mac OS X guest support upstream ;-).


So who's sending out the actual project application? I'd feel odd  
if I'd do it.


I hope that with native EFI and Mac's memory space, not just a PCI  
PC booting a hacked OS X (we do not want Apple to see QEMU as a  
piracy movement, watching what happened to Psystar)


I was talking about my work that tried to model Qemu towards what  
xnu expects. There's quite some work left to do to get it upstream,  
slowly moving us towards a real -M mac machine type. Using EFI or  
not is the least of our problems IMHO.


Hacked OS X version should work already, but I don't care about those.


Alex

Re: [Qemu-devel] Summer of Code 2010

[Natalia Portillo]

http://wiki.qemu.org/Google_Summer_of_Code_2010

This is a start.

El 09/03/2010, a las 14:14, Anthony Liguori escribió:


On 03/08/2010 02:20 PM, Luiz Capitulino wrote:

 Hi there,

 Google has this wonderful program called Summer of Code, in which  
open source
projects like ours, suggest possible projects and provide mentors  
to help

selected students to do them.

 It's a great opportunity for students to get in touch with open  
source
development, also good for us to get some projects done and more  
people

involved (students are paid too, btw).

 The dead-line is a bit short: next friday (March, 12), more  
information

in the program's page:

http://socghop.appspot.com/



I'd suggest creating a page on the qemu.org wiki and start  
collecting ideas.  I'd strongly suggest that all ideas are  
constructed like a release feature and have an appropriate wiki page.


I think the key to success with a student project is to have a wide  
range of success criteria.   If people post ideas to a common wiki  
page, we can review them and come up with a set of suggested items.


Regards,

Anthony Liguori

 I didn't read it fully yet, but I _guess_ the most important is to  
come

up with project ideas and mentors. Everything should be in a wiki.

PS: I have participated as a student some years ago, didn't produce  
anything

useful, but was a great experience.

Re: [Qemu-devel] Summer of Code 2010

[Natalia Portillo]

El 09/03/2010, a las 15:56, Alexander Graf escribió:



On 09.03.2010, at 16:50, Natalia Portillo wrote:

Qemu towards what xnu expects -- that's what I called Mac's  
memory space.


Of course is not only memory, the SMU, TPM module, anything it will  
search for without hacking.


(If you need testing comment me I have every x86 versions that is  
outside of Apple and nVidia, and hardware access to all in-sell  
Macintosh models)


No worries - I'd rather need someone implementing an ICH-7 PCI  
bridge, LPC and AHCI controller :-).


I'd love to know how to do that.

Documenting QEMU's hardware model may be also a good idea for  
GSoC2010, as most complains about contributing QEMU are precisely  
that, having to study the whole code to know how to make anything new.

[Qemu-devel] Most PowerPC machines not working.

[Natalia Portillo]

Mac OS X 0.12.2 following:

zeus:Apple_Service_Diagnostic claunia$ qemu-system-ppc -M prep
qemu: hardware error: PowerPC 601 / 620 / 970 need a 1MB BIOS

CPU #0:
NIP    LR  CTR  XER 
MSR  HID0   HF  idx 0
TB   DECR 
GPR00     

GPR04     

GPR08     

GPR12     

GPR16     

GPR20     

GPR24     

GPR28     


CR   [ -  -  -  -  -  -  -  -  ] RES 
FPR00     

FPR04     

FPR08     

FPR12     

FPR16     

FPR20     

FPR24     

FPR28     


FPSCR 
SRR0  SRR1  SDR1 
Abort trap
zeus:Apple_Service_Diagnostic claunia$ qemu-system-ppc -M mac99
zeus:Apple_Service_Diagnostic claunia$ qemu-system-ppc -M g3beige
zeus:Apple_Service_Diagnostic claunia$ qemu-system-ppc -M ref405ep
ref405ep_init: register cpu
ppc4xx_opba_init: offset ef600600
ppc405_gpio_init: offset ef600700
ppc4xx_gpt_init: offset ef60
ref405ep_init: register SRAM at offset 08001000
ref405ep_init: register BIOS
Load BIOS from file
qemu: could not load PowerPC bios 'ppc405_rom.bin'
zeus:Apple_Service_Diagnostic claunia$ qemu-system-ppc -M taihu
taihu_405ep_init: register cpu
ppc4xx_opba_init: offset ef600600
ppc405_gpio_init: offset ef600700
ppc4xx_gpt_init: offset ef60
taihu_405ep_init: register BIOS
Load BIOS from file
qemu: could not load PowerPC bios 'ppc405_rom.bin'
zeus:Apple_Service_Diagnostic claunia$ qemu-system-ppc -M bamboo
Truncating memory to 128 MiB to fit SDRAM controller limits.
qemu: fatal: Trying to execute code outside RAM or ROM at 0x

NIP    LR  CTR  XER 
MSR  HID0 0300  HF  idx 0
Segmentation fault
zeus:Apple_Service_Diagnostic claunia$ qemu-system-ppc -M mpc8544ds
qemu: fatal: BookE FSL MMU model not implemented

NIP    LR  CTR  XER 
MSR  HID0   HF  idx 0
Segmentation fault

Linux 0.12.3 following:
clau...@hades /mnt/datos/Operating Systems/Incoming $ qemu-system-ppc - 
M prep

qemu: hardware error: PowerPC 601 / 620 / 970 need a 1MB BIOS

CPU #0:
NIP    LR  CTR  XER 
MSR  HID0   HF  idx 0
TB   DECR 
GPR00     

GPR04     

GPR08     

GPR12     

GPR16     

GPR20     

GPR24     

GPR28     


CR   [ -  -  -  -  -  -  -  -  ] RES 
FPR00     

FPR04     

FPR08     

FPR12     

FPR16     

FPR20     

FPR24     

FPR28     


FPSCR 
SRR0  SRR1  SDR1 
Abortado
clau...@hades /mnt/datos/Operating Systems/Incoming $ qemu-system-ppc - 
M mac99
clau...@hades /mnt/datos/Operating Systems/Incoming $ qemu-system-ppc - 
M g3beige
clau...@hades /mnt/datos/Operating Systems/Incoming $ qemu-system-ppc - 
M ref405ep

ref405ep_init: register cpu
ppc4xx_opba_init: offset 

Re: [Qemu-devel] SeaBIOS error with Nextstep bootloader

[Natalia Portillo]

No, sorry.

NeXTStep and OpenStep are the precursors of Mac OS X and are retail  
(abandoned but).


The source code of the bootloader evolved in the currently available  
at http://opensource.apple.com but who knows how much it changed.


However I can test it with any you want, and if you want to add me to  
instant messaging you could guide me in the debugging.


Regards

El 28/02/2010, a las 19:51, Kevin O'Connor escribió:


On Mon, Feb 22, 2010 at 02:56:22AM +, Natalia Portillo wrote:

Ok, QEMU is absolutely unable to boot nextstep/openstep, while using
SeaBIOS.

Changing to old Bochs BIOS, makes it work, however no video is
output (until NeXT starts using VESA).


Hi Natalia,

Is nextstep/openstep something that can be freely downloaded?

It would help if you can extract some SeaBIOS debugging info.  I've
uploaded a SeaBIOS image with the debug level set to 8 and serial
debugging enabled.  It is at:

http://linuxtogo.org/~kevin/SeaBIOS/test/bios.bin-0.5.1-debug-20100228

Can you use this image with qemu, add -serial file:mylog to qemu's
command line, and forward the resulting mylog file back?

Also, please include the full qemu command line that you used.

Thanks,
-Kevin

Re: [Qemu-devel] [ANNOUNCE] Release 0.12.2 of QEMU

[Natalia Portillo]

Added to Official OS Support List.

El 25/02/2010, a las 22:30, Anthony Liguori escribió:


The QEMU team is pleased to announce the availability of the 0.12.3
release.  This is a stable release of the 0.12 series and only  
contains bug fixes since 0.12.2.


It can be downloaded from Savannah at:

http://download.savannah.gnu.org/releases/qemu/qemu-0.12.3.tar.gz

On behalf of the QEMU team, I'd like to thank everyone who contributed
to make this release happen!

 - kvm: Fix eflags corruption in kvm mode (Jan Kiszka)
 - qcow2: Fix access after end of array (Kevin Wolf)
 - ide save/restore pio/atapi cmd transfer fields and io buffer  
(Marcelo Tosatti)
 - net: Monitor command set_link finds only VLAN clients, fix  
(Markus Armbruster)

 - net: info network shows only VLAN clients, fix (Markus Armbruster)
 - net: net_check_clients() checks only VLAN clients, fix (Markus  
Armbruster)
 - net: Fix bogus Warning: vlan 0 with no nics with -device  
(Markus Armbruster)
 - net: net_check_clients() runs too early to see -device, fix  
(Markus Armbruster)

 - net: Remove unused net_client_uninit() (Markus Armbruster)
 - don't dereference NULL after failed strdup (Jim Meyering)
 - virtio-net: fix network stall under load (Tom Lendacky)
 - json: fix PRId64 on Win32 (Roy Tam)
 - fix inet_parse typo (Marcelo Tosatti)
 - iothread: fix vcpu stop with smp tcg (Marcelo Tosatti)
 - segfault due to buffer overrun in usb-serial (David S. Ahern)
 - qcow2: Fix signedness bugs (Kevin Wolf)
 - Do not ignore error, if open file failed (-serial /dev/tty)  
(Evgeniy Dushistov)
 - pc-bios: update to newer version of (stable) seabios (Anthony  
Liguori)

 - target-mips: fix ROTR and DROTR by zero (Aurelien Jarno)
 - target-mips: fix CpU exception for coprocessor 0 (Nathan Froyd)
 - tcg/mips: fix crash in tcg_out_qemu_ld() (Aurelien Jarno)
 - target-mips: don't call cpu_loop_exit() from helper.c (Aurelien  
Jarno)
 - virtio-blk: Fix error cases which ignored rerror/werror (Kevin  
Wolf)

 - virtio-blk: Fix restart after read error (Kevin Wolf)
 - virtio_blk: Factor virtio_blk_handle_request out (Kevin Wolf)
 - cirrus: Properly re-register cirrus_linear_io_addr on vram unmap  
(Jan Kiszka)

 - qcow2: Don't ignore qcow2_alloc_clusters return value (Kevin Wolf)
 - qcow2: Don't ignore update_refcount return value (Kevin Wolf)
 - qcow2: Allow updating no refcounts (Kevin Wolf)
 - qcow2: Improve error handling in update_refcount (Kevin Wolf)
 - qcow2: Fix error handling in grow_refcount_table (Kevin Wolf)
 - block: Return original error codes in bdrv_pread/write (Kevin Wolf)
 - qcow2: Return 0/-errno in qcow2_alloc_cluster_offset (Kevin Wolf)
 - qcow2: Return 0/-errno in get_cluster_table (Kevin Wolf)
 - qcow2: Fix error handling in qcow_save_vmstate (Kevin Wolf)
 - qcow2: Fix error handling in qcow2_grow_l1_table (Kevin Wolf)
 - win32/sdl: Fix toggle full screen (Herve Poussineau)
 - win32: pair qemu_memalign() with qemu_vfree() (Herve Poussineau)
 - vnc_refresh: calling vnc_update_client might free vs (Stefano  
Stabellini)

 - Musicpal: Fix descriptor walk in eth_send (Jan Kiszka)
 - Musicpal: Fix wm8750 I2C address (Jan Kiszka)
 - fix savevm command without id or tag (Marcelo Tosatti)
 - reduce number of reinjects on ACK (Gleb Natapov)
 - QMP: Fix asynchronous events delivery (Luiz Capitulino)
 - Documentation: Add missing documentation for qdev related command  
line options (Stefan Weil)

 - pc: add driver version compat properties (Gerd Hoffmann)
 - scsi: device version property (Gerd Hoffmann)
 - ide: device version property (Gerd Hoffmann)
 - QMP: Emit asynchronous events on all QMP monitors (Adam Litke)
 - Fix QEMU_WARN_UNUSED_RESULT (Kevin Wolf)

[Qemu-devel] Incorrect screenshot when text mode under Linux.

[Natalia Portillo]

When the guest is in text mode only the first line is shown.

Tested under KDE4 + NVidia binary drivers + Linux 2.6.31-gentoo-r1  
(x86-64) using QEMU 0.12.2.


Attached example:
inline: 2.png


It should be like (took in Mac OS X 10.6.2 using QEMU 0.12.2):
inline: 4.png

[Qemu-devel] Re: Severe data corruption in QEMU under Mac OS X

[Natalia Portillo]

What I've found is that the PPMs are still opened while QEMU is not,  
however the PPM corruption only happens on network shares, while the  
QCOW2 happens also in local disks.


zeus:feo claunia$ ps aux | grep -i qemu
claunia  80680   0,7  0,0  2435032472 s002  R+9:16PM   0:00.00  
grep -i qemu

zeus:feo claunia$ rm 3.ppm
rm: 3.ppm: Resource busy
zeus:feo claunia$ sudo lsof | grep 3.ppm
Password:

El 24/02/2010, a las 09:04, Paolo Bonzini escribió:


On 02/24/2010 02:36 AM, Natalia Portillo wrote:

10% of saved PPMs are corrupted or empty,


This seems easier to bisect, can you do that?

Thanks!

Paolo

[Qemu-devel] Severe data corruption in QEMU under Mac OS X

[Natalia Portillo]

10% of saved PPMs are corrupted or empty, hard disk images are  
randomly corrupted.


Tested under Mac OS X 10.6.1 (x86-64) and under Linux 2.6.31-gentoo-r1  
(x86-64) using QEMU 0.12.2 (manually compiled both)


No other program corrupts files (cp, Finder, Mail, TextEdit), neither  
they are corrupted when working on local hard disks.
There is no hardware error and testing have been done over an AFP  
share (shared by netatalk in the Linux test machine) as well as under  
local hard disk (Intel AHCI SATA)


When installing Nexenta OS Alpha 6 over the AFP share, the installer  
ends the copy at 5%, letting the QCOW2 image at 462 mebibytes, and  
restarting it shows corrupt on boot sector (GRUB unable to load).
When instaling in local hard disk, the installer ends at 100%, and the  
QCOW2 image is 1.7 gibibytes (1868300288 bytes). Bootloader is unable  
to find superblock.
When installing in Linux, using same QEMU command line and same  
installer choices (what should give the same QCOW2 image), the QCOW2  
image is 1.8 gibibytes (1919287296 bytes) and Nexenta boots correctly.


Using QCOW1 gives the same results.

zeus:QEMU claunia$ ls -l *.qcow2
-rw-r--r--  1 claunia  staff  1868300288 23 feb 20:21 Elatte Alpha  
6.qcow2


clau...@hades /mnt/datos/Operating Systems/Incoming/feo/finished/ 
Elatte Alpha 6 $ ls -l *.qcow2
-rwxr-xr-x 1 claunia claunia 1919287296 feb 23 20:27 Elatte Alpha  
6.qcow2


zeus:Debian GNU-Hurd K10 claunia$ qemu -m 1024 -hda Debian\ GNU-Hurd\  
K10.qcow2 -monitor stdio -cdrom ../Debian\ GNU-Hurd\ K10\ \(DVD\).iso - 
net user -soundhw sb16 -vga cirrus -net nic,model=rtl8139

QEMU 0.12.2 monitor - type 'help' for more information
(qemu) screendump 1.ppm
(qemu) screendump 2.ppm
(qemu) screendump 3.ppm
(qemu) screendump 4.ppm
(qemu) screendump 5.ppm
(qemu) screendump 6.ppm
(qemu) screendump 7.ppm
(qemu) screendump 8.ppm
(qemu) screendump 9.ppm
(qemu) screendump 10.ppm
(qemu) screendump 11.ppm
(qemu) screendump 12.ppm
(qemu) screendump 13.ppm
(qemu) quit
zeus:Debian GNU-Hurd K10 claunia$ for i in *.ppm; do j=`basename  
$i .ppm`; convert -quality 90 $i ${j}.jpg; done

convert: unable to read image data `11.ppm' @ pnm.c/ReadPNMImage/924.
convert: missing an image filename `11.jpg' @ convert.c/ 
ConvertImageCommand/2849.

convert: unable to read image data `9.ppm' @ pnm.c/ReadPNMImage/924.
convert: missing an image filename `9.jpg' @ convert.c/ 
ConvertImageCommand/2849.



zeus:Elatte Alpha 6 claunia$ qemu -m 1024 -hda Elatte\ Alpha\ 6.qcow2 - 
monitor stdio -cdrom Elatte\ Alpha\ 6.iso -net user -soundhw sb16 -vga  
cirrus -net nic,model=rtl8139

QEMU 0.12.2 monitor - type 'help' for more information
(qemu) screendump 1.ppm
(qemu) screendump 2.ppm
(qemu) screendump 3.ppm
(qemu) screendump 4.ppm
(qemu) screendump 5.ppm
(qemu) screendump 6.ppm
(qemu) screendump 7.ppm
(qemu) screendump 8.ppm
(qemu) screendump 9.ppm
(qemu) screendump 10.ppm
(qemu) screendump 11.ppm
(qemu) screendump 12.ppm
(qemu) screendump 13.ppm
(qemu) screendump 14.ppm
(qemu) screendump 15.ppm
(qemu) screendump 16.ppm
(qemu) screendump 17.ppm
(qemu) screendump 18.ppm
(qemu) screendump 19.ppm
(qemu) screendump 20.ppm
(qemu) screendump 21.ppm
(qemu) screendump 22.ppm
(qemu) screendump 23.ppm
(qemu) screendump 24.ppm
(qemu) screendump 25.ppm
(qemu) screendump 26.ppm
(qemu) screendump 27.ppm
(qemu) screendump 28.ppm
(qemu) quit
zeus:Elatte Alpha 6 claunia$ for i in *.ppm; do j=`basename  
$i .ppm`; convert -quality 90 $i ${j}.jpg; done

convert: unable to read image data `15.ppm' @ pnm.c/ReadPNMImage/924.
convert: missing an image filename `15.jpg' @ convert.c/ 
ConvertImageCommand/2849.

convert: unable to read image data `19.ppm' @ pnm.c/ReadPNMImage/924.
convert: missing an image filename `19.jpg' @ convert.c/ 
ConvertImageCommand/2849.

convert: unable to read image data `20.ppm' @ pnm.c/ReadPNMImage/924.
convert: missing an image filename `20.jpg' @ convert.c/ 
ConvertImageCommand/2849.

convert: unable to read image data `21.ppm' @ pnm.c/ReadPNMImage/924.
convert: missing an image filename `21.jpg' @ convert.c/ 
ConvertImageCommand/2849.

convert: unable to read image data `27.ppm' @ pnm.c/ReadPNMImage/924.
convert: missing an image filename `27.jpg' @ convert.c/ 
ConvertImageCommand/2849.

convert: unable to read image data `28.ppm' @ pnm.c/ReadPNMImage/924.
convert: missing an image filename `28.jpg' @ convert.c/ 
ConvertImageCommand/2849.

convert: unable to read image data `3.ppm' @ pnm.c/ReadPNMImage/924.
convert: missing an image filename `3.jpg' @ convert.c/ 
ConvertImageCommand/2849.

convert: improper image header `4.ppm' @ pnm.c/ReadPNMImage/298.
convert: missing an image filename `4.jpg' @ convert.c/ 
ConvertImageCommand/2849.

convert: unable to read image data `7.ppm' @ pnm.c/ReadPNMImage/924.
convert: missing an image filename `7.jpg' @ convert.c/ 
ConvertImageCommand/2849.

[Qemu-devel] SeaBIOS error with Nextstep bootloader

[Natalia Portillo]

Ok, QEMU is absolutely unable to boot nextstep/openstep, while using  
SeaBIOS.


Changing to old Bochs BIOS, makes it work, however no video is output  
(until NeXT starts using VESA).


Until all that numerous issues with SeaBIOS are solved (may the  
keyboard problem with DOS' Scandisk be also a BIOS problem -needs to  
test-) Bochs BIOS should continue to be included at least as a command  
line option (like -use-old-bios)


I attached images.

inline: 1.png


inline: 2.png

Re: [Qemu-devel] qemu 0.12.x / -git PS/2 mouse not working under Win3.11 / Win9x

[Natalia Portillo]

As shown in the lastest test in the official os support list for  
windows me this problem happens also on windows me installer.


At the same time, scandisk is unable to receive any key but the arrow  
keys.


This may be related.

I know from myself that in 0.9.x it worked so you should start testing  
older versions until it works and then test each commit to the ps2  
emulator onward that.


El 09/02/2010, a las 18:03, Klaus Rechert escribió:


Hi,

I've just compiled 0.12.x and current git HEAD and tested it with  
Windows 3.11 and Windows 9x images. In both cases the mouse is not  
working. I've also attached the qemu-monitor, which states that the  
PS/2 mouse is available. The hardware discovery under win9x also  
does not find the mouse.


Any ideas to debug this issue further?

Thanks
  Klaus

Re: [Qemu-devel] Seabios dislikes -M isapc

[Natalia Portillo]

There are operating systems that simple conflict with some assumptions  
made by PCI architecture.


Rembember that the PC memory map changed to include the PCI  
configuration space and so on, space that can be expected to contain  
other data, or not at all, and could be used in ISA/EISA/VLB/MCA  
systems by PCI-unaware operating systems or applications.


El 09/02/2010, a las 19:50, Anthony Liguori escribió:


On 02/08/2010 04:17 AM, Jan Kiszka wrote:

Hi,

Seabios seems to have some assumptions built in that break when -M  
isapc

is selected. Is this supposed to work or is isapc about to die?



Does anything actually require isapc?

pc has an ISA bridge, a PCI VGA device is still VGA/SVGA compliant.

Would anything break if we just dropped isapc?

Regards,

Anthony Liguori


Jan

Re: [Qemu-devel] Seabios dislikes -M isapc

[Natalia Portillo]

Xenix is currently working (when copied from real hardware).
As well Interactive UNIX and some other non-DOS from 8086 and 286 era.

I'm not really sure that operating systems (specially the 8086 ones  
that do mmu functions in software) will be happy with the PCI bus  
present.


Same for first 386 operating systems (OS/2 2, UNIX, Xenix, so on).

I don't think it is so bad forking the BIOS, letting the ISA one only  
for bug fixes, and the PCI one for new features.
Even the ISA BIOS can be code cleaned, there is no SMBIOS or ACPI in  
ISA hardware.


Or, use bochs bios, that we know is working (at least for now) for  
isapc, and seabios for pcipc.


There are a lot of ways to do that, but I think that simply forgetting  
about isapc and deleting it is not a bugfix, but a big big bug.


El 09/02/2010, a las 21:05, Anthony Liguori escribió:


On 02/09/2010 02:36 PM, Natalia Portillo wrote:
There are operating systems that simple conflict with some  
assumptions made by PCI architecture.


Rembember that the PC memory map changed to include the PCI  
configuration space and so on, space that can be expected to  
contain other data, or not at all, and could be used in ISA/EISA/ 
VLB/MCA systems by PCI-unaware operating systems or applications.


But practically speaking, given the devices that we emulate, is  
there any workload that works with -M isapc but not -M pc?


Having to support an ISA and PCI system in the BIOS is a bit of a  
burden.  If we can eliminate that without regressing any guest  
workloads, I think it would be a net win.


Regards,

Anthony Liguori