How to disable 'restart required'

Hi folks,

I meet a problem when developing windows pv drivers for Xen.

There are two mode for a virtual disk in Xen, one is QEMU, the other is PV.
QEMU is supported by windows defaultly and now I am developing drivers for
PV mode. I need to install PV drivers when virtual disk working on QEMU
mode. In QEMU mode, I need to hide PV virtual disks otherwise we may have
some problems on data coherence. After PV drivers are installed on system
successful, I can reboot system to enter PV mode. Then my PV drivers will
take effect and virtual disk will work on PV mode.

My problem is when PV drivers take effect for the first time, Vista/Srv2008
will install PV drivers to service virtual disk, but system reboot again is
required. It will pops up a dialog to reboot system again. Of course we can
reboot sytem later and PV drivers can work fine, but I think it’s not
confortable for customers. How can I hide this dialog?

Thanks
Wayne

> My problem is when PV drivers take effect for the first time,
Vista/Srv2008 will install PV drivers to

service virtual disk, but system reboot again is required. It will pops
up a dialog to reboot system again.
Of course we can reboot sytem later and PV drivers can work fine, but I
think it’s not confortable for
customers. How can I hide this dialog?

What you’re seeing is a new storage driver is partially installed by the
kernel using the critical device database. When the OS then fully comes up,
the user mode PnP subsystem takes over and runs a full INF based install.
For the boot disk controller, it will not be possible to stop the partial
install device instance and restart the fully installed instance without a
reboot. Storage controller drivers often set some registry parameters via
the INF, and these won’t be set on the partially installed instance. Hiding
the dialog won’t fix the PnP system’s need to reboot.

You should make the PV controller instance install before you need to boot
from it, like during the time the QEMU emulated device is the boot disk
controller.

Jan

>You should make the PV controller instance install before you need to boot

from it.

How can I do that? I install the PV controller driver when virtual disk working on QEMU mdoe. If I take the controller driver effect, it will enumerate a new disk volume. I set the capacity to 0 otherwise there are two disk volume represent that same disk media. That’s danger for data coherence. When I set the PV virtual disk’s capacity to 0, Vista/Srv2008 will pop up a dialog to let user to format the disk since it think the new PV virtual disk volume cannot work. That’s also unacceptable for customer. How can I deal with such scenario?

> >You should make the PV controller instance install before

you need to
>boot from it.

How can I do that? I install the PV controller driver when
virtual disk working on QEMU mdoe. If I take the controller
driver effect, it will enumerate a new disk volume. I set the
capacity to 0 otherwise there are two disk volume represent
that same disk media. That’s danger for data coherence. When
I set the PV virtual disk’s capacity to 0, Vista/Srv2008 will
pop up a dialog to let user to format the disk since it think
the new PV virtual disk volume cannot work. That’s also
unacceptable for customer. How can I deal with such scenario?

While booted from the QEMU controller, make the PV controller show up on the
virtual bus, BUT also make it not find any volumes until the next boot. You
basically need the PV controller driver to get detected and successfully
started, so the PnP subsystem will not try to do any installing on the next
boot. You might need to get the PC controller driver to set a registry value
to indicate “not initial load” (which would get written to the hive file by
the active QEMU controller), so on the second boot, the PV controller can be
fully operational, and the QEMU instance never shows up on the virtual bus.

Jan

>

While booted from the QEMU controller, make the PV controller show up on the
virtual bus, BUT also make it not find any volumes until the next boot. You
basically need the PV controller driver to get detected and successfully
started, so the PnP subsystem will not try to do any installing on the next
boot.

You mean to return SP_RETURN_NOT_FOUND in FindAdapter routine? I just
have a try, find that Vista/Srv2008 still notify me to reboot OS after
first reboot.

You might need to get the PC controller driver to set a registry value
to indicate “not initial load” (which would get written to the hive file by
the active QEMU controller), so on the second boot, the PV controller can be
fully operational, and the QEMU instance never shows up on the virtual bus.

Yes, I have done that.

Thanks
Wayne

> >

> While booted from the QEMU controller, make the PV controller show
up on
the
> virtual bus, BUT also make it not find any volumes until the next
boot.
You
> basically need the PV controller driver to get detected and
successfully
> started, so the PnP subsystem will not try to do any installing on
the
next
> boot.

You mean to return SP_RETURN_NOT_FOUND in FindAdapter routine? I just
have a try, find that Vista/Srv2008 still notify me to reboot OS after
first reboot.

I think what he means is to return SRB_STATUS_NO_DEVICE in StartIo.
That’s what I do in my drivers, which I believe yours are based on.
Search for xvdd->inactive.

James

>> You mean to return SP_RETURN_NOT_FOUND in FindAdapter routine? I just

> have a try, find that Vista/Srv2008 still notify me to reboot OS after
> first reboot.
>

I think what he means is to return SRB_STATUS_NO_DEVICE in StartIo.
That’s what I do in my drivers, which I believe yours are based on.
Search for xvdd->inactive.

I have done what you said in my driver. But Vista/Srv2008 also notify me
to reboot OS to take driver changed effect after first reboot.

Thanks
Wayne

> I have done what you said in my driver. But Vista/Srv2008

also notify me to reboot OS to take driver changed effect
after first reboot.

That’s a statement, not a question. It sounds like you need to do some PnP
debugging and verify the PV driver is working before the reboot, and then
debug why PnP is requesting the reboot. Turning up the setupapi log detail
level (read the WDK docs) would be a good direction to go. W2K8/Vista has
much improved setupapi logging over XP/W2K3.

