Re: [Qemu-devel] [PATCH] bdrv_flush error handling

2008-02-21 Thread risc
On Thu, Feb 21, 2008 at 05:24:10PM +, Daniel P. Berrange wrote:
 On Thu, Feb 21, 2008 at 12:19:22PM -0500, Ben Taylor wrote:
  
   Daniel P. Berrange [EMAIL PROTECTED] wrote: 
   On Wed, Feb 20, 2008 at 03:53:46PM +, Ian Jackson wrote:
   Content-Description: message body text
bdrv_flush is declared to return void, but this is wrong because it
means that the implementations have nowhere to report their errors.
Indeed, the implementations generally ignore errors.

This patch corrects this by making it return int (implicitly, either 0
or -errno, as for other similar functions).  All of the
implementations and callers are adjusted too.


While looking at this I was surprised to see this:

static void scsi_write_complete(void * opaque, int ret)
...
if (ret) {
fprintf(stderr, scsi-disc: IO write error\n);
exit(1);
}

Surely that is overkill ?
   
   Yes, any i/o errors I'd expect to be propagated back up to the guest
   OS as the most appropriate IDE / SCSI error code.
   
Also, in block-raw-posix.c, raw_pwrite et al seem to return -1 on
error (the return value from write) whereas the other block read/write
methods return errno values.  This is a mistake, surely ?  -1 would be
-EPERM.  If any of the callers did anything with these return values
you'd get incorrect error indications.


Finally, it would perhaps be best if the block device emulators wrote
to the qemu console to complain if they give write errors.  Otherwise
the errno value and other important information will be lost, which
makes debugging hard.
   
   If by 'qemu console' you mean stderr, then fine, but please don't
   spew log messages to the  monitor console, because that'll make it
   very hard to interact with reliably from management tools. 
  
  Would it make sense to have a log messages screen associated with
  the monitor (like Ctrl-Alt-7) to deal with those sorts of things?
 
 Why invent a new special QEMU log screen, when stderr works just fine. If an
 app wants to capture log messages they just capture stderr and persist it.
 We already capture stderr for exactly this reason in libvirt when managing
 QEMU instances.
 
 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  -=| 
 

Please excuse my intrusion in this thread, but I'm a user of the new
ncurses user interface. when ssh'd in, running qemu, I don't believe 
having messages pop out of stderr and over the current screen contents is 
the appropriate behavior, as it sounds to me like it would cause redraw 
defects in the normal text console (via ncurses)

Julia Longtin [EMAIL PROTECTED]





Re: [Qemu-devel] [PATCH 1/3] Add args to -cdrom to define where is connected the cdrom

2007-10-29 Thread risc
On Mon, Oct 29, 2007 at 03:02:21PM +0100, Laurent Vivier wrote:
 Daniel P. Berrange a écrit :
 On Sun, Oct 28, 2007 at 11:43:33PM +0100, [EMAIL PROTECTED] wrote:
 From: Laurent Vivier [EMAIL PROTECTED](none)
 
 This patch allows to define where is connected the CDROM device (bus,
 unit).
 It extends the -cdrom syntax to add these paramaters:
 
  -cdrom file[,if=type][,bus=n][,unit=m]
 
  where type defines the interface (by default, ide)
n defines the bus number (by default 1)
m defines the unit number (by default 0)
 
 
 Having a separately named arg just for CDROMs was always rather 
 odd/unhelpful.
 I'd suggest that we leave all the -hda,hdb,hdc,-cdrom,-fda,-fdb etc 
 unchanged
 and use the -disk for setting up all types of disks, floppys, cdroms, etc. 
 It
 would just require one extra field for the -disk arg:
 
   -disk file[,if=type][,bus=n][,unit=m][,mode=mode]
  
   where type defines the interface. [ide,scsi,fd] (by default, ide)
 n defines the bus number (by default 1)
 m defines the unit number (by default 0)
 mode defines one of [disk,floppy,cdrom]
 
 If we ever up able to emulate other types of SCSI / IDE devices (tape 
 drives,
 cdr, dvd perhaps) then the 'mode' can easily be extended to cover them.
 
 I agree with that. And if everyone agrees I can modify patches to do that...
 
 Laurent
 -- 
  [EMAIL PROTECTED]  -
 Given enough eyeballs, all bugs are shallow E. S. Raymond
 
 
 
