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  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] 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  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] 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] 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  wrote:
> 
> From: Natalia Portillo 
> Subject: Re: [Qemu-devel] Webcams under KVM and Linux
> To: "Andreas Färber" 
> Cc: "Peter Baitz" , "QEMU Developers" 
> 
> 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 
> >&

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] [0/7] USB UVC updates

[Natalia Portillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Brad,

El 02/06/2011, a las 06:41, Brad Hards escribió:

> Hi Natalia,
> 
> As you suggested, I've stopped my nonsense and worked from your
> UVC patches (http://patchwork.ozlabs.org/patch/55001 and
> http://patchwork.ozlabs.org/patch/55000). These changes
> are relative to your patches (applied on top of trunk).
> 
> I've mostly just incorporated some changes requested by Blue
> Swirl in his review. Fixing the checkpatch stuff changed a lot
> of whitespace (tab -> spaces), so I'd like to make sure this is
> OK before making more changes.

I see it ok, have you tested nothing broken? (specially with the &s patch)
I should take more care with 's's in typos next time

> The next change I propose to make is to rework the descriptors
> and add constants / defines for magic numbers.

Yeah, there are a couple of magic numbers that can be added.
Please note that most of the constants used in the descriptors should go
in usb.h

Also take special care with the descriptors, the minimal change can break it 
very easily.
The ideal solution would be to make the descriptors be dynamic depending on the 
host
webcam capabilities.

Bad thing the USB IF put the resolutions and formats in the descriptor, instead 
of in a
query command.
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iF0EAREIAAYFAk3snrEACgkQv/wfOsykIRRbngD492YNOzZGwRgwwVqok+AewO6H
kXvTClUJibR4fTVaDgEArEqcnm/xLF8gvANDc7DX6l8z7jOY8pagK4V488PMOhI=
=gzkf
-END PGP SIGNATURE-

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
> 

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][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"  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"  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"  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][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,

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, w

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 cut&paste 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] 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] 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] 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] 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] 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] 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-

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-

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

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,   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] [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

[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] webcam under windows xp guest

[Natalia Portillo]

No sorry, use the search on the mailing list webpage.

El 30/08/2010, a las 13:54, Paul Bolle escribió:

> On Sun, 2010-08-29 at 13:05 +0100, Natalia Portillo wrote:
>> Connecting the webcam directly with usb pass-thru will never work well
>> because of timing issues.
>> 
>> Too much USB packets dropped and image that cannot be formed.
> 
> Would you have any links to discussions, threads, etc. that concern
> these issues?
> 
> 
> Paul
> 

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  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] 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?
> 
> 

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

[Qemu-devel] [Bug 392032] Re: qemu-system-x86_64 fails to install debian-501-amd64-CD-1

[Natalia Portillo]

This only affected QEMU 0.10 and was solved in QEMU 0.11.

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

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

-- 
qemu-system-x86_64 fails to install debian-501-amd64-CD-1
https://bugs.launchpad.net/bugs/392032
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:
This is also reported as

http://bugs.debian.org/530645

The problem is that while installing debian-501-amd64-CD-1.iso at some point 
the entire thing fails when GPG segfaults. There is more info in the debian bug 
entry.

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

[Natalia Portillo]

Public bug reported:

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.

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

-- 
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: New

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 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 588691] Re: QEMU is not correctly detecting host CDs

[Natalia Portillo]

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

-- 
QEMU is not correctly detecting host CDs
https://bugs.launchpad.net/bugs/588691
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:
QEMU's block layer contains code for detecting and using ioctls when real 
CD-ROM host devices are attached.

This detection is not working in some host OSes while bad implemented on 
anothers.

E.g., in Linux host qemu -cdrom /dev/sr0 is not detecting it as a CD-ROM
E.g., in Mac OS X host qemu asks the kernel to enumerate optical devices and 
the compares it to the constant string "/dev/cdrom". This is useless, that 
enumeration is just enough, and "/dev/cdrom" will NEVER exist in Mac OS X 
unless manually created by the user.

[Qemu-devel] [Bug 588691] [NEW] QEMU is not correctly detecting host CDs

[Natalia Portillo]

Public bug reported:

QEMU's block layer contains code for detecting and using ioctls when
real CD-ROM host devices are attached.

This detection is not working in some host OSes while bad implemented on
anothers.

E.g., in Linux host qemu -cdrom /dev/sr0 is not detecting it as a CD-ROM
E.g., in Mac OS X host qemu asks the kernel to enumerate optical devices and 
the compares it to the constant string "/dev/cdrom". This is useless, that 
enumeration is just enough, and "/dev/cdrom" will NEVER exist in Mac OS X 
unless manually created by the user.

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

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