Is it possible your PV device shows up on a different virtual PCI slot or
something like that (causing a new instance) when you disable the QEMU
device. I’d check the PV device instance id after the initial install and
then again after the third reboot, they should be the same.

Jan

> That’s a statement, not a question. It sounds like you need to do some PnP

debugging and verify the PV driver is working before the reboot,

Yes. I have done that find that pv driver works before reboot. PV disk
driver can get lot’s of StartIo command. As James advice, I return
SRB_STATUS_NO_DEVICE for all these command.

and then debug why PnP is requesting the reboot. Turning up the setupapi log detail
level (read the WDK docs) would be a good direction to go. W2K8/Vista has
much improved setupapi logging over XP/W2K3.

Will have a try.

Is it possible your PV device shows up on a different virtual PCI slot or
something like that (causing a new instance) when you disable the QEMU
device. I’d check the PV device instance id after the initial install and
then again after the third reboot, they should be the same.

I make sure that device instance ID is the same when before and after
first reboot.

Thanks
Wayne

> Turning up the setupapi log detail

level (read the WDK docs) would be a good direction to go. W2K8/Vista has
much improved setupapi logging over XP/W2K3.

In Vista, default output logging level is 0x2000ffff, means log verbose
device installation information. After my pv driver installed and reboot
for the first time. (Vista notify me to reboot OS again), in
setupapi.dev.log file, I get some log as follow:

dvi: {Restarting Devices} 07:34:59.254
dvi: Query-remove: OVMPCI\VBD\4&32FE5319&0&768
dvi: Query-remove complete
dvi: Query-remove:
OVMPCI\VBD\4&32FE5319&0&5632
dvi: Query-remove complete
! dvi: Driver ‘XenConfig’ required reboot:
Driver did not unload.
dvi: Restart: OVMPCI\VIF\4&32FE5319&0&0
dvi: Restart complete.
dvi: Restart: OVMPCI\VBD\4&32FE5319&0&768
dvi: Restart complete.
dvi: Restart: OVMPCI\VBD\4&32FE5319&0&5632
dvi: Restart complete.
dvi: {Restarting Devices exit} 07:35:01.348

Is that means XenConfig driver has something wrong when system querying
remove vbd device?

Thanks
Wayne

Also I get some log as follow:

dvi: Writing common driver property settings.
dvi: DriverDescription=Disk drive
dvi: DeviceDisplayName=Disk drive
dvi: Install Device: Removing device sub-tree.
07:37:11.145
dvi: Install Device: Removing device sub-tree
completed. 07:37:17.770
! dvi: Query-removal during install of
‘SCSI\DISK&VEN_XENVM&PROD_PV&REV_0001\5&1239C666&0&000000’ was vetoed by
‘SCSI\Disk&Ven_XENVM&Prod_PV&Rev_0001\5&1239c666&0&000000’ (veto type 6:
PNP_VetoDevice).
! dvi: Device required reboot: Query remove failed
(install) 0x17: CR_REMOVE_VETOED.

That means after the first reboot, PnP manager will query to remove the
boot disk which is serviced by PV drivers. Of course my PV drivers will
fail this command, otherwise system will crash I believe. Then system
will pop up a dialog to restart OS again.

In current version of my PV drivers, after PV driver installed for the
first time. No new PV disk volume would be enumerate since I fail all
StartIo command. But in ‘Storage Controller’ list, I can find device
which PV drivers service. Is that correct?

Thanks
Wayne

> Also I get some log as follow:

dvi: Writing common driver property settings.
dvi: DriverDescription=Disk drive
dvi: DeviceDisplayName=Disk drive
dvi: Install Device: Removing device sub-tree.
07:37:11.145
dvi: Install Device: Removing device sub-tree
completed. 07:37:17.770
! dvi: Query-removal during install of
‘SCSI\DISK&VEN_XENVM&PROD_PV&REV_0001\5&1239C666&0&000000’
was vetoed by
‘SCSI\Disk&Ven_XENVM&Prod_PV&Rev_0001\5&1239c666&0&000000’
(veto type 6:
PNP_VetoDevice).
! dvi: Device required reboot: Query remove failed
(install) 0x17: CR_REMOVE_VETOED.

That means after the first reboot, PnP manager will query to
remove the boot disk which is serviced by PV drivers. Of
course my PV drivers will fail this command, otherwise system
will crash I believe. Then system will pop up a dialog to
restart OS again.

It looks potentially like it’s the DISK device that is requiring a reboot,
not the controller. On the initial PV driver install, you perhaps need to
enumerate the target but don’t let the file system mount it (by failing
certain srb’s), or maybe marking the disk read-only. This is because the IDE
and PV controller are using different PnP instance id’s for the same disk.

Jan

> It looks potentially like it’s the DISK device that is requiring a reboot,

not the controller.

I think so. If I enumerate the PV disk and set capacity to 0, which let
user can do nothing with PV disk, Vista/Srv2008 won’t let me reboot for
the second time.

On the initial PV driver install, you perhaps need to
enumerate the target but don’t let the file system mount it (by failing
certain srb’s), or maybe marking the disk read-only. This is because the IDE
and PV controller are using different PnP instance id’s for the same disk.

Now in my driver, I set PV virtual disk capacity to 0 and fail
TEST_UNIT_READY and VERIFY command can let the PV virtual disk offline.
In this case, a disk volume will be enumerated but user can do nothing
about it. This can avoid second reboot but I think it’s not very
comfortable for customer. Any other good idea?

Thanks
Wayne