Re: [Qemu-devel] QEMU version 0.9.1
On Sun, Jan 06, 2008 at 11:03:45PM +0100, Fabrice Bellard wrote: > > QEMU version 0.9.1 is out ! and if you want to install an OpenSolaris guest on it, apply the attached patch over it. the patch prevents OpenSolaris from overflowing a small buffer when querying the emulated CDROM for its capabilities and getting more data than requested at install time. beware that there are still other problems with the implementation of that command that are being addressed in a bigger patch that is still under revision. Carlo Index: hw/ide.c === RCS file: /sources/qemu/qemu/hw/ide.c,v retrieving revision 1.79 diff -u -p -r1.79 ide.c --- hw/ide.c24 Dec 2007 14:33:24 - 1.79 +++ hw/ide.c7 Jan 2008 05:24:16 - @@ -1648,6 +1648,7 @@ static void ide_atapi_cmd(IDEState *s) ASC_INV_FIELD_IN_CMD_PACKET); break; } +max_len = ube16_to_cpu(packet + 7); memset(buf, 0, 32); bdrv_get_geometry(s->bs, &total_sectors); buf[3] = 16; @@ -1658,7 +1659,7 @@ static void ide_atapi_cmd(IDEState *s) buf[14] = buf[7] == 0x10; /* (in)active */ buf[17] = 0x08; /* CD-ROM profile */ buf[18] = buf[7] == 0x08; /* (in)active */ -ide_atapi_cmd_reply(s, 32, 32); +ide_atapi_cmd_reply(s, 32, max_len); break; } default:
Re: [Qemu-devel] [RESEND] [PATCH] ide: fix GET_CONFIGURATION DVD-ROM support
On Sun, Jan 06, 2008 at 03:22:15AM -0600, Rob Landley wrote: > > > > > @@ -1648,17 +1649,27 @@ static void ide_atapi_cmd(IDEState *s) > > > > > ASC_INV_FIELD_IN_CMD_PACKET); > > > > > break; > > > > > } > > > > > -memset(buf, 0, 32); > > > > > > This moved a few lines down, but that just seems to be churn. > > > > it is structured in a way that could be later structured away into a > > function when/if more profiles are added. > > Makes sense. I should also said that unless done after as shown by the patch, reading the parameter will be imposible, because the buffer used for the IDE commands is reused for input/output as shown by lines 1295 to 1300 at the beginning of ide_atapi_cmd : const uint8_t *packet; uint8_t *buf; int max_len; packet = s->io_buffer; buf = s->io_buffer; > > > > > +max_len = ube16_to_cpu(packet + 7); > > > > > > Why are you doing math on a value _before_ you adjust its endianness from > > > a potentially foreign format into the CPU native one? I take it that > > > gives you a pointer from which a 16 byte value is fetched? > > > > yes, this adds not to the value but the pointer where the packet is stored > > and that contains on byte 7 (MSB) and 8 (LSB) the value for the Allocation > > Length parameter as described in Table 275 of T10/1836-D Revision 1 (*) > > Is dereferencing a word value at an odd address alignment safe on all the > potential host platforms? (I dunno if qemu runs on an arm host, nor if the > ube16_to_cpu value is already dealing with this. Just curious.) good point, and I am affraid that it might be unsafe in those architectures with strict alignment requirements, but sadly there is no mechanism available (at least for the ide emulation) to emulate the hardware buffers in a safe way. could someone with most experience on this hint into the right direction to approach this problem and that affects several other emulated commandas as well? > > > > > -buf[7] = total_sectors <= 1433600 ? 0x08 : 0x10; /* > > > > > current profile */ > > > > > > This becomes 3-state now. You added a state 0 when there's no cdrom in > > > the drive. The less intrusive change would be keeping the above line and > > > adding a second line: "if (!total_sectors) buf[7] = 0;" Not actually any > > > larger, codewise, and a less intrusive change. > > > > I refactored this code so that it is hopefully more clear in the intended > > effect, which is to set the default profile to either of the available > > profiles depending on the kind of media that was available, and as it is > > done by real hardware. > > > > Again, even if the refactoring was more of an intrusive change, it also > > allows for more flexibility to expand this code to support more profiles in > > a cleaner way. > > I take it buf[7]=0 is what real hardware returns when there's no disk in the > drive? yes > > It is clearer on why the size of the response includes the profile > > definitions plus the 2 headers, remember that buf[11] is now a constant > > because we are defining only 2 profiles by hand, but the aim was to clean > > the code and make it extensible (and I hoped self explanatory) even if it > > makes the computer do some math or is not as compact as the original one, > > after all this code doesn't need to be optimized for speed and, well I > > trust compilers ;) > > I.E. if the value gets set in a more complicated way, it propagates naturally > to all the places it needs to go. > > *shrug* I suppose I can see trying to have fewer instances of each magic > constant... will try to make a simpler version then that could be used at least as an intermediate step and that is less intrusive than this one, while avoiding so may magic values. Carlo
Re: [Qemu-devel] qemu Makefile
Fabrice Bellard wrote: > CVSROOT: /sources/qemu > Module name: qemu > Changes by: Fabrice Bellard08/01/06 18:27:12 > > Modified files: > . : Makefile > > Log message: > update binary distribution > > CVSWeb URLs: > http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile?cvsroot=qemu&r1=1.139&r2=1.140 I intentionally left out the mipsn32/mips64 userland emulation, as it is not working yet (and not built by default). Thiemo
Re: [Qemu-devel] [RESEND] [PATCH] ide: fix GET_CONFIGURATION DVD-ROM support
On Sun, Jan 06, 2008 at 03:32:27PM +0100, Andreas Färber wrote: > Either way, shouldn't it be a preprocessor define rather than a magic > number, maybe something like MAX_SECTORS_CD? Then it can more easily > be found and changed, where necessary. Point taken, will fix that if we still have to rely on the number of sectors to detect the media type. Carlo
Re: [Qemu-devel] [RESEND] [PATCH] ide: fix GET_CONFIGURATION DVD-ROM support
On Sun, Jan 06, 2008 at 01:57:38PM +, Stuart Brady wrote: > On Sat, Jan 05, 2008 at 08:22:33PM -0600, Carlo Marcelo Arenas Belon wrote: > > > the exact number of sectors is really not that relevant, as the whole point > > here is to try to detect if it is a CD (700MB) or a DVD (4.7GB) and the > > logic > > is just assuming that if it has more sectors than you should normally expect > > in a CD, then it is a DVD. > > My answer was quite relevant to Rob's question, which was "Where does > the constant come from, anyway?" Yes, and my comment didn't meant it wasn't relevant, but that the exact value isn't as important as finding the upper possible limit that can be used to assume that anything bigger than that has to be a DVD instead. when I looked at the patch originally, tried to find something in the specifications that could be used to define a "standard" CD size but couldn't find anything, because as other people pointed out, there isn't a "standard" CD size even if most of the CDs out there are 80min large. > As for the code, there's a choice between using an incorrect value, and > correctly detecting for the vast majority of cases, and using the > correct value and correctly detecting for 100% of cases. Perhaps "only > marginally broken" is "good enough", seeing as nobody's complained. Agree, and that is why I said using 144 will be probably better and provided a tool that can be used to generate this call in the guests (only for Linux though), so that the maximum value could be found empirically. Since this is meant to work for ISO images in a file as well as devices with physical CDs on them, I suspect (and remember the original code which included this magic value wasn't mine) that the number of sectors might be the only reliable indication of media size, but will look at it again and see if there is any other metadata available in all cases which could be used instead. > > but I had already enough problems trying to get this > > merged without trying to change the code that much to try to guess a better > > magic number than the one was originally used (I like 144 though) > > Sorry, but did anyone complain? > > No. Not sure what you mean by this, but having a patch resent several times with no comments is IMHO more problematic that complains. Carlo
Re: [Qemu-devel] qemu-cvs FreeBSD guests, cirrus, vmwarevga emulation - experimental qemu-devel FreeBSD port update available for testing
On Sun, Jan 06, 2008 at 11:44:50PM +0100, Juergen Lock wrote: > Also, still slirp causes qemu to crash on amd64 hosts when just > trying to access a webpage from inside a guest. I never though slirp will ever work in an amd64 (judging by all the pointer <-> integer size mismatches) or any other LP64 architecture, regardless of the guest OS being used, which is why I never even bother to test. > So, can anyone reproduce any of these problems on e.g. a Linux host? does anyone have a woking setup for slirp for linux 64bit hosts? Carlo
[Qemu-devel] [PATCH] Implement ARM floating point exception emulation
The patch below, written by Ulrich Hecht implements ARM floating point
exception emulation. It is in the Debian qemu package for more than 2
years, and looks good enough to be committed upsteam.
Index: linux-user/main.c
===
RCS file: /sources/qemu/qemu/linux-user/main.c,v
retrieving revision 1.159
diff -u -d -p -r1.159 main.c
--- linux-user/main.c 6 Jan 2008 17:21:48 - 1.159
+++ linux-user/main.c 6 Jan 2008 22:35:49 -
@@ -377,19 +377,68 @@ void cpu_loop(CPUARMState *env)
{
TaskState *ts = env->opaque;
uint32_t opcode;
+int rc;
/* we handle the FPU emulation here, as Linux */
/* we get the opcode */
/* FIXME - what to do if get_user() fails? */
get_user_u32(opcode, env->regs[15]);
-if (EmulateAll(opcode, &ts->fpa, env) == 0) {
+rc = EmulateAll(opcode, &ts->fpa, env);
+if (rc == 0) { /* illegal instruction */
info.si_signo = SIGILL;
info.si_errno = 0;
info.si_code = TARGET_ILL_ILLOPN;
info._sifields._sigfault._addr = env->regs[15];
queue_signal(info.si_signo, &info);
-} else {
+} else if (rc < 0) { /* FP exception */
+int arm_fpe=0;
+
+/* translate softfloat flags to FPSR flags */
+if (-rc & float_flag_invalid)
+ arm_fpe |= BIT_IOC;
+if (-rc & float_flag_divbyzero)
+ arm_fpe |= BIT_DZC;
+if (-rc & float_flag_overflow)
+ arm_fpe |= BIT_OFC;
+if (-rc & float_flag_underflow)
+ arm_fpe |= BIT_UFC;
+if (-rc & float_flag_inexact)
+ arm_fpe |= BIT_IXC;
+
+FPSR fpsr = ts->fpa.fpsr;
+//printf("fpsr 0x%x, arm_fpe 0x%x\n",fpsr,arm_fpe);
+
+if (fpsr & (arm_fpe << 16)) { /* exception enabled? */
+ info.si_signo = SIGFPE;
+ info.si_errno = 0;
+
+ /* ordered by priority, least first */
+ if (arm_fpe & BIT_IXC) info.si_code = TARGET_FPE_FLTRES;
+ if (arm_fpe & BIT_UFC) info.si_code = TARGET_FPE_FLTUND;
+ if (arm_fpe & BIT_OFC) info.si_code = TARGET_FPE_FLTOVF;
+ if (arm_fpe & BIT_DZC) info.si_code = TARGET_FPE_FLTDIV;
+ if (arm_fpe & BIT_IOC) info.si_code = TARGET_FPE_FLTINV;
+
+ info._sifields._sigfault._addr = env->regs[15];
+ queue_signal(info.si_signo, &info);
+} else {
+ env->regs[15] += 4;
+}
+
+/* accumulate unenabled exceptions */
+if ((!(fpsr & BIT_IXE)) && (arm_fpe & BIT_IXC))
+ fpsr |= BIT_IXC;
+if ((!(fpsr & BIT_UFE)) && (arm_fpe & BIT_UFC))
+ fpsr |= BIT_UFC;
+if ((!(fpsr & BIT_OFE)) && (arm_fpe & BIT_OFC))
+ fpsr |= BIT_OFC;
+if ((!(fpsr & BIT_DZE)) && (arm_fpe & BIT_DZC))
+ fpsr |= BIT_DZC;
+if ((!(fpsr & BIT_IOE)) && (arm_fpe & BIT_IOC))
+ fpsr |= BIT_IOC;
+ts->fpa.fpsr=fpsr;
+} else { /* everything OK */
/* increment PC */
env->regs[15] += 4;
}
Index: target-arm/nwfpe/fpa11.c
===
RCS file: /sources/qemu/qemu/target-arm/nwfpe/fpa11.c,v
retrieving revision 1.5
diff -u -d -p -r1.5 fpa11.c
--- target-arm/nwfpe/fpa11.c17 Sep 2007 08:09:52 - 1.5
+++ target-arm/nwfpe/fpa11.c6 Jan 2008 22:35:49 -
@@ -162,6 +162,8 @@ unsigned int EmulateAll(unsigned int opc
fpa11->initflag = 1;
}
+ set_float_exception_flags(0, &fpa11->fp_status);
+
if (TEST_OPCODE(opcode,MASK_CPRT))
{
//fprintf(stderr,"emulating CPRT\n");
@@ -191,6 +193,11 @@ unsigned int EmulateAll(unsigned int opc
}
// restore_flags(flags);
+ if(nRc == 1 && get_float_exception_flags(&fpa11->fp_status))
+ {
+//printf("fef 0x%x\n",float_exception_flags);
+nRc=-get_float_exception_flags(&fpa11->fp_status);
+ }
//printf("returning %d\n",nRc);
return(nRc);
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
[Qemu-devel] qemu-cvs FreeBSD guests, cirrus, vmwarevga emulation - experimental qemu-devel FreeBSD port update available for testing
Hi! Yesterday (so, just before the qemu version commit...) I prepared a FreeBSD qemu-devel port update using the 2008-01-05_05 snapshot, http://people.freebsd.org/~nox/qemu/qemu-devel-20080105.patch and I already got a report of xorg 7.3 using the cirrus emulation in a FreeBSD 6.3 RC guest crashing with -kernel-kqemu, and hanging without it, which he said worked with the previous qemu cvs snapshot thats still in ports (2007-08-02_05.) -vmwarevga worked, but still had the old problem of causing the ne2kpci nic not to attach (ed0.) The i82557b nic can be used as a workaround (fxp0, its faster anyway), but I just verified with a FreeBSD 6.2 guest (you can use e.g. a FreeSBIE livecd iso, use `su' if you want to edit its /etc/X11/xorg.conf, after that exit the root shell and run `startx'; I gave qemu -m 256) that -vmwarevga also still causes the es1370 soundcard not to attach and I don't know a workaround for that. Also, still slirp causes qemu to crash on amd64 hosts when just trying to access a webpage from inside a guest. So, can anyone reproduce any of these problems on e.g. a Linux host? Also, more testing of the FreeBSD port update is certainly needed, also using non-FreeBSD guests, non-i386/amd64 targets, and the new -disk option (which I didn't yet test at all, it should e.g. allow scsi drives to be emulated, tho very likely FreeBSD host support for the scsi passthru feature still needs to be done, and io via qemu is probably too slow to burn a dvd anyway. :) Thanx, Juergen PS: I just see that 0.9.1 is actually out now, so I guess I should prepare an update to the qemu port instead, but not today... (and testing this one is still useful.)
[Qemu-devel] [PATCH] RTC dyntick
Hello.
This patch stops the qemu seconds timer when the RTC is not used. Once
the cmos is accessed, the skipped seconds are accounted for, and the
timer is enabled again.
In case interrupts are to be delivered, the timer is not disabled.
I have obviously gone mad from staring too much at PowerTOP, as this
really is a micro-optimization. On the other hand, this change
eliminates the last host-induced periodic timer in my kvm setup, so it
seems worth the trouble.
Please comment, does it make sense?
Anders.
diff --git a/qemu/hw/mc146818rtc.c b/qemu/hw/mc146818rtc.c
index e1e6427..fd00f3a 100644
--- a/qemu/hw/mc146818rtc.c
+++ b/qemu/hw/mc146818rtc.c
@@ -72,6 +72,7 @@ struct RTCState {
static void rtc_set_time(RTCState *s);
static void rtc_copy_date(RTCState *s);
+static void rtc_catchup(RTCState *s);
static void rtc_timer_update(RTCState *s, int64_t current_time)
{
@@ -108,6 +109,8 @@ static void cmos_ioport_write(void *opaque, uint32_t addr, uint32_t data)
{
RTCState *s = opaque;
+rtc_catchup(s);
+
if ((addr & 1) == 0) {
s->cmos_index = data & 0x7f;
} else {
@@ -334,13 +337,48 @@ static void rtc_update_second2(void *opaque)
s->cmos_data[RTC_REG_A] &= ~REG_A_UIP;
s->next_second_time += ticks_per_sec;
-qemu_mod_timer(s->second_timer, s->next_second_time);
+
+/* Keep going only if interrupts are needed */
+if (s->cmos_data[RTC_REG_B] & (REG_B_AIE | REG_B_UIE)) {
+qemu_mod_timer(s->second_timer, s->next_second_time);
+}
+}
+
+static void rtc_catchup(RTCState *s)
+{
+int64_t now;
+
+if (!qemu_timer_pending(s->second_timer) &&
+!qemu_timer_pending(s->second_timer2)) {
+
+/* Count the seconds passed since last access */
+now = qemu_get_clock(vm_clock);
+
+while (s->next_second_time <= now) {
+rtc_next_second(&s->current_tm);
+s->next_second_time += ticks_per_sec;
+}
+
+if (!(s->cmos_data[RTC_REG_B] & REG_B_SET)) {
+rtc_copy_date(s);
+}
+
+/* Restart the right timer */
+if ((s->next_second_time - now) < ticks_per_sec/100) {
+rtc_update_second(s);
+} else {
+qemu_mod_timer(s->second_timer, s->next_second_time);
+}
+}
}
static uint32_t cmos_ioport_read(void *opaque, uint32_t addr)
{
RTCState *s = opaque;
int ret;
+
+rtc_catchup(s);
+
if ((addr & 1) == 0) {
return 0xff;
} else {
[Qemu-devel] [PATCH] SCSI support for vmdk images
I just noticed this patch, I've had lying around for a while, but forgot
to send here.
--
Soren Hansen
Ubuntu Server Team
http://www.ubuntu.com/
=== modified file 'block-vmdk.c'
--- block-vmdk.c 2007-11-11 02:51:15 +
+++ block-vmdk.c 2008-01-06 21:18:57 +
@@ -717,7 +717,7 @@
"ddb.geometry.cylinders = \"%lu\"\n"
"ddb.geometry.heads = \"16\"\n"
"ddb.geometry.sectors = \"63\"\n"
-"ddb.adapterType = \"ide\"\n";
+"ddb.adapterType = \"%s\"\n";
char desc[1024];
const char *real_filename, *temp_str;
@@ -790,7 +790,7 @@
if ((temp_str = strrchr(real_filename, ':')) != NULL)
real_filename = temp_str + 1;
sprintf(desc, desc_template, time(NULL), (unsigned long)total_size,
-real_filename, (flags & BLOCK_FLAG_COMPAT6 ? 6 : 4), total_size / (63 * 16));
+real_filename, (flags & BLOCK_FLAG_COMPAT6 ? 6 : 4), total_size / (63 * 16), (flags & BLOCK_FLAG_SCSI ? "lsilogic" : "ide"));
/* write the descriptor */
lseek(fd, le64_to_cpu(header.desc_offset) << 9, SEEK_SET);
=== modified file 'block_int.h'
--- block_int.h 2007-12-24 16:10:43 +
+++ block_int.h 2008-01-06 21:18:57 +
@@ -29,6 +29,7 @@
#define BLOCK_FLAG_ENCRYPT 1
#define BLOCK_FLAG_COMPRESS 2
#define BLOCK_FLAG_COMPAT6 4
+#define BLOCK_FLAG_SCSI 8
struct BlockDriver {
const char *format_name;
=== modified file 'qemu-img.c'
--- qemu-img.c 2008-01-06 17:21:48 +
+++ qemu-img.c 2008-01-06 22:04:55 +
@@ -88,9 +88,9 @@
"QEMU disk image utility\n"
"\n"
"Command syntax:\n"
- " create [-e] [-6] [-b base_image] [-f fmt] filename [size]\n"
+ " create [-e] [-6] [-s] [-b base_image] [-f fmt] filename [size]\n"
" commit [-f fmt] filename\n"
- " convert [-c] [-e] [-6] [-f fmt] filename [filename2 [...]] [-O output_fmt] output_filename\n"
+ " convert [-c] [-e] [-6] [-s] [-f fmt] filename [-O output_fmt] output_filename\n"
" info [-f fmt] filename\n"
"\n"
"Command parameters:\n"
@@ -105,6 +105,7 @@
" '-c' indicates that target image must be compressed (qcow format only)\n"
" '-e' indicates that the target image must be encrypted (qcow format only)\n"
" '-6' indicates that the target image must use compatibility level 6 (vmdk format only)\n"
+ " '-s' indicates that the target image must use of type SCSI (vmdk format only)\n"
);
printf("\nSupported format:");
bdrv_iterate_format(format_print, NULL);
@@ -261,6 +262,9 @@
case '6':
flags |= BLOCK_FLAG_COMPAT6;
break;
+case 's':
+flags |= BLOCK_FLAG_SCSI;
+break;
}
}
if (optind >= argc)
@@ -297,6 +301,8 @@
printf(", encrypted");
if (flags & BLOCK_FLAG_COMPAT6)
printf(", compatibility level=6");
+if (flags & BLOCK_FLAG_SCSI)
+printf(", type=scsi");
if (base_filename) {
printf(", backing_file=%s",
base_filename);
@@ -473,6 +479,8 @@
error("Encryption not supported for this file format");
if (flags & BLOCK_FLAG_COMPAT6 && drv != &bdrv_vmdk)
error("Alternative compatibility level not supported for this file format");
+if (flags & BLOCK_FLAG_SCSI && drv != &bdrv_vmdk)
+error("SCSI disks are not supported for this file format");
if (flags & BLOCK_FLAG_ENCRYPT && flags & BLOCK_FLAG_COMPRESS)
error("Compression and encryption not supported at the same time");
signature.asc
Description: Digital signature
[Qemu-devel] QEMU version 0.9.1
Hi, QEMU version 0.9.1 is out ! You can get it from: http://bellard.org/qemu/download.html . Fabrice.
Re: [Qemu-devel] Request for Qemu bugzilla
Well, the bugzilla doesn't have to be on the main site, but a _link_ to the "official" Qemu bugzilla should exist from the main site. -- -Alexey Eremenko "Technologov"
Re: [Qemu-devel] Request for Qemu bugzilla
On Sun, Jan 06, 2008 at 07:56:11PM +, Daniel P. Berrange wrote: Would that be possible to add Qemu bugzilla to the main Qemu site (http://fabrice.bellard.free.fr/qemu/index.html), please ? >>> While QEMU is officially still in alpha stage ;) I'd agree that an >>> issue tracking system can be useful. However I doubt it'll be >>> possible to host a Bugzilla at free.fr. >> I'm sure Launchpad.net would be happy to host QEMU's bug tracking >> system. > It'd be rather strange to host it on Ubuntu bug tracker, It's a common misconception that Launchpad is "Ubuntu bug tracker". Although Ubuntu is the most active project using Launchpad, Launchpad is not specific to Ubuntu at all. There are almost 5000 projects registered on Launchpad. Only one of them is Ubuntu. > given that QEMU is already hosted on the FSF project hosting > infrastructure (http://nongnu.org) which provides bug tracking > services. They're simply not enabled for the QEMU project currently. If I'm not much mistaken, the nongnu.org bug tracker is quite similar to the one on sourceforge? Personally, I find the Sourceforge bug tracker to be quite terrible, so if they are indeed similar, I'd like to put down a loud vote against using it. -- Soren Hansen Ubuntu Server Team http://www.ubuntu.com/ signature.asc Description: Digital signature
[Qemu-devel] [PATCH] qemu manpage: describe arguments of usbdevice option
The patch below improve the manpage by describing the possible arguments
of the usbdevice option. The text is taken from the online
documentation.
Index: qemu-doc.texi
===
RCS file: /sources/qemu/qemu/qemu-doc.texi,v
retrieving revision 1.175
diff -u -d -p -r1.175 qemu-doc.texi
--- qemu-doc.texi 28 Dec 2007 20:59:22 - 1.175
+++ qemu-doc.texi 6 Jan 2008 20:01:29 -
@@ -492,6 +492,28 @@ Enable the USB driver (will be the defau
@item -usbdevice @var{devname}
Add the USB device @var{devname}. @xref{usb_devices}.
+
[EMAIL PROTECTED] @code
+
[EMAIL PROTECTED] mouse
+Virtual Mouse. This will override the PS/2 mouse emulation when activated.
+
[EMAIL PROTECTED] tablet
+Pointer device that uses absolute coordinates (like a touchscreen). This
+means qemu is able to report the mouse position without having to grab the
+mouse. Also overrides the PS/2 mouse emulation when activated.
+
[EMAIL PROTECTED] disk:file
+Mass storage device based on file
+
[EMAIL PROTECTED] host:bus.addr
+Pass through the host device identified by bus.addr (Linux only).
+
[EMAIL PROTECTED] host:vendor_id:product_id
+Pass through the host device identified by vendor_id:product_id (Linux only).
+
[EMAIL PROTECTED] table
+
@end table
Network options:
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
Re: [Qemu-devel] Request for Qemu bugzilla
On Sun, Jan 06, 2008 at 08:12:48PM +0100, Soren Hansen wrote: > On Sun, Jan 06, 2008 at 08:06:28PM +0100, Andreas Färber wrote: > >> I would like to be helpful, and join as a BETA tester to the Qemu > >> community. However, to be effective I need the right tools to > >> successfully accomplish my mission. One tool that I would really like > >> to have is a Qemu bugzilla. > >> > >> Would that be possible to add Qemu bugzilla to the main Qemu site > >> (http://fabrice.bellard.free.fr/qemu/index.html), please ? > > While QEMU is officially still in alpha stage ;) I'd agree that an > > issue tracking system can be useful. However I doubt it'll be > > possible to host a Bugzilla at free.fr. > > I'm sure Launchpad.net would be happy to host QEMU's bug tracking > system. It'd be rather strange to host it on Ubuntu bug tracker, given that QEMU is already hosted on the FSF project hosting infrastructure (http://nongnu.org) which provides bug tracking services. They're simply not enabled for the QEMU project currently. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Re: [Qemu-devel] [PATCH] SCSI passthrough: DVD support
Le dimanche 06 janvier 2008 à 19:47 +0100, Fabrice Bellard a écrit :
> Can you explain why you use the block layer (block-raw-posix.c) to send
> your low level SCSI commands ?
only because it uses asynchrones AIO and I don't want to rewrite
block-raw-posix.c for this special case.
> I suggest to remove your patches to
As you want...
> block-raw-posix.c and to implement all the SCSI passthough in
> scsi-generic.c.
and I'll do as you want.
> Regards,
>
> Fabrice.
Regards,
Laurent
> Laurent Vivier wrote:
> > This patch allows to use SCSI passthrough to read movies from DVD.
> > It has been tested with PowerDVD and XP.
> >
> > It also introduces some comments in block-raw-posix.c to explain behavior of
> > negative offset and negative nb_sectors.
> > It restores original value of aio_num and aio_threads.
> >
> > Laurent
> > ---
> > block-raw-posix.c |7 +--
> > hw/scsi-generic.c | 14 --
> > 2 files changed, 17 insertions(+), 4 deletions(-)
> >
> > Index: qemu/hw/scsi-generic.c
> > ===
> > --- qemu.orig/hw/scsi-generic.c 2008-01-06 18:43:44.0 +0100
> > +++ qemu/hw/scsi-generic.c 2008-01-06 18:55:46.0 +0100
> > @@ -44,9 +44,12 @@ do { fprintf(stderr, "scsi-generic: " fm
> > #include
> > #include
> >
> > +#define BLANK 0xa1
> > +#define SEND_KEY 0xa3
> > +#define REPORT_KEY 0xa4
> > #define LOAD_UNLOAD 0xa6
> > +#define READ_DVD_STRUCTURE 0xad
> > #define SET_CD_SPEED 0xbb
> > -#define BLANK 0xa1
> >
> > #define SCSI_CMD_BUF_SIZE 16
> > #define SCSI_SENSE_BUF_SIZE 32
> > @@ -166,7 +169,7 @@ static void scsi_command_complete(void *
> > sense = s->sensebuf[2] & 0x0f;
> > }
> >
> > -DPRINTF("Command complete 0x%p tag=0x%x sense=%d\n", r, r->tag, sense);
> > +DPRINTF("Command complete %p tag=0x%x sense=%d\n", r, r->tag, sense);
> > tag = r->tag;
> > scsi_remove_request(r);
> > s->completion(s->opaque, SCSI_REASON_DONE, tag, sense);
> > @@ -427,6 +430,12 @@ static int scsi_length(uint8_t *cmd, int
> > case READ_12:
> > *len *= blocksize;
> > break;
> > + case READ_DVD_STRUCTURE:
> > + case SEND_KEY:
> > + case REPORT_KEY:
> > + *len &= 0x;
> > + break;
> > +
> > }
> > return 0;
> > }
> > @@ -464,6 +473,7 @@ static int is_write(int command)
> > case MEDIUM_SCAN:
> > case SEND_VOLUME_TAG:
> > case WRITE_LONG_2:
> > +case SEND_KEY:
> > return 1;
> > }
> > return 0;
> > Index: qemu/block-raw-posix.c
> > ===
> > --- qemu.orig/block-raw-posix.c 2008-01-06 18:43:44.0 +0100
> > +++ qemu/block-raw-posix.c 2008-01-06 18:45:38.0 +0100
> > @@ -151,6 +151,8 @@ static int raw_pread(BlockDriverState *b
> > if (ret < 0)
> > return ret;
> >
> > +/* if offset < 0, we don't make lseek() */
> > +
> > if (offset >= 0 && lseek(s->fd, offset, SEEK_SET) == (off_t)-1) {
> > ++(s->lseek_err_cnt);
> > if(s->lseek_err_cnt <= 10) {
> > @@ -276,8 +278,8 @@ void qemu_aio_init(void)
> > seems to fix the problem. */
> > struct aioinit ai;
> > memset(&ai, 0, sizeof(ai));
> > -ai.aio_threads = 16;
> > -ai.aio_num = 16;
> > +ai.aio_threads = 1;
> > +ai.aio_num = 1;
> > ai.aio_idle_time = 365 * 10;
> > aio_init(&ai);
> > }
> > @@ -387,6 +389,7 @@ static RawAIOCB *raw_aio_setup(BlockDriv
> > acb->aiocb.aio_sigevent.sigev_signo = aio_sig_num;
> > acb->aiocb.aio_sigevent.sigev_notify = SIGEV_SIGNAL;
> > acb->aiocb.aio_buf = buf;
> > +/* if nb_sectors < 0, -nb_sectors is a number of bytes */
> > if (nb_sectors < 0)
> > acb->aiocb.aio_nbytes = -nb_sectors;
> > else
> >
> >
> >
> >
>
>
>
--
- [EMAIL PROTECTED] --
"La perfection est atteinte non quand il ne reste rien à
ajouter mais quand il ne reste rien à enlever." Saint Exupéry
signature.asc
Description: Ceci est une partie de message numériquement signée
Re: [Qemu-devel] Request for Qemu bugzilla
On Sun, Jan 06, 2008 at 08:06:28PM +0100, Andreas Färber wrote: >> I would like to be helpful, and join as a BETA tester to the Qemu >> community. However, to be effective I need the right tools to >> successfully accomplish my mission. One tool that I would really like >> to have is a Qemu bugzilla. >> >> Would that be possible to add Qemu bugzilla to the main Qemu site >> (http://fabrice.bellard.free.fr/qemu/index.html), please ? > While QEMU is officially still in alpha stage ;) I'd agree that an > issue tracking system can be useful. However I doubt it'll be > possible to host a Bugzilla at free.fr. I'm sure Launchpad.net would be happy to host QEMU's bug tracking system. -- Soren Hansen Ubuntu Server Team http://www.ubuntu.com/ signature.asc Description: Digital signature
Re: [Qemu-devel] Request for Qemu bugzilla
Hi, Am 06.01.2008 um 19:56 schrieb Alexey Eremenko: I would like to be helpful, and join as a BETA tester to the Qemu community. However, to be effective I need the right tools to successfully accomplish my mission. One tool that I would really like to have is a Qemu bugzilla. Would that be possible to add Qemu bugzilla to the main Qemu site (http://fabrice.bellard.free.fr/qemu/index.html ), please ? While QEMU is officially still in alpha stage ;) I'd agree that an issue tracking system can be useful. However I doubt it'll be possible to host a Bugzilla at free.fr. Andreas
[Qemu-devel] Request for Qemu bugzilla
Hi all, I would like to be helpful, and join as a BETA tester to the Qemu community. However, to be effective I need the right tools to successfully accomplish my mission. One tool that I would really like to have is a Qemu bugzilla. Would that be possible to add Qemu bugzilla to the main Qemu site ( http://fabrice.bellard.free.fr/qemu/index.html), please ? Thanks in advance, -- -Alexey Eremenko "Technologov", Qumranet QA team member
[Qemu-devel] qemu block-raw-posix.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/01/06 18:53:07 Modified files: . : block-raw-posix.c Log message: restore original values for ai.aio_threads and ai.aio_num CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/block-raw-posix.c?cvsroot=qemu&r1=1.3&r2=1.4
Re: [Qemu-devel] [PATCH] SCSI passthrough: DVD support
Can you explain why you use the block layer (block-raw-posix.c) to send
your low level SCSI commands ? I suggest to remove your patches to
block-raw-posix.c and to implement all the SCSI passthough in
scsi-generic.c.
Regards,
Fabrice.
Laurent Vivier wrote:
> This patch allows to use SCSI passthrough to read movies from DVD.
> It has been tested with PowerDVD and XP.
>
> It also introduces some comments in block-raw-posix.c to explain behavior of
> negative offset and negative nb_sectors.
> It restores original value of aio_num and aio_threads.
>
> Laurent
> ---
> block-raw-posix.c |7 +--
> hw/scsi-generic.c | 14 --
> 2 files changed, 17 insertions(+), 4 deletions(-)
>
> Index: qemu/hw/scsi-generic.c
> ===
> --- qemu.orig/hw/scsi-generic.c 2008-01-06 18:43:44.0 +0100
> +++ qemu/hw/scsi-generic.c2008-01-06 18:55:46.0 +0100
> @@ -44,9 +44,12 @@ do { fprintf(stderr, "scsi-generic: " fm
> #include
> #include
>
> +#define BLANK 0xa1
> +#define SEND_KEY 0xa3
> +#define REPORT_KEY 0xa4
> #define LOAD_UNLOAD 0xa6
> +#define READ_DVD_STRUCTURE 0xad
> #define SET_CD_SPEED 0xbb
> -#define BLANK 0xa1
>
> #define SCSI_CMD_BUF_SIZE 16
> #define SCSI_SENSE_BUF_SIZE 32
> @@ -166,7 +169,7 @@ static void scsi_command_complete(void *
> sense = s->sensebuf[2] & 0x0f;
> }
>
> -DPRINTF("Command complete 0x%p tag=0x%x sense=%d\n", r, r->tag, sense);
> +DPRINTF("Command complete %p tag=0x%x sense=%d\n", r, r->tag, sense);
> tag = r->tag;
> scsi_remove_request(r);
> s->completion(s->opaque, SCSI_REASON_DONE, tag, sense);
> @@ -427,6 +430,12 @@ static int scsi_length(uint8_t *cmd, int
> case READ_12:
> *len *= blocksize;
> break;
> + case READ_DVD_STRUCTURE:
> + case SEND_KEY:
> + case REPORT_KEY:
> + *len &= 0x;
> + break;
> +
> }
> return 0;
> }
> @@ -464,6 +473,7 @@ static int is_write(int command)
> case MEDIUM_SCAN:
> case SEND_VOLUME_TAG:
> case WRITE_LONG_2:
> +case SEND_KEY:
> return 1;
> }
> return 0;
> Index: qemu/block-raw-posix.c
> ===
> --- qemu.orig/block-raw-posix.c 2008-01-06 18:43:44.0 +0100
> +++ qemu/block-raw-posix.c2008-01-06 18:45:38.0 +0100
> @@ -151,6 +151,8 @@ static int raw_pread(BlockDriverState *b
> if (ret < 0)
> return ret;
>
> +/* if offset < 0, we don't make lseek() */
> +
> if (offset >= 0 && lseek(s->fd, offset, SEEK_SET) == (off_t)-1) {
> ++(s->lseek_err_cnt);
> if(s->lseek_err_cnt <= 10) {
> @@ -276,8 +278,8 @@ void qemu_aio_init(void)
> seems to fix the problem. */
> struct aioinit ai;
> memset(&ai, 0, sizeof(ai));
> -ai.aio_threads = 16;
> -ai.aio_num = 16;
> +ai.aio_threads = 1;
> +ai.aio_num = 1;
> ai.aio_idle_time = 365 * 10;
> aio_init(&ai);
> }
> @@ -387,6 +389,7 @@ static RawAIOCB *raw_aio_setup(BlockDriv
> acb->aiocb.aio_sigevent.sigev_signo = aio_sig_num;
> acb->aiocb.aio_sigevent.sigev_notify = SIGEV_SIGNAL;
> acb->aiocb.aio_buf = buf;
> +/* if nb_sectors < 0, -nb_sectors is a number of bytes */
> if (nb_sectors < 0)
> acb->aiocb.aio_nbytes = -nb_sectors;
> else
>
>
>
>
[Qemu-devel] qemu configure Makefile.target
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/01/06 18:27:58 Modified files: . : configure Makefile.target Log message: fixed ppc64abi32 executable name CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemu&r1=1.177&r2=1.178 http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemu&r1=1.237&r2=1.238
[Qemu-devel] qemu Makefile
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/01/06 18:27:12 Modified files: . : Makefile Log message: update binary distribution CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile?cvsroot=qemu&r1=1.139&r2=1.140
[Qemu-devel] [PATCH] SCSI passthrough: DMA split
With some emulated SCSI devices, like usb-storage or ide-scsi, DMA transfers
are limited to 64 kiB or 32 kiB.
This patch allows to split a READ or WRITE into several READ or WRITE.
Laurent
---
hw/scsi-generic.c | 104 +++---
1 file changed, 100 insertions(+), 4 deletions(-)
Index: qemu/hw/scsi-generic.c
===
--- qemu.orig/hw/scsi-generic.c 2008-01-04 18:01:14.0 +0100
+++ qemu/hw/scsi-generic.c 2008-01-04 18:06:21.0 +0100
@@ -61,6 +61,8 @@ do { fprintf(stderr, "scsi-generic: " fm
#define MAX_UINT ((unsigned int)-1)
#endif
+#define MAX_CHUNK 65536
+
typedef struct SCSIRequest {
BlockDriverAIOCB *aiocb;
struct SCSIRequest *next;
@@ -72,6 +74,8 @@ typedef struct SCSIRequest {
int buflen;
int len;
sg_io_hdr_t io_header;
+int remaining;
+int offset;
} SCSIRequest;
struct SCSIDeviceState
@@ -84,6 +88,7 @@ struct SCSIDeviceState
void *opaque;
int driver_status;
uint8_t sensebuf[SCSI_SENSE_BUF_SIZE];
+int max_chunk;
};
/* Global pool of SCSIRequest structures. */
@@ -101,6 +106,7 @@ static SCSIRequest *scsi_new_request(SCS
r->buf = NULL;
r->buflen = 0;
}
+r->offset = 0;
r->dev = s;
r->tag = tag;
memset(r->cmd, 0, sizeof(r->cmd));
@@ -191,24 +197,90 @@ static void scsi_cancel_io(SCSIDevice *d
}
}
+static void scsi_cmd_next(uint8_t *cmd, uint32_t inc)
+{
+uint32_t addr;
+switch (cmd[0] >> 5) {
+case 0:
+addr = cmd[3] | (cmd[2] << 8);
+addr += inc;
+cmd[2] = addr >> 8;
+cmd[3] = addr;
+break;
+case 1:
+case 2:
+case 4:
+case 5:
+addr = cmd[5] | ((cmd[4] << 8) | ((cmd[3] << 16) | (cmd[2] << 24)));
+addr += inc;
+cmd[2] = addr >> 24;
+cmd[3] = addr >> 16;
+cmd[4] = addr >> 8;
+cmd[5] = addr;
+break;
+}
+}
+static void scsi_set_length(uint8_t *cmd, uint32_t len)
+{
+switch (cmd[0] >> 5) {
+case 0:
+cmd[4] = len;
+break;
+case 1:
+case 2:
+cmd[7] = (len >> 8);
+cmd[8] = len;
+break;
+case 4:
+cmd[10] = len >> 24;
+cmd[11] = len >> 16;
+cmd[12] = len >> 8;
+cmd[13] = len;
+break;
+case 5:
+cmd[6] = len >> 24;
+cmd[7] = len >> 16;
+cmd[8] = len >> 8;
+cmd[9] = len;
+break;
+}
+}
+
static int execute_command(BlockDriverState *bdrv,
SCSIRequest *r, int direction,
BlockDriverCompletionFunc *complete)
{
+SCSIDeviceState *s = r->dev;
+r->remaining = 0;
+retry:
+if (s->max_chunk && r->buflen > s->max_chunk) {
+r->remaining = r->buflen - s->max_chunk;
+scsi_set_length(r->cmd, s->max_chunk / s->blocksize);
+r->buflen = s->max_chunk;
+}
r->io_header.interface_id = 'S';
r->io_header.dxfer_direction = direction;
-r->io_header.dxferp = r->buf;
+r->io_header.dxferp = r->buf + r->offset;
r->io_header.dxfer_len = r->buflen;
r->io_header.cmdp = r->cmd;
r->io_header.cmd_len = r->cmdlen;
-r->io_header.mx_sb_len = sizeof(r->dev->sensebuf);
-r->io_header.sbp = r->dev->sensebuf;
+r->io_header.mx_sb_len = sizeof(s->sensebuf);
+r->io_header.sbp = s->sensebuf;
r->io_header.timeout = MAX_UINT;
r->io_header.usr_ptr = r;
r->io_header.flags |= SG_FLAG_DIRECT_IO;
if (bdrv_pwrite(bdrv, -1, &r->io_header, sizeof(r->io_header)) == -1) {
+if (errno == 12) {
+if (!s->max_chunk) {
+s->max_chunk = MAX_CHUNK;
+goto retry;
+} else if (s->max_chunk > s->blocksize) {
+s->max_chunk >>= 1;
+goto retry;
+}
+}
BADF("execute_command: write failed ! (%d)\n", errno);
return -1;
}
@@ -246,7 +318,18 @@ static void scsi_read_complete(void * op
scsi_command_complete(r, ret);
return;
}
-len = r->io_header.dxfer_len - r->io_header.resid;
+r->offset += r->io_header.dxfer_len - r->io_header.resid;
+if (r->remaining != 0) {
+scsi_cmd_next(r->cmd, r->buflen / s->blocksize);
+scsi_set_length(r->cmd, r->remaining / s->blocksize);
+r->buflen = r->remaining;
+ret = execute_command(s->bdrv, r, SG_DXFER_FROM_DEV,
+ scsi_read_complete);
+if (ret == -1)
+scsi_command_complete(r, -EINVAL);
+return;
+}
+len = r->offset;
DPRINTF("Data ready tag=0x%x len=%d\n", r->tag, len);
r->len = -1;
@@ -293,6 +376,7 @@ static void scsi_read_data(SCSIDevice *d
static void scsi_write_complete(void * opaque, int ret)
{
SCSIRequest *r = (SCSIRequest *)opaque;
+SCSIDeviceState *s = r->dev;
DPRINTF("scsi_write_complete() ret = %d
[Qemu-devel] [PATCH] SCSI passthrough: DVD support
This patch allows to use SCSI passthrough to read movies from DVD.
It has been tested with PowerDVD and XP.
It also introduces some comments in block-raw-posix.c to explain behavior of
negative offset and negative nb_sectors.
It restores original value of aio_num and aio_threads.
Laurent
---
block-raw-posix.c |7 +--
hw/scsi-generic.c | 14 --
2 files changed, 17 insertions(+), 4 deletions(-)
Index: qemu/hw/scsi-generic.c
===
--- qemu.orig/hw/scsi-generic.c 2008-01-06 18:43:44.0 +0100
+++ qemu/hw/scsi-generic.c 2008-01-06 18:55:46.0 +0100
@@ -44,9 +44,12 @@ do { fprintf(stderr, "scsi-generic: " fm
#include
#include
+#define BLANK 0xa1
+#define SEND_KEY 0xa3
+#define REPORT_KEY 0xa4
#define LOAD_UNLOAD 0xa6
+#define READ_DVD_STRUCTURE 0xad
#define SET_CD_SPEED 0xbb
-#define BLANK 0xa1
#define SCSI_CMD_BUF_SIZE 16
#define SCSI_SENSE_BUF_SIZE 32
@@ -166,7 +169,7 @@ static void scsi_command_complete(void *
sense = s->sensebuf[2] & 0x0f;
}
-DPRINTF("Command complete 0x%p tag=0x%x sense=%d\n", r, r->tag, sense);
+DPRINTF("Command complete %p tag=0x%x sense=%d\n", r, r->tag, sense);
tag = r->tag;
scsi_remove_request(r);
s->completion(s->opaque, SCSI_REASON_DONE, tag, sense);
@@ -427,6 +430,12 @@ static int scsi_length(uint8_t *cmd, int
case READ_12:
*len *= blocksize;
break;
+ case READ_DVD_STRUCTURE:
+ case SEND_KEY:
+ case REPORT_KEY:
+ *len &= 0x;
+ break;
+
}
return 0;
}
@@ -464,6 +473,7 @@ static int is_write(int command)
case MEDIUM_SCAN:
case SEND_VOLUME_TAG:
case WRITE_LONG_2:
+case SEND_KEY:
return 1;
}
return 0;
Index: qemu/block-raw-posix.c
===
--- qemu.orig/block-raw-posix.c 2008-01-06 18:43:44.0 +0100
+++ qemu/block-raw-posix.c 2008-01-06 18:45:38.0 +0100
@@ -151,6 +151,8 @@ static int raw_pread(BlockDriverState *b
if (ret < 0)
return ret;
+/* if offset < 0, we don't make lseek() */
+
if (offset >= 0 && lseek(s->fd, offset, SEEK_SET) == (off_t)-1) {
++(s->lseek_err_cnt);
if(s->lseek_err_cnt <= 10) {
@@ -276,8 +278,8 @@ void qemu_aio_init(void)
seems to fix the problem. */
struct aioinit ai;
memset(&ai, 0, sizeof(ai));
-ai.aio_threads = 16;
-ai.aio_num = 16;
+ai.aio_threads = 1;
+ai.aio_num = 1;
ai.aio_idle_time = 365 * 10;
aio_init(&ai);
}
@@ -387,6 +389,7 @@ static RawAIOCB *raw_aio_setup(BlockDriv
acb->aiocb.aio_sigevent.sigev_signo = aio_sig_num;
acb->aiocb.aio_sigevent.sigev_notify = SIGEV_SIGNAL;
acb->aiocb.aio_buf = buf;
+/* if nb_sectors < 0, -nb_sectors is a number of bytes */
if (nb_sectors < 0)
acb->aiocb.aio_nbytes = -nb_sectors;
else
[Qemu-devel] qemu qemu-img.c vl.c linux-user/main.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/01/06 17:21:49 Modified files: . : qemu-img.c vl.c linux-user : main.c Log message: copyright update CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-img.c?cvsroot=qemu&r1=1.27&r2=1.28 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemu&r1=1.393&r2=1.394 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemu&r1=1.158&r2=1.159
[Qemu-devel] qemu Changelog VERSION
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/01/06 17:10:54 Modified files: . : Changelog VERSION Log message: version change CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Changelog?cvsroot=qemu&r1=1.150&r2=1.151 http://cvs.savannah.gnu.org/viewcvs/qemu/VERSION?cvsroot=qemu&r1=1.31&r2=1.32
Re: [Qemu-devel] [PATCH] Let user set vnc password from command line or file
On Sun, Jan 06, 2008 at 11:45:58AM +0100, Leandro Dardini wrote: > Here is a little patch to let the user specify the vnc server password > in the command line (yes, it is visible with the ps command) or via an > external file (better choice). This adds two new arguments, > -vnc-password and -vnc-password-file. The file containing the vnc > password is in clear. Providing a password which is clearly visible on the command line to all users of a machine is unacceptable. This capability was *explicitly* left out when I did the original VNC password support in QEMU. Providing a password via a file is reasonable, but this should be made more general than just VNC. QCow2 disks files can be encrypted and require passwords too. So I think it'd be more useful to have a '-passwd-file file' arg, and in that file have 1 line per (device, password) pair. eg Assuming use of VNC, and 2 qcow encrypted disks one might have: vnc: 123456 hda: mysecret hdb: othersecret Perhaps 'hda' should be the more general syntax used by the -drive param instead, or even the qcow file name... Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
[Qemu-devel] [PATCH] sparc32: add ecc irq
Index: hw/eccmemctl.c
===
RCS file: /sources/qemu/qemu/hw/eccmemctl.c,v
retrieving revision 1.2
diff -p -u -r1.2 eccmemctl.c
--- hw/eccmemctl.c 1 Jan 2008 17:06:38 - 1.2
+++ hw/eccmemctl.c 6 Jan 2008 15:03:52 -
@@ -68,7 +68,7 @@
#define ECC_FAR0_TYPE 0x00f0 /* Transaction type */
#define ECC_FAR0_SIZE 0x0700 /* Transaction size */
#define ECC_FAR0_CACHE 0x0800 /* Mapped cacheable */
-#define ECC_FAR0_LOCK 0x1000 /* Error occurred in attomic cycle */
+#define ECC_FAR0_LOCK 0x1000 /* Error occurred in atomic cycle */
#define ECC_FAR0_BMODE 0x2000 /* Boot mode */
#define ECC_FAR0_VADDR 0x003fc000 /* VA[12-19] (superset bits) */
#define ECC_FAR0_S 0x0800 /* Supervisor mode */
@@ -90,6 +90,7 @@
#define ECC_ADDR_MASK (ECC_SIZE - 1)
typedef struct ECCState {
+qemu_irq irq;
uint32_t regs[ECC_NREGS];
} ECCState;
@@ -222,7 +223,7 @@ static void ecc_reset(void *opaque)
s->regs[i] = 0;
}
-void * ecc_init(target_phys_addr_t base, uint32_t version)
+void * ecc_init(target_phys_addr_t base, qemu_irq irq, uint32_t version)
{
int ecc_io_memory;
ECCState *s;
@@ -232,6 +233,7 @@ void * ecc_init(target_phys_addr_t base,
return NULL;
s->regs[0] = version;
+s->irq = irq;
ecc_io_memory = cpu_register_io_memory(0, ecc_mem_read, ecc_mem_write, s);
cpu_register_physical_memory(base, ECC_SIZE, ecc_io_memory);
Index: hw/sun4m.c
===
RCS file: /sources/qemu/qemu/hw/sun4m.c,v
retrieving revision 1.80
diff -p -u -r1.80 sun4m.c
--- hw/sun4m.c 6 Jan 2008 07:50:38 - 1.80
+++ hw/sun4m.c 6 Jan 2008 15:03:52 -
@@ -91,7 +91,7 @@ struct hwdef {
// IRQ numbers are not PIL ones, but master interrupt controller
// register bit numbers
int intctl_g_intr, esp_irq, le_irq, clock_irq, clock1_irq;
-int ser_irq, ms_kb_irq, fd_irq, me_irq, cs_irq;
+int ser_irq, ms_kb_irq, fd_irq, me_irq, cs_irq, ecc_irq;
int machine_id; // For NVRAM
uint32_t iommu_version;
uint32_t intbit_to_level[32];
@@ -528,7 +528,8 @@ static void sun4m_hw_init(const struct h
graphic_height, graphic_depth, hwdef->machine_id, "Sun4m");
if (hwdef->ecc_base != (target_phys_addr_t)-1)
-ecc_init(hwdef->ecc_base, hwdef->ecc_version);
+ecc_init(hwdef->ecc_base, slavio_irq[hwdef->ecc_irq],
+ hwdef->ecc_version);
}
static void sun4c_hw_init(const struct hwdef *hwdef, int RAM_size,
@@ -742,6 +743,7 @@ static const struct hwdef hwdefs[] = {
.fd_irq = 22,
.me_irq = 30,
.cs_irq = -1,
+.ecc_irq = 28,
.machine_id = 0x72,
.iommu_version = 0x0300,
.intbit_to_level = {
@@ -783,6 +785,7 @@ static const struct hwdef hwdefs[] = {
.fd_irq = 22,
.me_irq = 30,
.cs_irq = -1,
+.ecc_irq = 28,
.machine_id = 0x71,
.iommu_version = 0x0100,
.intbit_to_level = {
@@ -824,6 +827,7 @@ static const struct hwdef hwdefs[] = {
.fd_irq = 22,
.me_irq = 30,
.cs_irq = -1,
+.ecc_irq = 28,
.machine_id = 0x72,
.iommu_version = 0x1300,
.intbit_to_level = {
Index: hw/sun4m.h
===
RCS file: /sources/qemu/qemu/hw/sun4m.h,v
retrieving revision 1.8
diff -p -u -r1.8 sun4m.h
--- hw/sun4m.h 1 Jan 2008 17:04:45 - 1.8
+++ hw/sun4m.h 6 Jan 2008 15:03:53 -
@@ -81,6 +81,6 @@ void lance_init(NICInfo *nd, target_phys
qemu_irq irq, qemu_irq *reset);
/* eccmemctl.c */
-void *ecc_init(target_phys_addr_t base, uint32_t version);
+void *ecc_init(target_phys_addr_t base, qemu_irq irq, uint32_t version);
#endif
Re: [Qemu-devel] [RESEND] [PATCH] ide: fix GET_CONFIGURATION DVD-ROM support
Am 06.01.2008 um 14:57 schrieb Stuart Brady: On Sat, Jan 05, 2008 at 08:22:33PM -0600, Carlo Marcelo Arenas Belon wrote: the exact number of sectors is really not that relevant, as the whole point here is to try to detect if it is a CD (700MB) or a DVD (4.7GB) and the logic is just assuming that if it has more sectors than you should normally expect in a CD, then it is a DVD. My answer was quite relevant to Rob's question, which was "Where does the constant come from, anyway?" As for the code, there's a choice between using an incorrect value, and correctly detecting for the vast majority of cases, and using the correct value and correctly detecting for 100% of cases. Perhaps "only marginally broken" is "good enough", seeing as nobody's complained. Either way, shouldn't it be a preprocessor define rather than a magic number, maybe something like MAX_SECTORS_CD? Then it can more easily be found and changed, where necessary.
Re: [Qemu-devel] [RESEND] [PATCH] ide: fix GET_CONFIGURATION DVD-ROM support
On Sat, Jan 05, 2008 at 08:22:33PM -0600, Carlo Marcelo Arenas Belon wrote: > the exact number of sectors is really not that relevant, as the whole point > here is to try to detect if it is a CD (700MB) or a DVD (4.7GB) and the logic > is just assuming that if it has more sectors than you should normally expect > in a CD, then it is a DVD. My answer was quite relevant to Rob's question, which was "Where does the constant come from, anyway?" As for the code, there's a choice between using an incorrect value, and correctly detecting for the vast majority of cases, and using the correct value and correctly detecting for 100% of cases. Perhaps "only marginally broken" is "good enough", seeing as nobody's complained. > but I had already enough problems trying to get this > merged without trying to change the code that much to try to guess a better > magic number than the one was originally used (I like 144 though) Sorry, but did anyone complain? No. -- Stuart Brady
Re: [Qemu-devel] [PATCH] fix possible NULL pointer use in hw/ptimer.c
Markus Hitter wrote: Quite obviously, we have very different expectations on what executables should do. I expect code to be as reliable as possible, to be careful when aquiring resources and if a process would ever happen to make my computer spontanuously reboot, I'd throw that binary as far away as possible and warn everybody else not to even touch this thing. If a user program causes your computer to spontaneously reboot, you should throw away your OS instead of that program. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH] Let user set vnc password from command line or file
Here is a little patch to let the user specify the vnc server password
in the command line (yes, it is visible with the ps command) or via an
external file (better choice). This adds two new arguments,
-vnc-password and -vnc-password-file. The file containing the vnc
password is in clear.
Please let me know if there is any writing rule I was not following,
I'll be glad to modify the patch accordingly. I was doubtful whether to
use a straight fopen or the QEMU_fopen. Let me know the difference.
Thank you
Leandro
diff -u -p vl.c.orig vl.c
--- vl.c.orig 2008-01-05 01:17:53.0 +0100
+++ vl.c2008-01-06 12:17:11.0 +0100
@@ -7606,6 +7606,8 @@ static void help(int exitcode)
"-no-reboot exit instead of rebooting\n"
"-loadvm filestart right away with a saved state (loadvm
in monitor)\n"
"-vnc displaystart a VNC server on display\n"
+ "-vnc-password passwordset VNC server password\n"
+ "-vnc-password-file file set VNC server password (in clear)
from file\n"
#ifndef _WIN32
"-daemonize daemonize QEMU after initializing\n"
#endif
@@ -7717,6 +7719,8 @@ enum {
QEMU_OPTION_old_param,
QEMU_OPTION_clock,
QEMU_OPTION_startdate,
+QEMU_OPTION_vnc_password,
+QEMU_OPTION_vnc_password_file,
};
typedef struct QEMUOption {
@@ -7803,6 +7807,8 @@ const QEMUOption qemu_options[] = {
{ "usbdevice", HAS_ARG, QEMU_OPTION_usbdevice },
{ "smp", HAS_ARG, QEMU_OPTION_smp },
{ "vnc", HAS_ARG, QEMU_OPTION_vnc },
+{ "vnc-password", HAS_ARG, QEMU_OPTION_vnc_password },
+{ "vnc-password-file", HAS_ARG, QEMU_OPTION_vnc_password_file },
/* temporary options */
{ "usb", 0, QEMU_OPTION_usb },
@@ -8085,6 +8091,9 @@ int main(int argc, char **argv)
int fds[2];
const char *pid_file = NULL;
VLANState *vlan;
+char vnc_password[9];
+FILE *fd_vnc_password_file;
+const char *vnc_password_file = NULL;
LIST_INIT (&vm_change_state_head);
#ifndef _WIN32
@@ -8580,6 +8589,13 @@ int main(int argc, char **argv)
case QEMU_OPTION_vnc:
vnc_display = optarg;
break;
+ case QEMU_OPTION_vnc_password:
+ strncpy(vnc_password,optarg,8);
+ vnc_password[8] = '\0';
+break;
+ case QEMU_OPTION_vnc_password_file:
+ vnc_password_file = optarg;
+ break;
case QEMU_OPTION_no_acpi:
acpi_enabled = 0;
break;
@@ -8849,8 +8865,21 @@ int main(int argc, char **argv)
dumb_display_init(ds);
} else if (vnc_display != NULL) {
vnc_display_init(ds);
+ if (vnc_password_file != NULL) {
+ fd_vnc_password_file = fopen(vnc_password_file, "r");
+ if (!fd_vnc_password_file) {
+ fprintf(stderr, "qemu: could not open vnc server password
file '%s'\n", vnc_password_file);
+ exit(1);
+ }
+ fgets(vnc_password,9,fd_vnc_password_file);
+ if (vnc_password[strlen(vnc_password) - 1] == '\n')
+ vnc_password[strlen(vnc_password) - 1] = '\0';
+ fclose(fd_vnc_password_file);
+ }
+ if (vnc_password && vnc_password[0])
+ vnc_display_password(NULL,vnc_password);
if (vnc_display_open(ds, vnc_display) < 0)
-exit(1);
+ exit(1);
} else {
#if defined(CONFIG_SDL)
sdl_display_init(ds, full_screen, no_frame);
Re: [Qemu-devel] [RESEND] [PATCH] ide: fix GET_CONFIGURATION DVD-ROM support
I re-downloaded the GNU/Solaris preview CD, linked from here: http://lwn.net/Articles/256737/ And fired it up: qemu -cdrom solaris-preview.iso -boot d -m 256 Note that it won't boot with the default 128 megs, because Solaris is a pig. Without the patch at the start of this thread, the GNU/Solaris boot hangs. With this patch, it boots just fine. On Friday 04 January 2008 21:36:41 Carlo Marcelo Arenas Belon wrote: > On Fri, Jan 04, 2008 at 06:25:25PM -0600, Rob Landley wrote: > > On Friday 04 January 2008 04:02:07 Carlo Marcelo Arenas Belon wrote: > > > > padstr8(buf + 8, 8, "QEMU"); > > > > -padstr8(buf + 16, 16, "QEMU CD-ROM"); > > > > +padstr8(buf + 16, 16, "QEMU DVD-ROM"); > > > > padstr8(buf + 32, 4, QEMU_VERSION); > > > > I take it Solaris is actually checking these strings? Or is this a > > cosmetic change? (Not a _bad_ change, I'm just curious.) > > this is just cosmetic. Ok. > > > > @@ -1648,17 +1649,27 @@ static void ide_atapi_cmd(IDEState *s) > > > > ASC_INV_FIELD_IN_CMD_PACKET); > > > > break; > > > > } > > > > -memset(buf, 0, 32); > > > > This moved a few lines down, but that just seems to be churn. > > it is structured in a way that could be later structured away into a > function when/if more profiles are added. Makes sense. > > > > +max_len = ube16_to_cpu(packet + 7); > > > > Why are you doing math on a value _before_ you adjust its endianness from > > a potentially foreign format into the CPU native one? I take it that > > gives you a pointer from which a 16 byte value is fetched? > > yes, this adds not to the value but the pointer where the packet is stored > and that contains on byte 7 (MSB) and 8 (LSB) the value for the Allocation > Length parameter as described in Table 275 of T10/1836-D Revision 1 (*) Is dereferencing a word value at an odd address alignment safe on all the potential host platforms? (I dunno if qemu runs on an arm host, nor if the ube16_to_cpu value is already dealing with this. Just curious.) > > > > -buf[3] = 16; > > > > The new code doesn't directly set buf[3] anymore, leaving it 0 from the > > memset. I take it this is now handled by the cpu_to_ube32() targeting 4 > > bytes of buf[] much later? > > yes, the response as described in Table 277 of T10/1836-D Revision 1 > contains a 4 byte "Data Length" field (LSB is byte 3) and I am calculating > it at the end instead of hardcoding it at the beginning, so that this code > could adapt if later extended to add more profiles (CD-RW, HD-DVD, ..). Ok. > > > > -buf[7] = total_sectors <= 1433600 ? 0x08 : 0x10; /* > > > > current profile */ > > > > This becomes 3-state now. You added a state 0 when there's no cdrom in > > the drive. The less intrusive change would be keeping the above line and > > adding a second line: "if (!total_sectors) buf[7] = 0;" Not actually any > > larger, codewise, and a less intrusive change. > > I refactored this code so that it is hopefully more clear in the intended > effect, which is to set the default profile to either of the available > profiles depending on the kind of media that was available, and as it is > done by real hardware. > > Again, even if the refactoring was more of an intrusive change, it also > allows for more flexibility to expand this code to support more profiles in > a cleaner way. I take it buf[7]=0 is what real hardware returns when there's no disk in the drive? > > > > -buf[10] = 0x10 | 0x1; > > > > This turns into 0x02 | 0x01 further down. Why the change? > > the original implementation got the bits to be enabled in the flags wrong, > 0x10 is part of the Version Field and is meant to be 0 as detailed in table > 87 of T10/1836-D Revision 1. Explicit bug fix. Check. > > > > buf[17] = 0x08; /* CD-ROM profile */ > > > > -buf[18] = buf[7] == 0x08; /* (in)active */ > > > > -ide_atapi_cmd_reply(s, 32, 32); > > > > +buf[18] = buf[17] == buf[7]; /* (in)active */ > > > > Again, the added line is not actually a change. What's the difference? > > I think it is clearer this way, and matches better the wording of the > specification which says : > > "The CurrentP bit when set to one, shall indicate that this profile is > currently active. If no mediums is present, no profile should be active" Not sure how that part addresses the question, but you address it in the next hunk. > > > > +len = 8 + 4 + buf[11]; /* headers + size of profile list > > > > */ > > > > Once again, buf[11] is a constant (0x08) that you just set above. So > > this is actually a constant value, but unless the constant propagation is > > good enough to track individual array members, you're forcing the machine > > to do unnecessary math. Is there a reason for this? > > It is clearer on why the size of the response includes the profile > definitions plus the