-- 
QEMU is not correctly detecting host CDs
https://bugs.launchpad.net/bugs/588691
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:
QEMU's block layer contains code for detecting and using ioctls when real 
CD-ROM host devices are attached.

This detection is not working in some host OSes while bad implemented on 
anothers.

E.g., in Linux host qemu -cdrom /dev/sr0 is not detecting it as a CD-ROM
E.g., in Mac OS X host qemu asks the kernel to enumerate optical devices and 
the compares it to the constant string "/dev/cdrom". This is useless, that 
enumeration is just enough, and "/dev/cdrom" will NEVER exist in Mac OS X 
unless manually created by the user.

[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:
 :
   0:   4e71nop
   2:   4e71nop
   4:   4e71nop
   6:   4640notw %d0
0008 :
   8:   6000 fffe   braw 8 

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 557546] Re: no sound device found in ipc 10.5.6 image

[Natalia Portillo]

iPC 10.5.6 is a hacked version of Mac OS X 10.5.6.

QEMU does not emulate any Apple sound card right now, and that's the
expected behaviour.

** Changed in: qemu
   Status: New => Invalid

-- 
no sound device found in ipc 10.5.6 image
https://bugs.launchpad.net/bugs/557546
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:
i have windows 7 installed on physical computer my computer configuration is 
good for install any operating system ,i success for installing windows xp 
,windows 7 and linux inside vmware 7.0.1 as virtual os  and when i heard about 
hakintosh i download ipc 10.5.6 and when installing on host computer it success 
and it work very good but when trying install it inside qemu happend what is 
not expected first it take very long time to install about 5 hours second it 
work very slow third is the important the sound is not work and no sound device 
installed in mac guest  i try many times with the same result i cant use vmware 
to install mac because vt is not enabled in bios of mb and no update avilable 
for it the question is how can i make qemu manger 6 v 0.10.2 to install sound 
device in ipc 10.5.6 virtual image although i select sound driver when creating 
vm configuration and how can i accelerate it although acceleration is installed

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

[Natalia Portillo]

QEMU 0.12.3 does not present this bug.

Tested quick and full format, KVM and SOFTMMU, with Windows XP
Professional SP0.

Closing bug.

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

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

[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 
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:
...
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] [RFC PATCH 1/2] USB Video Class device emulation.

[Natalia Portillo]

Signed-off-by: Natalia Portillo 
---
 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 
+ *
+ * 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 
+#include 
+#include 
+// V4L2 ioctls
+#include 
+#include 
+
+#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 */
+   0x

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

[Natalia Portillo]

Signed-off-by: Natalia Portillo 
---
 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=

Regards,
Natalia Portillo

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

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

Re: [Qemu-devel] OVMF Google Summer of Code ideas

[Natalia Portillo]

Hi all,

This may come late in the discussion, but, has OVMF been tested with Mac OS X?

A decent Intel Macintosh emulation requires of course EFI + HFS.

Regards,
Natalia Portillo

El 09/03/2011, a las 05:34, Jordan Justen escribió:

> On Tue, Mar 8, 2011 at 18:23, Kevin O'Connor  wrote:
>> On Tue, Mar 08, 2011 at 09:00:05AM -0800, Jordan Justen wrote:
>>> Yes, the UEFI system is still in place.  The UEFI part still handles
>>> the majority of platform init, and calls into the CSM at various
>>> points.  The CSM returns back to UEFI for all CSM calls, except the
>>> legacy boot.
>> 
>> Is there a concise list of these various callbacks between UEFI and
>> CSM?
>> 
>> If SeaBIOS just needs to be loaded up for legacy boots, that doesn't
>> sound too difficult.  However, if SeaBIOS would need to translate
>> various BIOS calls into UEFI calls - that sounds like it could be
>> complex.
> 
> A CSM does not really know about UEFI for the most part.  Rather it
> carries out some tasks when request by the UEFI environment.  The UEFI
> side still manages the high level boot flow (even for legacy boots).
> The CSM does not call into UEFI services, but just returns back to
> whoever invoked the CSM call.
> 
> The 16-bit CSM component interface is described in this file:
> https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/IntelFrameworkPkg/Include/Protocol/LegacyBios.h
> 
> The full CSM specification document is available here:
> http://www.intel.com/technology/framework/spec.htm
> 
> Thanks,
> 
> -Jordan
> 

Re: [Qemu-devel] OVMF Google Summer of Code ideas

