GPLPV drivers 0.9.12-pre9 upload

GPLPV drivers 0.9.12-pre9 upload

[James Harper]

I've just uploaded 0.9.12-pre9. Please read the following before using:

1. Windows 2000 is no longer included in the binary distribution. It
didn't work.

2. qemu network and disk adapters are disabled, but will now appear as
having failed due to a change in the hiding code. This is cosmetic
(you'll get a warning on start that a service or driver failed to start)
but the effect is the same, except you won't get strange things
happening as a result of pci devices just disappearing - I was seeing
delays in places during startup and shutdown.

3. If you are using the latest Xen 3.3.1 hg (maybe 3.3.0 too?), the
qemu_disable_patches.diff patch applied to the ioemu-remote git repo
(after 'make tools' has downloaded it, or after you've updated it to the
latest) will completely remove the ide disks and network interfaces,
leaving the cdroms as emulated by qemu. This is how things should be
going forward - qemu cdrom's means you get eject and virtual image swap
etc, and performance on a cdrom is hardly critical. Hopefully these
patches will make it into Xen 3.4.

4. Please test in a dev environment. I haven't broken my test servers
during upgrade or anything, but testing first is just common sense.

5. 64 bit block addressing is in place but not really tested. If you
have block devices >1TB that didn't work previously, please give it a go
and let me know.

6. Save+restore is working for me at the moment, please report any
issues.

Go to http://www.meadowcourt.org/downloads/ for the gplpv driver
download and, if you want, the qemu_disable_patches.diff patch.

See the thread in xen-devel with a subject of 'disable qemu PCI devices
in HVM domains' for an explanation of how the qemu device disabling
works.

James

Re: GPLPV drivers 0.9.12-pre9 upload

[Pasi Kärkkäinen]

On Fri, Dec 19, 2008 at 11:25:39PM +1100, James Harper wrote:
> I've just uploaded 0.9.12-pre9. Please read the following before using:
> 
> 1. Windows 2000 is no longer included in the binary distribution. It
> didn't work.
> 
> 2. qemu network and disk adapters are disabled, but will now appear as
> having failed due to a change in the hiding code. This is cosmetic
> (you'll get a warning on start that a service or driver failed to start)
> but the effect is the same, except you won't get strange things
> happening as a result of pci devices just disappearing - I was seeing
> delays in places during startup and shutdown.
> 
> 3. If you are using the latest Xen 3.3.1 hg (maybe 3.3.0 too?), the
> qemu_disable_patches.diff patch applied to the ioemu-remote git repo
> (after 'make tools' has downloaded it, or after you've updated it to the
> latest) will completely remove the ide disks and network interfaces,
> leaving the cdroms as emulated by qemu. This is how things should be
> going forward - qemu cdrom's means you get eject and virtual image swap
> etc, and performance on a cdrom is hardly critical. Hopefully these
> patches will make it into Xen 3.4.
> 
> 4. Please test in a dev environment. I haven't broken my test servers
> during upgrade or anything, but testing first is just common sense.
> 
> 5. 64 bit block addressing is in place but not really tested. If you
> have block devices >1TB that didn't work previously, please give it a go
> and let me know.
> 
> 6. Save+restore is working for me at the moment, please report any
> issues.
> 
> Go to http://www.meadowcourt.org/downloads/ for the gplpv driver
> download and, if you want, the qemu_disable_patches.diff patch.
> 

Hmm..

$ wget "http://www.meadowcourt.org/downloads/qemu_disable_patches.diff"
--15:26:47--  http://www.meadowcourt.org/downloads/qemu_disable_patches.diff
           => `qemu_disable_patches.diff'
Resolving www.meadowcourt.org... 203.16.224.103
Connecting to www.meadowcourt.org|203.16.224.103|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
15:26:48 ERROR 404: Not Found.

Xen PV Drivers 0.9.12-pre9.exe I was able to download just fine..

-- Pasi

RE: [Xen-devel] GPLPV drivers 0.9.12-pre9 upload

[James Harper]

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

> > Go to http://www.meadowcourt.org/downloads/ for the gplpv driver
> > download and, if you want, the qemu_disable_patches.diff patch.
> >
> 
> Hmm..
> 
> $ wget "http://www.meadowcourt.org/downloads/qemu_disable_patches.diff"
> --15:26:47--
> http://www.meadowcourt.org/downloads/qemu_disable_patches.diff
>            => `qemu_disable_patches.diff'
> Resolving www.meadowcourt.org... 203.16.224.103
> Connecting to www.meadowcourt.org|203.16.224.103|:80... connected.
> HTTP request sent, awaiting response... 404 Not Found
> 15:26:48 ERROR 404: Not Found.
> 
> Xen PV Drivers 0.9.12-pre9.exe I was able to download just fine..
> 

Doh. That website is on IIS, and will only let you access files with extensions it knows about.

I've attached the patch to this message.

James

[-- Attachment #2: qemu-pci-disable.patch --]
[-- Type: application/octet-stream, Size: 5187 bytes --]

diff --git a/hw/ide.c b/hw/ide.c
index dae6e7f..b7b6871 100644
--- a/hw/ide.c
+++ b/hw/ide.c
@@ -3419,6 +3419,8 @@ void pci_piix3_ide_init(PCIBus *bus, BlockDriverState **hd_table, int devfn,
                                            sizeof(PCIIDEState),
                                            devfn,
                                            NULL, NULL);
+    d->dev.disable_flag = 1;
+
     d->type = IDE_TYPE_PIIX3;
 
     pci_conf = d->dev.config;
diff --git a/hw/pci.c b/hw/pci.c
index 1de68fd..c55c371 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -26,6 +26,8 @@
 #include "console.h"
 #include "net.h"
 
+uint32_t xen_pci_disable_devices;
+
 //#define DEBUG_PCI
 
 struct PCIBus {
@@ -160,6 +162,7 @@ PCIDevice *pci_register_device(PCIBus *bus, const char *name,
     pci_dev->config_write = config_write;
     bus->devices[devfn] = pci_dev;
     pci_dev->irq = qemu_allocate_irqs(pci_set_irq, pci_dev, 4);
+    pci_dev->disable_flag = 0;
     return pci_dev;
 }
 
@@ -465,6 +468,12 @@ uint32_t pci_data_read(void *opaque, uint32_t addr, int len)
         }
         goto the_end;
     }
+    if (pci_dev->disable_flag && xen_pci_disable_devices)
+    {
+        printf("read disabled device\n");
+	goto fail;
+    }
+
     config_addr = addr & 0xff;
     val = pci_dev->config_read(pci_dev, config_addr, len);
 #if defined(DEBUG_PCI)
diff --git a/hw/pci.h b/hw/pci.h
index 4adc4d7..c57841a 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -61,6 +61,9 @@ struct PCIDevice {
 
     /* Current IRQ levels.  Used internally by the generic PCI code.  */
     int irq_state[4];
+
+    /* when set, this device will be disabled when xen_pci_disable_devices is set */
+    int disable_flag;
 };
 
 extern char direct_pci_str[];
diff --git a/hw/rtl8139.c b/hw/rtl8139.c
index 9ae76e6..d5f0774 100644
--- a/hw/rtl8139.c
+++ b/hw/rtl8139.c
@@ -536,7 +536,7 @@ static void prom9346_decode_command(EEprom9346 *eeprom, uint8_t command)
                     DEBUG_PRINT(("RTL8139: eeprom begin write all\n"));
                     break;
                 case Chip9346_op_write_disable:
-                    DEBUG_PRINT(("RTL8139: eeprom write disabled\n"));
+                    DEBUG_PRINT(("RTL8139: eeprom write disable\n"));
                     break;
             }
             break;
@@ -3429,6 +3429,7 @@ void pci_rtl8139_init(PCIBus *bus, NICInfo *nd, int devfn)
                                               "RTL8139", sizeof(PCIRTL8139State),
                                               devfn,
                                               NULL, NULL);