not to be rude, but my version of the scsi patch supports three controllers,
for a total of 21 disks. might i reccomend you impliment -disk with a 
controller,
bus, target syntax, ALA sun?

Julia Longtin [EMAIL PROTECTED]




Re: [Qemu-devel] Using Microsoft-provided Windows images

2007-08-01 Thread risc
on x86, qemu by default does not emulate a scsi device.

if you look at my last set of postings, you will see a patch set for adding 
scsi controllers on demand.

its got some code formatting issues, so i understand why it hasnt been merged 
as of yet. i intend to publish a new version in the next couple of days.

Julia Longtin [EMAIL PROTECTED]

On Wed, Aug 01, 2007 at 04:33:31PM +0200, GUERRAZ Francois wrote:
 Hello.
 
 Micro$oft's 64bits OSes are known to be problematic w/ kvm.
 
 I guess that the main problem w/ Qemu is that Microsoft Virtual Server
 can emulate a SCSI controller and Qemu cannot... I havent checked but I
 bet they installed their VM's with just SCSI drivers...
 Try to install IDE drivers from VM Ware and then to boot from QEMU.
 Also, try to disable ACPI (update the computer driver to Standard PC
 if available)
 
 Regards,
 
 François.
 
 Le mercredi 01 août 2007 à 23:35 +0930, Dan Shearer a écrit :
  I have been playing around with the demonstration Windows images
  downloadable from Microsoft just to see how hard it would be to use the
  OSs they provide. The images are designed for Microsoft Virtual Server,
  but can be successfully converted to qcow2 and vhdx using qemu-img. QEMU
  won't boot the images (not a difficult problem, I think) but VMware can.
  I'll try other free virtualisation systems at some point.
  
  See http://shearer.org/Microsoft_Demo_VMs for my notes so far.
  
 
 
 




[Qemu-devel] -disk patch

2007-07-24 Thread risc
the attached patch is a re-hash of the old -disk patch against current CVS.

things it does(on X86):
adds a -disk scsi,hba=ADAPTER_NO,id=SCSI_ID,img=DISK_IMAGE,type=disk syntax, 
for specifying scsi devices.
supports the old -hd[a-d] arguments.
supports using -cdrom twice, creating two cdrom devices on the second IDE 
channel.
supports multiple adapters. i coded for four, but can only get 3 working under 
linux, due to the driver in linux not supporting sharing the IRQ.

things it dosent do:
bochbios and linuxbios don't support booting off of a scsi disk.
-cdrom can't create a device on the primary controller. i'm suspecting irq 
routing, or somesuch.
the scsi driver still dosent support devices [8..15].

with this patch, i'm running a qemu session with one IDE disk, two cdroms, and 
21[!] scsi disks.

comments, suggestions, etc welcome.

Julia Longtin [EMAIL PROTECTED]





[Qemu-devel] -disk patch

2007-07-24 Thread risc
Lets try this again. (forgot to attach patch! )

the attached patch is a re-hash of the old -disk patch against current CVS.

things it does(on X86):
adds a -disk scsi,hba=ADAPTER_NO,id=SCSI_ID,img=DISK_IMAGE,type=disk syntax, 
for specifying scsi devices.
supports the old -hd[a-d] arguments.
supports using -cdrom twice, creating two cdrom devices on the second IDE 
channel.
supports multiple adapters. i coded for four, but can only get 3 working under 
linux, due to the driver in linux not supporting sharing the IRQ.

things it dosent do:
bochbios and linuxbios don't support booting off of a scsi disk.
-cdrom can't create a device on the primary controller. i'm suspecting irq 
routing, or somesuch.
the scsi driver still dosent support devices [8..15].

with this patch, i'm running a qemu session with one IDE disk, two cdroms, and 
21[!] scsi disks.

comments, suggestions, etc welcome.

Julia Longtin [EMAIL PROTECTED]
--- hw/pc.c.orig  2006-10-09 10:30:32.0 -0400
+++ hw/pc.c 2007-06-30 13:38:50.0 -0500
@@ -913,23 +913,25 @@
 if (i440fx_state) {
 i440fx_init_memory_mappings(i440fx_state);
 }
