Marius Nuennerich | 1 Dec 2006 02:17
Picon

Emulating a machine with no keyboard connected

Hi List,

I would like to emulate an i386 machine which has no PS/2 keyboard or
USB keyboard plugged in. Is this possible?

If there is currently no way to do this, where could one start to
implement this "feature"? I thought about something like
"-k none" as parameter.

regards
Marius

P.S. I'm not a subscriber so please CC me.
Ed Swierk | 1 Dec 2006 03:01
Favicon

OHCI for i386

After spending some time trying to figure out why the emulated UHCI
USB controller is so slow, I switched uhci_usb_init() in hw/pc.c to
ohci_usb_init(). To my delight, Linux booted up and detected the
controller on the first try, and accessing an emulated block device is
2 to 3 times faster.

It seems that UHCI is used only on i386, while the other architectures
use OHCI. Would switching i386 to OHCI cause problems for other guest
OSes?

--Ed
Yu, Xiaoyang | 1 Dec 2006 09:21
Picon
Favicon

RE: About the code to detect a CD-ROM disk is unmounted

Great! Thanks a lot for the information! I found the function definition in the files you pointed out, by
looking into the latest CVS snapshot. 

It seems that code changed a lot since version 0.8.2 released. So if I still use version 0.8.2, is there some
files or function I should look at instead? Thanks a lot!

Thanks
Xiaoyang

-----Original Message-----
From: qemu-devel-bounces+xiaoyang.yu=intel.com <at> nongnu.org
[mailto:qemu-devel-bounces+xiaoyang.yu=intel.com <at> nongnu.org] On Behalf Of Lonnie Mendez
Sent: 2006年11月30日 15:08
To: qemu-devel <at> nongnu.org
Subject: Re: [Qemu-devel] About the code to detect a CD-ROM disk is unmounted

On Thu, 2006-11-30 at 15:03 +0800, Yu, Xiaoyang wrote:
> Hi guys,
> 
>  
> 
> I am using QEMU with Xen and Intel VT, and I have a question about
> detecting the CD-ROM disk unmount event: When user ejects CD-ROM in
> the guest domain, how can QEMU detect this event?
> 
>  
> 
> I know if we use “info block” command before and after a CD-ROM disk
> is ejected, we can see the difference. But I want to add code to
> handle the CD-ROM unmount event, so I need to know which source file I
(Continue reading)

Lonnie Mendez | 1 Dec 2006 10:01
Picon

RE: About the code to detect a CD-ROM disk is unmounted

On Fri, 2006-12-01 at 16:21 +0800, Yu, Xiaoyang wrote:
> Great! Thanks a lot for the information! I found the function definition in the files you pointed out, by
looking into the latest CVS snapshot. 
> 
> It seems that code changed a lot since version 0.8.2 released. So if I still use version 0.8.2, is there some
files or function I should look at instead? Thanks a lot!

I found this just by searching for 'eject' in the source.  It does look
like qemu from cvs has nicely refactored the code for dealing with
removable media since the qemu 0.8.2 release.  Follow the path of the
bdrv_close handler (for cdrom raw_close() is called).  The call is made
from hw/ide.c (GPCMD_START_STOP_UNIT).
Picon
Gravatar

Trying to run L4dope on Q/QEMU (OSX/ppc)

Greetz.

I found a strange bug. Downloading this file (http://os.inf.tu- 
dresden.de/drops/download/drops-demo-floppydisk-current.img.gz), and  
executing:

/Applications/Q.app/Contents/MacOS/i386-softmmu.app/Contents/MacOS/ 
i386-softmmu -fda drops-demo-floppydisk-20050815.img -boot a

then selecting "DOpE demo" option from grub can yield two results:

- on an i386 mac, it works
- on a ppc mac, it produces only black screen! (no matter what OSX  
video output)

Is this a qemu, Q, or gcc bug?

Didn't receive answer from Q developers, nor in qemu user forum.

--

-- 
Gábor Bérczi
Martin Guy | 1 Dec 2006 16:43
Picon
Favicon