+    d->dev.disable_flag = 1; /* should be disabled by PV on HVM drivers */
     pci_conf = d->dev.config;
     pci_conf[0x00] = 0xec; /* Realtek 8139 */
     pci_conf[0x01] = 0x10;
diff --git a/hw/xen_platform.c b/hw/xen_platform.c
index 430e603..11acac3 100644
--- a/hw/xen_platform.c
+++ b/hw/xen_platform.c
@@ -30,6 +30,7 @@
 #include <xenguest.h>
 
 extern FILE *logfile;
+extern uint32_t xen_pci_disable_devices;
 
 #define PFFLAG_ROM_LOCK 1 /* Sets whether ROM memory area is RW or RO */
 
@@ -39,6 +40,59 @@ typedef struct PCIXenPlatformState
   uint8_t    platform_flags;
 } PCIXenPlatformState;
 
+static uint32_t platform_global_ioport_readb(void *opaque, uint32_t addr)
+{
+    switch (addr & 0x0f)
+    {
+    case 0:
+	return 'X';
+    case 1:
+	return 'E';
+    case 2:
+	return 'N';
+    case 3:
+	return 1; /* version */
+    default:
+	return 0;
+    }
+}
+
+static void platform_global_ioport_writeb(void *opaque, uint32_t addr, uint32_t val)
+{
+    static char buffer[8][512];
+    static int bufpos[8] = {0};
+    int cpu;
+
+    switch (addr & 0x0f)
+    {
+    case 0:
+    case 1:
+    case 2:
+    case 3:
+    case 4:
+    case 5:
+    case 6:
+    case 7:
+	cpu = addr & 0x07;
+    	if (bufpos[cpu] == 511 || val == '\n')
+    	{
+            buffer[cpu][bufpos[cpu]] = 0;
+            printf("%02d: %s\n", cpu, buffer[cpu]);
+            bufpos[cpu] = 0;
+        }
+        if (val == '\n')
+	    return;
+        buffer[cpu][bufpos[cpu]++] = val;
+	break;
+    case 8:
+	xen_pci_disable_devices = val;
+	printf("set xen_pci_disable_devices = %d\n", val);
+	break;
+    default:
+	break;
+    }
+}
+
 static uint32_t xen_platform_ioport_readb(void *opaque, uint32_t addr)
 {
     PCIXenPlatformState *s = opaque;
@@ -208,6 +262,9 @@ void pci_xen_platform_init(PCIBus *bus)
     pci_register_io_region(&d->pci_dev, 0, 0x100,
                            PCI_ADDRESS_SPACE_IO, platform_ioport_map);
 
+    register_ioport_write(0x10, 0x10, 1, platform_global_ioport_writeb, NULL);
+    register_ioport_read(0x10, 0x10, 1, platform_global_ioport_readb, NULL);
+
     /* reserve 16MB mmio address for share memory*/
     pci_register_io_region(&d->pci_dev, 1, 0x1000000,
                            PCI_ADDRESS_SPACE_MEM_PREFETCH, platform_mmio_map);
diff --git a/vl.c b/vl.c
index e50a02d..1366a37 100644
--- a/vl.c
+++ b/vl.c
@@ -5401,6 +5401,8 @@ static int drive_init(struct drive_opt *arg, int snapshot,
            approximation.  */
     case IF_FLOPPY:
         bdrv_set_type_hint(bdrv, BDRV_TYPE_FLOPPY);
+	if (!drv)
+	    drv = &bdrv_raw;
         break;
     case IF_PFLASH:
     case IF_MTD:

[-- Attachment #3: Type: text/plain, Size: 137 bytes --]

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Re: GPLPV drivers 0.9.12-pre9 upload

[Jun Koi]

On Fri, Dec 19, 2008 at 9:25 PM, James Harper
<james.harper@bendigoit.com.au> wrote:
> I've just uploaded 0.9.12-pre9. Please read the following before using:
>
> 1. Windows 2000 is no longer included in the binary distribution. It
> didn't work.
>
> 2. qemu network and disk adapters are disabled, but will now appear as
> having failed due to a change in the hiding code. This is cosmetic
> (you'll get a warning on start that a service or driver failed to start)
> but the effect is the same, except you won't get strange things
> happening as a result of pci devices just disappearing - I was seeing
> delays in places during startup and shutdown.
>
> 3. If you are using the latest Xen 3.3.1 hg (maybe 3.3.0 too?), the
> qemu_disable_patches.diff patch applied to the ioemu-remote git repo
> (after 'make tools' has downloaded it, or after you've updated it to the
> latest) will completely remove the ide disks and network interfaces,
> leaving the cdroms as emulated by qemu. This is how things should be
> going forward - qemu cdrom's means you get eject and virtual image swap
> etc, and performance on a cdrom is hardly critical. Hopefully these
> patches will make it into Xen 3.4.
>
> 4. Please test in a dev environment. I haven't broken my test servers
> during upgrade or anything, but testing first is just common sense.
>
> 5. 64 bit block addressing is in place but not really tested. If you
> have block devices >1TB that didn't work previously, please give it a go
> and let me know.
>
> 6. Save+restore is working for me at the moment, please report any
> issues.
>
> Go to http://www.meadowcourt.org/downloads/ for the gplpv driver
> download and, if you want, the qemu_disable_patches.diff patch.
>
> See the thread in xen-devel with a subject of 'disable qemu PCI devices
> in HVM domains' for an explanation of how the qemu device disabling
> works.

I had a question on compiling the code few days ago. Could you answer that?

Thanks,
J

Re: GPLPV drivers 0.9.12-pre9 upload

[Ian Jackson]

James Harper writes ("[Xen-devel] GPLPV drivers 0.9.12-pre9 upload"):
> 3. If you are using the latest Xen 3.3.1 hg (maybe 3.3.0 too?), the
> qemu_disable_patches.diff patch applied to the ioemu-remote git repo
> (after 'make tools' has downloaded it, or after you've updated it to the
> latest) will completely remove the ide disks and network interfaces,
> leaving the cdroms as emulated by qemu. This is how things should be
> going forward - qemu cdrom's means you get eject and virtual image swap
> etc, and performance on a cdrom is hardly critical. Hopefully these
> patches will make it into Xen 3.4.

Did you want me to apply that .diff to the current qemu-xen-unstable ?
If so could you please post it to the list (with an appropriate
Signed-off-by section which should probably include the original
authorship trail ?

Or should I pick up Steven Smith's patch ?

Alternatively I'm happy to wait, but current unstable is what will
become 3.4 and if you're happy with the interface and the code I'm
happy to do so right away.

Ian.

RE: qemu patch for GPLPV drivers

[James Harper]

> 
> James Harper writes ("[Xen-devel] GPLPV drivers 0.9.12-pre9 upload"):
> > 3. If you are using the latest Xen 3.3.1 hg (maybe 3.3.0 too?), the
> > qemu_disable_patches.diff patch applied to the ioemu-remote git repo
> > (after 'make tools' has downloaded it, or after you've updated it to
the
> > latest) will completely remove the ide disks and network interfaces,
> > leaving the cdroms as emulated by qemu. This is how things should be
> > going forward - qemu cdrom's means you get eject and virtual image
swap
> > etc, and performance on a cdrom is hardly critical. Hopefully these
> > patches will make it into Xen 3.4.
> 
> Did you want me to apply that .diff to the current qemu-xen-unstable ?
> If so could you please post it to the list (with an appropriate
> Signed-off-by section which should probably include the original
> authorship trail ?
> 
> Or should I pick up Steven Smith's patch ?
> 
> Alternatively I'm happy to wait, but current unstable is what will
> become 3.4 and if you're happy with the interface and the code I'm
> happy to do so right away.

My patch is just Steven Smith's patch anyway, with the fix to make it
apply to the current head and the addition of GPLPV as product number 2,
so go ahead and apply his patches please and then I'll submit the GPLPV
addition after that.

I've tested Steven's patches enough that I'm happy with them.

OT, I'm curious, why is Xen in hg but the qemu stuff in git?

Thanks

James

Re: qemu patch for GPLPV drivers

[Keir Fraser]

On 20/12/2008 01:41, "James Harper" <james.harper@bendigoit.com.au> wrote:

> OT, I'm curious, why is Xen in hg but the qemu stuff in git?

Upstream qemu uses git, so it's easiest to do the same. We'll probably do
the same for our Linux tree when we move from 2.6.18 to upstream pv_ops.

Xen itself uses mercurial just because that's what we switched to when
bitkeeper went away.

 -- Keir

RE: GPLPV drivers 0.9.12-pre9 upload

[James Harper]

> 1. Windows 2000 is no longer included in the binary distribution. It
> didn't work.
> 
> 2. qemu network and disk adapters are disabled, but will now appear as
> having failed due to a change in the hiding code. This is cosmetic
> (you'll get a warning on start that a service or driver failed to
start)
> but the effect is the same, except you won't get strange things
> happening as a result of pci devices just disappearing - I was seeing
> delays in places during startup and shutdown.
> 
> 3. If you are using the latest Xen 3.3.1 hg (maybe 3.3.0 too?), the
> qemu_disable_patches.diff patch applied to the ioemu-remote git repo
> (after 'make tools' has downloaded it, or after you've updated it to
the
> latest) will completely remove the ide disks and network interfaces,
> leaving the cdroms as emulated by qemu. This is how things should be
> going forward - qemu cdrom's means you get eject and virtual image
swap
> etc, and performance on a cdrom is hardly critical. Hopefully these
> patches will make it into Xen 3.4.
> 
> 4. Please test in a dev environment. I haven't broken my test servers
> during upgrade or anything, but testing first is just common sense.
> 
> 5. 64 bit block addressing is in place but not really tested. If you
> have block devices >1TB that didn't work previously, please give it a
go
> and let me know.
> 
> 6. Save+restore is working for me at the moment, please report any
> issues.
> 

Forgot one important thing. /GPLPV isn't required anymore. Use /NOGPLPV
to disable the device drivers, or boot into safe mode which will also
disable them.

James

RE: RE: [Xen-devel] GPLPV drivers 0.9.12-pre9 upload

[Venefax]

Dear James
My Windows 2003 32 with the latest drivers (0.9.12-pre9 ) has this error
after booting:
(Event Viewer)
Driver detected an internal error in its data structures for XenVbd

The following  boot-start or system-start driver(s) failed to load: XenVbd
Any idea
Federico


-----Original Message-----
From: xen-users-bounces@lists.xensource.com
[mailto:xen-users-bounces@lists.xensource.com] On Behalf Of James Harper
Sent: Friday, December 19, 2008 8:50 PM
To: James Harper; xen-devel@lists.xensource.com;
xen-users@lists.xensource.com
Subject: [Xen-users] RE: [Xen-devel] GPLPV drivers 0.9.12-pre9 upload

> 1. Windows 2000 is no longer included in the binary distribution. It
> didn't work.
> 
> 2. qemu network and disk adapters are disabled, but will now appear as
> having failed due to a change in the hiding code. This is cosmetic
> (you'll get a warning on start that a service or driver failed to
start)
> but the effect is the same, except you won't get strange things
> happening as a result of pci devices just disappearing - I was seeing
> delays in places during startup and shutdown.
> 
> 3. If you are using the latest Xen 3.3.1 hg (maybe 3.3.0 too?), the
> qemu_disable_patches.diff patch applied to the ioemu-remote git repo
> (after 'make tools' has downloaded it, or after you've updated it to
the
> latest) will completely remove the ide disks and network interfaces,
> leaving the cdroms as emulated by qemu. This is how things should be
> going forward - qemu cdrom's means you get eject and virtual image
swap
> etc, and performance on a cdrom is hardly critical. Hopefully these
> patches will make it into Xen 3.4.
> 
> 4. Please test in a dev environment. I haven't broken my test servers
> during upgrade or anything, but testing first is just common sense.
> 
> 5. 64 bit block addressing is in place but not really tested. If you
> have block devices >1TB that didn't work previously, please give it a
go
> and let me know.
> 
> 6. Save+restore is working for me at the moment, please report any
> issues.
> 

Forgot one important thing. /GPLPV isn't required anymore. Use /NOGPLPV
to disable the device drivers, or boot into safe mode which will also
disable them.

James

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

RE: RE: [Xen-devel] GPLPV drivers 0.9.12-pre9 upload

[James Harper]

> Dear James
> My Windows 2003 32 with the latest drivers (0.9.12-pre9 ) has this
error
> after booting:
> (Event Viewer)
> Driver detected an internal error in its data structures for XenVbd
> 
> The following  boot-start or system-start driver(s) failed to load:
XenVbd
> Any idea

A few people have reported that in the past, but we were never able to
get to the bottom of it.

When you get that error after booting, are you actually running on the
PV drivers and not the qemu devices any more?

I'll ask over on the ntdev list what that message could mean.

Thanks

James

RE: RE: [Xen-devel] GPLPV drivers 0.9.12-pre9 upload

[Venefax]

Dear James
I am unable to connect via VNC to my windows domain, since I executed this
command;

xend restart

since then the graphic virtual machine manager would not connect to the
local machine. I also did execute this command, to see if it would work, but
it did not:
service libvirtd restart

How do I my graphic virtual machine connect again? my Xen domains are
working fine, it seems. I use SLES SP2.
Yours
Federico

-----Original Message-----
From: James Harper [mailto:james.harper@bendigoit.com.au] 
Sent: Sunday, December 21, 2008 3:37 AM
To: Venefax; xen-devel@lists.xensource.com; xen-users@lists.xensource.com
Subject: RE: [Xen-users] RE: [Xen-devel] GPLPV drivers 0.9.12-pre9 upload

> Dear James
> My Windows 2003 32 with the latest drivers (0.9.12-pre9 ) has this
error
> after booting:
> (Event Viewer)
> Driver detected an internal error in its data structures for XenVbd
> 
> The following  boot-start or system-start driver(s) failed to load:
XenVbd
> Any idea

A few people have reported that in the past, but we were never able to
get to the bottom of it.

When you get that error after booting, are you actually running on the
PV drivers and not the qemu devices any more?

I'll ask over on the ntdev list what that message could mean.

Thanks

James

RE: RE: [Xen-devel] GPLPV drivers 0.9.12-pre9 upload

[Venefax]

Dear James
I removed the offending service as well as other left overs from the Suse
Drivers and now my windows blue screens with 
Stop: 0x0000007B(0xf789EA94,0xC0000034,00000000,000000)
I have no idea how to boot Windows in safe mode. Is this possible? How do
you press F8, and if you did manage to boot in safe mode, what then?
Federico

-----Original Message-----
From: xen-users-bounces@lists.xensource.com
[mailto:xen-users-bounces@lists.xensource.com] On Behalf Of James Harper
Sent: Friday, December 19, 2008 8:50 PM
To: James Harper; xen-devel@lists.xensource.com;
xen-users@lists.xensource.com
Subject: [Xen-users] RE: [Xen-devel] GPLPV drivers 0.9.12-pre9 upload

> 1. Windows 2000 is no longer included in the binary distribution. It
> didn't work.
> 
> 2. qemu network and disk adapters are disabled, but will now appear as
> having failed due to a change in the hiding code. This is cosmetic
> (you'll get a warning on start that a service or driver failed to
start)
> but the effect is the same, except you won't get strange things
> happening as a result of pci devices just disappearing - I was seeing
> delays in places during startup and shutdown.
> 
> 3. If you are using the latest Xen 3.3.1 hg (maybe 3.3.0 too?), the
> qemu_disable_patches.diff patch applied to the ioemu-remote git repo
> (after 'make tools' has downloaded it, or after you've updated it to
the
> latest) will completely remove the ide disks and network interfaces,
> leaving the cdroms as emulated by qemu. This is how things should be
> going forward - qemu cdrom's means you get eject and virtual image
swap
> etc, and performance on a cdrom is hardly critical. Hopefully these
> patches will make it into Xen 3.4.
> 
> 4. Please test in a dev environment. I haven't broken my test servers
> during upgrade or anything, but testing first is just common sense.
> 
> 5. 64 bit block addressing is in place but not really tested. If you
> have block devices >1TB that didn't work previously, please give it a
go
> and let me know.
> 
> 6. Save+restore is working for me at the moment, please report any
> issues.
> 

Forgot one important thing. /GPLPV isn't required anymore. Use /NOGPLPV
to disable the device drivers, or boot into safe mode which will also
disable them.

James

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

RE: [Xen-users] RE: GPLPV drivers 0.9.12-pre9 upload

[James Harper]

> 
> Dear James
> I removed the offending service as well as other left overs from the
Suse
> Drivers and now my windows blue screens with
> Stop: 0x0000007B(0xf789EA94,0xC0000034,00000000,000000)
> I have no idea how to boot Windows in safe mode. Is this possible? How
do
> you press F8, and if you did manage to boot in safe mode, what then?
> Federico

You press F8 just as the BIOS finishes. If you only have a single entry
in your boot.ini then Windows won't wait very long (or at all) to wait
for that keypress.

If you have trouble getting vnc up between starting the domain and
windows booting, try starting the domain paused (xm create -p), then
connect with vnc, then unpause the domain (xm unpause).

The reason for the 0x7B messages will be that xenhide.sys is attached as
an upperfilter to the ide devices (it's this sort of thing that is the
reason why I want to make qemu do the hiding!). after booting into safe
mode, use regedit and look for any upperfilter lines containing
'xenhide' and remove them, but only if you have otherwise removed the
drivers.

James

Re: [Xen-users] RE: GPLPV drivers 0.9.12-pre9 upload

[Andrew Lyon]

On Sun, Dec 21, 2008 at 6:48 AM, Venefax <venefax@gmail.com> wrote:
> Dear James
> I removed the offending service as well as other left overs from the Suse
> Drivers and now my windows blue screens with
> Stop: 0x0000007B(0xf789EA94,0xC0000034,00000000,000000)
> I have no idea how to boot Windows in safe mode. Is this possible? How do
> you press F8, and if you did manage to boot in safe mode, what then?
> Federico
>
> -----Original Message-----
> From: xen-users-bounces@lists.xensource.com
> [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of James Harper
> Sent: Friday, December 19, 2008 8:50 PM
> To: James Harper; xen-devel@lists.xensource.com;
> xen-users@lists.xensource.com
> Subject: [Xen-users] RE: [Xen-devel] GPLPV drivers 0.9.12-pre9 upload
>
>> 1. Windows 2000 is no longer included in the binary distribution. It
>> didn't work.
>>
>> 2. qemu network and disk adapters are disabled, but will now appear as
>> having failed due to a change in the hiding code. This is cosmetic
>> (you'll get a warning on start that a service or driver failed to
> start)
>> but the effect is the same, except you won't get strange things
>> happening as a result of pci devices just disappearing - I was seeing
>> delays in places during startup and shutdown.
>>
>> 3. If you are using the latest Xen 3.3.1 hg (maybe 3.3.0 too?), the
>> qemu_disable_patches.diff patch applied to the ioemu-remote git repo
>> (after 'make tools' has downloaded it, or after you've updated it to
> the
>> latest) will completely remove the ide disks and network interfaces,
>> leaving the cdroms as emulated by qemu. This is how things should be
>> going forward - qemu cdrom's means you get eject and virtual image
> swap
>> etc, and performance on a cdrom is hardly critical. Hopefully these
>> patches will make it into Xen 3.4.
>>
>> 4. Please test in a dev environment. I haven't broken my test servers
>> during upgrade or anything, but testing first is just common sense.
>>
>> 5. 64 bit block addressing is in place but not really tested. If you
>> have block devices >1TB that didn't work previously, please give it a
> go
>> and let me know.
>>
>> 6. Save+restore is working for me at the moment, please report any
>> issues.
>>
>
> Forgot one important thing. /GPLPV isn't required anymore. Use /NOGPLPV
> to disable the device drivers, or boot into safe mode which will also
> disable them.
>
> James
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>

I installed the drivers into a existing Vista 32 bit HVM which had
older version of the drivers installed and it bsod on reboot with
0x0000007B, I tried /nogpl and also safe mode but neither worked, I
reinstalled Vista and tried again but I got the same result.

Once the qemu drivers have been disabled by booting with /gplpv (or
without /nogplpv in newer versions) is it sufficient to reset/reboot
the domain to boot without the drivers, or does it need to be
destroyed and created again for the qemu emulation to resume?

Fresh install of vista + 0.9.12 pre9 = 0x0000007B :(.

What do I need to do to debug this?

I am running 3.3.1 rc4, I can try 3.3  if you think it might help,
perhaps I need the patch for hiding devices?

Andy

Re: RE: [Xen-devel] GPLPV drivers 0.9.12-pre9 upload

[Wizard Vandal]

[-- Attachment #1.1: Type: text/plain, Size: 3920 bytes --]

confirm BSOD with 0.9.12 pre9 driver on Windows server 2008 with latest
updates.

2008/12/23 Andrew Lyon <andrew.lyon@gmail.com>

> On Sun, Dec 21, 2008 at 6:48 AM, Venefax <venefax@gmail.com> wrote:
> > Dear James
> > I removed the offending service as well as other left overs from the Suse
> > Drivers and now my windows blue screens with
> > Stop: 0x0000007B(0xf789EA94,0xC0000034,00000000,000000)
> > I have no idea how to boot Windows in safe mode. Is this possible? How do
> > you press F8, and if you did manage to boot in safe mode, what then?
> > Federico
> >
> > -----Original Message-----
> > From: xen-users-bounces@lists.xensource.com
> > [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of James Harper
> > Sent: Friday, December 19, 2008 8:50 PM
> > To: James Harper; xen-devel@lists.xensource.com;
> > xen-users@lists.xensource.com
> > Subject: [Xen-users] RE: [Xen-devel] GPLPV drivers 0.9.12-pre9 upload
> >
> >> 1. Windows 2000 is no longer included in the binary distribution. It
> >> didn't work.
> >>
> >> 2. qemu network and disk adapters are disabled, but will now appear as
> >> having failed due to a change in the hiding code. This is cosmetic
> >> (you'll get a warning on start that a service or driver failed to
> > start)
> >> but the effect is the same, except you won't get strange things
> >> happening as a result of pci devices just disappearing - I was seeing
> >> delays in places during startup and shutdown.
> >>
> >> 3. If you are using the latest Xen 3.3.1 hg (maybe 3.3.0 too?), the
> >> qemu_disable_patches.diff patch applied to the ioemu-remote git repo
> >> (after 'make tools' has downloaded it, or after you've updated it to
> > the
> >> latest) will completely remove the ide disks and network interfaces,
> >> leaving the cdroms as emulated by qemu. This is how things should be
> >> going forward - qemu cdrom's means you get eject and virtual image
> > swap
> >> etc, and performance on a cdrom is hardly critical. Hopefully these
> >> patches will make it into Xen 3.4.
> >>
> >> 4. Please test in a dev environment. I haven't broken my test servers
> >> during upgrade or anything, but testing first is just common sense.
> >>
> >> 5. 64 bit block addressing is in place but not really tested. If you
> >> have block devices >1TB that didn't work previously, please give it a
> > go
> >> and let me know.
> >>
> >> 6. Save+restore is working for me at the moment, please report any
> >> issues.
> >>
> >
> > Forgot one important thing. /GPLPV isn't required anymore. Use /NOGPLPV
> > to disable the device drivers, or boot into safe mode which will also
> > disable them.
> >
> > James
> >
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@lists.xensource.com
> > http://lists.xensource.com/xen-users
> >
> >
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@lists.xensource.com
> > http://lists.xensource.com/xen-users
> >
>
> I installed the drivers into a existing Vista 32 bit HVM which had
> older version of the drivers installed and it bsod on reboot with
> 0x0000007B, I tried /nogpl and also safe mode but neither worked, I
> reinstalled Vista and tried again but I got the same result.
>
> Once the qemu drivers have been disabled by booting with /gplpv (or
> without /nogplpv in newer versions) is it sufficient to reset/reboot
> the domain to boot without the drivers, or does it need to be
> destroyed and created again for the qemu emulation to resume?
>
> Fresh install of vista + 0.9.12 pre9 = 0x0000007B :(.
>
> What do I need to do to debug this?
>
> I am running 3.3.1 rc4, I can try 3.3  if you think it might help,
> perhaps I need the patch for hiding devices?
>
> Andy
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>



-- 
С Уважением, Виталий

[-- Attachment #1.2: Type: text/html, Size: 5443 bytes --]

[-- Attachment #2: Type: text/plain, Size: 137 bytes --]

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Re: [Xen-devel] GPLPV drivers 0.9.12-pre9 upload

[Andrew Lyon]

On Fri, Dec 19, 2008 at 12:25 PM, James Harper
<james.harper@bendigoit.com.au> wrote:
> I've just uploaded 0.9.12-pre9. Please read the following before using:
>
> 1. Windows 2000 is no longer included in the binary distribution. It
> didn't work.
>
> 2. qemu network and disk adapters are disabled, but will now appear as
> having failed due to a change in the hiding code. This is cosmetic
> (you'll get a warning on start that a service or driver failed to start)
> but the effect is the same, except you won't get strange things
> happening as a result of pci devices just disappearing - I was seeing
> delays in places during startup and shutdown.
>
> 3. If you are using the latest Xen 3.3.1 hg (maybe 3.3.0 too?), the
> qemu_disable_patches.diff patch applied to the ioemu-remote git repo
> (after 'make tools' has downloaded it, or after you've updated it to the
> latest) will completely remove the ide disks and network interfaces,
> leaving the cdroms as emulated by qemu. This is how things should be
> going forward - qemu cdrom's means you get eject and virtual image swap
> etc, and performance on a cdrom is hardly critical. Hopefully these
> patches will make it into Xen 3.4.

I posted this earlier in the wrong thread, I tried to use the
qemu_disable_patches.diff today with 3.3.1 rc4 but it didn't hide the
devices or change cdrom to emulated when using the pre11 drivers, this
is what I did:

hg clone -r 3.3.1-rc4 http://xenbits.xensource.com/xen-3.3-testing.hg
cd xen-3.3-testing.hg
make tools # I believe this is necessary to pull ioemu-remote ?
cd tools/ioemu-remote
patch -p1 -i /usr/src/qemu-pci-disable.patch # I removed the last
chunk of the patch which changes vl.c as the changes are in 3.3.1-rc4.
make clean
cd ../../
make clean
make tools
make install-tools
/etc/init.d/xend restart

I did not recompile xen, only the tools.

In my vista hvm the Intel IDE and Realtek NIC are still visible, and
cdrom is XEN PV not ioemu/qemu.

Is my method incorrect?

Andy

>
> 4. Please test in a dev environment. I haven't broken my test servers
> during upgrade or anything, but testing first is just common sense.
>
> 5. 64 bit block addressing is in place but not really tested. If you
> have block devices >1TB that didn't work previously, please give it a go
> and let me know.
>
> 6. Save+restore is working for me at the moment, please report any
> issues.
>
> Go to http://www.meadowcourt.org/downloads/ for the gplpv driver
> download and, if you want, the qemu_disable_patches.diff patch.
>
> See the thread in xen-devel with a subject of 'disable qemu PCI devices
> in HVM domains' for an explanation of how the qemu device disabling
> works.
>
> James
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

RE: [Xen-devel] GPLPV drivers 0.9.12-pre9 upload

[James Harper]

> > 3. If you are using the latest Xen 3.3.1 hg (maybe 3.3.0 too?), the
> > qemu_disable_patches.diff patch applied to the ioemu-remote git repo
> > (after 'make tools' has downloaded it, or after you've updated it to
the
> > latest) will completely remove the ide disks and network interfaces,
> > leaving the cdroms as emulated by qemu. This is how things should be
> > going forward - qemu cdrom's means you get eject and virtual image
swap
> > etc, and performance on a cdrom is hardly critical. Hopefully these
> > patches will make it into Xen 3.4.
> 
> I posted this earlier in the wrong thread, I tried to use the
> qemu_disable_patches.diff today with 3.3.1 rc4 but it didn't hide the
> devices or change cdrom to emulated when using the pre11 drivers, this
> is what I did:
> 
> hg clone -r 3.3.1-rc4 http://xenbits.xensource.com/xen-3.3-testing.hg
> cd xen-3.3-testing.hg
> make tools # I believe this is necessary to pull ioemu-remote ?
> cd tools/ioemu-remote
> patch -p1 -i /usr/src/qemu-pci-disable.patch # I removed the last
> chunk of the patch which changes vl.c as the changes are in 3.3.1-rc4.
> make clean
> cd ../../
> make clean
> make tools
> make install-tools
> /etc/init.d/xend restart
> 
> I did not recompile xen, only the tools.
> 
> In my vista hvm the Intel IDE and Realtek NIC are still visible, and
> cdrom is XEN PV not ioemu/qemu.
> 
> Is my method incorrect?
> 

It looks to be. Can you confirm that the qemu-dm installed by 'make
install-tools' is definitely the one being used by your domain?

One of the other changes is that logging should appear in the logfile
for that domain. Can you have a look there and see what's in there?

Thanks

James

Re: GPLPV drivers 0.9.12-pre9 upload

[Andrew Lyon]

On Wed, Dec 24, 2008 at 5:35 AM, James Harper
<james.harper@bendigoit.com.au> wrote:
>> > 3. If you are using the latest Xen 3.3.1 hg (maybe 3.3.0 too?), the
>> > qemu_disable_patches.diff patch applied to the ioemu-remote git repo
>> > (after 'make tools' has downloaded it, or after you've updated it to
> the
>> > latest) will completely remove the ide disks and network interfaces,
>> > leaving the cdroms as emulated by qemu. This is how things should be
>> > going forward - qemu cdrom's means you get eject and virtual image
> swap
>> > etc, and performance on a cdrom is hardly critical. Hopefully these
>> > patches will make it into Xen 3.4.
>>
>> I posted this earlier in the wrong thread, I tried to use the
>> qemu_disable_patches.diff today with 3.3.1 rc4 but it didn't hide the
>> devices or change cdrom to emulated when using the pre11 drivers, this
>> is what I did:
>>
>> hg clone -r 3.3.1-rc4 http://xenbits.xensource.com/xen-3.3-testing.hg
>> cd xen-3.3-testing.hg
>> make tools # I believe this is necessary to pull ioemu-remote ?
>> cd tools/ioemu-remote
>> patch -p1 -i /usr/src/qemu-pci-disable.patch # I removed the last
>> chunk of the patch which changes vl.c as the changes are in 3.3.1-rc4.
>> make clean
>> cd ../../
>> make clean
>> make tools
>> make install-tools
>> /etc/init.d/xend restart
>>
>> I did not recompile xen, only the tools.
>>
>> In my vista hvm the Intel IDE and Realtek NIC are still visible, and
>> cdrom is XEN PV not ioemu/qemu.
>>
>> Is my method incorrect?
>>
>
> It looks to be. Can you confirm that the qemu-dm installed by 'make
> install-tools' is definitely the one being used by your domain?

The method I used does not work, it appears that after patching and
recompiling the binary does not get updated, it is the same as the one
produced by the first "make tools".

Instead I started from scratch and immediately after "make tools"
downloaded ioemu-remote git I paused the process, applied the patch,
and then resumed, this time the binary is different, and in my vista
vm the devices have changed, but they are still not correct, both are
now emulated:

QEMU HARDDISK ATA Device
QEMU QEMU DVD-ROM ATA Device
Realtek RTL8139C

Andy





>
> One of the other changes is that logging should appear in the logfile
> for that domain. Can you have a look there and see what's in there?
>
> Thanks
>
> James
>