-#if 0
-/* ??? Need to figure out some way for the user to
-   specify SCSI devices.  */
 if (pci_enabled) {
-void *scsi;
-BlockDriverState *bdrv;
+void *scsi[MAX_SCSI_CONTROLLERS];;
+int id, hba;
 
-scsi = lsi_scsi_init(pci_bus, -1);
-bdrv = bdrv_new(scsidisk);
-bdrv_open(bdrv, scsi_disk.img, 0);
-lsi_scsi_attach(scsi, bdrv, -1);
-bdrv = bdrv_new(scsicd);
-bdrv_open(bdrv, scsi_cd.iso, 0);
-bdrv_set_type_hint(bdrv, BDRV_TYPE_CDROM);
-lsi_scsi_attach(scsi, bdrv, -1);
+if (scsi_disks  0) {
+for (i=0; iscsi_hba_lsi; i++) {
+if (!(scsi[i] = lsi_scsi_init(pci_bus, -1))){
+exit(1);
+}
+}
+for (i=0; iMAX_SCSI_DISKS; i++) {
+if (bs_scsi_table[i]!=NULL) {
+id=scsi_disks_info[i].id;
+hba=scsi_disks_info[i].hba;
+lsi_scsi_attach(scsi[hba], bs_scsi_table[i],id);
+}
+}
+}
 }
-#endif
 }
 
 static void pc_init_pci(int ram_size, int vga_ram_size, int boot_device,

--- vl.c.orig   2006-11-29 14:34:33.0 -0500
+++ vl.c  2006-12-05 15:12:11.0 -0500
@@ -132,6 +132,8 @@
 /* XXX: use a two level table to limit memory usage */
 #define MAX_IOPORTS 65536
 
+#define DISK_OPTIONS_SIZE 256
+
 const char *bios_dir = CONFIG_QEMU_SHAREDIR;
 char phys_ram_file[1024];
 void *ioport_opaque[MAX_IOPORTS];
@@ -145,6 +147,12 @@
 BlockDriverState *mtd_bdrv;
 /* point to the block driver where the snapshots are managed */
 BlockDriverState *bs_snapshots;
+BlockDriverState *bs_scsi_table[MAX_SCSI_DISKS]; 
+SCSIDiskInfo scsi_disks_info[MAX_SCSI_DISKS];
+int scsi_hba_lsi; /* Count of scsi lsi adapters */
+int scsi_disks; /* Count of scsi disks and cdroms */
+int cdrom_drives; /* Count of total cdroms */
+int first_bootable_cdrom; /* cdrom drive to boot off of */
 int vga_ram_size;
 static DisplayState display_state;
 int nographic;
@@ -4304,7 +4309,184 @@
 term_printf(  %s\n, vc-info_str);
 }
 }
 