Re: [PATCH] intentinoal slowing down qemu - brake

Then again, if someone needed it... it's not as if I have to use it...

    M
Martin Guy | 1 Dec 2006 16:41
Picon
Favicon

Re: [PATCH] intentinoal slowing down qemu - brake

> This patch adds support for slowing down qemu and saving cpu load.

Poooooooooooooooo!

if you're using the right kernel, QEMU will sleep while there is
nothing to be done.
Otherwise just nice -10 it.

Voto contra

    M
Johannes Schindelin | 1 Dec 2006 20:35
Picon
Picon

Re: [PATCH] intentinoal slowing down qemu - brake

Hi,

On Fri, 1 Dec 2006, Martin Guy wrote:

> > This patch adds support for slowing down qemu and saving cpu load.
> 
> if you're using the right kernel, QEMU will sleep while there is
> nothing to be done.

As was stated by the OP, this is for DOS games. So, there is no "nothing 
to be done". Further, you are assuming everybody uses Linux. What makes 
you think so?

Besides, your "nice" would not do the same thing, you know? You'd need 
_another_ tast _using_ the CPU to slow down QEmu. Which would burn through 
the battery like hell.

Ciao,
Dscho
Andrzej Zaborowski | 2 Dec 2006 00:55
Favicon

[PATCH] Handle encrypted usb stick images.

 * Move asking for password to vl.c instead of duplicate code
in vl.c and monitor.c;
 * Call the same code for usb mass storage;
 * Fix a typo where a char * pointer is compared against '\0';
---
 hw/usb-msd.c |    2 ++
 monitor.c    |   12 +-----------
 vl.c         |   35 ++++++++++++++++++++++-------------
 vl.h         |    2 ++
 4 files changed, 27 insertions(+), 24 deletions(-)

diff --git a/hw/usb-msd.c b/hw/usb-msd.c
index 4530a1c..46aa234 100644
--- a/hw/usb-msd.c
+++ b/hw/usb-msd.c
 <at>  <at>  -522,6 +522,8  <at>  <at>  USBDevice *usb_msd_init(const char *file
     bdrv = bdrv_new("usb");
     if (bdrv_open(bdrv, filename, 0) < 0)
         goto fail;
+    if (qemu_key_check(bdrv, filename))
+        goto fail;
     s->bs = bdrv;

     s->dev.speed = USB_SPEED_FULL;
diff --git a/monitor.c b/monitor.c
index f2a2417..ad4e018 100644
--- a/monitor.c
+++ b/monitor.c
 <at>  <at>  -337,8 +337,6  <at>  <at>  static void do_eject(int force, const ch
 static void do_change(const char *device, const char *filename)
(Continue reading)

Martin Bochnig | 1 Dec 2006 22:59
Picon
Favicon

SoftICE under DOS16, anybody? __/__ Re: [PATCH] intentinoal slowing down qemu - brake

Johannes Schindelin wrote:

>>>This patch adds support for slowing down qemu and saving cpu load.
>>>      
>>>
>>if you're using the right kernel, QEMU will sleep while there is
>>nothing to be done.
>>    
>>
>
>As was stated by the OP, this is for DOS games. So, there is no "nothing 
>to be done". Further, you are assuming everybody uses Linux. What makes 
>you think so?
>
>Besides, your "nice" would not do the same thing, you know? You'd need 
>_another_ tast _using_ the CPU to slow down QEmu. Which would burn through 
>the battery like hell.
>
>Ciao,
>Dscho
>  
>

Might something like that help SoftICE for DOS16 to run properly without
freezing the whole guest after one or two ^D's  (i.e. for setting
breakpoints and switching back to the dos command.com)?
WinICE (on DOS386 a.k.a. {win386.exe / chicago's dos386.exe, now called
vmm32.vxd}) does/did already work well, when I last tested this a year
ago, but SoftICE for real mode DOS would always hang the whole guest
when being run inside QEMU (emulation case, not yet tested in case of
(Continue reading)


Gmane