[Natalia Portillo]

Hi,
El 09/03/2011, a las 18:44, Jordan Justen escribió:

> On Wed, Mar 9, 2011 at 05:43, Natalia Portillo  wrote:
>> This may come late in the discussion, but, has OVMF been tested with Mac OS 
>> X?
> 
> No.
> 
> I don't think Apple considers VMs an acceptable usage environment for
> OS X.  Please correct me if I am mistaken.

Their EULA explicitly says that OS X Server can be run in VMs, as long as the 
VM is running on Apple hardware (VMWare Fusion, Parallels Desktop and VMWare 
ESXi for Mac are clearly authorized).
For OS X non-server it just says "must run on Apple hardware" nothing specific 
as on VM, but none of the previously named took the risk.

VirtualBox is almost able to run OS X now but with some tricks and no 
"officially supported" statement.

As currently OS X searches for an encryption key on the hardware, and there has 
been code for providing it if being known in QEMU, as long as the requirement 
is reading that code on runtime on the real hardware, there should be no legal 
problems.
MacOnLinux allowed to virtualize OS X on PowerPC and never received 
communications from Apple, even if it allowed to run on non-Apple PowerPC 
machines.
PearPC emulated enough of a PowerMac to make OS X run and also never received 
communications from Apple.

In any case, IMHO, it's up to the user to respect or violate the EULA, we just 
provide the knife, it's not our fault it's used for assassination and not for 
cutting food.

> Thanks,
> 
> -Jordan

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

[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"  wrote: 
> > From: "Natalia Portillo" 
> > 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_US&cmd=displayKC&externalId=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] [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

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] 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] [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 
> 
> 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 
> ---
> 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] 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] [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 ' 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

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

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  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  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] webcam under windows xp guest

[Natalia Portillo]

Connecting the webcam directly with usb pass-thru will never work well because 
of timing issues.

Too much USB packets dropped and image that cannot be formed.

If you want to use it, use the qemu-v4l2 patchset posted two months ago in the 
list.

It's still experimental but will give you image if your webcam is supported.

Regards,
Natalia Portillo

El 27/08/2010, a las 23:07, Frans de Boer escribió:

> I have searched the Internet, but could not find conclusive answers. I
> did find a lot of questions, but that's about it.
> 
> I run Linux, QEMU/KVM 0.12.5 and have loaded windows XP.
> My webcam is being recognized by Windows XP, but all I get is a black
> screen when I try to use it. I use the -usbdevice host:vendor:id
> directive. The light goes on (and never off again until I reboot the
> physical machine).
> 
> Since this problem is not new, I just wonder what might be wrong?
> 
> Regards,
> Frans.
> 

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

[Qemu-devel] RELEASE: QEMU Official OS Support List 3.0 (aka, QEMU OS DB)

[Natalia Portillo]

Notice: If you are receiving this email is because you are registered  
in the QEMU mailing list or you posted an entry in the Official OS  
Support List.


Dear developers, testers and users.

Stuart Brady and I are proud to present you the new QEMU's Official OS  
Support List 3.0.


This list is based on Wine's Application Database code, modified to  
apply better to QEMU's requirements, and the code will be posted when  
all changes are finished.


All valid entries in the old OS Support List have been migrated.  
Unluckily they appear all as mine, sorry for that.
I welcome all of you to check it out at the usual address ( http://www.claunia.com/qemu 
 ), register, and put your test results.


Advantages:
You can now put more detailed information, command line used, extended  
description of behaviour, so on.

You can upload screenshots freely, any number of it.
You can become a maintainer and contribute to the list clean up.
You can check for regressions, seeing more easily, if an operating  
system worked in an old QEMU version.
You can post HOW-TOs so they stay. All but one of the HOW-TOs linked  
by url in the old os database are now dead. This will not happen  
anymore.
Your email is now private, but other database users may contact others  
users for feedback or questions.

Spam bots are no more welcome.
All spam, incomplete, or invalid entries, have been deleted or  
corrected.
You can explain in detail what devices you used, what worked, what  
configuration, in each test.
Changed the 3 state status (working, partially, not working) to a more  
complete 5 state status (platinum, gold, silver, bronze, garbage) like  
in Wine.
A help system explains you how to use the database in simple terms and  
gives you guidelines about how operating systems should be created.


Disadvantages:
You cannot put your own QEMU release, so GIT/SVN/CVS revisions are not  
feasible. If there is a real need to put a test data using a "live"  
revision, you can email me and I'll add that release to the database  
(if there is a real need for).


