RE: [Qemu-devel] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lonnie Mendez Sent: 2006年11月30日 15:08 To: qemu-devel@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 should take a look. It seems to be not “monitor.c”. Any comment will be appreciated. Thanks in advance! hw/ide.c, block.c:bdrv_eject() ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
RE: [Qemu-devel] 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). ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] 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 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] intentinoal slowing down qemu - brake
This patch adds support for slowing down qemu and saving cpu load. P! 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 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [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 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [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
@@ -522,6 +522,8 @@ 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
@@ -337,8 +337,6 @@ static void do_eject(int force, const ch
static void do_change(const char *device, const char *filename)
{
BlockDriverState *bs;
-int i;
-char password[256];
bs = bdrv_find(device);
if (!bs) {
@@ -348,15 +346,7 @@ static void do_change(const char *device
if (eject_device(bs, 0) 0)
return;
bdrv_open(bs, filename, 0);
-if (bdrv_is_encrypted(bs)) {
-term_printf(%s is encrypted.\n, device);
-for(i = 0; i 3; i++) {
-monitor_readline(Password: , 1, password, sizeof(password));
-if (bdrv_set_key(bs, password) == 0)
-break;
-term_printf(invalid password\n);
-}
-}
+qemu_key_check(bs, filename);
}
static void do_screen_dump(const char *filename)
diff --git a/vl.c b/vl.c
index 447da38..1ddedda 100644
--- a/vl.c
+++ b/vl.c
@@ -6108,6 +6108,24 @@ #endif
/* password input */
+int qemu_key_check(BlockDriverState *bs, const char *name)
+{
+char password[256];
+int i;
+
+if (!bdrv_is_encrypted(bs))
+return 0;
+
+term_printf(%s is encrypted.\n, name);
+for(i = 0; i 3; i++) {
+monitor_readline(Password: , 1, password, sizeof(password));
+if (bdrv_set_key(bs, password) == 0)
+return 0;
+term_printf(invalid password\n);
+}
+return -EPERM;
+}
+
static BlockDriverState *get_bdrv(int index)
{
BlockDriverState *bs;
@@ -6125,21 +6143,12 @@ static BlockDriverState *get_bdrv(int in
static void read_passwords(void)
{
BlockDriverState *bs;
-int i, j;
-char password[256];
+int i;
for(i = 0; i 6; i++) {
bs = get_bdrv(i);
-if (bs bdrv_is_encrypted(bs)) {
-term_printf(%s is encrypted.\n, bdrv_get_device_name(bs));
-for(j = 0; j 3; j++) {
-monitor_readline(Password: ,
- 1, password, sizeof(password));
-if (bdrv_set_key(bs, password) == 0)
-break;
-term_printf(invalid password\n);
-}
-}
+if (bs)
+qemu_key_check(bs, bdrv_get_device_name(bs));
}
}
@@ -6838,7 +6847,7 @@ #endif
fd_table[i] = bdrv_new(buf);
bdrv_set_type_hint(fd_table[i], BDRV_TYPE_FLOPPY);
}
-if (fd_filename[i] != '\0') {
+if (fd_filename[i][0] != '\0') {
if (bdrv_open(fd_table[i], fd_filename[i],
snapshot ? BDRV_O_SNAPSHOT : 0) 0) {
fprintf(stderr, qemu: could not open floppy disk image
'%s'\n,
diff --git a/vl.h b/vl.h
index eedef51..124cda5 100644
--- a/vl.h
+++ b/vl.h
@@ -585,6 +585,8 @@ void qemu_aio_wait_start(void);
void qemu_aio_wait(void);
void qemu_aio_wait_end(void);
+int qemu_key_check(BlockDriverState *bs, const char *name);
+
/* Ensure contents are flushed to disk. */
void bdrv_flush(BlockDriverState *bs);
--
1.4.3.2
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
SoftICE under DOS16, anybody? __/__ Re: [Qemu-devel] [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
x86_x_x86 virtualization).
The same happens when using the Insignia_SoftWindows Pentium-ISA-PC
Emulator on Solaris_sparc, running any version of (MS-/IBM) or DRDOS.
Bochs claims to provide a more accurate emulation than qemu (at the cost
of making it marginally slower), but doesn't fix the SoftICE issue either.
It does - on the other hand - work as expected inside any version of
SunPCi, which only emulates a bit of io and graphics, but uses a
physical x86 cpu, rather than emulating it (I think it doesn't even have
to virtualize it, because nobody else is using the cpu sitting on that
pci card).
Has onybody found a way to work around the SoftICE_for_DOS16
instabilities under qemu?
(btw, my problems *are* qemu-dependant, not caused by an incompatible
himem.sys or anything of that sort / identical diskimages tested under
SunPCi, SoftWindows and qemu_for_SolarisSPARC-Hosts).
Thanks,
Maddin
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: SoftICE under DOS16, anybody? __/__ Re: [Qemu-devel] [PATCH] intentinoal slowing down qemu - brake
Martin Bochnig wrote:
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
x86_x_x86 virtualization).
The same happens when using the Insignia_SoftWindows Pentium-ISA-PC
Emulator on Solaris_sparc, running any version of (MS-/IBM) or DRDOS.
Bochs claims to provide a more accurate emulation than qemu (at the cost
of making it marginally slower), but doesn't fix the SoftICE issue either.
It does - on the other hand - work as expected inside any version of
SunPCi, which only emulates a bit of io and graphics, but uses a
physical x86 cpu, rather than emulating it (I think it doesn't even have
to virtualize it, because nobody else is using the cpu sitting on that
pci card).
Has onybody found a way to work around the SoftICE_for_DOS16
instabilities under qemu?
(btw, my problems *are* qemu-dependant, not caused by an incompatible
himem.sys or anything of that sort / identical diskimages tested under
SunPCi, SoftWindows and qemu_for_SolarisSPARC-Hosts).
Thanks,
Maddin
I might some remote day invest a bit of effort into trying to find out
WHY exactly SoftICE_for_realmodeDOS hangs the emulation (under qemu,
bochs and SoftWindows/RealPC) :
Whether or not it freezes somehow internally because of actually
running, or, more specifically, whether it just has to do with
listening to the keyboard for ^D sequences (int16h and int21h_AH==01 /
see Ralf Brown's grand Interrupt list) to activate the SoftICE UI.
If it is just the latter, then maybe due to a timing related problem,
or maybe because the SoftICE-TSR somehow interferes with COMMAND.COM (or
any shell like i.e. BASH_for_DOS or 4DOS.COM) that are concurrently
listening to kbd input and therefore actively issuing certains DOS-21h
and 16h interrupts permanently (with appropriate values in (E)AL, (E)AL,
or(E)AX, permanently requesting the keyboard, if it has new input in its
associated stdin buffer (not quite correct, simplified).
The issue applies to all major SoftICE_for_realmodeDOS releases/versions.
Thanks.
--
Martin
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