+ /* Parse IDE and SCSI disk options */
+static int disk_options_init(int num_ide_disks, 
+ char ide_disk_options[][DISK_OPTIONS_SIZE],
+ int snapshot,
+ int num_scsi_disks,
+ char scsi_disk_options[][DISK_OPTIONS_SIZE],
+ int cyls, 
+ int heads, 
+ int secs, 
+ int translation
+ )
+{
+char buf[256];
+char dev_name[64];
+int id, hba, i, j;
+int cdrom_device;
+scsi_host_adapters temp_adapter;
+
+/* Process any IDE devices */
+
+if (num_ide_disksMAX_DISKS) {
+fprintf(stderr,too many ide disks. called with %d, MAX_DISKS is set 
to %d\n,num_ide_disks,MAX_DISKS);
+return -1;
+}
+
+for (i=0; iMAX_DISKS; i++) {
+
+if (ide_disk_options[i][0] == '\0') {
+bs_table[i]=NULL;
+continue;
+}
+
+if (get_param_value(buf, sizeof(buf),type,ide_disk_options[i])) {
+if (!strcmp(buf, disk) ) {
+cdrom_device = 0;
+}else if (!strcmp(buf, cdrom) ) {
+cdrom_device = 1;
+} else {
+fprintf(stderr, qemu: invalid IDE device type= value: %s\n, 
buf);
+return -1;
+}
+}
+else {
+cdrom_device = 0;
+}
+
+if (!(get_param_value(buf, sizeof(buf),hdx,ide_disk_options[i]) ) ) {
+fprintf(stderr, qemu: missing IDE device hdx= value.\n);
+return -1;
+}
+
+/* cdrom device 

Re: [Qemu-devel] Regression bug

2007-05-29 Thread risc
On Tue, May 29, 2007 at 01:10:02AM -0400, Ben Taylor wrote:
 
 I've been keeping up with CVS patches for qemu about once a week.  I just 
 updated
 tonight after the big round of patches that have been commited and am seeing a
 consistent failure with my existing ubuntu-7.04 32-bit guest on Solaris 
 10/x86 32-bit
 host.  The last time I tested the CVS code would have been 5/21/07, so 
 something
 recently changed has broken the i386-softmmu
 
 qemu: fatal: Trying to execute code outside RAM or ROM at 0xfff0
 
 EAX= EBX= ECX= EDX=0600
 ESI= EDI= EBP= ESP=
 EIP=fff0 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0
 ES =   
 CS =f000   
 SS =   
 DS =   
 FS =   
 GS =   
 LDT=   8000
 TR =   8000
 GDT=  
 IDT=  
 CR0=6010 CR2= CR3= CR4=
 CCS= CCD= CCO=EFLAGS
 FCW=037f FSW= [ST=0] FTW=00 MXCSR=1f80
 FPR0=  FPR1= 
 FPR2=  FPR3= 
 FPR4=  FPR5= 
 FPR6=  FPR7= 
 XMM00= XMM01=
 XMM02= XMM03=
 XMM04= XMM05=
 XMM06= XMM07=
 
 Anyone seen this?
 
 Ben
 
Ben:

i've been monitoring this, and reporting on irc since the bug was comitted. 
i've tracked it down to somewhere between CVS version 2007-05-26 15:00 and 
2007-05-26 17:40.
as in, 15:00 works, 17:40 dosent, and if i try to check out the version 
between.. it fails to compile.

I'm quite new here, so i didn't feel like yelling the sky is falling on a 
mailing list.

hope this helps,

Julia Longtin [EMAIL PROTECTED]




Re: [Qemu-devel] Regression bug

2007-05-29 Thread risc
On Tue, May 29, 2007 at 09:44:39PM +0300, Blue Swirl wrote:
 Hi,
 
 I found a bug in the subpage checking code. Could you try if the
 attached patch fixes the problem?

thats a negative. the exact same behavior as before.

qemu: fatal: Trying to execute code outside RAM or ROM at 0xfff0

EAX= EBX= ECX= EDX=0600
ESI= EDI= EBP= ESP=
EIP=fff0 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =   
CS =f000   
SS =   
DS =   
FS =   
GS =   
LDT=   8000
TR =   8000
GDT=  
IDT=  
CR0=6010 CR2= CR3= CR4=
CCS= CCD= CCO=EFLAGS  
FCW=037f FSW= [ST=0] FTW=00 MXCSR=1f80
FPR0=  FPR1= 
FPR2=  FPR3= 
FPR4=  FPR5= 
FPR6=  FPR7= 
XMM00= XMM01=
XMM02= XMM03=
XMM04= XMM05=
XMM06= XMM07=
./start.sh: line 4: 14065 Aborted qemu -hda ide0.img

ouch.

Julia Longtin [EMAIL PROTECTED]




Re: [Qemu-devel] Regression bug

2007-05-29 Thread risc
On Tue, May 29, 2007 at 10:33:37PM +0300, Blue Swirl wrote:
 On 5/29/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 On Tue, May 29, 2007 at 09:44:39PM +0300, Blue Swirl wrote:
  Hi,
 
  I found a bug in the subpage checking code. Could you try if the
  attached patch fixes the problem?
 
 thats a negative. the exact same behavior as before.
 
 Thanks.
 
 The bug was actually that on PC, the very last addresses are mapped,
 and the current code failed when the start_addr + size wrapped back to
 0. That didn't happen on amd64, where I first tried to reproduce the
 bug.
 
 The attached patch fixes the problem for me, I'll commit it if there
 are no objections.

this patch works. thanks. :)

Julia Longtin [EMAIL PROTECTED]