Still todo:
List the different video, audio, network, other devices, so you can  
just click a checkbox of what is used and/or tested. For now, you can  
freely describe it.
Rebrand/rename some sentences, parts, of the database, that may still  
reference to Wine (working on progress)


The new list contains the following data:
Users:  2
Users active within the last 30 days:   2
Users active within the last 60 days:   2
Users active within the last 90 days:   2
Inactive users (not logged in since six months):0
Inactive users pending deletion:0
Comments:   0
OS families:87
Versions:   227
OS maintainers: 2
Test reports:   255
Screenshots:456

I hope you like this late christmas gift.

Sincerely yours,
Natalia Portillo

Re: [Qemu-devel] The new qemu.org

[Natalia Portillo]

Indeed that section is just a static HTML so all the wiki advantages  
get lost with it.


El 03/02/2010, a las 08:07, Jes Sorensen escribió:


On 02/02/10 17:22, G 3 wrote:
The new site looks nice. When is the Mac OS X section under  
"Compilation

from the sources" going to be updated from the lame "The Mac OS X
patches are not fully merged in QEMU, so you should look at the QEMU
mailing list archive to have all the necessary information.". This is
unacceptable.


Well as Anthony pointed out, this is a Wiki, so you should just go  
ahead
and update the page, in fact it is unacceptable that you haven't  
done so

already!

Someone who uses OSX needs to do it, you cannot expect someone who is
not developing on OSX to keep up-to-date with all the OSX details.

Jes

Re: [Qemu-devel] The new qemu.org

[Natalia Portillo]

I think the wiki should contain different articles for configuration,  
command line options, compilation, network configuration (tun/tap  
needs different articles for every host) so on, and the "how to  
install X guest" should be in the os support list.


That's a clean way to do it IMHO.

El 03/02/2010, a las 19:27, Anthony Liguori escribió:


On 02/03/2010 01:20 PM, Andreas Färber wrote:


Am 03.02.2010 um 15:15 schrieb Anthony Liguori:


On 02/03/2010 08:11 AM, Natalia Portillo wrote:
Indeed that section is just a static HTML so all the wiki  
advantages get lost with it.


It's derived from qemu-doc.texi in the git tree so patches can be  
submitted against it.


I'd like to convert it to just a wiki page but there was quite a  
bit of support for keeping it in the repository.


Didn't that mostly apply to the ever-changing options, machine/ 
hardware emulation etc.?


Would there be something wrong with having the pretty stable ./ 
configure --target-list=...; make; make install stuff in a new Wiki  
page and referencing the other stuff from there?


Nope.  I think migrating chunks of reasonable static content from  
qemu-doc.texi into the wiki would be a potentially non-contraversal  
thing to do.


Regards,

Anthony Liguori


Andreas

Re: [Qemu-devel] 0.12.2, PowerPC, CPU 750 wrongly identified (?), hardware error

[Natalia Portillo]

Nope this is not correct.

And I don't even see why the 601 / 620 / 970 are treated as equal.

You are asking to run a fully implemented "so called G3" PowerPC  
processor.
However the 601 is a hybrid PowerPC/POWER ("G1"), the 620 is a 64-bit  
early implementation ("64bit G2") and the 970 the final 64-bit so  
called G5.


There is no relation at all between that four CPUs.

El 08/02/2010, a las 12:40, Bartlomiej Celary escribió:


Hi,
I've just compiled qemu 0.12.2 for Windows under msys.

I am using "-m prep -M 750" options which on 0.11 worked fine. In  
012.2 however, I get the following error:


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 

This application has requested the Runtime to terminate it in an  
unusual way.

Please contact the application's support team for more information.

Am I correct, that somehow the CPU was recognized as PowerPC 601 /  
620 / 970? Is this OK?


Any help greatly appreciated.

Regards,
Bartek Celary

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

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

[Natalia Portillo]

2.x was "working", 3.x simply does not install, the rest need to check.

1.x NEVER worked, ironically, it is working in VirtualPC, the one that  
was the most OS/2 incompatible emulator/simulator.


El 09/02/2010, a las 22:41, malc escribió:


On Tue, 9 Feb 2010, Natalia Portillo wrote:


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


News to me that OS/2 worked.. I don't quite remember which version
someone (you?) asked me to try on IRC a few years back, but it  
definitely

didn't work.

[..snip..]

--
mailto:av1...@comtv.ru

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

<>


<>

[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] 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:
<>


It should be like (took in Mac OS X 10.6.2 using QEMU 0.12.2):
<>

[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

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)

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 +0000, 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

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

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