* Win2003 got blue Screen when ballooning with serial out put: "Iomem mapping not permitted" [not found] <SNT0-MC4-F15TlpsWqi0002f5ac@snt0-mc4-f15.Snt0.hotmail.com> @ 2010-12-17 3:24 ` tinnycloud 2010-12-17 8:53 ` Paul Durrant 0 siblings, 1 reply; 26+ messages in thread From: tinnycloud @ 2010-12-17 3:24 UTC (permalink / raw) To: steven.smith, xen-devel; +Cc: james.harper, keir.fraser, JBeulich Hi Steven: I was trying to make use of balloon driver on my win2003 HVM Guests, but confront a Guest crash problem with blue screen. The serial output is much like (XEN)grant_table.c:555:d0 Iomem mapping not permitted ffffffffffffffff My pvdriver changeset is 823. From http://xenbits.xensource.com/ext/win-pvdrivers.hg Xen is 4.0.0 I've done quite a lot experiments to locate the crash, and finally make it easy to reproduce. Here is the situation: 1) Start several Win2003 Guest with 2G memory to occupy host memory till from xm info | grep free to see xen has only almost 3G memory 2) Start another Guest with 2G memory, say domain X, and set its target to be 512M, after balloon, dom X will has only 512M, and xen has 2.5G memory 3) Start another Guest with 2G memory, then xen will have only 0.5G memory left 4) At this time, I set the domain X target to 2G (use xenstore-write /local/domain/x/memory/target 2097152) 5) domain X got blue screen at once. With code says 0x0000007f (0x0000000d, 0x00000000, 0x00000000, 0x00000000)" So, in short, when a domain wants more memory, it deflates its balloon, but if Xen doesn't enough memory, the domain will crash. I've go through http://lists.xensource.com/archives/html/xen-devel/2010-01/msg01230.html http://lists.xensource.com/archives/html/xen-devel/2010-02/msg00074.html it looks like the crash is because windows crash dumper go through those balloon out pages and from the discuss it would be harmless, but why I got this crash? Could you kindly offer me some help, thanks. ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Win2003 got blue Screen when ballooning with serial out put: "Iomem mapping not permitted" 2010-12-17 3:24 ` Win2003 got blue Screen when ballooning with serial out put: "Iomem mapping not permitted" tinnycloud @ 2010-12-17 8:53 ` Paul Durrant 2010-12-17 9:20 ` James Harper 2010-12-17 9:39 ` Win2003 got blue Screen when ballooning with serial out put: "Iomem mapping not permitted" tinnycloud 0 siblings, 2 replies; 26+ messages in thread From: Paul Durrant @ 2010-12-17 8:53 UTC (permalink / raw) To: tinnycloud, Steven Smith, xen-devel@lists.xensource.com Cc: Keir, james.harper@bendigoit.com.au, Fraser, JBeulich@novell.com If the frontend GPL PV storport driver is not ignoring block write failures in crashdump mode then you are unlikely the get a good dump from the ballooned down VM. As for the original crash, I guess the balloon driver is just not handling the populate hypercall failure gracefully. Paul > -----Original Message----- > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel- > bounces@lists.xensource.com] On Behalf Of tinnycloud > Sent: 17 December 2010 03:24 > To: Steven Smith; xen-devel@lists.xensource.com > Cc: james.harper@bendigoit.com.au; Keir Fraser; JBeulich@novell.com > Subject: [Xen-devel] Win2003 got blue Screen when ballooning with > serial out put: "Iomem mapping not permitted" > > Hi Steven: > > I was trying to make use of balloon driver on my win2003 HVM > Guests, > but confront a Guest crash problem with blue screen. > The serial output is much like > (XEN)grant_table.c:555:d0 Iomem mapping not permitted > ffffffffffffffff > > My pvdriver changeset is 823. From > http://xenbits.xensource.com/ext/win-pvdrivers.hg > Xen is 4.0.0 > > I've done quite a lot experiments to locate the crash, and > finally > make it easy to reproduce. > Here is the situation: > > 1) Start several Win2003 Guest with 2G memory to occupy host > memory > till from xm info | grep free to see xen has only almost 3G memory > 2) Start another Guest with 2G memory, say domain X, and set > its > target to be 512M, after balloon, dom X will has only 512M, and xen > has 2.5G > memory > 3) Start another Guest with 2G memory, then xen will have > only 0.5G > memory left > 4) At this time, I set the domain X target to 2G (use > xenstore-write > /local/domain/x/memory/target 2097152) > 5) domain X got blue screen at once. With code says 0x0000007f > (0x0000000d, 0x00000000, 0x00000000, 0x00000000)" > > So, in short, when a domain wants more memory, it deflates > its > balloon, but if Xen doesn't enough memory, the domain will crash. > > I've go through > http://lists.xensource.com/archives/html/xen-devel/2010- > 01/msg01230.html > > http://lists.xensource.com/archives/html/xen-devel/2010- > 02/msg00074.html > > it looks like the crash is because windows crash dumper go > through > those balloon out pages > and from the discuss it would be harmless, but why I got this > crash? > > Could you kindly offer me some help, thanks. > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Win2003 got blue Screen when ballooning with serial out put: "Iomem mapping not permitted" 2010-12-17 8:53 ` Paul Durrant @ 2010-12-17 9:20 ` James Harper 2010-12-20 2:06 ` tinnycloud ` (4 more replies) 2010-12-17 9:39 ` Win2003 got blue Screen when ballooning with serial out put: "Iomem mapping not permitted" tinnycloud 1 sibling, 5 replies; 26+ messages in thread From: James Harper @ 2010-12-17 9:20 UTC (permalink / raw) To: Paul Durrant, tinnycloud, Steven Smith, xen-devel; +Cc: Keir Fraser, JBeulich > > If the frontend GPL PV storport driver is not ignoring block write failures in > crashdump mode then you are unlikely the get a good dump from the ballooned > down VM. It does, because I had to balloon down a few pages for migration to work (probably an old bug by now). I did put a limit as to how many failures it was prepared to put up with though. > As for the original crash, I guess the balloon driver is just not handling the > populate hypercall failure gracefully. > Quite likely. James ^ permalink raw reply [flat|nested] 26+ messages in thread
* re: Win2003 got blue Screen when ballooning with serial out put: "Iomem mapping not permitted" 2010-12-17 9:20 ` James Harper @ 2010-12-20 2:06 ` tinnycloud 2011-01-05 13:11 ` Could the page sharing inside domain? (memory_sharing on xen) xiaoyun.maoxy ` (3 subsequent siblings) 4 siblings, 0 replies; 26+ messages in thread From: tinnycloud @ 2010-12-20 2:06 UTC (permalink / raw) To: 'James Harper', 'Paul Durrant', 'Steven Smith', xen-devel Cc: 'Keir Fraser', JBeulich Hi James: Thanks for your help. Beside not handling populating page failure, it seems like PV driver hasn't support POD yet. Another question is, in Linux Balloon driver, every time balloon 2MB, while in windows PV driver, the balloon unit is 1MB, Is there anything make this difference? Thanks. ----- ----- From: James Harper [mailto:james.harper@bendigoit.com.au] date: 20101217 17:20 tp: Paul Durrant; tinnycloud; Steven Smith; xen-devel@lists.xensource.com cc: Keir Fraser; JBeulich@novell.com subject: RE: [Xen-devel] Win2003 got blue Screen when ballooning with serial out put: "Iomem mapping not permitted" > > If the frontend GPL PV storport driver is not ignoring block write failures in > crashdump mode then you are unlikely the get a good dump from the ballooned > down VM. It does, because I had to balloon down a few pages for migration to work (probably an old bug by now). I did put a limit as to how many failures it was prepared to put up with though. > As for the original crash, I guess the balloon driver is just not handling the > populate hypercall failure gracefully. > Quite likely. James ^ permalink raw reply [flat|nested] 26+ messages in thread
* Could the page sharing inside domain? (memory_sharing on xen) 2010-12-17 9:20 ` James Harper 2010-12-20 2:06 ` tinnycloud @ 2011-01-05 13:11 ` xiaoyun.maoxy 2011-02-25 5:56 ` TODO in windows balloon driver tinnycloud ` (2 subsequent siblings) 4 siblings, 0 replies; 26+ messages in thread From: xiaoyun.maoxy @ 2011-01-05 13:11 UTC (permalink / raw) To: 'Keir Fraser' Cc: 'tinnycloud', 'James Harper', JBeulich, 'Paul Durrant', 'Steven Smith', xen-devel Hi Keir: One of the features listed as having been added to Xen 4 is page sharing for HVM domUs. Pity is it has been disabled since buggy. Well I tried to make it work these days. After go through the code and get thoroughly concept of page sharing, I've been able to setup test environment, but confronted domU crash. One abnormal output from serial is (XEN) mm.c:859:d0 Error getting mfn 2df15f (pfn fffffffffffffffe) from L1 entry 80000002df15f627 for l1e_owner=0, pg_owner=4 (XEN) mm.c:859:d0 Error getting mfn 2df160 (pfn fffffffffffffffe) from L1 entry 80000002df160627 for l1e_owner=0, pg_owner=4 Later, I found this is related to page sharing inside domain itself. That is when a domain X first read IO sectors Y, it will nominate the gref into xen(that is build a hash entry in xen) , after IO completion, it will build a hash entry in tapdisk2 hash table. But later domain X read same sectors again, it can find entry in both hash tables, and page sharing works, one page freed. Then I can see above serial output. So my question is: Is page sharing legal inside domain? Thanks. ^ permalink raw reply [flat|nested] 26+ messages in thread
* TODO in windows balloon driver 2010-12-17 9:20 ` James Harper 2010-12-20 2:06 ` tinnycloud 2011-01-05 13:11 ` Could the page sharing inside domain? (memory_sharing on xen) xiaoyun.maoxy @ 2011-02-25 5:56 ` tinnycloud 2011-02-26 12:17 ` James Harper 2011-02-26 11:20 ` blue screen " xiaoyun.maoxy [not found] ` <000301cbd5a7$3245a1b0$96d0e510$@maoxy@aliyun-inc.com> 4 siblings, 1 reply; 26+ messages in thread From: tinnycloud @ 2011-02-25 5:56 UTC (permalink / raw) To: xen-devel; +Cc: 'James Harper' HI James: I've noticed the TODO tag in xenpci/xenpci_fdo.c, line 294 290 KdPrint((__DRIVER_NAME " Calling HYPERVISOR_memory_op(XENMEM_populate_physmap) - pfn_count = %d\n", pfn_count)); 291 ret = HYPERVISOR_memory_op(xpdd, XENMEM_populate_physmap, &reservation); 292 ExFreePoolWithTag(pfns, XENPCI_POOL_TAG); 293 KdPrint((__DRIVER_NAME " populated %d pages\n", ret)); 294 /* TODO: what do we do if less than the required number of pages were populated??? can this happen??? */ Could we fix it in linux balloon driver way? When no enough pfn_count got, give memory back to xen. What do you think? Thanks. /* TODO: what do we do if less than the required number of pages were populated??? can this happen??? */ /* fixed! */ if(ret < (ULONG)pfn_count){ if(ret > 0){ /* We hit the Xen hard limit: reprobe. */ reservation.nr_extents = ret; ret = HYPERVISOR_memory_op(xpdd, XENMEM_decrease_reservation, &reservation); KdPrint((__DRIVER_NAME " decreased %d pages\n", ret)); } mdl->Next = head; head = mdl; ExFreePoolWithTag(pfns, XENPCI_POOL_TAG); break; } ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: TODO in windows balloon driver 2011-02-25 5:56 ` TODO in windows balloon driver tinnycloud @ 2011-02-26 12:17 ` James Harper 2011-02-26 13:35 ` MaoXiaoyun 0 siblings, 1 reply; 26+ messages in thread From: James Harper @ 2011-02-26 12:17 UTC (permalink / raw) To: tinnycloud, xen-devel > > HI James: > > I've noticed the TODO tag in xenpci/xenpci_fdo.c, line 294 > > 290 KdPrint((__DRIVER_NAME " Calling > HYPERVISOR_memory_op(XENMEM_populate_physmap) - pfn_count = %d\n", > pfn_count)); > 291 ret = HYPERVISOR_memory_op(xpdd, XENMEM_populate_physmap, > &reservation); > 292 ExFreePoolWithTag(pfns, XENPCI_POOL_TAG); > 293 KdPrint((__DRIVER_NAME " populated %d pages\n", ret)); > 294 /* TODO: what do we do if less than the required number of > pages were populated??? can this happen??? */ > > > Could we fix it in linux balloon driver way? > When no enough pfn_count got, give memory back to xen. > What do you think? > Thanks. I guess that would work, but then it would keep trying to decrease again every second. Maybe that's what we want but I'd rather put in some sort of backoff in there eg retry in one second then two seconds then 4 seconds etc up to a maximum of 1 minute or so, to reduce the noise. Are you seeing this happen? I'm guessing it's because xen doesn't have enough pages for you or because you've ballooned up above the maxmem limit or something... James ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: TODO in windows balloon driver 2011-02-26 12:17 ` James Harper @ 2011-02-26 13:35 ` MaoXiaoyun 2011-02-27 1:43 ` James Harper 0 siblings, 1 reply; 26+ messages in thread From: MaoXiaoyun @ 2011-02-26 13:35 UTC (permalink / raw) To: james.harper, xen devel [-- Attachment #1.1: Type: text/plain, Size: 1767 bytes --] Ye, You are right, it happens when xen doesn't have enough pages for the VM. And windows will crash now. In memory overcommit, If there are many VMs on a physical host, and in dom0 use a daemon for memory managment between VMS, it is possible that xen has no pages for the VM needs memory. So I think , it is better to fix it. Thanks. > Subject: RE: TODO in windows balloon driver > Date: Sat, 26 Feb 2011 23:17:54 +1100 > From: james.harper@bendigoit.com.au > To: tinnycloud@hotmail.com; xen-devel@lists.xensource.com > > > > > HI James: > > > > I've noticed the TODO tag in xenpci/xenpci_fdo.c, line 294 > > > > 290 KdPrint((__DRIVER_NAME " Calling > > HYPERVISOR_memory_op(XENMEM_populate_physmap) - pfn_count = %d\n", > > pfn_count)); > > 291 ret = HYPERVISOR_memory_op(xpdd, > XENMEM_populate_physmap, > > &reservation); > > 292 ExFreePoolWithTag(pfns, XENPCI_POOL_TAG); > > 293 KdPrint((__DRIVER_NAME " populated %d pages\n", > ret)); > > 294 /* TODO: what do we do if less than the required number > of > > pages were populated??? can this happen??? */ > > > > > > Could we fix it in linux balloon driver way? > > When no enough pfn_count got, give memory back to xen. > > What do you think? > > Thanks. > > I guess that would work, but then it would keep trying to decrease again > every second. Maybe that's what we want but I'd rather put in some sort > of backoff in there eg retry in one second then two seconds then 4 > seconds etc up to a maximum of 1 minute or so, to reduce the noise. > > Are you seeing this happen? I'm guessing it's because xen doesn't have > enough pages for you or because you've ballooned up above the maxmem > limit or something... > > James > [-- Attachment #1.2: Type: text/html, Size: 2336 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: TODO in windows balloon driver 2011-02-26 13:35 ` MaoXiaoyun @ 2011-02-27 1:43 ` James Harper 2011-02-27 3:35 ` James Harper 0 siblings, 1 reply; 26+ messages in thread From: James Harper @ 2011-02-27 1:43 UTC (permalink / raw) To: MaoXiaoyun, xen devel > > Ye, You are right, it happens when xen doesn't have enough pages for the VM. > And windows will crash now. > > In memory overcommit, If there are many VMs on a physical host, and in dom0 > use a daemon for > memory managment between VMS, it is possible that xen has no pages for the VM > needs memory. > > So I think , it is better to fix it. > I have put your fix in as well as the backoff delay I mentioned earlier, but I'm reviewing the ballooning stuff now. I can see one bug where I don't do the initial balloon down in the case of PoD. I've fixed that, but I'm not doing it early enough, so for Windows 2008 32 bit with memory=512 and maxmem=1024, Windows still crashes and 'xm dmesg' shows "Out of populate-on-demand memory!" just after my driver starts to load (in DriverEntry). It seems to work fine when memory=768 and maxmem=1024 but I still think it could crash on startup if you are unlucky. The only possible workaround is to do it in DriverEntry of xenpci but that will require a bit of a refactoring. I think it's probably worth doing though. James ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: RE: TODO in windows balloon driver 2011-02-27 1:43 ` James Harper @ 2011-02-27 3:35 ` James Harper 0 siblings, 0 replies; 26+ messages in thread From: James Harper @ 2011-02-27 3:35 UTC (permalink / raw) To: MaoXiaoyun, xen devel > > > > > Ye, You are right, it happens when xen doesn't have enough pages for > the VM. > > And windows will crash now. > > > > In memory overcommit, If there are many VMs on a physical host, and in > dom0 > > use a daemon for > > memory managment between VMS, it is possible that xen has no pages for > the VM > > needs memory. > > > > So I think , it is better to fix it. > > > > I have put your fix in as well as the backoff delay I mentioned earlier, > but I'm reviewing the ballooning stuff now. I can see one bug where I > don't do the initial balloon down in the case of PoD. I've fixed that, > but I'm not doing it early enough, so for Windows 2008 32 bit with > memory=512 and maxmem=1024, Windows still crashes and 'xm dmesg' shows > "Out of populate-on-demand memory!" just after my driver starts to load > (in DriverEntry). It seems to work fine when memory=768 and maxmem=1024 > but I still think it could crash on startup if you are unlucky. > > The only possible workaround is to do it in DriverEntry of xenpci but > that will require a bit of a refactoring. I think it's probably worth > doing though. > I've just pushed a partial fix for this. The initial balloon-down is now done during DriverEntry and I'm able to boot with memory=256 and maxmem=1024 without any problems (other than that Windows doesn't run particularly well with 256MB of memory :) I haven't worked out a way to pass the memory reserved in DriverEntry back to the xenpci FDO yet though so it's not particularly useful at this time as you can't balloon up again. I'll fix that soon now that I have the DriverEntry thing working. James ^ permalink raw reply [flat|nested] 26+ messages in thread
* blue screen in windows balloon driver 2010-12-17 9:20 ` James Harper ` (2 preceding siblings ...) 2011-02-25 5:56 ` TODO in windows balloon driver tinnycloud @ 2011-02-26 11:20 ` xiaoyun.maoxy [not found] ` <000301cbd5a7$3245a1b0$96d0e510$@maoxy@aliyun-inc.com> 4 siblings, 0 replies; 26+ messages in thread From: xiaoyun.maoxy @ 2011-02-26 11:20 UTC (permalink / raw) To: xen-devel; +Cc: george.dunlap, 'James Harper' Hi: We've confronted the windows 2003 Blue screen when using balloon driver. The blue screen has the information of "NO_PAGES_AVAILABLE", and Technical information: ***STOP: 0x0000004D (0x0002A8FB,0x0002A8FB,0x00000000,0x00000000) In fact we are doing the stress test on 24 windows2003 HVM on a 24G, 16core host. In dom0, there is a daemon process (balloond) will give memory back to the VM who acclaim memory. The balloond will ensure every VM at least has 512M memory. Each VM is started with memory=512 maxmem=2048 Inside each of the VM, there is two processes eat memory, each of which will eat 1G memory. And the page file size configured on C:\ is init size 1536M, max size 3072M, which I think even If balloond process not give back the memory back to VM, the VM can has 512M+3072M = 3.5G virtual memory. Am I right?, if so , since our eat memory process only consume 2G memory, h how could "NO_PAGES_AVAILABLE" happen? Also, since we enable VM writes its memory status into xenstore, and when blue screen, it has only has 972KB memory. Any comments? Many thanks. ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <000301cbd5a7$3245a1b0$96d0e510$@maoxy@aliyun-inc.com>]
* RE: blue screen in windows balloon driver [not found] ` <000301cbd5a7$3245a1b0$96d0e510$@maoxy@aliyun-inc.com> @ 2011-02-26 11:59 ` James Harper 0 siblings, 0 replies; 26+ messages in thread From: James Harper @ 2011-02-26 11:59 UTC (permalink / raw) To: xiaoyun.maoxy, xen-devel; +Cc: george.dunlap > Hi: > > We've confronted the windows 2003 Blue screen when using balloon > driver. > > The blue screen has the information of "NO_PAGES_AVAILABLE", and > Technical information: > ***STOP: 0x0000004D (0x0002A8FB,0x0002A8FB,0x00000000,0x00000000) > > In fact we are doing the stress test on 24 windows2003 HVM on a 24G, > 16core host. > In dom0, there is a daemon process (balloond) will give memory back > to the VM who acclaim memory. > The balloond will ensure every VM at least has 512M memory. > > Each VM is started with memory=512 maxmem=2048 > Inside each of the VM, there is two processes eat memory, each of > which will eat 1G memory. > And the page file size configured on C:\ is init size 1536M, max > size 3072M, which I think even > If balloond process not give back the memory back to VM, the VM can > has 512M+3072M = 3.5G virtual > memory. > > Am I right?, if so , since our eat memory process only consume 2G > memory, h > how could "NO_PAGES_AVAILABLE" happen? > > Also, since we enable VM writes its memory status into xenstore, and > when blue screen, it has only has 972KB memory. > > Any comments? Many thanks. > You've put myself (I wrote GPLPV) and George Dunlap (from Citrix) in the CC list but you don't say if you are using GPLPV drivers or Citrix PV drivers. If you are using GPLPV drivers let me know and I'll get some more information about the problem from you. If you aren't using GPLPV drivers then I don't think I can be of much assistance... Thanks James ^ permalink raw reply [flat|nested] 26+ messages in thread
* re: Win2003 got blue Screen when ballooning with serial out put: "Iomem mapping not permitted" 2010-12-17 8:53 ` Paul Durrant 2010-12-17 9:20 ` James Harper @ 2010-12-17 9:39 ` tinnycloud 1 sibling, 0 replies; 26+ messages in thread From: tinnycloud @ 2010-12-17 9:39 UTC (permalink / raw) To: 'Paul Durrant', 'Steven Smith', xen-devel Cc: james.harper, 'Keir Fraser', JBeulich Hi Paul: You are right. Thanks. From the code PV driver, the exception handle is not finished by James. KdPrint((__DRIVER_NAME " Calling HYPERVISOR_memory_op(XENMEM_populate_physmap) - pfn_count = %d\n", pfn_count)); ret = HYPERVISOR_memory_op(xpdd, XENMEM_populate_physmap, &reservation); ExFreePoolWithTag(pfns, XENPCI_POOL_TAG); KdPrint((__DRIVER_NAME " populated %d pages\n", ret)); /* TODO: what do we do if less than the required number of pages were populated??? can this happen??? * I will first try to implement myself. Also, that would be great appreciation if someone could offer this patch. -----mail----- : Paul Durrant [mailto:Paul.Durrant@citrix.com] sent: 2010年12月17日 16:53 to: tinnycloud; Steven Smith; xen-devel@lists.xensource.com cc: james.harper@bendigoit.com.au; Keir Fraser; JBeulich@novell.com Subject: RE: [Xen-devel] Win2003 got blue Screen when ballooning with serial out put: "Iomem mapping not permitted" If the frontend GPL PV storport driver is not ignoring block write failures in crashdump mode then you are unlikely the get a good dump from the ballooned down VM. As for the original crash, I guess the balloon driver is just not handling the populate hypercall failure gracefully. Paul > -----Original Message----- > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel- > bounces@lists.xensource.com] On Behalf Of tinnycloud > Sent: 17 December 2010 03:24 > To: Steven Smith; xen-devel@lists.xensource.com > Cc: james.harper@bendigoit.com.au; Keir Fraser; JBeulich@novell.com > Subject: [Xen-devel] Win2003 got blue Screen when ballooning with > serial out put: "Iomem mapping not permitted" > > Hi Steven: > > I was trying to make use of balloon driver on my win2003 HVM > Guests, > but confront a Guest crash problem with blue screen. > The serial output is much like > (XEN)grant_table.c:555:d0 Iomem mapping not permitted > ffffffffffffffff > > My pvdriver changeset is 823. From > http://xenbits.xensource.com/ext/win-pvdrivers.hg > Xen is 4.0.0 > > I've done quite a lot experiments to locate the crash, and > finally > make it easy to reproduce. > Here is the situation: > > 1) Start several Win2003 Guest with 2G memory to occupy host > memory > till from xm info | grep free to see xen has only almost 3G memory > 2) Start another Guest with 2G memory, say domain X, and set > its > target to be 512M, after balloon, dom X will has only 512M, and xen > has 2.5G > memory > 3) Start another Guest with 2G memory, then xen will have > only 0.5G > memory left > 4) At this time, I set the domain X target to 2G (use > xenstore-write > /local/domain/x/memory/target 2097152) > 5) domain X got blue screen at once. With code says 0x0000007f > (0x0000000d, 0x00000000, 0x00000000, 0x00000000)" > > So, in short, when a domain wants more memory, it deflates > its > balloon, but if Xen doesn't enough memory, the domain will crash. > > I've go through > http://lists.xensource.com/archives/html/xen-devel/2010- > 01/msg01230.html > > http://lists.xensource.com/archives/html/xen-devel/2010- > 02/msg00074.html > > it looks like the crash is because windows crash dumper go > through > those balloon out pages > and from the discuss it would be harmless, but why I got this > crash? > > Could you kindly offer me some help, thanks. > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* re:RE: blue screen in windows balloon driver
@ 2011-02-26 13:01 MaoXiaoyun
2011-02-27 11:25 ` James Harper
0 siblings, 1 reply; 26+ messages in thread
From: MaoXiaoyun @ 2011-02-26 13:01 UTC (permalink / raw)
To: xen devel; +Cc: george.dunlap, james.harper
[-- Attachment #1.1: Type: text/plain, Size: 2392 bytes --]
Thanks James.
I think it is GPLPV. The driver is from http://xenbits.xen.org/ext/win-pvdrivers.hg
But, I have done some other things
1) Add pod support
2) enable a meminfo thread, periodically write VM meminfo into xenstore
We use info of Current Memory, Free memory, and Committed memory, retrived through NativeAPI
3) our code is based from changeset 823, attached is the diff of my current code with changset of 853.
Maybe I need add my code to 853, and test again.
Thanks.
>From: James Harper [mailto:james.harper@bendigoit.com.au]
>To: xiaoyun.maoxy; xen-devel@lists.xensource.com
>cc: george.dunlap@eu.citrix.com
>Subject: RE: blue screen in windows balloon driver
>
>> Hi:
>> We've confronted the windows 2003 Blue screen when using balloon
>> driver.
>
>> The blue screen has the information of "NO_PAGES_AVAILABLE", and
>> Technical information:
>> ***STOP: 0x0000004D (0x0002A8FB,0x0002A8FB,0x00000000,0x00000000)
>
>> In fact we are doing the stress test on 24 windows2003 HVM on a
>> 24G, 16core host.
>> In dom0, there is a daemon process (balloond) will give memory
>> back to the VM who acclaim memory.
>> The balloond will ensure every VM at least has 512M memory.
>> Each VM is started with memory=512 maxmem=2048
>> Inside each of the VM, there is two processes eat memory, each
of which will eat 1G memory.
>> And the page file size configured on C:\ is init size 1536M, max
>> size 3072M, which I think even
>> If balloond process not give back the memory back to VM, the VM
> can has 512M+3072M = 3.5G virtual
>> memory.
>>
>> Am I right?, if so , since our eat memory process only consume
>> 2G memory, how could "NO_PAGES_AVAILABLE" happen?
>> Also, since we enable VM writes its memory status into xenstore,
>> when blue screen, it has only has 972KB memory.
>> Any comments? Many thanks.
>>
>
>
>You've put myself (I wrote GPLPV) and George Dunlap (from Citrix) in the
>CC list but you don't say if you are using GPLPV drivers or Citrix PV
>drivers. If you are using GPLPV drivers let me know and I'll get some
>more information about the problem from you. If you aren't using GPLPV
>drivers then I don't think I can be of much assistance...
>
>Thanks
>
>James
>
[-- Attachment #1.2: Type: text/html, Size: 3715 bytes --]
[-- Attachment #2: changset823.diff --]
[-- Type: application/octet-stream, Size: 72585 bytes --]
diff -ruN ../win-pvdrivers.hg/xenpci/evtchn.c xenpci/evtchn.c
--- ../win-pvdrivers.hg/xenpci/evtchn.c 2011-02-26 20:43:12.000000000 +0800
+++ xenpci/evtchn.c 2011-02-26 20:44:33.000000000 +0800
@@ -154,50 +154,38 @@
switch (ev_action->type)
{
case EVT_ACTION_TYPE_NORMAL:
- //KdPrint((__DRIVER_NAME " EVT_ACTION_TYPE_NORMAL port = %d\n", port));
+ //KdPrint((__DRIVER_NAME " EVT_ACTION_TYPE_NORMAL\n"));
ev_action->ServiceRoutine(ev_action->ServiceContext);
break;
case EVT_ACTION_TYPE_IRQ:
- //KdPrint((__DRIVER_NAME " EVT_ACTION_TYPE_IRQ port = %d\n", port));
+ //KdPrint((__DRIVER_NAME " EVT_ACTION_TYPE_IRQ\n"));
synch_set_bit(evt_bit, (volatile xen_long_t *)&xpdd->evtchn_pending_pvt[pcpu][evt_word]);
deferred = TRUE;
break;
case EVT_ACTION_TYPE_DPC:
- //KdPrint((__DRIVER_NAME " EVT_ACTION_TYPE_DPC port = %d\n", port));
+ //KdPrint((__DRIVER_NAME " EVT_ACTION_TYPE_DPC\n"));
KeInsertQueueDpc(&ev_action->Dpc, NULL, NULL);
break;
case EVT_ACTION_TYPE_SUSPEND:
KdPrint((__DRIVER_NAME " EVT_ACTION_TYPE_SUSPEND\n"));
for (i = 0; i < ARRAY_SIZE(xpdd->evtchn_pending_pvt[pcpu]); i++)
{
- if (!(xpdd->ev_actions[i].flags & EVT_ACTION_FLAGS_NO_SUSPEND))
+ if (xpdd->ev_actions[i].type == EVT_ACTION_TYPE_IRQ)
{
- switch(xpdd->ev_actions[i].type)
- {
- case EVT_ACTION_TYPE_IRQ:
- {
- int suspend_bit = i & (BITS_PER_LONG - 1);
- int suspend_word = i >> BITS_PER_LONG_SHIFT;
- synch_set_bit(suspend_bit, (volatile xen_long_t *)&xpdd->evtchn_pending_pvt[pcpu][suspend_word]);
- }
- break;
- case EVT_ACTION_TYPE_NORMAL:
- if (xpdd->ev_actions[i].ServiceRoutine)
- {
- xpdd->ev_actions[i].ServiceRoutine(xpdd->ev_actions[i].ServiceContext);
- }
- break;
- case EVT_ACTION_TYPE_DPC:
- KeInsertQueueDpc(&xpdd->ev_actions[i].Dpc, NULL, NULL);
- break;
- }
+ int suspend_bit = i & (BITS_PER_LONG - 1);
+ int suspend_word = i >> BITS_PER_LONG_SHIFT;
+ synch_set_bit(suspend_bit, (volatile xen_long_t *)&xpdd->evtchn_pending_pvt[pcpu][suspend_word]);
+ }
+ else if (xpdd->ev_actions[i].type == EVT_ACTION_TYPE_NORMAL && xpdd->ev_actions[i].ServiceRoutine)
+ {
+ xpdd->ev_actions[i].ServiceRoutine(xpdd->ev_actions[i].ServiceContext);
}
}
KeInsertQueueDpc(&ev_action->Dpc, NULL, NULL);
deferred = TRUE;
break;
default:
- KdPrint((__DRIVER_NAME " Unhandled Event!!! port=%d\n", port));
+ KdPrint((__DRIVER_NAME " Unhandled Event!!!\n"));
break;
}
}
@@ -235,7 +223,7 @@
}
NTSTATUS
-EvtChn_Bind(PVOID Context, evtchn_port_t Port, PXEN_EVTCHN_SERVICE_ROUTINE ServiceRoutine, PVOID ServiceContext, ULONG flags)
+EvtChn_Bind(PVOID Context, evtchn_port_t Port, PXEN_EVTCHN_SERVICE_ROUTINE ServiceRoutine, PVOID ServiceContext)
{
PXENPCI_DEVICE_DATA xpdd = Context;
ev_action_t *action = &xpdd->ev_actions[Port];
@@ -251,7 +239,6 @@
xpdd->ev_actions[Port].ServiceRoutine = ServiceRoutine;
xpdd->ev_actions[Port].ServiceContext = ServiceContext;
xpdd->ev_actions[Port].xpdd = xpdd;
- xpdd->ev_actions[Port].flags = flags;
KeMemoryBarrier();
xpdd->ev_actions[Port].type = EVT_ACTION_TYPE_NORMAL;
@@ -263,7 +250,7 @@
}
NTSTATUS
-EvtChn_BindDpc(PVOID Context, evtchn_port_t Port, PXEN_EVTCHN_SERVICE_ROUTINE ServiceRoutine, PVOID ServiceContext, ULONG flags)
+EvtChn_BindDpc(PVOID Context, evtchn_port_t Port, PXEN_EVTCHN_SERVICE_ROUTINE ServiceRoutine, PVOID ServiceContext)
{
PXENPCI_DEVICE_DATA xpdd = Context;
ev_action_t *action = &xpdd->ev_actions[Port];
@@ -279,7 +266,6 @@
xpdd->ev_actions[Port].ServiceRoutine = ServiceRoutine;
xpdd->ev_actions[Port].ServiceContext = ServiceContext;
xpdd->ev_actions[Port].xpdd = xpdd;
- xpdd->ev_actions[Port].flags = flags;
KeMemoryBarrier(); // make sure that the new service routine is only called once the context is set up
InterlockedExchange((volatile LONG *)&action->type, EVT_ACTION_TYPE_DPC);
@@ -291,7 +277,7 @@
}
NTSTATUS
-EvtChn_BindIrq(PVOID Context, evtchn_port_t Port, ULONG vector, PCHAR description, ULONG flags)
+EvtChn_BindIrq(PVOID Context, evtchn_port_t Port, ULONG vector, PCHAR description)
{
PXENPCI_DEVICE_DATA xpdd = Context;
ev_action_t *action = &xpdd->ev_actions[Port];
@@ -309,8 +295,7 @@
KeMemoryBarrier();
xpdd->ev_actions[Port].type = EVT_ACTION_TYPE_IRQ;
RtlStringCbCopyA(xpdd->ev_actions[Port].description, 128, description);
- xpdd->ev_actions[Port].flags = flags;
-
+
EvtChn_Unmask(Context, Port);
FUNCTION_EXIT();
@@ -461,7 +446,7 @@
KeInitializeEvent(&xpdd->pdo_suspend_event, SynchronizationEvent, FALSE);
xpdd->pdo_event_channel = EvtChn_AllocIpi(xpdd, 0);
- EvtChn_BindDpc(xpdd, xpdd->pdo_event_channel, EvtChn_PdoEventChannelDpc, xpdd, EVT_ACTION_FLAGS_DEFAULT);
+ EvtChn_BindDpc(xpdd, xpdd->pdo_event_channel, EvtChn_PdoEventChannelDpc, xpdd);
xpdd->ev_actions[xpdd->pdo_event_channel].type = EVT_ACTION_TYPE_SUSPEND; /* override dpc type */
KdPrint((__DRIVER_NAME " pdo_event_channel = %d\n", xpdd->pdo_event_channel));
diff -ruN ../win-pvdrivers.hg/xenpci/getphyinfo.c xenpci/getphyinfo.c
--- ../win-pvdrivers.hg/xenpci/getphyinfo.c 1970-01-01 08:00:00.000000000 +0800
+++ xenpci/getphyinfo.c 2011-02-26 20:44:33.000000000 +0800
@@ -0,0 +1,348 @@
+#include "getphyinfo.h"
+#include <WinError.h>
+
+//copy from the "xenpci.h"
+#define XENPCI_POOL_TAG (ULONG) 'XenP'
+
+typedef struct _SYSTEM_PERFORMANCE_INFORMATION{
+ LARGE_INTEGER IdleTime;
+ LARGE_INTEGER ReadTransferCount;
+ LARGE_INTEGER WriteTransferCount;
+ LARGE_INTEGER OtherTransferCount;
+ ULONG ReadOperationCount;
+ ULONG WriteOperationCount;
+ ULONG OtherOperationCount;
+ ULONG AvailablePages;
+ ULONG TotalCommittedPages;
+ ULONG TotalCommitLimit;
+ ULONG PeakCommitment;
+ ULONG PageFaults;
+ ULONG WriteCopyFaults;
+ ULONG TransitionFaults;
+ ULONG Reserved1;
+ ULONG DemandZeroFaults;
+ ULONG PagesRead;
+ ULONG PageReadIos;
+ ULONG Reserved2[2];
+ ULONG PagefilePagesWritten;
+ ULONG PagefilePageWriteIos;
+ ULONG MappedFilePagesWritten;
+ ULONG MappedFilePageWriteIos;
+ ULONG PagedPoolUsage;
+ ULONG NonPagedPoolUsage;
+ ULONG PagedPoolAllocs;
+ ULONG PagedPoolFrees;
+ ULONG NonPagedPoolAllocs;
+ ULONG NonPagedPoolFrees;
+ ULONG TotalFreeSystemPtes;
+ ULONG SystemCodePage;
+ ULONG TotalSystemDriverPages;
+ ULONG TotalSystemCodePages;
+ ULONG SmallNonPagedLookasideListAllocateHits;
+ ULONG SmallPagedLookasideListAllocateHits;
+ ULONG Reserved3;
+ ULONG MmSystemCachePage;
+ ULONG PagedPoolPage;
+ ULONG SystemDriverPage;
+ ULONG FastReadNoWait;
+ ULONG FastReadWait;
+ ULONG FastReadResourceMiss;
+ ULONG FastReadNotPossible;
+ ULONG FastMdlReadNoWait;
+ ULONG FastMdlReadWait;
+ ULONG FastMdlReadResourceMiss;
+ ULONG FastMdlReadNotPossible;
+ ULONG MapDataNoWait;
+ ULONG MapDataWait;
+ ULONG MapDataNoWaitMiss;
+ ULONG MapDataWaitMiss;
+ ULONG PinMappedDataCount;
+ ULONG PinReadNoWait;
+ ULONG PinReadWait;
+ ULONG PinReadNoWaitMiss;
+ ULONG PinReadWaitMiss;
+ ULONG CopyReadNoWait;
+ ULONG CopyReadWait;
+ ULONG CopyReadNoWaitMiss;
+ ULONG CopyReadWaitMiss;
+ ULONG MdlReadNoWait;
+ ULONG MdlReadWait;
+ ULONG MdlReadNoWaitMiss;
+ ULONG MdlReadWaitMiss;
+ ULONG ReadAheadIos;
+ ULONG LazyWriteIos;
+ ULONG LazyWritePages;
+ ULONG DataFlushes;
+ ULONG DataPages;
+ ULONG ContextSwitches;
+ ULONG FirstLevelTbFills;
+ ULONG SecondLevelTbFills;
+ ULONG SystemCalls;
+ } SYSTEM_PERFORMANCE_INFORMATION, *PSYSTEM_PERFORMANCE_INFORMATION;
+
+typedef struct _SYSTEM_BASIC_INFORMATION{
+ ULONG Unknown;
+ ULONG MaximumIncrement;
+ ULONG PageSize;
+ ULONG NumberOfPhysicalPages;
+ ULONG LowestPhysicalPage;
+ ULONG HighestPhysicalPage;
+ ULONG AllocationGranularity;
+ ULONG_PTR LowestUserAddress;
+ ULONG_PTR HighestUserAddress;
+ ULONG_PTR ActiveProcessors;
+ CCHAR NumberProcessors;
+ }SYSTEM_BASIC_INFORMATION, *PSYSTEM_BASIC_INFORMATION;
+
+
+typedef enum _SYSTEM_INFORMATION_CLASS {
+ SystemBasicInformation, // 0 Y N
+ SystemProcessorInformation, // 1 Y N
+ SystemPerformanceInformation, // 2 Y N
+ SystemTimeOfDayInformation, // 3 Y N
+ SystemNotImplemented1, // 4 Y N
+ SystemProcessesAndThreadsInformation, // 5 Y N
+ SystemCallCounts, // 6 Y N
+ SystemConfigurationInformation, // 7 Y N
+ SystemProcessorTimes, // 8 Y N
+ SystemGlobalFlag, // 9 Y Y
+ SystemNotImplemented2, // 10 Y N
+ SystemModuleInformation, // 11 Y N
+ SystemLockInformation, // 12 Y N
+ SystemNotImplemented3, // 13 Y N
+ SystemNotImplemented4, // 14 Y N
+ SystemNotImplemented5, // 15 Y N
+ SystemHandleInformation, // 16 Y N
+ SystemObjectInformation, // 17 Y N
+ SystemPagefileInformation, // 18 Y N
+ SystemInstructionEmulationCounts, // 19 Y N
+ SystemInvalidInfoClass1, // 20
+ SystemCacheInformation, // 21 Y Y
+ SystemPoolTagInformation, // 22 Y N
+ SystemProcessorStatistics, // 23 Y N
+ SystemDpcInformation, // 24 Y Y
+ SystemNotImplemented6, // 25 Y N
+ SystemLoadImage, // 26 N Y
+ SystemUnloadImage, // 27 N Y
+ SystemTimeAdjustment, // 28 Y Y
+ SystemNotImplemented7, // 29 Y N
+ SystemNotImplemented8, // 30 Y N
+ SystemNotImplemented9, // 31 Y N
+ SystemCrashDumpInformation, // 32 Y N
+ SystemExceptionInformation, // 33 Y N
+ SystemCrashDumpStateInformation, // 34 Y Y/N
+ SystemKernelDebuggerInformation, // 35 Y N
+ SystemContextSwitchInformation, // 36 Y N
+ SystemRegistryQuotaInformation, // 37 Y Y
+ SystemLoadAndCallImage, // 38 N Y
+ SystemPrioritySeparation, // 39 N Y
+ SystemNotImplemented10, // 40 Y N
+ SystemNotImplemented11, // 41 Y N
+ SystemInvalidInfoClass2, // 42
+ SystemInvalidInfoClass3, // 43
+ SystemTimeZoneInformation, // 44 Y N
+ SystemLookasideInformation, // 45 Y N
+ SystemSetTimeSlipEvent, // 46 N Y
+ SystemCreateSession, // 47 N Y
+ SystemDeleteSession, // 48 N Y
+ SystemInvalidInfoClass4, // 49
+ SystemRangeStartInformation, // 50 Y N
+ SystemVerifierInformation, // 51 Y Y
+ SystemAddVerifier, // 52 N Y
+ SystemSessionProcessesInformation // 53 Y N
+} SYSTEM_INFORMATION_CLASS;
+
+
+
+typedef enum {
+ StateInitialized,
+ StateReady,
+ StateRunning,
+ StateStandby,
+ StateTerminated,
+ StateWait,
+ StateTransition,
+ StateUnknown
+} THREAD_STATE;
+
+typedef struct _SYSTEM_THREADS {
+ LARGE_INTEGER KernelTime;
+ LARGE_INTEGER UserTime;
+ LARGE_INTEGER CreateTime;
+ ULONG WaitTime;
+ PVOID StartAddress;
+ CLIENT_ID ClientId;
+ KPRIORITY Priority;
+ KPRIORITY BasePriority;
+ ULONG ContextSwitchCount;
+ THREAD_STATE State;
+ KWAIT_REASON WaitReason;
+} SYSTEM_THREADS, *PSYSTEM_THREADS;
+
+#if defined(_WIN64)
+
+/*
+ the struct has been changed to avoid error!
+*/
+typedef struct _VM_COUNTERSEX {
+ ULONGLONG PeakVirtualSize; // used to be ULONG
+ ULONGLONG VirtualSize; // used to be ULONG
+ ULONG PageFaultCount; // used to be ULONG
+ ULONGLONG PeakWorkingSetSize; // used to be ULONG
+ ULONGLONG WorkingSetSize; // used to be ULONG
+ ULONGLONG QuotaPeakPagedPoolUsage; // used to be ULONG
+ ULONGLONG QuotaPagedPoolUsage; // used to be ULONG
+ ULONGLONG QuotaPeakNonPagedPoolUsage; // used to be ULONG
+ ULONGLONG QuotaNonPagedPoolUsage; // used to be ULONG
+ ULONGLONG PagefileUsage; // used to be ULONG
+ ULONGLONG PeakPagefileUsage; // used to be ULONG
+ ULONGLONG PrivateByte; // add by pengfei.zhangpf
+} VM_COUNTERSEX, *PVM_COUNTERSEX;
+
+typedef struct _SYSTEM_PROCESSES {
+ ULONG NextEntryDelta;
+ ULONG ThreadCount;
+ ULONG Reserved1[6];
+ LARGE_INTEGER CreateTime;
+ LARGE_INTEGER UserTime;
+ LARGE_INTEGER KernelTime;
+ UNICODE_STRING ProcessName;
+ KPRIORITY BasePriority;
+ ULONGLONG ProcessId; // used to be ULONG
+ ULONGLONG InheritedFromProcessId; // used to be ULONG
+ ULONGLONG HandleCount; // used to be ULONG
+ ULONG Reserved2[2];
+ VM_COUNTERSEX VmCounters;
+ IO_COUNTERS IoCounters;
+ SYSTEM_THREADS Threads[1];
+} SYSTEM_PROCESSES, *PSYSTEM_PROCESSES;
+
+#else
+typedef struct _VM_COUNTERSEX {
+ ULONG PeakVirtualSize;
+ ULONG VirtualSize;
+ ULONG PageFaultCount;
+ ULONG PeakWorkingSetSize;
+ ULONG WorkingSetSize;
+ ULONG QuotaPeakPagedPoolUsage;
+ ULONG QuotaPagedPoolUsage;
+ ULONG QuotaPeakNonPagedPoolUsage;
+ ULONG QuotaNonPagedPoolUsage;
+ ULONG PagefileUsage;
+ ULONG PeakPagefileUsage;
+ ULONG PrivateByte; // add by pengfei.zhangpf
+} VM_COUNTERSEX, *PVM_COUNTERSEX;
+
+typedef struct _SYSTEM_PROCESSES {
+ ULONG NextEntryDelta;
+ ULONG ThreadCount;
+ ULONG Reserved1[6];
+ LARGE_INTEGER CreateTime;
+ LARGE_INTEGER UserTime;
+ LARGE_INTEGER KernelTime;
+ UNICODE_STRING ProcessName;
+ KPRIORITY BasePriority;
+ ULONG ProcessId;
+ ULONG InheritedFromProcessId;
+ ULONG HandleCount;
+ ULONG Reserved2[2];
+ VM_COUNTERSEX VmCounters;
+ IO_COUNTERS IoCounters;
+ SYSTEM_THREADS Threads[1];
+} SYSTEM_PROCESSES, *PSYSTEM_PROCESSES;
+#endif
+
+#define DEF_BUF_SIZE 65536
+
+NTSYSAPI
+ NTSTATUS
+ NTAPI
+ NtQuerySystemInformation(
+ IN SYSTEM_INFORMATION_CLASS SystemInformationClass,
+ OUT PVOID SystemInformation,
+ IN ULONG SystemInformationLength,
+ OUT PULONG ReturnLength OPTIONAL );
+
+NTSTATUS NTAPI
+PvGlobalMemoryStatus(PVOID pBuffer)
+{
+ LPMEMORYSTATUS pBufferXsMem;
+ SYSTEM_BASIC_INFORMATION BaseCachedSysInfo;
+ SYSTEM_PERFORMANCE_INFORMATION PerformanceInfo;
+ ULONG uSizeSysInfo;
+ ULONGLONG totalCommitSize;
+ NTSTATUS status;
+ PVOID pBufferSysMem;
+ PSYSTEM_PROCESSES pInfo;
+
+ pBufferXsMem = (LPMEMORYSTATUS)pBuffer;
+
+ status = NtQuerySystemInformation(SystemBasicInformation,
+ &BaseCachedSysInfo,
+ sizeof(BaseCachedSysInfo),
+ NULL);
+ if (!NT_SUCCESS(status))
+ return status;
+
+ /* Query performance information */
+ status = NtQuerySystemInformation(SystemPerformanceInformation,
+ &PerformanceInfo,
+ sizeof(PerformanceInfo),
+ NULL);
+ if (!NT_SUCCESS(status))
+ return status;
+
+ pBufferXsMem->totalPhys = BaseCachedSysInfo.NumberOfPhysicalPages * BaseCachedSysInfo.PageSize;
+
+ /* Now save available physical memory */
+ pBufferXsMem->MemFree = (PerformanceInfo.AvailablePages * BaseCachedSysInfo.PageSize) >> 10;
+
+ uSizeSysInfo = DEF_BUF_SIZE;
+
+ do{
+ pBufferSysMem = ExAllocatePoolWithTag(NonPagedPool, uSizeSysInfo, XENPCI_POOL_TAG);
+ if(pBufferSysMem == NULL)
+ return status;
+
+ status = NtQuerySystemInformation(SystemProcessesAndThreadsInformation, pBufferSysMem, uSizeSysInfo, NULL);
+
+ if (!NT_SUCCESS(status))
+ {
+ if (status == STATUS_INFO_LENGTH_MISMATCH)
+ {
+ uSizeSysInfo += DEF_BUF_SIZE ;
+ ExFreePoolWithTag(pBufferSysMem, XENPCI_POOL_TAG);
+ continue;
+ }
+ else
+ {
+ ExFreePoolWithTag(pBufferSysMem, XENPCI_POOL_TAG);
+ return STATUS_SEVERITY_ERROR;
+ }
+ }
+ else
+ break;
+
+ }while(!NT_SUCCESS(status));/* Query process information */
+
+ KdPrint(("xenpci""cbffer:------%d\n", uSizeSysInfo));
+ pInfo = (PSYSTEM_PROCESSES)pBufferSysMem;
+ totalCommitSize = 0;
+
+ for (;;) {
+
+ if (pInfo -> ProcessId != 0)
+ totalCommitSize += (pInfo->VmCounters).PagefileUsage;
+
+ if (pInfo->NextEntryDelta == 0)
+ break;
+
+ pInfo = (PSYSTEM_PROCESSES)(((PUCHAR)pInfo) + pInfo->NextEntryDelta);
+ }
+
+ pBufferXsMem->Committed_AS =(totalCommitSize >>10);
+ ExFreePoolWithTag(pBufferSysMem, XENPCI_POOL_TAG);
+
+ return 0;
+}
+
diff -ruN ../win-pvdrivers.hg/xenpci/getphyinfo.h xenpci/getphyinfo.h
--- ../win-pvdrivers.hg/xenpci/getphyinfo.h 1970-01-01 08:00:00.000000000 +0800
+++ xenpci/getphyinfo.h 2011-02-26 20:44:33.000000000 +0800
@@ -0,0 +1,28 @@
+#if !defined(_GETPHYINFO_H_)
+#define _GETPHYINFO_H_
+
+#define DDKAPI
+#include <ntddk.h>
+#include <wdm.h>
+#define NTSTRSAFE_LIB
+#include <ntstrsafe.h>
+#include <stdlib.h>
+
+/*
+ if meminfo changed value less than BOUND_VALUE, no xenstore updated
+ default 5M
+*/
+#define BOUND_VALUE 5120
+#define CHANGED(x,y) (((x)>(y)+BOUND_VALUE)||((y)>(x)+BOUND_VALUE))
+
+typedef struct _MEMORYSTATUS {
+ ULONG totalPhys;
+ ULONG MemCur;
+ ULONG MemFree;
+ ULONGLONG Committed_AS;
+} MEMORYSTATUS, *LPMEMORYSTATUS;
+
+NTSTATUS NTAPI
+PvGlobalMemoryStatus(PVOID pBuffer);
+
+#endif
diff -ruN ../win-pvdrivers.hg/xenpci/gnttbl.c xenpci/gnttbl.c
--- ../win-pvdrivers.hg/xenpci/gnttbl.c 2011-02-26 20:43:12.000000000 +0800
+++ xenpci/gnttbl.c 2011-02-26 20:44:33.000000000 +0800
@@ -27,12 +27,12 @@
UNREFERENCED_PARAMETER(tag);
#if DBG
- if (xpdd->gnttbl_tag[ref] != tag)
- KdPrint((__DRIVER_NAME " Grant Entry %d for %.4s doesn't match %.4s\n", ref, (PUCHAR)&tag, (PUCHAR)&xpdd->gnttbl_tag[ref]));
- ASSERT(xpdd->gnttbl_tag[ref] == tag);
- xpdd->gnttbl_tag[ref] = 0;
+ if (xpdd->gnttab_tag[ref] != tag)
+ KdPrint((__DRIVER_NAME " Grant Entry %d for %.4s doesn't match %.4s\n", ref, (PUCHAR)&tag, (PUCHAR)&xpdd->gnttab_tag[ref]));
+ ASSERT(xpdd->gnttab_tag[ref] == tag);
+ xpdd->gnttab_tag[ref] = 0;
#endif
- stack_push(xpdd->gnttbl_ss, (PVOID)ref);
+ stack_push(xpdd->gnttab_ss, (PVOID)ref);
}
grant_ref_t
@@ -44,17 +44,17 @@
UNREFERENCED_PARAMETER(tag);
- if (!stack_pop(xpdd->gnttbl_ss, &ptr_ref))
+ if (!stack_pop(xpdd->gnttab_ss, &ptr_ref))
{
KdPrint((__DRIVER_NAME " No free grant refs\n"));
return INVALID_GRANT_REF;
}
ref = (grant_ref_t)(ULONG_PTR)ptr_ref;
#if DBG
- if (xpdd->gnttbl_tag[ref])
- KdPrint((__DRIVER_NAME " Grant Entry %d for %.4s in use by %.4s\n", ref, (PUCHAR)&tag, (PUCHAR)&xpdd->gnttbl_tag[ref]));
- ASSERT(!xpdd->gnttbl_tag[ref]);
- xpdd->gnttbl_tag[ref] = tag;
+ if (xpdd->gnttab_tag[ref])
+ KdPrint((__DRIVER_NAME " Grant Entry %d for %.4s in use by %.4s\n", ref, (PUCHAR)&tag, (PUCHAR)&xpdd->gnttab_tag[ref]));
+ ASSERT(!xpdd->gnttab_tag[ref]);
+ xpdd->gnttab_tag[ref] = tag;
#endif
return ref;
@@ -67,19 +67,17 @@
struct xen_add_to_physmap xatp;
unsigned int i = end_idx;
- FUNCTION_ENTER();
/* Loop backwards, so that the first hypercall has the largest index, ensuring that the table will grow only once. */
do {
xatp.domid = DOMID_SELF;
xatp.idx = i;
xatp.space = XENMAPSPACE_grant_table;
- xatp.gpfn = (xen_pfn_t)MmGetMdlPfnArray(xpdd->gnttbl_mdl)[i];
+ xatp.gpfn = (xen_pfn_t)(xpdd->gnttab_table_physical.QuadPart >> PAGE_SHIFT) + i;
if (HYPERVISOR_memory_op(xpdd, XENMEM_add_to_physmap, &xatp))
{
- KdPrint((__DRIVER_NAME " *** ERROR MAPPING FRAME %d ***\n", i));
+ KdPrint((__DRIVER_NAME " ***ERROR MAPPING FRAME***\n"));
}
} while (i-- > start_idx);
- FUNCTION_EXIT();
return 0;
}
@@ -102,24 +100,24 @@
if (ref == INVALID_GRANT_REF)
return ref;
- ASSERT(xpdd->gnttbl_tag[ref] == tag);
+ ASSERT(xpdd->gnttab_tag[ref] == tag);
- xpdd->gnttbl_table[ref].frame = frame;
- xpdd->gnttbl_table[ref].domid = domid;
+ xpdd->gnttab_table[ref].frame = frame;
+ xpdd->gnttab_table[ref].domid = domid;
- if (xpdd->gnttbl_table[ref].flags)
+ if (xpdd->gnttab_table[ref].flags)
{
#if DBG
- KdPrint((__DRIVER_NAME " Grant Entry %d for %.4s still in use by %.4s\n", ref, (PUCHAR)&tag, (PUCHAR)&xpdd->gnttbl_tag[ref]));
+ KdPrint((__DRIVER_NAME " Grant Entry %d for %.4s still in use by %.4s\n", ref, (PUCHAR)&tag, (PUCHAR)&xpdd->gnttab_tag[ref]));
#else
KdPrint((__DRIVER_NAME " Grant Entry %d for %.4s still in use\n", ref, (PUCHAR)&tag));
#endif
}
- ASSERT(!xpdd->gnttbl_table[ref].flags);
+ ASSERT(!xpdd->gnttab_table[ref].flags);
KeMemoryBarrier();
readonly *= GTF_readonly;
- xpdd->gnttbl_table[ref].flags = GTF_permit_access | (uint16_t)readonly;
+ xpdd->gnttab_table[ref].flags = GTF_permit_access | (uint16_t)readonly;
return ref;
}
@@ -135,9 +133,9 @@
unsigned short flags, nflags;
ASSERT(ref != INVALID_GRANT_REF);
- ASSERT(xpdd->gnttbl_tag[ref] == tag);
+ ASSERT(xpdd->gnttab_tag[ref] == tag);
- nflags = xpdd->gnttbl_table[ref].flags;
+ nflags = xpdd->gnttab_table[ref].flags;
do {
if ((flags = nflags) & (GTF_reading|GTF_writing))
{
@@ -145,7 +143,7 @@
return FALSE;
}
} while ((nflags = InterlockedCompareExchange16(
- (volatile SHORT *)&xpdd->gnttbl_table[ref].flags, 0, flags)) != flags);
+ (volatile SHORT *)&xpdd->gnttab_table[ref].flags, 0, flags)) != flags);
if (!keepref)
GntTbl_PutRef(Context, ref, tag);
@@ -185,48 +183,28 @@
grant_entries = min(NR_GRANT_ENTRIES, (xpdd->grant_frames * PAGE_SIZE / sizeof(grant_entry_t)));
KdPrint((__DRIVER_NAME " grant_entries = %d\n", grant_entries));
#if DBG
- xpdd->gnttbl_tag = ExAllocatePoolWithTag(NonPagedPool, grant_entries * sizeof(ULONG), XENPCI_POOL_TAG);
- RtlZeroMemory(xpdd->gnttbl_tag, grant_entries * sizeof(ULONG));
- xpdd->gnttbl_tag_copy = ExAllocatePoolWithTag(NonPagedPool, grant_entries * sizeof(ULONG), XENPCI_POOL_TAG);
+ xpdd->gnttab_tag = ExAllocatePoolWithTag(NonPagedPool, grant_entries * sizeof(ULONG), XENPCI_POOL_TAG);
+ RtlZeroMemory(xpdd->gnttab_tag, grant_entries * sizeof(ULONG));
#endif
- xpdd->gnttbl_table_copy = ExAllocatePoolWithTag(NonPagedPool, xpdd->grant_frames * PAGE_SIZE, XENPCI_POOL_TAG);
- ASSERT(xpdd->gnttbl_table_copy); // lazy
- xpdd->gnttbl_table = ExAllocatePoolWithTag(NonPagedPool, xpdd->grant_frames * PAGE_SIZE, XENPCI_POOL_TAG);
- ASSERT(xpdd->gnttbl_table); // lazy
- /* dom0 crashes if we allocate the wrong amount of memory here! */
- xpdd->gnttbl_mdl = IoAllocateMdl(xpdd->gnttbl_table, xpdd->grant_frames * PAGE_SIZE, FALSE, FALSE, NULL);
- ASSERT(xpdd->gnttbl_mdl); // lazy
- MmBuildMdlForNonPagedPool(xpdd->gnttbl_mdl);
-
- /* make some holes for the grant pages to fill in */
- for (i = 0; i < (int)xpdd->grant_frames; i++)
- {
- struct xen_memory_reservation reservation;
- xen_pfn_t pfn;
- ULONG ret;
-
- reservation.address_bits = 0;
- reservation.extent_order = 0;
- reservation.domid = DOMID_SELF;
- reservation.nr_extents = 1;
- #pragma warning(disable: 4127) /* conditional expression is constant */
- pfn = (xen_pfn_t)MmGetMdlPfnArray(xpdd->gnttbl_mdl)[i];
- KdPrint((__DRIVER_NAME " pfn = %x\n", (ULONG)pfn));
- set_xen_guest_handle(reservation.extent_start, &pfn);
-
- KdPrint((__DRIVER_NAME " Calling HYPERVISOR_memory_op - pfn = %x\n", (ULONG)pfn));
- ret = HYPERVISOR_memory_op(xpdd, XENMEM_decrease_reservation, &reservation);
- KdPrint((__DRIVER_NAME " decreased %d pages for grant table frame %d\n", ret, i));
+ xpdd->gnttab_table_copy = ExAllocatePoolWithTag(NonPagedPool, xpdd->grant_frames * PAGE_SIZE, XENPCI_POOL_TAG);
+ ASSERT(xpdd->gnttab_table_copy); // lazy
+ xpdd->gnttab_table_physical = XenPci_AllocMMIO(xpdd, PAGE_SIZE * xpdd->grant_frames);
+ xpdd->gnttab_table = MmMapIoSpace(xpdd->gnttab_table_physical, PAGE_SIZE * xpdd->grant_frames, MmNonCached);
+ if (!xpdd->gnttab_table)
+ {
+ KdPrint((__DRIVER_NAME " Error Mapping Grant Table Shared Memory\n"));
+ // this should be a show stopper...
+ return;
}
- stack_new(&xpdd->gnttbl_ss, grant_entries);
+ stack_new(&xpdd->gnttab_ss, grant_entries);
for (i = NR_RESERVED_ENTRIES; i < grant_entries; i++)
- stack_push(xpdd->gnttbl_ss, (PVOID)i);
+ stack_push(xpdd->gnttab_ss, (PVOID)i);
GntTbl_Map(xpdd, 0, xpdd->grant_frames - 1);
- RtlZeroMemory(xpdd->gnttbl_table, PAGE_SIZE * xpdd->grant_frames);
+ RtlZeroMemory(xpdd->gnttab_table, PAGE_SIZE * xpdd->grant_frames);
FUNCTION_EXIT();
}
@@ -234,54 +212,7 @@
VOID
GntTbl_Suspend(PXENPCI_DEVICE_DATA xpdd)
{
- #if DBG
- int grant_entries;
- #endif
- int i;
-
- FUNCTION_ENTER();
-
- /* copy some grant refs and switch to an alternate freelist, but only on hiber */
- if (KeGetCurrentIrql() <= DISPATCH_LEVEL)
- {
- KdPrint((__DRIVER_NAME " backing up grant ref stack\n"));
- for (i = 0; i < HIBER_GREF_COUNT; i++)
- {
- xpdd->hiber_grefs[i] = INVALID_GRANT_REF;
- }
- for (i = 0; i < HIBER_GREF_COUNT; i++)
- {
- if ((xpdd->hiber_grefs[i] = GntTbl_GetRef(xpdd, (ULONG)'HIBR')) == INVALID_GRANT_REF)
- break;
- }
- KdPrint((__DRIVER_NAME " %d grant refs reserved\n", i));
- xpdd->gnttbl_ss_copy = xpdd->gnttbl_ss;
- stack_new(&xpdd->gnttbl_ss, HIBER_GREF_COUNT);
- }
- else
- {
- xpdd->gnttbl_ss_copy = NULL;
- }
-
- memcpy(xpdd->gnttbl_table_copy, xpdd->gnttbl_table, xpdd->grant_frames * PAGE_SIZE);
- #if DBG
- /* even though gnttbl_tag is actually preserved, it is used by the dump driver so must be restored to exactly the same state as it was on suspend */
- grant_entries = min(NR_GRANT_ENTRIES, (xpdd->grant_frames * PAGE_SIZE / sizeof(grant_entry_t)));
- memcpy(xpdd->gnttbl_tag_copy, xpdd->gnttbl_tag, grant_entries * sizeof(ULONG));
- #endif
-
- /* put the grant entries on the new freelist, after copying the tables above */
- if (KeGetCurrentIrql() <= DISPATCH_LEVEL)
- {
- for (i = 0; i < HIBER_GREF_COUNT; i++)
- {
- if (xpdd->hiber_grefs[i] == INVALID_GRANT_REF)
- break;
- GntTbl_PutRef(xpdd, xpdd->hiber_grefs[i], (ULONG)'HIBR');
- }
- }
-
- FUNCTION_EXIT();
+ memcpy(xpdd->gnttab_table_copy, xpdd->gnttab_table, xpdd->grant_frames * PAGE_SIZE);
}
VOID
@@ -289,58 +220,15 @@
{
ULONG new_grant_frames;
ULONG result;
- int i;
- #if DBG
- int grant_entries;
- #endif
-
+
FUNCTION_ENTER();
-
- for (i = 0; i < (int)xpdd->grant_frames; i++)
- {
- struct xen_memory_reservation reservation;
- xen_pfn_t pfn;
- ULONG ret;
-
- reservation.address_bits = 0;
- reservation.extent_order = 0;
- reservation.domid = DOMID_SELF;
- reservation.nr_extents = 1;
- #pragma warning(disable: 4127) /* conditional expression is constant */
- pfn = (xen_pfn_t)MmGetMdlPfnArray(xpdd->gnttbl_mdl)[i];
- KdPrint((__DRIVER_NAME " pfn = %x\n", (ULONG)pfn));
- set_xen_guest_handle(reservation.extent_start, &pfn);
-
- KdPrint((__DRIVER_NAME " Calling HYPERVISOR_memory_op - pfn = %x\n", (ULONG)pfn));
- ret = HYPERVISOR_memory_op(xpdd, XENMEM_decrease_reservation, &reservation);
- KdPrint((__DRIVER_NAME " decreased %d pages for grant table frame %d\n", ret, i));
- }
-
+
new_grant_frames = GntTbl_QueryMaxFrames(xpdd);
KdPrint((__DRIVER_NAME " new_grant_frames = %d\n", new_grant_frames));
ASSERT(new_grant_frames >= xpdd->grant_frames); // lazy
result = GntTbl_Map(xpdd, 0, xpdd->grant_frames - 1);
KdPrint((__DRIVER_NAME " GntTbl_Map result = %d\n", result));
- memcpy(xpdd->gnttbl_table, xpdd->gnttbl_table_copy, xpdd->grant_frames * PAGE_SIZE);
- #if DBG
- grant_entries = min(NR_GRANT_ENTRIES, (xpdd->grant_frames * PAGE_SIZE / sizeof(grant_entry_t)));
- memcpy(xpdd->gnttbl_tag, xpdd->gnttbl_tag_copy, grant_entries * sizeof(ULONG));
- #endif
-
- /* switch back and put the hiber grants back again */
- if (xpdd->gnttbl_ss_copy)
- {
- KdPrint((__DRIVER_NAME " restoring grant ref stack\n"));
- stack_delete(xpdd->gnttbl_ss, NULL, NULL);
- xpdd->gnttbl_ss = xpdd->gnttbl_ss_copy;
- for (i = 0; i < HIBER_GREF_COUNT; i++)
- {
- if (xpdd->hiber_grefs[i] == INVALID_GRANT_REF)
- break;
- GntTbl_PutRef(xpdd, xpdd->hiber_grefs[i], (ULONG)'HIBR');
- }
- xpdd->gnttbl_ss_copy = NULL;
- }
-
+ memcpy(xpdd->gnttab_table, xpdd->gnttab_table_copy, xpdd->grant_frames * PAGE_SIZE);
+
FUNCTION_EXIT();
}
diff -ruN ../win-pvdrivers.hg/xenpci/hypercall.h xenpci/hypercall.h
--- ../win-pvdrivers.hg/xenpci/hypercall.h 2011-02-26 20:43:12.000000000 +0800
+++ xenpci/hypercall.h 2011-02-26 20:44:33.000000000 +0800
@@ -55,6 +55,7 @@
a.domid = DOMID_SELF;
a.index = hvm_param;
a.value = value;
+ //a.value = via;
retval = HYPERVISOR_hvm_op(xpdd, HVMOP_set_param, &a);
KdPrint((__DRIVER_NAME " HYPERVISOR_hvm_op retval = %d\n", retval));
FUNCTION_EXIT();
diff -ruN ../win-pvdrivers.hg/xenpci/memoryinfothread.c xenpci/memoryinfothread.c
--- ../win-pvdrivers.hg/xenpci/memoryinfothread.c 1970-01-01 08:00:00.000000000 +0800
+++ xenpci/memoryinfothread.c 2011-02-26 20:44:33.000000000 +0800
@@ -0,0 +1,48 @@
+#include "xenpci.h"
+#include "xenpod.h"
+#include "xenpci_sleep.h"
+#include "getphyinfo.h"
+#define BALLOON_MEMINFO_PATH "memory/meminfo"
+
+VOID PvMemoryInfoThreadProc(PVOID StartContext)
+{
+ PXENPCI_DEVICE_DATA xpdd = StartContext;
+ MEMORYSTATUS oldLpBuffer,lpBuffer;
+ ULONG changed ,first;
+ DWORD status;
+ FUNCTION_ENTER();
+ first = 1;
+ oldLpBuffer.MemCur=0;
+ oldLpBuffer.MemFree=0;
+ oldLpBuffer.Committed_AS=0;
+
+ for (;;)
+ {
+ status = PvGlobalMemoryStatus(&lpBuffer);
+
+ /*if error, write status to xenstore for debug*/
+ if (!NT_SUCCESS(status)){
+ XenBus_Printf(xpdd, XBT_NIL, BALLOON_MEMINFO_PATH,
+ "Error:0x%x", status);
+ continue;
+ }
+
+ lpBuffer.MemCur = xpdd->current_memory << 10;
+ changed =
+ first|
+ CHANGED(lpBuffer.MemCur, oldLpBuffer.MemCur)|
+ CHANGED(lpBuffer.MemFree, oldLpBuffer.MemFree)|
+ CHANGED(lpBuffer.Committed_AS, oldLpBuffer.Committed_AS);
+
+ if(changed){
+ XenBus_Printf(xpdd, XBT_NIL, BALLOON_MEMINFO_PATH,
+ "Current:%u,Free:%u,Commit:%u",
+ lpBuffer.MemCur, lpBuffer.MemFree, lpBuffer.Committed_AS);
+ oldLpBuffer = lpBuffer;
+ }
+
+ first = 0;
+ PvWaitMicroSecond(1000 * 1000);/* 1 second*/
+ }
+ //FUNCTION_EXIT();
+}
diff -ruN ../win-pvdrivers.hg/xenpci/pv.diff xenpci/pv.diff
--- ../win-pvdrivers.hg/xenpci/pv.diff 1970-01-01 08:00:00.000000000 +0800
+++ xenpci/pv.diff 2011-02-26 20:45:54.000000000 +0800
@@ -0,0 +1,258 @@
+diff -r b63f69bf9cf5 xenpci/sources
+--- a/xenpci/sources Sat Oct 16 23:25:32 2010 +1100
++++ b/xenpci/sources Sat Feb 26 20:45:54 2011 +0800
+@@ -19,4 +19,4 @@
+ SOURCES=xenpci.rc xenpci.c xenpci_fdo.c xenpci_pdo.c evtchn.c \
+ gnttbl.c xenbus.c memory.c xenpci_device_interface.c \
+ xenbus_device_interface.c xenpci_highsync.c xenpci_patch_kernel.c \
+- xenpci_dbgprint.c
++ xenpci_dbgprint.c getphyinfo.c xenpci_sleep.c memoryinfothread.c
+diff -r b63f69bf9cf5 xenpci/xenpci.h
+--- a/xenpci/xenpci.h Sat Oct 16 23:25:32 2010 +1100
++++ b/xenpci/xenpci.h Sat Feb 26 20:45:54 2011 +0800
+@@ -171,6 +171,12 @@
+ struct xenstore_domain_interface *xen_store_interface;
+
+ #define BALLOON_UNITS (1024 * 1024) /* 1MB */
++
++ /*meminfo thread*/
++ PKTHREAD memory_thread;
++ KEVENT memory_event;
++
++ BOOLEAN memory_shutdown;
+ PKTHREAD balloon_thread;
+ KEVENT balloon_event;
+ BOOLEAN balloon_shutdown;
+diff -r b63f69bf9cf5 xenpci/xenpci_fdo.c
+--- a/xenpci/xenpci_fdo.c Sat Oct 16 23:25:32 2010 +1100
++++ b/xenpci/xenpci_fdo.c Sat Feb 26 20:45:54 2011 +0800
+@@ -1,4 +1,4 @@
+-/*
++ /*
+ PV Drivers for Windows Xen HVM Domains
+ Copyright (C) 2007 James Harper
+
+@@ -20,10 +20,14 @@
+ #include "xenpci.h"
+ #include <stdlib.h>
+ #include <aux_klib.h>
++#include "getphyinfo.h"
++#include "xenpod.h"
++#include "xenpci_sleep.h"
+
+ #define SYSRQ_PATH "control/sysrq"
+ #define SHUTDOWN_PATH "control/shutdown"
+-#define BALLOON_PATH "memory/target"
++#define BALLOON_TARGET_PATH "memory/target"
++#define BALLOON_WORKTIME_PATH "memory/worktime"
+
+ /* Not really necessary but keeps PREfast happy */
+ static EVT_WDF_WORKITEM XenPci_SuspendResume;
+@@ -31,6 +35,8 @@
+ static KSTART_ROUTINE XenPci_BalloonThreadProc;
+ #endif
+
++extern KSTART_ROUTINE PvMemoryInfoThreadProc;
++
+ static VOID
+ XenPci_MapHalThenPatchKernel(PXENPCI_DEVICE_DATA xpdd)
+ {
+@@ -238,6 +244,11 @@
+ ULONG ret;
+ int pfn_count;
+
++#ifdef BALLOON_PATH_WORK_TIME
++ ULONG workbegintime;
++ ULONG workendtime;
++#endif
++
+ FUNCTION_ENTER();
+
+ for(;;)
+@@ -267,6 +278,11 @@
+ KdPrint((__DRIVER_NAME " No change to memory\n"));
+ continue;
+ }
++
++#ifdef BALLOON_PATH_WORK_TIME
++ PvGetTickCount(&workbegintime);
++#endif
++
+ else if (xpdd->current_memory < new_target)
+ {
+ KdPrint((__DRIVER_NAME " Trying to take %d MB from Xen\n", new_target - xpdd->current_memory));
+@@ -277,6 +293,12 @@
+
+ pfn_count = ADDRESS_AND_SIZE_TO_SPAN_PAGES(MmGetMdlVirtualAddress(mdl), MmGetMdlByteCount(mdl));
+ pfns = ExAllocatePoolWithTag(NonPagedPool, pfn_count * sizeof(xen_pfn_t), XENPCI_POOL_TAG);
++ if(pfns == NULL){
++ mdl->Next = head;
++ head = mdl;
++ break;
++ }
++
+ /* sizeof(xen_pfn_t) may not be the same as PPFN_NUMBER */
+ for (i = 0; i < pfn_count; i++)
+ pfns[i] = (xen_pfn_t)(MmGetMdlPfnArray(mdl)[i]);
+@@ -289,10 +311,24 @@
+
+ KdPrint((__DRIVER_NAME " Calling HYPERVISOR_memory_op(XENMEM_populate_physmap) - pfn_count = %d\n", pfn_count));
+ ret = HYPERVISOR_memory_op(xpdd, XENMEM_populate_physmap, &reservation);
+- ExFreePoolWithTag(pfns, XENPCI_POOL_TAG);
++
+ KdPrint((__DRIVER_NAME " populated %d pages\n", ret));
+ /* TODO: what do we do if less than the required number of pages were populated??? can this happen??? */
++ /* fixed! */
++ if(ret < (ULONG)pfn_count){
++ if(ret > 0){
++ /* We hit the Xen hard limit: reprobe. */
++ reservation.nr_extents = ret;
++ ret = HYPERVISOR_memory_op(xpdd, XENMEM_decrease_reservation, &reservation);
++ KdPrint((__DRIVER_NAME " decreased %d pages\n", ret));
++ }
++ mdl->Next = head;
++ head = mdl;
++ ExFreePoolWithTag(pfns, XENPCI_POOL_TAG);
++ break;
++ }
+
++ ExFreePoolWithTag(pfns, XENPCI_POOL_TAG);
+ MmFreePagesFromMdl(mdl);
+ ExFreePool(mdl);
+ xpdd->current_memory++;
+@@ -334,6 +370,12 @@
+ break;
+ }
+ pfns = ExAllocatePoolWithTag(NonPagedPool, pfn_count * sizeof(xen_pfn_t), XENPCI_POOL_TAG);
++ if(pfns == NULL){
++ MmFreePagesFromMdl(mdl);
++ ExFreePool(mdl);
++ break;
++ }
++
+ /* sizeof(xen_pfn_t) may not be the same as PPFN_NUMBER */
+ for (i = 0; i < pfn_count; i++)
+ pfns[i] = (xen_pfn_t)(MmGetMdlPfnArray(mdl)[i]);
+@@ -361,6 +403,11 @@
+ }
+ }
+ }
++#ifdef BALLOON_PATH_WORK_TIME
++ PvGetTickCount(&workendtime);
++ XenBus_Printf(xpdd, XBT_NIL, BALLOON_PATH_WORK_TIME, "%u", workendtime - workbegintime);
++#endif
++
+ }
+ //FUNCTION_EXIT();
+ }
+@@ -380,7 +427,7 @@
+
+ XenBus_StartTransaction(xpdd, &xbt);
+
+- XenBus_Read(xpdd, XBT_NIL, BALLOON_PATH, &value);
++ XenBus_Read(xpdd, XBT_NIL, BALLOON_TARGET_PATH, &value);
+
+ if (value == NULL)
+ {
+@@ -404,6 +451,7 @@
+ FUNCTION_EXIT();
+ }
+
++
+ static VOID
+ XenPci_Suspend0(PVOID context)
+ {
+@@ -646,9 +694,9 @@
+ xpdd->platform_mmio_flags = translated_descriptor->Flags;
+ break;
+ case CmResourceTypeInterrupt:
+- xpdd->irq_level = (KIRQL)translated_descriptor->u.Interrupt.Level;
+- xpdd->irq_vector = translated_descriptor->u.Interrupt.Vector;
+- xpdd->irq_affinity = translated_descriptor->u.Interrupt.Affinity;
++ xpdd->irq_level = (KIRQL)translated_descriptor->u.Interrupt.Level;
++ xpdd->irq_vector = translated_descriptor->u.Interrupt.Vector;
++ xpdd->irq_affinity = translated_descriptor->u.Interrupt.Affinity;
+ xpdd->irq_mode = (translated_descriptor->Flags & CM_RESOURCE_INTERRUPT_LATCHED)?Latched:LevelSensitive;
+ xpdd->irq_number = raw_descriptor->u.Interrupt.Vector;
+ KdPrint((__DRIVER_NAME " irq_number = %03x\n", raw_descriptor->u.Interrupt.Vector));
+@@ -777,12 +825,15 @@
+ NTSTATUS status = STATUS_SUCCESS;
+ PXENPCI_DEVICE_DATA xpdd = GetXpdd(device);
+ PCHAR response;
+- char *value;
+ domid_t domid = DOMID_SELF;
+ ULONG ret;
++ ULONG totalram_bias;
+ xen_ulong_t *max_ram_page;
+ HANDLE thread_handle;
+-
++ HANDLE memory_info_thread_handle;
++ XEN_POD_TARGET_T pod_target;
++ pod_target.domid = DOMID_SELF;
++
+ UNREFERENCED_PARAMETER(previous_state);
+
+ FUNCTION_ENTER();
+@@ -808,14 +859,21 @@
+
+ if (!xpdd->initial_memory)
+ {
+- XenBus_Read(xpdd, XBT_NIL, BALLOON_PATH, &value);
+- if (atoi(value) > 0)
+- {
+- xpdd->initial_memory = atoi(value) >> 10; /* convert to MB */
+- xpdd->current_memory = xpdd->initial_memory;
+- xpdd->target_memory = xpdd->initial_memory;
++ MEMORYSTATUS lpBuffer;
++ PvGlobalMemoryStatus(&lpBuffer);
++ xpdd->initial_memory = (ULONG)(lpBuffer.totalPhys >> 10); /*convert to MB*/
++ xpdd->current_memory = xpdd->initial_memory;
++
++
++ ret = HYPERVISOR_memory_op(xpdd, XENMEM_get_pod_target, &pod_target);
++
++ totalram_bias = HYPERVISOR_memory_op(xpdd, ret != -ENOSYS && ret != 1
++ ? XENMEM_maximum_reservation : XENMEM_current_reservation,
++ &pod_target.domid);
++ if ((ULONG)totalram_bias != -ENOSYS) {
++ xpdd->initial_memory = totalram_bias >> (20 - PAGE_SHIFT);
++ xpdd->current_memory = xpdd->initial_memory + 1; /*lase line convert to MB may lost some KB, just add 1M*/
+ }
+- KdPrint((__DRIVER_NAME " Initial Memory Value = %d (%s)\n", xpdd->initial_memory, value));
+ KeInitializeEvent(&xpdd->balloon_event, SynchronizationEvent, FALSE);
+ xpdd->balloon_shutdown = FALSE;
+ status = PsCreateSystemThread(&thread_handle, THREAD_ALL_ACCESS, NULL, NULL, NULL, XenPci_BalloonThreadProc, xpdd);
+@@ -826,8 +884,18 @@
+ }
+ status = ObReferenceObjectByHandle(thread_handle, THREAD_ALL_ACCESS, NULL, KernelMode, &xpdd->balloon_thread, NULL);
+ ZwClose(thread_handle);
++
++ /* start pci meminfo thread */
++ status = PsCreateSystemThread(&memory_info_thread_handle, THREAD_ALL_ACCESS, NULL, NULL, NULL, PvMemoryInfoThreadProc, xpdd);
++ if (!NT_SUCCESS(status))
++ {
++ KdPrint((__DRIVER_NAME " Could not start memory thread\n"));
++ return status;
++ }
++ status = ObReferenceObjectByHandle(memory_info_thread_handle, THREAD_ALL_ACCESS, NULL, KernelMode, &xpdd->memory_thread, NULL);
++ ZwClose(memory_info_thread_handle);
+ }
+- response = XenBus_AddWatch(xpdd, XBT_NIL, BALLOON_PATH, XenPci_BalloonHandler, device);
++ response = XenBus_AddWatch(xpdd, XBT_NIL, BALLOON_TARGET_PATH, XenPci_BalloonHandler, device);
+ }
+ else
+ {
+diff -r b63f69bf9cf5 xenpci/xenpci_pdo.c
+--- a/xenpci/xenpci_pdo.c Sat Oct 16 23:25:32 2010 +1100
++++ b/xenpci/xenpci_pdo.c Sat Feb 26 20:45:54 2011 +0800
+@@ -502,7 +502,9 @@
+ {
+ /* it's possible that the workitems are blocked because the pagefile isn't available. Lets just re-read the backend value for now */
+ XenPci_UpdateBackendState(device);
+- remaining -= thiswait;
++
++ // this code is commented because it can cause the VM waitting forever
++ //remaining -= thiswait;
+ if (remaining == 0)
+ {
+ KdPrint((__DRIVER_NAME " Timed out waiting for %d!\n", backend_state_response));
diff -ruN ../win-pvdrivers.hg/xenpci/sources xenpci/sources
--- ../win-pvdrivers.hg/xenpci/sources 2011-02-26 20:43:12.000000000 +0800
+++ xenpci/sources 2011-02-26 20:44:33.000000000 +0800
@@ -19,4 +19,4 @@
SOURCES=xenpci.rc xenpci.c xenpci_fdo.c xenpci_pdo.c evtchn.c \
gnttbl.c xenbus.c memory.c xenpci_device_interface.c \
xenbus_device_interface.c xenpci_highsync.c xenpci_patch_kernel.c \
- xenpci_dbgprint.c
+ xenpci_dbgprint.c getphyinfo.c xenpci_sleep.c memoryinfothread.c
diff -ruN ../win-pvdrivers.hg/xenpci/xenbus.c xenpci/xenbus.c
--- ../win-pvdrivers.hg/xenpci/xenbus.c 2011-02-26 20:43:12.000000000 +0800
+++ xenpci/xenbus.c 2011-02-26 20:44:33.000000000 +0800
@@ -275,23 +275,21 @@
WDF_WORKITEM_CONFIG workitem_config;
WDF_OBJECT_ATTRIBUTES workitem_attributes;
WDFWORKITEM workitem;
- ULONG rsp_prod;
//FUNCTION_ENTER();
KeAcquireSpinLockAtDpcLevel(&xpdd->xb_ring_spinlock);
- /* snapshot rsp_prod so it doesn't change while we are looking at it */
- while ((rsp_prod = xpdd->xen_store_interface->rsp_prod) != xpdd->xen_store_interface->rsp_cons)
+ while (xpdd->xen_store_interface->rsp_prod != xpdd->xen_store_interface->rsp_cons)
{
- KeMemoryBarrier(); /* make sure the data in the ring is valid */
if (!xpdd->xb_msg)
{
- if (rsp_prod - xpdd->xen_store_interface->rsp_cons < sizeof(xsd_sockmsg_t))
+ if (xpdd->xen_store_interface->rsp_prod - xpdd->xen_store_interface->rsp_cons < sizeof(xsd_sockmsg_t))
{
//KdPrint((__DRIVER_NAME " +++ Message incomplete (not even a full header)\n"));
break;
}
+ KeMemoryBarrier();
memcpy_from_ring(xpdd->xen_store_interface->rsp, &msg,
MASK_XENSTORE_IDX(xpdd->xen_store_interface->rsp_cons), sizeof(xsd_sockmsg_t));
xpdd->xb_msg = ExAllocatePoolWithTag(NonPagedPool, sizeof(xsd_sockmsg_t) + msg.len, XENPCI_POOL_TAG);
@@ -300,7 +298,8 @@
xpdd->xen_store_interface->rsp_cons += sizeof(xsd_sockmsg_t);
}
- msg_len = min(rsp_prod - xpdd->xen_store_interface->rsp_cons, sizeof(xsd_sockmsg_t) + xpdd->xb_msg->len - xpdd->xb_msg_offset);
+ msg_len = min(xpdd->xen_store_interface->rsp_prod - xpdd->xen_store_interface->rsp_cons, sizeof(xsd_sockmsg_t) + xpdd->xb_msg->len - xpdd->xb_msg_offset);
+ KeMemoryBarrier(); /* make sure the data in the ring is valid */
ASSERT(xpdd->xb_msg_offset + msg_len <= sizeof(xsd_sockmsg_t) + xpdd->xb_msg->len);
memcpy_from_ring(xpdd->xen_store_interface->rsp,
(PUCHAR)xpdd->xb_msg + xpdd->xb_msg_offset,
@@ -359,7 +358,7 @@
pa_xen_store_interface.QuadPart = (ULONGLONG)xen_store_mfn << PAGE_SHIFT;
xpdd->xen_store_interface = MmMapIoSpace(pa_xen_store_interface, PAGE_SIZE, MmNonCached);
- EvtChn_BindDpc(xpdd, xpdd->xen_store_evtchn, XenBus_Dpc, xpdd, EVT_ACTION_FLAGS_NO_SUSPEND);
+ EvtChn_BindDpc(xpdd, xpdd->xen_store_evtchn, XenBus_Dpc, xpdd);
return STATUS_SUCCESS;
}
@@ -572,11 +571,10 @@
{
if (xpdd->XenBus_WatchEntries[i].Active)
{
- KdPrint((__DRIVER_NAME " Adding watch for path = %s\n", xpdd->XenBus_WatchEntries[i].Path));
+ //KdPrint((__DRIVER_NAME " Adding watch for path = %s\n", xpdd->XenBus_WatchEntries[i].Path));
XenBus_SendAddWatch(xpdd, XBT_NIL, xpdd->XenBus_WatchEntries[i].Path, i);
}
}
-
FUNCTION_EXIT();
return STATUS_SUCCESS;
@@ -667,7 +665,7 @@
if (i == MAX_WATCH_ENTRIES)
{
ExReleaseFastMutex(&xpdd->xb_watch_mutex);
- KdPrint((__DRIVER_NAME " Watch not set for %s - can't remove\n", Path));
+ KdPrint((__DRIVER_NAME " Watch not set - can't remove\n"));
return NULL;
}
diff -ruN ../win-pvdrivers.hg/xenpci/xenpci.c xenpci/xenpci.c
--- ../win-pvdrivers.hg/xenpci/xenpci.c 2011-02-26 20:43:12.000000000 +0800
+++ xenpci/xenpci.c 2011-02-26 20:44:33.000000000 +0800
@@ -487,10 +487,10 @@
WdfRegistryClose(sgo_key);
return; /* something is very wrong */
}
- if (dummy_group_index == 1 && wdf_load_group_index != -1 &&
+ if (dummy_group_index == 1 && (wdf_load_group_index == -1 ||
(dummy_group_index < wdf_load_group_index
&& wdf_load_group_index < xenpci_group_index
- && xenpci_group_index < boot_bus_extender_index))
+ && xenpci_group_index < boot_bus_extender_index)))
{
FUNCTION_EXIT();
return; /* our work here is done */
@@ -505,7 +505,7 @@
WdfCollectionAdd(new_load_order, tmp_wdf_string);
WdfObjectDelete(tmp_wdf_string);
}
- if (i == 1)
+ if (i == 1 && wdf_load_group_index != -1)
{
WDFSTRING tmp_wdf_string;
WdfStringCreate(&wdf_load_group_name, WDF_NO_OBJECT_ATTRIBUTES, &tmp_wdf_string);
diff -ruN ../win-pvdrivers.hg/xenpci/xenpci_fdo.c xenpci/xenpci_fdo.c
--- ../win-pvdrivers.hg/xenpci/xenpci_fdo.c 2011-02-26 20:43:12.000000000 +0800
+++ xenpci/xenpci_fdo.c 2011-02-26 20:44:33.000000000 +0800
@@ -1,4 +1,4 @@
-/*
+ /*
PV Drivers for Windows Xen HVM Domains
Copyright (C) 2007 James Harper
@@ -20,10 +20,14 @@
#include "xenpci.h"
#include <stdlib.h>
#include <aux_klib.h>
+#include "getphyinfo.h"
+#include "xenpod.h"
+#include "xenpci_sleep.h"
#define SYSRQ_PATH "control/sysrq"
#define SHUTDOWN_PATH "control/shutdown"
-#define BALLOON_PATH "memory/target"
+#define BALLOON_TARGET_PATH "memory/target"
+#define BALLOON_WORKTIME_PATH "memory/worktime"
/* Not really necessary but keeps PREfast happy */
static EVT_WDF_WORKITEM XenPci_SuspendResume;
@@ -31,6 +35,8 @@
static KSTART_ROUTINE XenPci_BalloonThreadProc;
#endif
+extern KSTART_ROUTINE PvMemoryInfoThreadProc;
+
static VOID
XenPci_MapHalThenPatchKernel(PXENPCI_DEVICE_DATA xpdd)
{
@@ -238,6 +244,11 @@
ULONG ret;
int pfn_count;
+#ifdef BALLOON_PATH_WORK_TIME
+ ULONG workbegintime;
+ ULONG workendtime;
+#endif
+
FUNCTION_ENTER();
for(;;)
@@ -267,6 +278,11 @@
KdPrint((__DRIVER_NAME " No change to memory\n"));
continue;
}
+
+#ifdef BALLOON_PATH_WORK_TIME
+ PvGetTickCount(&workbegintime);
+#endif
+
else if (xpdd->current_memory < new_target)
{
KdPrint((__DRIVER_NAME " Trying to take %d MB from Xen\n", new_target - xpdd->current_memory));
@@ -277,6 +293,12 @@
pfn_count = ADDRESS_AND_SIZE_TO_SPAN_PAGES(MmGetMdlVirtualAddress(mdl), MmGetMdlByteCount(mdl));
pfns = ExAllocatePoolWithTag(NonPagedPool, pfn_count * sizeof(xen_pfn_t), XENPCI_POOL_TAG);
+ if(pfns == NULL){
+ mdl->Next = head;
+ head = mdl;
+ break;
+ }
+
/* sizeof(xen_pfn_t) may not be the same as PPFN_NUMBER */
for (i = 0; i < pfn_count; i++)
pfns[i] = (xen_pfn_t)(MmGetMdlPfnArray(mdl)[i]);
@@ -289,10 +311,24 @@
KdPrint((__DRIVER_NAME " Calling HYPERVISOR_memory_op(XENMEM_populate_physmap) - pfn_count = %d\n", pfn_count));
ret = HYPERVISOR_memory_op(xpdd, XENMEM_populate_physmap, &reservation);
- ExFreePoolWithTag(pfns, XENPCI_POOL_TAG);
+
KdPrint((__DRIVER_NAME " populated %d pages\n", ret));
/* TODO: what do we do if less than the required number of pages were populated??? can this happen??? */
+ /* fixed! */
+ if(ret < (ULONG)pfn_count){
+ if(ret > 0){
+ /* We hit the Xen hard limit: reprobe. */
+ reservation.nr_extents = ret;
+ ret = HYPERVISOR_memory_op(xpdd, XENMEM_decrease_reservation, &reservation);
+ KdPrint((__DRIVER_NAME " decreased %d pages\n", ret));
+ }
+ mdl->Next = head;
+ head = mdl;
+ ExFreePoolWithTag(pfns, XENPCI_POOL_TAG);
+ break;
+ }
+ ExFreePoolWithTag(pfns, XENPCI_POOL_TAG);
MmFreePagesFromMdl(mdl);
ExFreePool(mdl);
xpdd->current_memory++;
@@ -334,6 +370,12 @@
break;
}
pfns = ExAllocatePoolWithTag(NonPagedPool, pfn_count * sizeof(xen_pfn_t), XENPCI_POOL_TAG);
+ if(pfns == NULL){
+ MmFreePagesFromMdl(mdl);
+ ExFreePool(mdl);
+ break;
+ }
+
/* sizeof(xen_pfn_t) may not be the same as PPFN_NUMBER */
for (i = 0; i < pfn_count; i++)
pfns[i] = (xen_pfn_t)(MmGetMdlPfnArray(mdl)[i]);
@@ -361,6 +403,11 @@
}
}
}
+#ifdef BALLOON_PATH_WORK_TIME
+ PvGetTickCount(&workendtime);
+ XenBus_Printf(xpdd, XBT_NIL, BALLOON_PATH_WORK_TIME, "%u", workendtime - workbegintime);
+#endif
+
}
//FUNCTION_EXIT();
}
@@ -380,7 +427,7 @@
XenBus_StartTransaction(xpdd, &xbt);
- XenBus_Read(xpdd, XBT_NIL, BALLOON_PATH, &value);
+ XenBus_Read(xpdd, XBT_NIL, BALLOON_TARGET_PATH, &value);
if (value == NULL)
{
@@ -404,39 +451,18 @@
FUNCTION_EXIT();
}
+
static VOID
XenPci_Suspend0(PVOID context)
{
PXENPCI_DEVICE_DATA xpdd = context;
ULONG cancelled;
- ULONGLONG sysenter_cs, sysenter_esp, sysenter_eip;
FUNCTION_ENTER();
GntTbl_Suspend(xpdd);
-
- sysenter_cs = __readmsr(0x174);
- sysenter_esp = __readmsr(0x175);
- sysenter_eip = __readmsr(0x176);
cancelled = hvm_shutdown(xpdd, SHUTDOWN_suspend);
-
- if (__readmsr(0x174) != sysenter_cs)
- {
- KdPrint((__DRIVER_NAME " sysenter_cs not restored. Fixing.\n"));
- __writemsr(0x174, sysenter_cs);
- }
- if (__readmsr(0x175) != sysenter_esp)
- {
- KdPrint((__DRIVER_NAME " sysenter_esp not restored. Fixing.\n"));
- __writemsr(0x175, sysenter_esp);
- }
- if (__readmsr(0x176) != sysenter_eip)
- {
- KdPrint((__DRIVER_NAME " sysenter_eip not restored. Fixing.\n"));
- __writemsr(0x176, sysenter_eip);
- }
-
KdPrint((__DRIVER_NAME " back from suspend, cancelled = %d\n", cancelled));
if (qemu_hide_flags_value)
@@ -476,7 +502,7 @@
KdPrint((__DRIVER_NAME " suspend event channel = %d\n", xpdd->suspend_evtchn));
RtlStringCbPrintfA(path, ARRAY_SIZE(path), "device/suspend/event-channel");
XenBus_Printf(xpdd, XBT_NIL, path, "%d", xpdd->suspend_evtchn);
- EvtChn_BindDpc(xpdd, xpdd->suspend_evtchn, XenPci_SuspendEvtDpc, xpdd->wdf_device, EVT_ACTION_FLAGS_NO_SUSPEND);
+ EvtChn_BindDpc(xpdd, xpdd->suspend_evtchn, XenPci_SuspendEvtDpc, xpdd->wdf_device);
return STATUS_SUCCESS;
}
@@ -507,6 +533,7 @@
KdPrint((__DRIVER_NAME " Suspending child\n"));
XenPci_Pdo_Suspend(child_device);
}
+ KdPrint((__DRIVER_NAME " WdfChildListRetrieveNextDevice = %08x, STATUS_NO_MORE_ENTRIES = %08x\n", status, STATUS_NO_MORE_ENTRIES));
WdfChildListEndIteration(child_list, &child_iterator);
XenBus_Suspend(xpdd);
@@ -524,6 +551,7 @@
KdPrint((__DRIVER_NAME " Resuming child\n"));
XenPci_Pdo_Resume(child_device);
}
+ KdPrint((__DRIVER_NAME " WdfChildListRetrieveNextDevice = %08x, STATUS_NO_MORE_ENTRIES = %08x\n", status, STATUS_NO_MORE_ENTRIES));
WdfChildListEndIteration(child_list, &child_iterator);
xpdd->suspend_state = SUSPEND_STATE_NONE;
@@ -666,9 +694,9 @@
xpdd->platform_mmio_flags = translated_descriptor->Flags;
break;
case CmResourceTypeInterrupt:
- xpdd->irq_level = (KIRQL)translated_descriptor->u.Interrupt.Level;
- xpdd->irq_vector = translated_descriptor->u.Interrupt.Vector;
- xpdd->irq_affinity = translated_descriptor->u.Interrupt.Affinity;
+ xpdd->irq_level = (KIRQL)translated_descriptor->u.Interrupt.Level;
+ xpdd->irq_vector = translated_descriptor->u.Interrupt.Vector;
+ xpdd->irq_affinity = translated_descriptor->u.Interrupt.Affinity;
xpdd->irq_mode = (translated_descriptor->Flags & CM_RESOURCE_INTERRUPT_LATCHED)?Latched:LevelSensitive;
xpdd->irq_number = raw_descriptor->u.Interrupt.Vector;
KdPrint((__DRIVER_NAME " irq_number = %03x\n", raw_descriptor->u.Interrupt.Vector));
@@ -710,6 +738,8 @@
{
NTSTATUS status = STATUS_SUCCESS;
PXENPCI_DEVICE_DATA xpdd = GetXpdd(device);
+ ULONG i;
+ ULONG ret;
FUNCTION_ENTER();
@@ -756,6 +786,24 @@
GntTbl_Init(xpdd);
EvtChn_Init(xpdd);
+ for (i = 0; i < NR_GRANT_FRAMES + 1; i++)
+ {
+ struct xen_memory_reservation reservation;
+ xen_pfn_t pfn;
+ PMDL mdl = AllocatePage();
+ pfn = (xen_pfn_t)(MmGetMdlPfnArray(mdl)[0]);
+ reservation.address_bits = 0;
+ reservation.extent_order = 0;
+ reservation.domid = DOMID_SELF;
+ reservation.nr_extents = 1;
+ #pragma warning(disable: 4127) /* conditional expression is constant */
+ set_xen_guest_handle(reservation.extent_start, &pfn);
+
+ //KdPrint((__DRIVER_NAME " Calling HYPERVISOR_memory_op - pfn = %x\n", (ULONG)pfn));
+ ret = HYPERVISOR_memory_op(xpdd, XENMEM_decrease_reservation, &reservation);
+ //KdPrint((__DRIVER_NAME " decreased %d pages\n", ret));
+ }
+
// use the memory_op(unsigned int op, void *arg) hypercall to adjust memory
// use XENMEM_increase_reservation and XENMEM_decrease_reservation
}
@@ -777,12 +825,15 @@
NTSTATUS status = STATUS_SUCCESS;
PXENPCI_DEVICE_DATA xpdd = GetXpdd(device);
PCHAR response;
- char *value;
domid_t domid = DOMID_SELF;
ULONG ret;
+ ULONG totalram_bias;
xen_ulong_t *max_ram_page;
HANDLE thread_handle;
-
+ HANDLE memory_info_thread_handle;
+ XEN_POD_TARGET_T pod_target;
+ pod_target.domid = DOMID_SELF;
+
UNREFERENCED_PARAMETER(previous_state);
FUNCTION_ENTER();
@@ -808,14 +859,21 @@
if (!xpdd->initial_memory)
{
- XenBus_Read(xpdd, XBT_NIL, BALLOON_PATH, &value);
- if (atoi(value) > 0)
- {
- xpdd->initial_memory = atoi(value) >> 10; /* convert to MB */
- xpdd->current_memory = xpdd->initial_memory;
- xpdd->target_memory = xpdd->initial_memory;
+ MEMORYSTATUS lpBuffer;
+ PvGlobalMemoryStatus(&lpBuffer);
+ xpdd->initial_memory = (ULONG)(lpBuffer.totalPhys >> 10); /*convert to MB*/
+ xpdd->current_memory = xpdd->initial_memory;
+
+
+ ret = HYPERVISOR_memory_op(xpdd, XENMEM_get_pod_target, &pod_target);
+
+ totalram_bias = HYPERVISOR_memory_op(xpdd, ret != -ENOSYS && ret != 1
+ ? XENMEM_maximum_reservation : XENMEM_current_reservation,
+ &pod_target.domid);
+ if ((ULONG)totalram_bias != -ENOSYS) {
+ xpdd->initial_memory = totalram_bias >> (20 - PAGE_SHIFT);
+ xpdd->current_memory = xpdd->initial_memory + 1; /*lase line convert to MB may lost some KB, just add 1M*/
}
- KdPrint((__DRIVER_NAME " Initial Memory Value = %d (%s)\n", xpdd->initial_memory, value));
KeInitializeEvent(&xpdd->balloon_event, SynchronizationEvent, FALSE);
xpdd->balloon_shutdown = FALSE;
status = PsCreateSystemThread(&thread_handle, THREAD_ALL_ACCESS, NULL, NULL, NULL, XenPci_BalloonThreadProc, xpdd);
@@ -826,8 +884,18 @@
}
status = ObReferenceObjectByHandle(thread_handle, THREAD_ALL_ACCESS, NULL, KernelMode, &xpdd->balloon_thread, NULL);
ZwClose(thread_handle);
+
+ /* start pci meminfo thread */
+ status = PsCreateSystemThread(&memory_info_thread_handle, THREAD_ALL_ACCESS, NULL, NULL, NULL, PvMemoryInfoThreadProc, xpdd);
+ if (!NT_SUCCESS(status))
+ {
+ KdPrint((__DRIVER_NAME " Could not start memory thread\n"));
+ return status;
+ }
+ status = ObReferenceObjectByHandle(memory_info_thread_handle, THREAD_ALL_ACCESS, NULL, KernelMode, &xpdd->memory_thread, NULL);
+ ZwClose(memory_info_thread_handle);
}
- response = XenBus_AddWatch(xpdd, XBT_NIL, BALLOON_PATH, XenPci_BalloonHandler, device);
+ response = XenBus_AddWatch(xpdd, XBT_NIL, BALLOON_TARGET_PATH, XenPci_BalloonHandler, device);
}
else
{
@@ -940,9 +1008,7 @@
}
else
{
- EvtChn_Suspend(xpdd);
GntTbl_Suspend(xpdd);
-
}
FUNCTION_EXIT();
diff -ruN ../win-pvdrivers.hg/xenpci/xenpci.h xenpci/xenpci.h
--- ../win-pvdrivers.hg/xenpci/xenpci.h 2011-02-26 20:43:12.000000000 +0800
+++ xenpci/xenpci.h 2011-02-26 20:44:33.000000000 +0800
@@ -69,10 +69,6 @@
#define EVT_ACTION_TYPE_SUSPEND 4
#define EVT_ACTION_TYPE_NEW 5 /* setup of event is in progress */
-#define EVT_ACTION_FLAGS_DEFAULT 0 /* no special flags */
-#define EVT_ACTION_FLAGS_NO_SUSPEND 1 /* should not be fired on EVT_ACTION_TYPE_SUSPEND event */
-
-
#define XEN_PV_PRODUCT_NUMBER 0x0002
#define XEN_PV_PRODUCT_BUILD 0x00000001
@@ -83,7 +79,6 @@
PVOID ServiceContext;
CHAR description[128];
ULONG type; /* EVT_ACTION_TYPE_* */
- ULONG flags; /* EVT_ACTION_FLAGS_* */
KDPC Dpc;
ULONG port;
ULONG vector;
@@ -122,9 +117,6 @@
#define SUSPEND_STATE_HIGH_IRQL 2 /* all processors are at high IRQL and spinning */
#define SUSPEND_STATE_RESUMING 3 /* we are the other side of the suspend and things are starting to get back to normal */
-/* we take some grant refs out and put them aside so that we dont get corrupted by hibernate */
-#define HIBER_GREF_COUNT 128
-
typedef struct {
WDFDEVICE wdf_device;
@@ -159,16 +151,16 @@
evtchn_port_t xen_store_evtchn;
/* grant related */
- struct stack_state *gnttbl_ss;
- struct stack_state *gnttbl_ss_copy;
- grant_ref_t hiber_grefs[HIBER_GREF_COUNT];
- PMDL gnttbl_mdl;
- grant_entry_t *gnttbl_table;
- grant_entry_t *gnttbl_table_copy;
+ struct stack_state *gnttab_ss;
+ grant_entry_t *gnttab_table;
+ grant_entry_t *gnttab_table_copy;
#if DBG
- PULONG gnttbl_tag;
- PULONG gnttbl_tag_copy;
+ PULONG gnttab_tag;
#endif
+ PHYSICAL_ADDRESS gnttab_table_physical;
+ //grant_ref_t *gnttab_list;
+ //int gnttab_list_free;
+ //KSPIN_LOCK grant_lock;
ULONG grant_frames;
ev_action_t ev_actions[NR_EVENTS];
@@ -179,6 +171,12 @@
struct xenstore_domain_interface *xen_store_interface;
#define BALLOON_UNITS (1024 * 1024) /* 1MB */
+
+ /*meminfo thread*/
+ PKTHREAD memory_thread;
+ KEVENT memory_event;
+
+ BOOLEAN memory_shutdown;
PKTHREAD balloon_thread;
KEVENT balloon_event;
BOOLEAN balloon_shutdown;
@@ -263,6 +261,8 @@
XENPCI_STATE_MAP_ELEMENT xb_post_connect_map[5];
XENPCI_STATE_MAP_ELEMENT xb_shutdown_map[5];
+
+
BOOLEAN hiber_usage_kludge;
} XENPCI_PDO_DEVICE_DATA, *PXENPCI_PDO_DEVICE_DATA;
@@ -469,11 +469,11 @@
NTSTATUS
EvtChn_Unmask(PVOID Context, evtchn_port_t Port);
NTSTATUS
-EvtChn_Bind(PVOID Context, evtchn_port_t Port, PXEN_EVTCHN_SERVICE_ROUTINE ServiceRoutine, PVOID ServiceContext, ULONG flags);
+EvtChn_Bind(PVOID Context, evtchn_port_t Port, PXEN_EVTCHN_SERVICE_ROUTINE ServiceRoutine, PVOID ServiceContext);
NTSTATUS
-EvtChn_BindDpc(PVOID Context, evtchn_port_t Port, PXEN_EVTCHN_SERVICE_ROUTINE ServiceRoutine, PVOID ServiceContext, ULONG flags);
+EvtChn_BindDpc(PVOID Context, evtchn_port_t Port, PXEN_EVTCHN_SERVICE_ROUTINE ServiceRoutine, PVOID ServiceContext);
NTSTATUS
-EvtChn_BindIrq(PVOID Context, evtchn_port_t Port, ULONG vector, PCHAR description, ULONG flags);
+EvtChn_BindIrq(PVOID Context, evtchn_port_t Port, ULONG vector, PCHAR description);
evtchn_port_t
EvtChn_AllocIpi(PVOID context, ULONG vcpu);
NTSTATUS
diff -ruN ../win-pvdrivers.hg/xenpci/xenpci_pdo.c xenpci/xenpci_pdo.c
--- ../win-pvdrivers.hg/xenpci/xenpci_pdo.c 2011-02-26 20:43:12.000000000 +0800
+++ xenpci/xenpci_pdo.c 2011-02-26 20:44:33.000000000 +0800
@@ -251,7 +251,7 @@
PXENPCI_PDO_DEVICE_DATA xppdd = GetXppdd(device);
PXENPCI_DEVICE_DATA xpdd = GetXpdd(xppdd->wdf_device_bus_fdo);
- return EvtChn_Bind(xpdd, Port, ServiceRoutine, ServiceContext, EVT_ACTION_FLAGS_DEFAULT);
+ return EvtChn_Bind(xpdd, Port, ServiceRoutine, ServiceContext);
}
static NTSTATUS
@@ -261,7 +261,7 @@
PXENPCI_PDO_DEVICE_DATA xppdd = GetXppdd(device);
PXENPCI_DEVICE_DATA xpdd = GetXpdd(xppdd->wdf_device_bus_fdo);
- return EvtChn_BindDpc(xpdd, Port, ServiceRoutine, ServiceContext, EVT_ACTION_FLAGS_DEFAULT);
+ return EvtChn_BindDpc(xpdd, Port, ServiceRoutine, ServiceContext);
}
static NTSTATUS
@@ -502,7 +502,9 @@
{
/* it's possible that the workitems are blocked because the pagefile isn't available. Lets just re-read the backend value for now */
XenPci_UpdateBackendState(device);
- remaining -= thiswait;
+
+ // this code is commented because it can cause the VM waitting forever
+ //remaining -= thiswait;
if (remaining == 0)
{
KdPrint((__DRIVER_NAME " Timed out waiting for %d!\n", backend_state_response));
@@ -581,8 +583,8 @@
EvtChn_Close(xpdd, PtrToUlong(value));
break;
case XEN_INIT_TYPE_GRANT_ENTRIES:
- for (i = 0; i < PtrToUlong(value); i++)
- GntTbl_EndAccess(xpdd, ((grant_ref_t *)value2)[i], FALSE, PtrToUlong(setting));
+ for (i = 0; i < PtrToUlong(setting); i++)
+ GntTbl_EndAccess(xpdd, ((grant_ref_t *)value)[i], FALSE, (ULONG)'XPDO');
break;
}
}
@@ -671,6 +673,7 @@
in_ptr = src;
while((type = GET_XEN_INIT_REQ(&in_ptr, (PVOID)&setting, (PVOID)&value, (PVOID)&value2)) != XEN_INIT_TYPE_END)
{
+//KdPrint((__DRIVER_NAME " in_ptr = %p, type = %d\n", in_ptr, type));
ADD_XEN_INIT_REQ(&xppdd->requested_resources_ptr, type, setting, value, value2);
switch (type)
@@ -697,7 +700,6 @@
ADD_XEN_INIT_RSP(&xppdd->assigned_resources_ptr, type, setting, ring, NULL);
// add the grant entry too so it gets freed automatically
__ADD_XEN_INIT_UCHAR(&xppdd->assigned_resources_ptr, XEN_INIT_TYPE_GRANT_ENTRIES);
- __ADD_XEN_INIT_ULONG(&xppdd->assigned_resources_ptr, (ULONG)'XPDO');
__ADD_XEN_INIT_ULONG(&xppdd->assigned_resources_ptr, 1);
__ADD_XEN_INIT_ULONG(&xppdd->assigned_resources_ptr, gref);
}
@@ -726,17 +728,17 @@
ADD_XEN_INIT_RSP(&xppdd->assigned_resources_ptr, type, setting, UlongToPtr(event_channel), NULL);
if (type == XEN_INIT_TYPE_EVENT_CHANNEL_IRQ)
{
- EvtChn_BindIrq(xpdd, event_channel, xppdd->irq_vector, path, EVT_ACTION_FLAGS_DEFAULT);
+ EvtChn_BindIrq(xpdd, event_channel, xppdd->irq_vector, path);
}
else if (type == XEN_INIT_TYPE_EVENT_CHANNEL_DPC)
{
#pragma warning(suppress:4055)
- EvtChn_BindDpc(xpdd, event_channel, (PXEN_EVTCHN_SERVICE_ROUTINE)value, value2, EVT_ACTION_FLAGS_DEFAULT);
+ EvtChn_BindDpc(xpdd, event_channel, (PXEN_EVTCHN_SERVICE_ROUTINE)value, value2);
}
else
{
#pragma warning(suppress:4055)
- EvtChn_Bind(xpdd, event_channel, (PXEN_EVTCHN_SERVICE_ROUTINE)value, value2, EVT_ACTION_FLAGS_DEFAULT);
+ EvtChn_Bind(xpdd, event_channel, (PXEN_EVTCHN_SERVICE_ROUTINE)value, value2);
}
}
else
@@ -830,13 +832,11 @@
//KdPrint((__DRIVER_NAME " XEN_INIT_TYPE_GRANT_ENTRIES - %d\n", PtrToUlong(value)));
__ADD_XEN_INIT_UCHAR(&out_ptr, type);
__ADD_XEN_INIT_UCHAR(&xppdd->assigned_resources_ptr, type);
- __ADD_XEN_INIT_ULONG(&out_ptr, PtrToUlong(setting));
- __ADD_XEN_INIT_ULONG(&xppdd->assigned_resources_ptr, PtrToUlong(setting));
__ADD_XEN_INIT_ULONG(&out_ptr, PtrToUlong(value));
__ADD_XEN_INIT_ULONG(&xppdd->assigned_resources_ptr, PtrToUlong(value));
for (i = 0; i < PtrToUlong(value); i++)
{
- gref = GntTbl_GetRef(xpdd, PtrToUlong(setting));
+ gref = GntTbl_GetRef(xpdd, 'XPDO');
__ADD_XEN_INIT_ULONG(&out_ptr, gref);
__ADD_XEN_INIT_ULONG(&xppdd->assigned_resources_ptr, gref);
}
@@ -1109,14 +1109,13 @@
{
}
-#if 0
if (previous_state == WdfPowerDevicePrepareForHibernation || previous_state == WdfPowerDeviceD3 || previous_state == WdfPowerDeviceD3Final)
{
xppdd->requested_resources_ptr = xppdd->requested_resources_start;
xppdd->assigned_resources_start = xppdd->assigned_resources_ptr = ExAllocatePoolWithTag(NonPagedPool, PAGE_SIZE, XENPCI_POOL_TAG);
}
+
XenConfig_InitConfigPage(device);
-#endif
status = XenPci_GetBackendAndAddWatch(device);
if (!NT_SUCCESS(status))
@@ -1125,31 +1124,7 @@
FUNCTION_EXIT_STATUS(status);
return status;
}
-
- if (previous_state == WdfPowerDeviceD3 || previous_state == WdfPowerDeviceD3Final)
- {
- xppdd->requested_resources_ptr = xppdd->requested_resources_start;
- xppdd->assigned_resources_start = xppdd->assigned_resources_ptr = ExAllocatePoolWithTag(NonPagedPool, PAGE_SIZE, XENPCI_POOL_TAG);
- XenConfig_InitConfigPage(device);
- status = XenPci_XenConfigDevice(device);
- }
- else if (previous_state == WdfPowerDevicePrepareForHibernation)
- {
- PVOID src, dst;
-
- ADD_XEN_INIT_REQ(&xppdd->requested_resources_ptr, XEN_INIT_TYPE_END, NULL, NULL, NULL);
- src = xppdd->requested_resources_start;
- xppdd->requested_resources_ptr = xppdd->requested_resources_start = ExAllocatePoolWithTag(NonPagedPool, PAGE_SIZE, XENPCI_POOL_TAG);;
- xppdd->assigned_resources_ptr = xppdd->assigned_resources_start;
-
- dst = MmMapIoSpace(xppdd->config_page_phys, xppdd->config_page_length, MmNonCached);
-
- status = XenPci_XenConfigDeviceSpecifyBuffers(device, src, dst);
-
- MmUnmapIoSpace(dst, xppdd->config_page_length);
- ExFreePoolWithTag(src, XENPCI_POOL_TAG);
- }
-
+ status = XenPci_XenConfigDevice(device);
if (!NT_SUCCESS(status))
{
RtlStringCbPrintfA(path, ARRAY_SIZE(path), "%s/state", xppdd->backend_path);
@@ -1451,7 +1426,7 @@
KdPrint((__DRIVER_NAME " WdfDeviceAddQueryInterface failed - %08x\n", status));
return status;
}
-
+
RtlStringCbCopyA(xppdd->path, ARRAY_SIZE(xppdd->path), identification->path);
RtlStringCbCopyA(xppdd->device, ARRAY_SIZE(xppdd->device), identification->device);
xppdd->index = identification->index;
@@ -1501,7 +1476,6 @@
PVOID setting;
PVOID value;
PVOID value2;
- int i;
KdPrint((__DRIVER_NAME " --> " __FUNCTION__ " (%s)\n", xppdd->path));
@@ -1523,25 +1497,18 @@
{
switch (type)
{
- case XEN_INIT_TYPE_RING: /* frontend ring */
- FreePages(value);
- break;
case XEN_INIT_TYPE_EVENT_CHANNEL: /* frontend event channel */
case XEN_INIT_TYPE_EVENT_CHANNEL_DPC: /* frontend event channel bound to dpc */
case XEN_INIT_TYPE_EVENT_CHANNEL_IRQ: /* frontend event channel bound to irq */
EvtChn_Unbind(xpdd, PtrToUlong(value));
EvtChn_Close(xpdd, PtrToUlong(value));
break;
- case XEN_INIT_TYPE_GRANT_ENTRIES:
- for (i = 0; i < (int)PtrToUlong(value); i++)
- GntTbl_EndAccess(xpdd, ((grant_ref_t *)value2)[i], FALSE, PtrToUlong(setting));
- break;
}
}
}
RtlStringCbPrintfA(path, ARRAY_SIZE(path), "%s/state", xppdd->backend_path);
- XenBus_RemWatch(xpdd, XBT_NIL, path, XenPci_BackendStateHandler, device);
+ XenBus_RemWatch(xpdd, XBT_NIL, path, XenPci_BackendStateHandler, xppdd);
}
else
{
@@ -1586,9 +1553,9 @@
src = xppdd->requested_resources_start;
xppdd->requested_resources_ptr = xppdd->requested_resources_start = ExAllocatePoolWithTag(NonPagedPool, PAGE_SIZE, XENPCI_POOL_TAG);;
xppdd->assigned_resources_ptr = xppdd->assigned_resources_start;
-
+
dst = MmMapIoSpace(xppdd->config_page_phys, xppdd->config_page_length, MmNonCached);
-
+
status = XenPci_XenConfigDeviceSpecifyBuffers(device, src, dst);
MmUnmapIoSpace(dst, xppdd->config_page_length);
diff -ruN ../win-pvdrivers.hg/xenpci/xenpci_sleep.c xenpci/xenpci_sleep.c
--- ../win-pvdrivers.hg/xenpci/xenpci_sleep.c 1970-01-01 08:00:00.000000000 +0800
+++ xenpci/xenpci_sleep.c 2011-02-26 20:44:33.000000000 +0800
@@ -0,0 +1,23 @@
+#include "xenpci_sleep.h"
+
+VOID PvWaitMicroSecond(ULONG ulMircoSecond)
+{
+ KTIMER kTimer;
+ LARGE_INTEGER timeout;
+ KeInitializeTimer(&kTimer);
+ timeout = RtlConvertLongToLargeInteger(ulMircoSecond * -10);
+
+ KeSetTimer(&kTimer, timeout, NULL);
+ KeWaitForSingleObject(&kTimer, Executive, KernelMode, FALSE, NULL);
+}
+
+void PvGetTickCount(PULONG msec)
+{
+ LARGE_INTEGER tick_count;
+ ULONG myinc = KeQueryTimeIncrement();
+ KeQueryTickCount(&tick_count);
+ tick_count.QuadPart *= myinc;
+ tick_count.QuadPart /= 10000;
+ *msec = tick_count.LowPart;
+}
+
diff -ruN ../win-pvdrivers.hg/xenpci/xenpci_sleep.h xenpci/xenpci_sleep.h
--- ../win-pvdrivers.hg/xenpci/xenpci_sleep.h 1970-01-01 08:00:00.000000000 +0800
+++ xenpci/xenpci_sleep.h 2011-02-26 20:44:33.000000000 +0800
@@ -0,0 +1,14 @@
+#if !defined(_XENPCISLEEP_H_)
+#define _XENPCISLEEP_H_
+
+#define DDKAPI
+#include <ntddk.h>
+#include <wdm.h>
+#define NTSTRSAFE_LIB
+#include <ntstrsafe.h>
+#include <stdlib.h>
+
+VOID PvWaitMicroSecond(ULONG ulMircoSecond);
+VOID PvGetTickCount(PULONG msec);
+
+#endif
diff -ruN ../win-pvdrivers.hg/xenpci/xenpod.h xenpci/xenpod.h
--- ../win-pvdrivers.hg/xenpci/xenpod.h 1970-01-01 08:00:00.000000000 +0800
+++ xenpci/xenpod.h 2011-02-26 20:44:33.000000000 +0800
@@ -0,0 +1,14 @@
+#if !defined(_XENPOD_H_)
+#define _XENPOD_H_
+
+#define XENMEM_get_pod_target 17
+
+typedef struct {
+ ULONG target_pages;
+ ULONG tot_pages;
+ ULONG pod_cache_pages;
+ ULONG pod_entries;
+ domid_t domid;
+} XEN_POD_TARGET_T;
+
+#endif
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread* RE: RE: blue screen in windows balloon driver 2011-02-26 13:01 re:RE: blue screen in windows balloon driver MaoXiaoyun @ 2011-02-27 11:25 ` James Harper 2011-02-28 4:33 ` MaoXiaoyun 0 siblings, 1 reply; 26+ messages in thread From: James Harper @ 2011-02-27 11:25 UTC (permalink / raw) To: MaoXiaoyun, xen devel; +Cc: george.dunlap > Thanks James. > > I think it is GPLPV. The driver is from http://xenbits.xen.org/ext/win- > pvdrivers.hg > But, I have done some other things > > 1) Add pod support > 2) enable a meminfo thread, periodically write VM meminfo into xenstore > We use info of Current Memory, Free memory, and Committed memory, retrived > through NativeAPI > 3) our code is based from changeset 823, attached is the diff of my current > code with changset of 853. > > Maybe I need add my code to 853, and test again. > Thanks. > As per other post, I have just committed some patches and PoD should now be working properly. I can start a DomU with 4GB of maxmem but only 128MB of populated memory without any problems. This now works because I do the initial balloon down in DriverEntry, way before xenpci does anything else. Before it would blow up in DriverEntry. I think I determine the amount to initially balloon down a little differently from you too. It takes a while to balloon down the memory though... I think Windows tends to delay large allocations or something, because ballooning up again is pretty much instant. How often are you writing meminfo stuff into xenstore? Could you do that in userspace (the interface to xenstore exists and seems to work well although it's a little tedious)? You would then be able to just run it as a service and not need to patch GPLPV. James ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: blue screen in windows balloon driver 2011-02-27 11:25 ` James Harper @ 2011-02-28 4:33 ` MaoXiaoyun [not found] ` <BLU157-w3689F78415A43CC5997DD7DADE0@phx.gbl> 0 siblings, 1 reply; 26+ messages in thread From: MaoXiaoyun @ 2011-02-28 4:33 UTC (permalink / raw) To: xen devel; +Cc: james.harper [-- Attachment #1.1: Type: text/plain, Size: 2291 bytes --] Thanks for fixing the POD. It's is better make it earlier to avoid crash. The meminfo is written every 1 seconds into xenstore dir /local/domain/did/memory/meminfo. And to avoid to many writes, only the memory changes large than 5M, the thread will do the write. As for userspace daemon, it is our first choice, but we found it xenstore daemon in dom0 comsume many CPU(we test in linux only), so we decide to move it into driver. I've done merge my code with latest changeset 866, and do the stree test later. many thanks. > Subject: RE: RE: blue screen in windows balloon driver > Date: Sun, 27 Feb 2011 22:25:28 +1100 > From: james.harper@bendigoit.com.au > To: tinnycloud@hotmail.com; xen-devel@lists.xensource.com > CC: george.dunlap@eu.citrix.com > > > Thanks James. > > > > I think it is GPLPV. The driver is from > http://xenbits.xen.org/ext/win- > > pvdrivers.hg > > But, I have done some other things > > > > 1) Add pod support > > 2) enable a meminfo thread, periodically write VM meminfo into > xenstore > > We use info of Current Memory, Free memory, and Committed memory, > retrived > > through NativeAPI > > 3) our code is based from changeset 823, attached is the diff of my > current > > code with changset of 853. > > > > Maybe I need add my code to 853, and test again. > > Thanks. > > > > As per other post, I have just committed some patches and PoD should now > be working properly. I can start a DomU with 4GB of maxmem but only > 128MB of populated memory without any problems. This now works because I > do the initial balloon down in DriverEntry, way before xenpci does > anything else. Before it would blow up in DriverEntry. I think I > determine the amount to initially balloon down a little differently from > you too. > > It takes a while to balloon down the memory though... I think Windows > tends to delay large allocations or something, because ballooning up > again is pretty much instant. > > How often are you writing meminfo stuff into xenstore? Could you do that > in userspace (the interface to xenstore exists and seems to work well > although it's a little tedious)? You would then be able to just run it > as a service and not need to patch GPLPV. > > James [-- Attachment #1.2: Type: text/html, Size: 2857 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <BLU157-w3689F78415A43CC5997DD7DADE0@phx.gbl>]
* RE: blue screen in windows balloon driver [not found] ` <BLU157-w3689F78415A43CC5997DD7DADE0@phx.gbl> @ 2011-02-28 8:29 ` MaoXiaoyun 2011-02-28 11:45 ` James Harper 2011-02-28 23:45 ` James Harper 0 siblings, 2 replies; 26+ messages in thread From: MaoXiaoyun @ 2011-02-28 8:29 UTC (permalink / raw) To: xen devel; +Cc: james.harper [-- Attachment #1.1: Type: text/plain, Size: 3513 bytes --] Hi James: Unfortunately, We still hit the blue screen on the stress test. (Start total 24 HVMS on a single 16core, 24G host, each HVM owns 2G Memory, start with memory=512M, and inside two eating memory processes, each of which will each 1G memory) As I go though the code, I noticed that all memory allocation relates to "ExAllocatePoolWithTag(NonPagedPool,...)", which is from NonePaged Pool, As I know, the NonePagePool memory is the memory could not be paged out, and that is limited, and for the blue screen VMS, I also found the free memory is quite low, only about hundreds KB left. So, when memory overcommit, some of the VM will not got enough memory, and if most of its Memory is occupied by eating memory process, then ExAllocatePoolWithTag will fail, thus caused "NO_PAGES_AVALIABLE" blue screen. Is this possible? Meanwhile, I will have your PVdriver tested to see if blue exists, thanks. >From: tinnycloud@hotmail.com >To: tinnycloud@hotmail.com >Subject: FW: blue screen in windows balloon driver >Date: Mon, 28 Feb 2011 16:16:59 +0800 > > >Thanks for fixing the POD. It's is better make it earlier to avoid crash. > >The meminfo is written every 1 seconds into xenstore dir /local/domain/did/memory/meminfo. >And to avoid to many writes, only the memory changes large than 5M, the thread will do the write. > >As for userspace daemon, it is our first choice, but we found it xenstore daemon in dom0 comsume >many CPU(we test in linux only), so we decide to move it into driver. > >I've done merge my code with latest changeset 866, and do the stree test later. > >many thanks. > >> Subject: RE: RE: blue screen in windows balloon driver >> Date: Sun, 27 Feb 2011 22:25:28 +1100 >> From: james.harper@bendigoit.com.au >> To: tinnycloud@hotmail.com; xen-devel@lists.xensource.com >> CC: george.dunlap@eu.citrix.com >> >> > Thanks James. >> > >> > I think it is GPLPV. The driver is from >> http://xenbits.xen.org/ext/win- >> > pvdrivers.hg >> > But, I have done some other things >> > >> > 1) Add pod support >> > 2) enable a meminfo thread, periodically write VM meminfo into >> xenstore >> > We use info of Current Memory, Free memory, and Committed memory, >> retrived >> > through NativeAPI >> > 3) our code is based from changeset 823, attached is the diff of my >> current >> > code with changset of 853. >> > >> > Maybe I need add my code to 853, and test again. >> > Thanks. >> > >> >> As per other post, I have just committed some patches and PoD should now >> be working properly. I can start a DomU with 4GB of maxmem but only >> 128MB of populated memory without any problems. This now works because I >> do the initial balloon down in DriverEntry, way before xenpci does >> anything else. Before it would blow up in DriverEntry. I think I >> determine the amount to initially balloon down a little differently from >> you too. >> >> It takes a while to balloon down the memory though... I think Windows >> tends to delay large allocations or something, because ballooning up >> again is pretty much instant. >> >> How often are you writing meminfo stuff into xenstore? Could you do that >> in userspace (the interface to xenstore exists and seems to work well >> although it's a little tedious)? You would then be able to just run it >> as a service and not need to patch GPLPV. >> >> James > [-- Attachment #1.2: Type: text/html, Size: 5025 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: blue screen in windows balloon driver 2011-02-28 8:29 ` MaoXiaoyun @ 2011-02-28 11:45 ` James Harper 2011-02-28 23:45 ` James Harper 1 sibling, 0 replies; 26+ messages in thread From: James Harper @ 2011-02-28 11:45 UTC (permalink / raw) To: MaoXiaoyun, xen devel > > Hi James: > > Unfortunately, We still hit the blue screen on the stress test. > (Start total 24 HVMS on a single 16core, 24G host, > each HVM owns 2G Memory, start with memory=512M, > and inside two eating memory processes, each of which will each 1G > memory) > > As I go though the code, I noticed that all memory allocation relates to > "ExAllocatePoolWithTag(NonPagedPool,...)", which is from NonePaged Pool, > As I know, the NonePagePool memory is the memory could not be paged out, > and that is limited, and for the blue screen VMS, I also found the free > memory is quite low, only about hundreds KB left. > > So, when memory overcommit, some of the VM will not got enough memory, > and if most of its Memory is occupied by eating memory process, then > ExAllocatePoolWithTag > will fail, thus caused "NO_PAGES_AVALIABLE" blue screen. Is this possible? > > Meanwhile, I will have your PVdriver tested to see if blue exists, Yes you are correct - NonPagedPool memory that will always be available. Most of my driver code is required at some point to run at DISPATCH_LEVEL (an IRQ priority level - not sure if you are familiar with the concept) and at DISPATCH_LEVEL any attempt to access memory that is paged out to disk will result in a blue screen. There are overheads with adding more memory to the system. Windows has to keep track of every page of memory so the more memory you have the more memory windows has to keep track of, and this in turn uses up more memory. If you had a system with maxmem=32768 and memory=256 or something in that order of numbers then maybe Windows needs most of that 256MB to keep track of the 32GB of memory and doesn't have enough left for itself. In your original email you said you were using maxmem=2048 and memory=512 so maybe that isn't the problem. Looking at the bug check, parameter 1 and 2 are both 0x0002A8FB (about 714MB). This means that there is 714MB of 'dirty' pages to be written to the pagefile. I think this might happen if you tried to allocate too much memory too fast and Windows couldn't write it out to disk fast enough (it could also happen if xenvbd had hung or something). Maybe a delay is needed when allocating memory, or else some sort of feedback into the ballooning down code. I'll post on ntdev for advice. James ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: blue screen in windows balloon driver 2011-02-28 8:29 ` MaoXiaoyun 2011-02-28 11:45 ` James Harper @ 2011-02-28 23:45 ` James Harper 2011-03-01 2:37 ` MaoXiaoyun 1 sibling, 1 reply; 26+ messages in thread From: James Harper @ 2011-02-28 23:45 UTC (permalink / raw) To: MaoXiaoyun, xen devel I have just pushed a change to check the "\KernelObjects\LowMemoryCondition" event before allocating memory for ballooning, and waiting if the event is set. This may resolve the problems you are seeing. What I have seen is that initially the event gets set, but then as Windows pages some active memory out the event gets cleared again and further ballooning down is possible. It may prevent you ballooning down quite as low as you could before, but if it stops windows crashing then I think it is good. James > -----Original Message----- > From: MaoXiaoyun [mailto:tinnycloud@hotmail.com] > Sent: Monday, 28 February 2011 19:30 > To: xen devel > Cc: James Harper > Subject: RE: blue screen in windows balloon driver > > Hi James: > > Unfortunately, We still hit the blue screen on the stress test. > (Start total 24 HVMS on a single 16core, 24G host, > each HVM owns 2G Memory, start with memory=512M, > and inside two eating memory processes, each of which will each 1G > memory) > > As I go though the code, I noticed that all memory allocation relates to > "ExAllocatePoolWithTag(NonPagedPool,...)", which is from NonePaged Pool, > As I know, the NonePagePool memory is the memory could not be paged out, > and that is limited, and for the blue screen VMS, I also found the free > memory > is quite low, only about hundreds KB left. > > So, when memory overcommit, some of the VM will not got enough memory, > and if most of its Memory is occupied by eating memory process, then > ExAllocatePoolWithTag > will fail, thus caused "NO_PAGES_AVALIABLE" blue screen. Is this possible? > > Meanwhile, I will have your PVdriver tested to see if blue exists, > thanks. > > > >From: tinnycloud@hotmail.com > >To: tinnycloud@hotmail.com > >Subject: FW: blue screen in windows balloon driver > >Date: Mon, 28 Feb 2011 16:16:59 +0800 > > > > > >Thanks for fixing the POD. It's is better make it earlier to avoid crash. > > > >The meminfo is written every 1 seconds into xenstore dir > /local/domain/did/memory/meminfo. > >And to avoid to many writes, only the memory changes large than 5M, the > thread will do the write. > > > >As for userspace daemon, it is our first choice, but we found it xenstore > daemon in dom0 comsume > >many CPU(we test in linux only), so we decide to move it into driver. > > > >I've done merge my code with latest changeset 866, and do the stree test > later. > > > >many thanks. > > > >> Subject: RE: RE: blue screen in windows balloon driver > >> Date: Sun, 27 Feb 2011 22:25:28 +1100 > >> From: james.harper@bendigoit.com.au > >> To: tinnycloud@hotmail.com; xen-devel@lists.xensource.com > >> CC: george.dunlap@eu.citrix.com > >> > >> > Thanks James. > >> > > >> > I think it is GPLPV. The driver is from > >> http://xenbits.xen.org/ext/win- > >> > pvdrivers.hg > >> > But, I have done some other things > >> > > >> > 1) Add pod support > >> > 2) enable a meminfo thread, periodically write VM meminfo into > >> xenstore > >> > We use info of Current Memory, Free memory, and Committed memory, > >> retrived > >> > through NativeAPI > >> > 3) our code is based from changeset 823, attached is the diff of my > >> current > >> > code with changset of 853. > >> > > >> > Maybe I need add my code to 853, and test again. > >> > Thanks. > >> > > >> > >> As per other post, I have just committed some patches and PoD should now > >> be working properly. I can start a DomU with 4GB of maxmem but only > >> 128MB of populated memory without any problems. This now works because I > >> do the initial balloon down in DriverEntry, way before xenpci does > >> anything else. Before it would blow up in DriverEntry. I think I > >> determine the amount to initially balloon down a little differently from > >> you too. > >> > >> It takes a while to balloon down the memory though... I think Windows > >> tends to delay large allocations or something, because ballooning up > >> again is pretty much instant. > >> > >> How often are you writing meminfo stuff into xenstore? Could you do that > >> in userspace (the interface to xenstore exists and seems to work well > >> although it's a little tedious)? You would then be able to just run it > >> as a service and not need to patch GPLPV. > >> > >> James > > ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: blue screen in windows balloon driver 2011-02-28 23:45 ` James Harper @ 2011-03-01 2:37 ` MaoXiaoyun 2011-03-01 5:01 ` James Harper 0 siblings, 1 reply; 26+ messages in thread From: MaoXiaoyun @ 2011-03-01 2:37 UTC (permalink / raw) To: xen devel; +Cc: james.harper [-- Attachment #1.1: Type: text/plain, Size: 5508 bytes --] Thanks James. Well, what if the memory is balloon dow already? In my test, the eat memory process(named memhog) is started after the server starts, (that is all VMs have already ballooned down to 512M) It looks like the "balloon down threads " is not working at that time. One more question is, if memhog eat process at very fast speed, will it consume the NopagePool memory? (I am not whether NopagePool and Page Pool is seperate pool). If so, if the memory is exhausted, some other places like"ExAllocatePoolWithTag(NonPagedPool,...)", will gets no memory, and could it cause bluescreen? I will have the latest driver tested, thanks. > Subject: RE: blue screen in windows balloon driver > Date: Tue, 1 Mar 2011 10:45:52 +1100 > From: james.harper@bendigoit.com.au > To: tinnycloud@hotmail.com; xen-devel@lists.xensource.com > > I have just pushed a change to check the > "\KernelObjects\LowMemoryCondition" event before allocating memory for > ballooning, and waiting if the event is set. This may resolve the > problems you are seeing. > > What I have seen is that initially the event gets set, but then as > Windows pages some active memory out the event gets cleared again and > further ballooning down is possible. It may prevent you ballooning down > quite as low as you could before, but if it stops windows crashing then > I think it is good. > > James > > > -----Original Message----- > > From: MaoXiaoyun [mailto:tinnycloud@hotmail.com] > > Sent: Monday, 28 February 2011 19:30 > > To: xen devel > > Cc: James Harper > > Subject: RE: blue screen in windows balloon driver > > > > Hi James: > > > > Unfortunately, We still hit the blue screen on the stress test. > > (Start total 24 HVMS on a single 16core, 24G host, > > each HVM owns 2G Memory, start with memory=512M, > > and inside two eating memory processes, each of which will each > 1G > > memory) > > > > As I go though the code, I noticed that all memory allocation > relates to > > "ExAllocatePoolWithTag(NonPagedPool,...)", which is from > NonePaged Pool, > > As I know, the NonePagePool memory is the memory could not be > paged out, > > and that is limited, and for the blue screen VMS, I also found > the free > > memory > > is quite low, only about hundreds KB left. > > > > So, when memory overcommit, some of the VM will not got enough > memory, > > and if most of its Memory is occupied by eating memory process, then > > ExAllocatePoolWithTag > > will fail, thus caused "NO_PAGES_AVALIABLE" blue screen. Is this > possible? > > > > Meanwhile, I will have your PVdriver tested to see if blue > exists, > > thanks. > > > > > > >From: tinnycloud@hotmail.com > > >To: tinnycloud@hotmail.com > > >Subject: FW: blue screen in windows balloon driver > > >Date: Mon, 28 Feb 2011 16:16:59 +0800 > > > > > > > > >Thanks for fixing the POD. It's is better make it earlier to avoid > crash. > > > > > >The meminfo is written every 1 seconds into xenstore dir > > /local/domain/did/memory/meminfo. > > >And to avoid to many writes, only the memory changes large than 5M, > the > > thread will do the write. > > > > > >As for userspace daemon, it is our first choice, but we found it > xenstore > > daemon in dom0 comsume > > >many CPU(we test in linux only), so we decide to move it into driver. > > > > > >I've done merge my code with latest changeset 866, and do the stree > test > > later. > > > > > >many thanks. > > > > > >> Subject: RE: RE: blue screen in windows balloon driver > > >> Date: Sun, 27 Feb 2011 22:25:28 +1100 > > >> From: james.harper@bendigoit.com.au > > >> To: tinnycloud@hotmail.com; xen-devel@lists.xensource.com > > >> CC: george.dunlap@eu.citrix.com > > >> > > >> > Thanks James. > > >> > > > >> > I think it is GPLPV. The driver is from > > >> http://xenbits.xen.org/ext/win- > > >> > pvdrivers.hg > > >> > But, I have done some other things > > >> > > > >> > 1) Add pod support > > >> > 2) enable a meminfo thread, periodically write VM meminfo into > > >> xenstore > > >> > We use info of Current Memory, Free memory, and Committed memory, > > >> retrived > > >> > through NativeAPI > > >> > 3) our code is based from changeset 823, attached is the diff of > my > > >> current > > >> > code with changset of 853. > > >> > > > >> > Maybe I need add my code to 853, and test again. > > >> > Thanks. > > >> > > > >> > > >> As per other post, I have just committed some patches and PoD > should now > > >> be working properly. I can start a DomU with 4GB of maxmem but only > > >> 128MB of populated memory without any problems. This now works > because I > > >> do the initial balloon down in DriverEntry, way before xenpci does > > >> anything else. Before it would blow up in DriverEntry. I think I > > >> determine the amount to initially balloon down a little differently > from > > >> you too. > > >> > > >> It takes a while to balloon down the memory though... I think > Windows > > >> tends to delay large allocations or something, because ballooning > up > > >> again is pretty much instant. > > >> > > >> How often are you writing meminfo stuff into xenstore? Could you do > that > > >> in userspace (the interface to xenstore exists and seems to work > well > > >> although it's a little tedious)? You would then be able to just run > it > > >> as a service and not need to patch GPLPV. > > >> > > >> James > > > [-- Attachment #1.2: Type: text/html, Size: 7192 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: blue screen in windows balloon driver 2011-03-01 2:37 ` MaoXiaoyun @ 2011-03-01 5:01 ` James Harper 2011-03-01 5:28 ` MaoXiaoyun 2011-03-01 7:14 ` MaoXiaoyun 0 siblings, 2 replies; 26+ messages in thread From: James Harper @ 2011-03-01 5:01 UTC (permalink / raw) To: MaoXiaoyun; +Cc: xen devel Please send logs and bug check codes for any future crashes Can you also send me your memhog program? Sent from my iPhone On 01/03/2011, at 13:37, "MaoXiaoyun" <tinnycloud@hotmail.com> wrote: > Thanks James. > > Well, what if the memory is balloon dow already? > In my test, the eat memory process(named memhog) is started after the server starts, > (that is all VMs have already ballooned down to 512M) > It looks like the "balloon down threads " is not working at that time. > > One more question is, if memhog eat process at very fast speed, will it consume the > NopagePool memory? (I am not whether NopagePool and Page Pool is seperate pool). > If so, if the memory is exhausted, some other places like"ExAllocatePoolWithTag(NonPagedPool,...)", > will gets no memory, and could it cause bluescreen? > > I will have the latest driver tested, thanks. > > > > Subject: RE: blue screen in windows balloon driver > > Date: Tue, 1 Mar 2011 10:45:52 +1100 > > From: james.harper@bendigoit.com.au > > To: tinnycloud@hotmail.com; xen-devel@lists.xensource.com > > > > I have just pushed a change to check the > > "\KernelObjects\LowMemoryCondition" event before allocating memory for > > ballooning, and waiting if the event is set. This may resolve the > > problems you are seeing. > > > > What I have seen is that initially the event gets set, but then as > > Windows pages some active memory out the event gets cleared again and > > further ballooning down is possible. It may prevent you ballooning down > > quite as low as you could before, but if it stops windows crashing then > > I think it is good. > > > > James > > > > > -----Original Message----- > > > From: MaoXiaoyun [mailto:tinnycloud@hotmail.com] > > > Sent: Monday, 28 February 2011 19:30 > > > To: xen devel > > > Cc: James Harper > > > Subject: RE: blue screen in windows balloon driver > > > > > > Hi James: > > > > > > Unfortunately, We still hit the blue screen on the stress test. > > > (Start total 24 HVMS on a single 16core, 24G host, > > > each HVM owns 2G Memory, start with memory=512M, > > > and inside two eating memory processes, each of which will each > > 1G > > > memory) > > > > > > As I go though the code, I noticed that all memory allocation > > relates to > > > "ExAllocatePoolWithTag(NonPagedPool,...)", which is from > > NonePaged Pool, > > > As I know, the NonePagePool memory is the memory could not be > > paged out, > > > and that is limited, and for the blue screen VMS, I also found > > the free > > > memory > > > is quite low, only about hundreds KB left. > > > > > > So, when memory overcommit, some of the VM will not got enough > > memory, > > > and if most of its Memory is occupied by eating memory process, then > > > ExAllocatePoolWithTag > > > will fail, thus caused "NO_PAGES_AVALIABLE" blue screen. Is this > > possible? > > > > > > Meanwhile, I will have your PVdriver tested to see if blue > > exists, > > > thanks. > > > > > > > > > >From: tinnycloud@hotmail.com > > > >To: tinnycloud@hotmail.com > > > >Subject: FW: blue screen in windows balloon driver > > > >Date: Mon, 28 Feb 2011 16:16:59 +0800 > > > > > > > > > > > >Thanks for fixing the POD. It's is better make it earlier to avoid > > crash. > > > > > > > >The meminfo is written every 1 seconds into xenstore dir > > > /local/domain/did/memory/meminfo. > > > >And to avoid to many writes, only the memory changes large than 5M, > > the > > > thread will do the write. > > > > > > > >As for userspace daemon, it is our first choice, but we found it > > xenstore > > > daemon in dom0 comsume > > > >many CPU(we test in linux only), so we decide to move it into driver. > > > > > > > >I've done merge my code with latest changeset 866, and do the stree > > test > > > later. > > > > > > > >many thanks. > > > > > > > >> Subject: RE: RE: blue screen in windows balloon driver > > > >> Date: Sun, 27 Feb 2011 22:25:28 +1100 > > > >> From: james.harper@bendigoit.com.au > > > >> To: tinnycloud@hotmail.com; xen-devel@lists.xensource.com > > > >> CC: george.dunlap@eu.citrix.com > > > >> > > > >> > Thanks James. > > > >> > > > > >> > I think it is GPLPV. The driver is from > > > >> http://xenbits.xen.org/ext/win- > > > >> > pvdrivers.hg > > > >> > But, I have done some other things > > > >> > > > > >> > 1) Add pod support > > > >> > 2) enable a meminfo thread, periodically write VM meminfo into > > > >> xenstore > > > >> > We use info of Current Memory, Free memory, and Committed memory, > > > >> retrived > > > >> > through NativeAPI > > > >> > 3) our code is based from changeset 823, attached is the diff of > > my > > > >> current > > > >> > code with changset of 853. > > > >> > > > > >> > Maybe I need add my code to 853, and test again. > > > >> > Thanks. > > > >> > > > > >> > > > >> As per other post, I have just committed some patches and PoD > > should now > > > >> be working properly. I can start a DomU with 4GB of maxmem but only > > > >> 128MB of populated memory without any problems. This now works > > because I > > > >> do the initial balloon down in DriverEntry, way before xenpci does > > > >> anything else. Before it would blow up in DriverEntry. I think I > > > >> determine the amount to initially balloon down a little differently > > from > > > >> you too. > > > >> > > > >> It takes a while to balloon down the memory though... I think > > Windows > > > >> tends to delay large allocations or something, because ballooning > > up > > > >> again is pretty much instant. > > > >> > > > >> How often are you writing meminfo stuff into xenstore? Could you do > > that > > > >> in userspace (the interface to xenstore exists and seems to work > > well > > > >> although it's a little tedious)? You would then be able to just run > > it > > > >> as a service and not need to patch GPLPV. > > > >> > > > >> James > > > > ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: blue screen in windows balloon driver 2011-03-01 5:01 ` James Harper @ 2011-03-01 5:28 ` MaoXiaoyun [not found] ` <AEC6C66638C05B468B556EA548C1A77D01C55AC7@trantor> 2011-03-01 7:14 ` MaoXiaoyun 1 sibling, 1 reply; 26+ messages in thread From: MaoXiaoyun @ 2011-03-01 5:28 UTC (permalink / raw) To: xen devel; +Cc: james.harper [-- Attachment #1.1: Type: text/plain, Size: 7598 bytes --] Attached is the memhog source code. In test, I run two memhogs at same time with options " -t 2 -M 512 -R 30 -s 2 -K 100" which means, 2threads, total alloc 512M memory, run 30times, sleep every 2 seconds between rounds, and every malloc, malloc 100KB. Also, in currently test, after VM starts with 512M memory, no memory is given back to VM. Actually, we have three physical host to test the blue screen, quite strange is only on machine hit the blue screen quite easily(your driver with/without low memory event hit the screen). But on other two machine, everything goes fine. Even I recompile the host system, different result still exists. I also noticed the your post on ntdev, is it possible "ExAllocatePoolWithTag" failed, but in code the return NULL is not fully checked? More, what kind of logs your need, and does "check code" means something like " ***STOP: 0x0000004D (0x00015742,0x00015742,0x00000000,0x00000000) ***STOP: 0x0000004D (0x0001583B,0x0001583B,0x00000000,0x00000000) this the latest two crashes. > Subject: Re: blue screen in windows balloon driver > From: james.harper@bendigoit.com.au > Date: Tue, 1 Mar 2011 16:01:46 +1100 > To: tinnycloud@hotmail.com > CC: xen-devel@lists.xensource.com > > Please send logs and bug check codes for any future crashes > > Can you also send me your memhog program? > > Sent from my iPhone > > On 01/03/2011, at 13:37, "MaoXiaoyun" <tinnycloud@hotmail.com> wrote: > > > Thanks James. > > > > Well, what if the memory is balloon dow already? > > In my test, the eat memory process(named memhog) is started after the server starts, > > (that is all VMs have already ballooned down to 512M) > > It looks like the "balloon down threads " is not working at that time. > > > > One more question is, if memhog eat process at very fast speed, will it consume the > > NopagePool memory? (I am not whether NopagePool and Page Pool is seperate pool). > > If so, if the memory is exhausted, some other places like"ExAllocatePoolWithTag(NonPagedPool,...)", > > will gets no memory, and could it cause bluescreen? > > > > I will have the latest driver tested, thanks. > > > > > > > Subject: RE: blue screen in windows balloon driver > > > Date: Tue, 1 Mar 2011 10:45:52 +1100 > > > From: james.harper@bendigoit.com.au > > > To: tinnycloud@hotmail.com; xen-devel@lists.xensource.com > > > > > > I have just pushed a change to check the > > > "\KernelObjects\LowMemoryCondition" event before allocating memory for > > > ballooning, and waiting if the event is set. This may resolve the > > > problems you are seeing. > > > > > > What I have seen is that initially the event gets set, but then as > > > Windows pages some active memory out the event gets cleared again and > > > further ballooning down is possible. It may prevent you ballooning down > > > quite as low as you could before, but if it stops windows crashing then > > > I think it is good. > > > > > > James > > > > > > > -----Original Message----- > > > > From: MaoXiaoyun [mailto:tinnycloud@hotmail.com] > > > > Sent: Monday, 28 February 2011 19:30 > > > > To: xen devel > > > > Cc: James Harper > > > > Subject: RE: blue screen in windows balloon driver > > > > > > > > Hi James: > > > > > > > > Unfortunately, We still hit the blue screen on the stress test. > > > > (Start total 24 HVMS on a single 16core, 24G host, > > > > each HVM owns 2G Memory, start with memory=512M, > > > > and inside two eating memory processes, each of which will each > > > 1G > > > > memory) > > > > > > > > As I go though the code, I noticed that all memory allocation > > > relates to > > > > "ExAllocatePoolWithTag(NonPagedPool,...)", which is from > > > NonePaged Pool, > > > > As I know, the NonePagePool memory is the memory could not be > > > paged out, > > > > and that is limited, and for the blue screen VMS, I also found > > > the free > > > > memory > > > > is quite low, only about hundreds KB left. > > > > > > > > So, when memory overcommit, some of the VM will not got enough > > > memory, > > > > and if most of its Memory is occupied by eating memory process, then > > > > ExAllocatePoolWithTag > > > > will fail, thus caused "NO_PAGES_AVALIABLE" blue screen. Is this > > > possible? > > > > > > > > Meanwhile, I will have your PVdriver tested to see if blue > > > exists, > > > > thanks. > > > > > > > > > > > > >From: tinnycloud@hotmail.com > > > > >To: tinnycloud@hotmail.com > > > > >Subject: FW: blue screen in windows balloon driver > > > > >Date: Mon, 28 Feb 2011 16:16:59 +0800 > > > > > > > > > > > > > > >Thanks for fixing the POD. It's is better make it earlier to avoid > > > crash. > > > > > > > > > >The meminfo is written every 1 seconds into xenstore dir > > > > /local/domain/did/memory/meminfo. > > > > >And to avoid to many writes, only the memory changes large than 5M, > > > the > > > > thread will do the write. > > > > > > > > > >As for userspace daemon, it is our first choice, but we found it > > > xenstore > > > > daemon in dom0 comsume > > > > >many CPU(we test in linux only), so we decide to move it into driver. > > > > > > > > > >I've done merge my code with latest changeset 866, and do the stree > > > test > > > > later. > > > > > > > > > >many thanks. > > > > > > > > > >> Subject: RE: RE: blue screen in windows balloon driver > > > > >> Date: Sun, 27 Feb 2011 22:25:28 +1100 > > > > >> From: james.harper@bendigoit.com.au > > > > >> To: tinnycloud@hotmail.com; xen-devel@lists.xensource.com > > > > >> CC: george.dunlap@eu.citrix.com > > > > >> > > > > >> > Thanks James. > > > > >> > > > > > >> > I think it is GPLPV. The driver is from > > > > >> http://xenbits.xen.org/ext/win- > > > > >> > pvdrivers.hg > > > > >> > But, I have done some other things > > > > >> > > > > > >> > 1) Add pod support > > > > >> > 2) enable a meminfo thread, periodically write VM meminfo into > > > > >> xenstore > > > > >> > We use info of Current Memory, Free memory, and Committed memory, > > > > >> retrived > > > > >> > through NativeAPI > > > > >> > 3) our code is based from changeset 823, attached is the diff of > > > my > > > > >> current > > > > >> > code with changset of 853. > > > > >> > > > > > >> > Maybe I need add my code to 853, and test again. > > > > >> > Thanks. > > > > >> > > > > > >> > > > > >> As per other post, I have just committed some patches and PoD > > > should now > > > > >> be working properly. I can start a DomU with 4GB of maxmem but only > > > > >> 128MB of populated memory without any problems. This now works > > > because I > > > > >> do the initial balloon down in DriverEntry, way before xenpci does > > > > >> anything else. Before it would blow up in DriverEntry. I think I > > > > >> determine the amount to initially balloon down a little differently > > > from > > > > >> you too. > > > > >> > > > > >> It takes a while to balloon down the memory though... I think > > > Windows > > > > >> tends to delay large allocations or something, because ballooning > > > up > > > > >> again is pretty much instant. > > > > >> > > > > >> How often are you writing meminfo stuff into xenstore? Could you do > > > that > > > > >> in userspace (the interface to xenstore exists and seems to work > > > well > > > > >> although it's a little tedious)? You would then be able to just run > > > it > > > > >> as a service and not need to patch GPLPV. > > > > >> > > > > >> James > > > > > [-- Attachment #1.2: Type: text/html, Size: 10683 bytes --] [-- Attachment #2: memhog.rar --] [-- Type: application/octet-stream, Size: 19571 bytes --] [-- Attachment #3: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <AEC6C66638C05B468B556EA548C1A77D01C55AC7@trantor>]
[parent not found: <BLU157-w655070D9CFE092D78C011DDAC10@phx.gbl>]
[parent not found: <AEC6C66638C05B468B556EA548C1A77D01C55ACA@trantor>]
* RE: blue screen in windows balloon driver [not found] ` <AEC6C66638C05B468B556EA548C1A77D01C55ACA@trantor> @ 2011-03-01 12:34 ` MaoXiaoyun 2011-03-01 12:35 ` James Harper 0 siblings, 1 reply; 26+ messages in thread From: MaoXiaoyun @ 2011-03-01 12:34 UTC (permalink / raw) To: james.harper; +Cc: xen devel [-- Attachment #1.1: Type: text/plain, Size: 1504 bytes --] I will have new driver tested. Attached is the xentop snapshot. thanks. > Subject: RE: blue screen in windows balloon driver > Date: Tue, 1 Mar 2011 23:11:14 +1100 > From: james.harper@bendigoit.com.au > To: tinnycloud@hotmail.com > > > > > exe attached, thanks. > > > > I have three machines, on each sum the *XenVbd_HwScsiResetBus* event. > > 24 VMS, so > > grep XenVbd_HwScsiResetBus qemu-dm-w3.MR_cp* | wc -l > > > > machine 25: VM easily got crash, the sum is 200 > > machine 23: VM never got crash, the sum is 10 > > machine 212: VM never got crash, the sum is 16 > > > > it seems that machine 25 has much more XenVbd_HwScsiResetBus event > > than other two machines. > > > > BTW, when start 24VM concurrently, the starting process is quite slow, > takes > > about 20 minutes more to whole started. > > > > I commented line 505 in xenpci_pdo.c to avoid timed out. > > > > 505 //remaining -= thiswait; > > > > It sounds like you are overloading your disk IO bandwidth. With many > DomU's swapping heavily, Dom0 may simply not be able to keep up with the > IO throughput required resulting in windows thinking that the scsi > device isn't responding. Can you check xentop and see what sort of IO > operations per second you are getting? > > I have just pushed a change to dump out the in-flight scsi requests > (srb) when HwScsiResetBus is called. Please apply the patch and send me > the next crash. > > Thanks > > James [-- Attachment #1.2: Type: text/html, Size: 2017 bytes --] [-- Attachment #2: xentop.txt --] [-- Type: text/plain, Size: 3059 bytes --] NAME STATE CPU(sec) CPU(%) MEM(k) MEM(%) MAXMEM(k) MAXMEM(%) VCPUS NETS NETTX(k) NETRX(k) VBDS VBD_OO VBD_RD VBD_WR VBD_RSECT VBD_WSECT SSID w3.MR_cp21 --b--- 281 1.3 524128 2.1 2101248 8.4 2 0 0 0 1 17946 12714 5836 455428 279489 0 w3.MR_cp8. --b--- 384 2.1 524128 2.1 2101248 8.4 2 0 0 0 1 17637 12766 5783 452159 284097 0 w3.MR_cp5. --b--- 288 1.9 524128 2.1 2101248 8.4 2 0 0 0 1 17479 12037 5739 434796 279302 0 w3.MR_cp1. --b--- 366 2.2 524128 2.1 2101248 8.4 2 0 0 0 1 17155 12468 5902 456344 290401 0 w3.MR_cp15 --b--- 369 2.0 524128 2.1 2101248 8.4 2 0 0 0 1 17055 13257 5152 450882 234945 0 w3.MR_cp12 -----r 291 4.5 524128 2.1 2101248 8.4 2 0 0 0 1 16760 11762 5898 432858 281974 0 w3.MR_cp22 --b--- 277 2.5 524128 2.1 2101248 8.4 2 0 0 0 1 16742 11753 5901 435315 286561 0 w3.MR_cp10 --b--- 353 2.0 524128 2.1 2101248 8.4 2 0 0 0 1 16646 13078 5703 438043 271899 0 w3.MR_cp13 --b--- 278 2.9 524128 2.1 2101248 8.4 2 0 0 0 1 16571 11628 5740 422040 277717 0 w3.MR_cp20 --b--- 280 2.9 524128 2.1 2101248 8.4 2 0 0 0 1 16493 11341 6260 417711 315668 0 w3.MR_cp19 --b--- 258 5.0 524128 2.1 2101248 8.4 2 0 0 0 1 16066 12823 5470 433721 257752 0 w3.MR_cp17 --b--- 248 1.3 524128 2.1 2101248 8.4 2 0 0 0 1 15232 11606 6335 432435 316746 0 w3.MR_cp18 ------ 224 2.4 524128 2.1 2101248 8.4 2 0 0 0 1 15114 11762 6080 431874 288844 0 w3.MR_cp4. --b--- 321 2.0 524128 2.1 2101248 8.4 2 0 0 0 1 14238 11535 6092 422576 294388 0 w3.MR_cp6. --b--- 297 2.0 524128 2.1 2101248 8.4 2 0 0 0 1 12811 11624 5990 424612 292594 0 w3.MR_cp14 --b--- 287 1.8 524128 2.1 2101248 8.4 2 0 0 0 1 12654 11628 6313 423478 310240 0 w3.MR_cp3. --b--- 119 1.9 524128 2.1 2101248 8.4 2 0 0 0 1 11737 11954 6098 425293 286504 0 Delay Networks vBds Tmem VCPUs Repeat header Sort order Quit [-- Attachment #3: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: blue screen in windows balloon driver 2011-03-01 12:34 ` MaoXiaoyun @ 2011-03-01 12:35 ` James Harper 0 siblings, 0 replies; 26+ messages in thread From: James Harper @ 2011-03-01 12:35 UTC (permalink / raw) To: MaoXiaoyun; +Cc: xen devel Hold off on testing. I'm fixing up the reset code so that it does what Windows wants. I'll post something soon if it doesn't take too long. James > -----Original Message----- > From: MaoXiaoyun [mailto:tinnycloud@hotmail.com] > Sent: Tuesday, 1 March 2011 23:34 > To: James Harper > Cc: xen devel > Subject: RE: blue screen in windows balloon driver > > I will have new driver tested. > Attached is the xentop snapshot. > > thanks. > > > Subject: RE: blue screen in windows balloon driver > > Date: Tue, 1 Mar 2011 23:11:14 +1100 > > From: james.harper@bendigoit.com.au > > To: tinnycloud@hotmail.com > > > > > > > > exe attached, thanks. > > > > > > I have three machines, on each sum the *XenVbd_HwScsiResetBus* event. > > > 24 VMS, so > > > grep XenVbd_HwScsiResetBus qemu-dm-w3.MR_cp* | wc -l > > > > > > machine 25: VM easily got crash, the sum is 200 > > > machine 23: VM never got crash, the sum is 10 > > > machine 212: VM never got crash, the sum is 16 > > > > > > it seems that machine 25 has much more XenVbd_HwScsiResetBus event > > > than other two machines. > > > > > > BTW, when start 24VM concurrently, the starting process is quite slow, > > takes > > > about 20 minutes more to whole started. > > > > > > I commented line 505 in xenpci_pdo.c to avoid timed out. > > > > > > 505 //remaining -= thiswait; > > > > > > > It sounds like you are overloading your disk IO bandwidth. With many > > DomU's swapping heavily, Dom0 may simply not be able to keep up with the > > IO throughput required resulting in windows thinking that the scsi > > device isn't responding. Can you check xentop and see what sort of IO > > operations per second you are getting? > > > > I have just pushed a change to dump out the in-flight scsi requests > > (srb) when HwScsiResetBus is called. Please apply the patch and send me > > the next crash. > > > > Thanks > > > > James ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: blue screen in windows balloon driver 2011-03-01 5:01 ` James Harper 2011-03-01 5:28 ` MaoXiaoyun @ 2011-03-01 7:14 ` MaoXiaoyun 2011-03-01 9:36 ` James Harper [not found] ` <AEC6C66638C05B468B556EA548C1A77D01C55AC5@trantor> 1 sibling, 2 replies; 26+ messages in thread From: MaoXiaoyun @ 2011-03-01 7:14 UTC (permalink / raw) To: xen devel; +Cc: james.harper [-- Attachment #1.1: Type: text/plain, Size: 7201 bytes --] Hi James: Attached are three logs. (I started test PV in debug mode) qemu-dm-w3.MR_cp7.vhd.log.normal: is the VM not crash qemu-dm-w3.MR_cp23.vhd.log.crash: is the vm crashed, but the log show a Assertion failed. *** Assertion failed: srb != NULL *** Source File: e:\download\win-pvdrivers.hg\xenvbd\xenvbd_scsiport.c, line 988 Blue screen on "NO_PAGES_AVAILABLE" ***STOP: 0x0000004D (0x0001566c,0x0001566c,0x00000000,0x00000000) qemu-dm-w3.MR_cp6.vhd.log.crash: is the vm crashed, bug no special error in log Blue screen on "NO_PAGES_AVAILABLE" ***STOP: 0x0000004D (0x0001590f,0x0001590f,0x00000000,0x00000000) thanks. > Subject: Re: blue screen in windows balloon driver > From: james.harper@bendigoit.com.au > Date: Tue, 1 Mar 2011 16:01:46 +1100 > To: tinnycloud@hotmail.com > CC: xen-devel@lists.xensource.com > > Please send logs and bug check codes for any future crashes > > Can you also send me your memhog program? > > Sent from my iPhone > > On 01/03/2011, at 13:37, "MaoXiaoyun" <tinnycloud@hotmail.com> wrote: > > > Thanks James. > > > > Well, what if the memory is balloon dow already? > > In my test, the eat memory process(named memhog) is started after the server starts, > > (that is all VMs have already ballooned down to 512M) > > It looks like the "balloon down threads " is not working at that time. > > > > One more question is, if memhog eat process at very fast speed, will it consume the > > NopagePool memory? (I am not whether NopagePool and Page Pool is seperate pool). > > If so, if the memory is exhausted, some other places like"ExAllocatePoolWithTag(NonPagedPool,...)", > > will gets no memory, and could it cause bluescreen? > > > > I will have the latest driver tested, thanks. > > > > > > > Subject: RE: blue screen in windows balloon driver > > > Date: Tue, 1 Mar 2011 10:45:52 +1100 > > > From: james.harper@bendigoit.com.au > > > To: tinnycloud@hotmail.com; xen-devel@lists.xensource.com > > > > > > I have just pushed a change to check the > > > "\KernelObjects\LowMemoryCondition" event before allocating memory for > > > ballooning, and waiting if the event is set. This may resolve the > > > problems you are seeing. > > > > > > What I have seen is that initially the event gets set, but then as > > > Windows pages some active memory out the event gets cleared again and > > > further ballooning down is possible. It may prevent you ballooning down > > > quite as low as you could before, but if it stops windows crashing then > > > I think it is good. > > > > > > James > > > > > > > -----Original Message----- > > > > From: MaoXiaoyun [mailto:tinnycloud@hotmail.com] > > > > Sent: Monday, 28 February 2011 19:30 > > > > To: xen devel > > > > Cc: James Harper > > > > Subject: RE: blue screen in windows balloon driver > > > > > > > > Hi James: > > > > > > > > Unfortunately, We still hit the blue screen on the stress test. > > > > (Start total 24 HVMS on a single 16core, 24G host, > > > > each HVM owns 2G Memory, start with memory=512M, > > > > and inside two eating memory processes, each of which will each > > > 1G > > > > memory) > > > > > > > > As I go though the code, I noticed that all memory allocation > > > relates to > > > > "ExAllocatePoolWithTag(NonPagedPool,...)", which is from > > > NonePaged Pool, > > > > As I know, the NonePagePool memory is the memory could not be > > > paged out, > > > > and that is limited, and for the blue screen VMS, I also found > > > the free > > > > memory > > > > is quite low, only about hundreds KB left. > > > > > > > > So, when memory overcommit, some of the VM will not got enough > > > memory, > > > > and if most of its Memory is occupied by eating memory process, then > > > > ExAllocatePoolWithTag > > > > will fail, thus caused "NO_PAGES_AVALIABLE" blue screen. Is this > > > possible? > > > > > > > > Meanwhile, I will have your PVdriver tested to see if blue > > > exists, > > > > thanks. > > > > > > > > > > > > >From: tinnycloud@hotmail.com > > > > >To: tinnycloud@hotmail.com > > > > >Subject: FW: blue screen in windows balloon driver > > > > >Date: Mon, 28 Feb 2011 16:16:59 +0800 > > > > > > > > > > > > > > >Thanks for fixing the POD. It's is better make it earlier to avoid > > > crash. > > > > > > > > > >The meminfo is written every 1 seconds into xenstore dir > > > > /local/domain/did/memory/meminfo. > > > > >And to avoid to many writes, only the memory changes large than 5M, > > > the > > > > thread will do the write. > > > > > > > > > >As for userspace daemon, it is our first choice, but we found it > > > xenstore > > > > daemon in dom0 comsume > > > > >many CPU(we test in linux only), so we decide to move it into driver. > > > > > > > > > >I've done merge my code with latest changeset 866, and do the stree > > > test > > > > later. > > > > > > > > > >many thanks. > > > > > > > > > >> Subject: RE: RE: blue screen in windows balloon driver > > > > >> Date: Sun, 27 Feb 2011 22:25:28 +1100 > > > > >> From: james.harper@bendigoit.com.au > > > > >> To: tinnycloud@hotmail.com; xen-devel@lists.xensource.com > > > > >> CC: george.dunlap@eu.citrix.com > > > > >> > > > > >> > Thanks James. > > > > >> > > > > > >> > I think it is GPLPV. The driver is from > > > > >> http://xenbits.xen.org/ext/win- > > > > >> > pvdrivers.hg > > > > >> > But, I have done some other things > > > > >> > > > > > >> > 1) Add pod support > > > > >> > 2) enable a meminfo thread, periodically write VM meminfo into > > > > >> xenstore > > > > >> > We use info of Current Memory, Free memory, and Committed memory, > > > > >> retrived > > > > >> > through NativeAPI > > > > >> > 3) our code is based from changeset 823, attached is the diff of > > > my > > > > >> current > > > > >> > code with changset of 853. > > > > >> > > > > > >> > Maybe I need add my code to 853, and test again. > > > > >> > Thanks. > > > > >> > > > > > >> > > > > >> As per other post, I have just committed some patches and PoD > > > should now > > > > >> be working properly. I can start a DomU with 4GB of maxmem but only > > > > >> 128MB of populated memory without any problems. This now works > > > because I > > > > >> do the initial balloon down in DriverEntry, way before xenpci does > > > > >> anything else. Before it would blow up in DriverEntry. I think I > > > > >> determine the amount to initially balloon down a little differently > > > from > > > > >> you too. > > > > >> > > > > >> It takes a while to balloon down the memory though... I think > > > Windows > > > > >> tends to delay large allocations or something, because ballooning > > > up > > > > >> again is pretty much instant. > > > > >> > > > > >> How often are you writing meminfo stuff into xenstore? Could you do > > > that > > > > >> in userspace (the interface to xenstore exists and seems to work > > > well > > > > >> although it's a little tedious)? You would then be able to just run > > > it > > > > >> as a service and not need to patch GPLPV. > > > > >> > > > > >> James > > > > > [-- Attachment #1.2: Type: text/html, Size: 10483 bytes --] [-- Attachment #2: qemu-dm-w3.MR_cp23.vhd.log.crash --] [-- Type: application/octet-stream, Size: 22734 bytes --] domid: 9 Watching /local/domain/0/device-model/9/logdirty/cmd Watching /local/domain/0/device-model/9/command char device redirected to /dev/pts/9 qemu_map_cache_init nr_buckets = 10000 size 4194304 shared page at pfn feffd buffered io page at pfn feffb Guest uuid = 94ad525f-1275-f022-fcb7-aa92087b17e8 Time offset set 0 populating video RAM at ff000000 mapping video RAM from ff000000 Register xen platform. Done register platform. platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state. xs_read(/local/domain/0/device-model/9/xen_extended_power_mgmt): read error xs_read(): vncpasswd get error. /vm/94ad525f-1275-f022-fcb7-aa92087b17e8/vncpasswd. Log-dirty: no command yet. I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 xs_read(/local/domain/9/log-throttling): read error qemu: ignoring not-understood drive `/local/domain/9/log-throttling' medium change watch on `/local/domain/9/log-throttling' - unknown device, ignored cirrus vga map change while on lfb mode mapping vram to f0000000 - f0400000 platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state. platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro state. XenPCI <-- XenPci_HighSyncCallFunctionN XenPCI <-- XenPci_HighSyncCallFunction0 XenPCI Waiting for highsync_complete_event XenPCI <-- XenPci_HighSync XenPCI --> XenPci_InitialBalloonDown XenPCI base = 0x40000000, Xen Signature = XenVMMXenVMM, EAX = 0x40000003 XenPCI Hypercall area at 89DB5000 XenPCI XENMEM_maximum_reservation = 525312 XenPCI XENMEM_current_reservation = 131288 XenPCI Trying to give 1540 MB to Xen XenPCI <-- XenPci_InitialBalloonDown XenPCI KeInitializeCrashDumpHeader status = 00000000, size = 4096 XenPCI GPLPV 0.10.0.0 XenPCI --> XenPci_FixLoadOrder XenPCI dummy_group_index = 1 XenPCI wdf_load_group_index = 2 XenPCI xenpci_group_index = 3 XenPCI boot_bus_extender_index = 4 XenPCI <-- XenPci_FixLoadOrder XenPCI Version = 1 Unknown PV product 2 loaded in guest PV driver build 1 XenPCI Disabled qemu devices 03 XenPCI <-- DriverEntry XenPCI Xen PCI device found - must be fdo XenPCI --> XenPci_EvtDeviceAdd_XenPci XenPCI <-- XenPci_EvtDeviceAdd_XenPci XenPCI --> XenPci_EvtDevicePrepareHardware XenPCI IoPort Address(c000) Length: 256 XenPCI Private Data: 0x01 0x00 0x00 XenPCI Memory mapped CSR:(f2000000:0) Length:(16777216) XenPCI Memory flags = 0004 XenPCI Private Data: 0x01 0x01 0x00 XenPCI irq_number = 01c XenPCI irq_vector = 1a3 XenPCI irq_level = 009 XenPCI irq_mode = LevelSensitive XenPCI ShareDisposition = CmResourceShareShared XenPCI <-- XenPci_EvtDevicePrepareHardware XenPCI --> XenPci_EvtDeviceD0Entry XenPCI WdfPowerDeviceD3Final XenPCI --> XenPci_Init XenPCI base = 0x40000000, Xen Signature = XenVMMXenVMM, EAX = 0x40000003 XenPCI Hypercall area at 89B62000 XenPCI shared_info_area_unmapped.QuadPart = f2000000 XenPCI gpfn = f2000 XenPCI hypervisor memory op (XENMAPSPACE_shared_info) ret = 0 XenPCI <-- XenPci_Init XenPCI --> GntTbl_Init XenPCI grant_frames = 32 XenPCI grant_entries = 16384 XenPCI pfn = 97b9 XenPCI Calling HYPERVISOR_memory_op - pfn = 97b9 XenPCI decreased 1 pages for grant table frame 0 XenPCI pfn = 97ba XenPCI Calling HYPERVISOR_memory_op - pfn = 97ba XenPCI decreased 1 pages for grant table frame 1 XenPCI pfn = 97bb XenPCI Calling HYPERVISOR_memory_op - pfn = 97bb XenPCI decreased 1 pages for grant table frame 2 XenPCI pfn = 97bc XenPCI Calling HYPERVISOR_memory_op - pfn = 97bc XenPCI decreased 1 pages for grant table frame 3 XenPCI pfn = 97bd XenPCI Calling HYPERVISOR_memory_op - pfn = 97bd XenPCI decreased 1 pages for grant table frame 4 XenPCI pfn = 97be XenPCI Calling HYPERVISOR_memory_op - pfn = 97be XenPCI decreased 1 pages for grant table frame 5 XenPCI pfn = 97bf XenPCI Calling HYPERVISOR_memory_op - pfn = 97bf XenPCI decreased 1 pages for grant table frame 6 XenPCI pfn = 97c0 XenPCI Calling HYPERVISOR_memory_op - pfn = 97c0 XenPCI decreased 1 pages for grant table frame 7 XenPCI pfn = 97c1 XenPCI Calling HYPERVISOR_memory_op - pfn = 97c1 XenPCI decreased 1 pages for grant table frame 8 XenPCI pfn = 97c2 XenPCI Calling HYPERVISOR_memory_op - pfn = 97c2 XenPCI decreased 1 pages for grant table frame 9 XenPCI pfn = 97c3 XenPCI Calling HYPERVISOR_memory_op - pfn = 97c3 XenPCI decreased 1 pages for grant table frame 10 XenPCI pfn = 97c4 XenPCI Calling HYPERVISOR_memory_op - pfn = 97c4 XenPCI decreased 1 pages for grant table frame 11 XenPCI pfn = 97c5 XenPCI Calling HYPERVISOR_memory_op - pfn = 97c5 XenPCI decreased 1 pages for grant table frame 12 XenPCI pfn = 97c6 XenPCI Calling HYPERVISOR_memory_op - pfn = 97c6 XenPCI decreased 1 pages for grant table frame 13 XenPCI pfn = 97c7 XenPCI Calling HYPERVISOR_memory_op - pfn = 97c7 XenPCI decreased 1 pages for grant table frame 14 XenPCI pfn = 97c8 XenPCI Calling HYPERVISOR_memory_op - pfn = 97c8 XenPCI decreased 1 pages for grant table frame 15 XenPCI pfn = 97c9 XenPCI Calling HYPERVISOR_memory_op - pfn = 97c9 XenPCI decreased 1 pages for grant table frame 16 XenPCI pfn = 97ca XenPCI Calling HYPERVISOR_memory_op - pfn = 97ca XenPCI decreased 1 pages for grant table frame 17 XenPCI pfn = 97cb XenPCI Calling HYPERVISOR_memory_op - pfn = 97cb XenPCI decreased 1 pages for grant table frame 18 XenPCI pfn = 97cc XenPCI Calling HYPERVISOR_memory_op - pfn = 97cc XenPCI decreased 1 pages for grant table frame 19 XenPCI pfn = 97cd XenPCI Calling HYPERVISOR_memory_op - pfn = 97cd XenPCI decreased 1 pages for grant table frame 20 XenPCI pfn = 97ce XenPCI Calling HYPERVISOR_memory_op - pfn = 97ce XenPCI decreased 1 pages for grant table frame 21 XenPCI pfn = 97cf XenPCI Calling HYPERVISOR_memory_op - pfn = 97cf XenPCI decreased 1 pages for grant table frame 22 XenPCI pfn = 97d0 XenPCI Calling HYPERVISOR_memory_op - pfn = 97d0 XenPCI decreased 1 pages for grant table frame 23 XenPCI pfn = 97d1 XenPCI Calling HYPERVISOR_memory_op - pfn = 97d1 XenPCI decreased 1 pages for grant table frame 24 XenPCI pfn = 97d2 XenPCI Calling HYPERVISOR_memory_op - pfn = 97d2 XenPCI decreased 1 pages for grant table frame 25 XenPCI pfn = 97d3 XenPCI Calling HYPERVISOR_memory_op - pfn = 97d3 XenPCI decreased 1 pages for grant table frame 26 XenPCI pfn = 97d4 XenPCI Calling HYPERVISOR_memory_op - pfn = 97d4 XenPCI decreased 1 pages for grant table frame 27 XenPCI pfn = 97d5 XenPCI Calling HYPERVISOR_memory_op - pfn = 97d5 XenPCI decreased 1 pages for grant table frame 28 XenPCI pfn = 97d6 XenPCI Calling HYPERVISOR_memory_op - pfn = 97d6 XenPCI decreased 1 pages for grant table frame 29 XenPCI pfn = 97d7 XenPCI Calling HYPERVISOR_memory_op - pfn = 97d7 XenPCI decreased 1 pages for grant table frame 30 XenPCI pfn = 97d8 XenPCI Calling HYPERVISOR_memory_op - pfn = 97d8 XenPCI decreased 1 pages for grant table frame 31 XenPCI --> GntTbl_Map XenPCI <-- GntTbl_Map XenPCI <-- GntTbl_Init XenPCI --> EvtChn_Init XenPCI --> _hvm_set_parameter XenPCI HYPERVISOR_hvm_op retval = 0 XenPCI <-- _hvm_set_parameter XenPCI hvm_set_parameter(HVM_PARAM_CALLBACK_IRQ, 28) = 0 XenPCI --> EvtChn_AllocIpi XenPCI <-- EvtChn_AllocIpi XenPCI --> EvtChn_BindDpc XenPCI <-- EvtChn_BindDpc XenPCI pdo_event_channel = 5 XenPCI <-- EvtChn_Init XenPCI <-- XenPci_EvtDeviceD0Entry XenPCI --> EvtChn_EvtInterruptEnable XenPCI <-- EvtChn_EvtInterruptEnable XenPCI --> XenPci_EvtDeviceD0EntryPostInterruptsEnabled XenPCI --> XenBus_Init XenPCI --> _hvm_get_parameter XenPCI HYPERVISOR_hvm_op retval = 0 XenPCI <-- _hvm_get_parameter XenPCI --> _hvm_get_parameter XenPCI HYPERVISOR_hvm_op retval = 0 XenPCI <-- _hvm_get_parameter XenPCI --> EvtChn_BindDpc XenPCI <-- EvtChn_BindDpc XenPCI <-- XenBus_Init XenPCI suspend event channel = 6 XenPCI --> EvtChn_BindDpc XenPCI <-- EvtChn_BindDpc XenPCI --> XenPci_SysrqHandler XenPCI SysRq Value = (null) XenPCI <-- XenPci_SysrqHandler XenPCI --> XenPci_ShutdownHandler XenPCI Initial Memory Value = 512 (524288) Error reading shutdown path - ENOENT XenPCI --> XenPci_BalloonThreadProc XenPCI <-- XenPci_ShutdownHandler XenPCI low_mem_event = 89D79D50, state = 0 XenPCI --> XenPci_DeviceWatchHandler XenPCI <-- XenPci_DeviceWatchHandler XenPCI <-- XenPci_EvtDeviceD0EntryPostInterruptsEnabled XenPCI --> XenPci_EvtChildListScanForChildren XenPCI --> XenPci_BalloonHandler XenPCI Found path = device/vbd/768 XenPCI target memory value = 512 (524288) XenPCI Found path = device/vif/0 XenPCI <-- XenPci_BalloonHandler XenPCI Got balloon event, current = 512, target = 512 XenPCI No change to memory XenPCI <-- XenPci_EvtChildListScanForChildren XenPCI --> XenPci_EvtChildListCreateDevice XenPCI device = 'vbd', index = '768', path = 'device/vbd/768' XenPCI <-- XenPci_EvtChildListCreateDevice XenPCI --> XenPci_EvtChildListCreateDevice XenPCI device = 'vif', index = '0', path = 'device/vif/0' XenPCI <-- XenPci_EvtChildListCreateDevice XenVbd --> DriverEntry XenVbd IRQL = 0 XenVbd DriverObject = 898EB8C0, RegistryPath = 80090C00 XenVbd <-- DriverEntry XenPCI --> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE XenPCI device/vbd/768 XenPCI CmResourceTypeMemory (0) XenPCI Start = f2000000, Length = 0 XenPCI pfn[0] = 0001f322 XenPCI New Start = 000000001f322000, Length = 4096 XenPCI CmResourceTypeMemory (1) XenPCI Start = f2000001, Length = 0 XenPCI <-- XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE XenPCI --> XenPciPdo_EvtDevicePrepareHardware XenPCI <-- XenPciPdo_EvtDevicePrepareHardware XenPCI --> XenPciPdo_EvtDeviceD0Entry XenPCI path = device/vbd/768 XenPCI WdfPowerDeviceD3Final XenPCI --> XenPci_GetBackendAndAddWatch XenPCI <-- XenPci_GetBackendAndAddWatch XenPCI --> XenConfig_InitConfigPage XenPCI fdo_driver_object = 898EB8C0 XenPCI fdo_driver_extension = 89AFC008 XenPCI <-- XenConfig_InitConfigPage XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers XenPCI XEN_INIT_TYPE_RING - ring-ref = 898BD000 XenPCI XEN_INIT_TYPE_RING - ring-ref = 16383 XenPCI XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 7 XenPCI --> XenPci_UpdateBackendState XenPCI --> EvtChn_BindIrq XenPCI <-- EvtChn_BindIrq XenPCI --> XenPci_ChangeFrontendStateMap XenPCI --> XenPci_ChangeFrontendState XenPCI Backend State Changed to InitWait XenPCI <-- XenPci_UpdateBackendState XenPCI --> XenPci_DeviceWatchHandler XenPCI <-- XenPci_DeviceWatchHandler XenPCI --> XenPci_DeviceWatchHandler XenPCI <-- XenPci_DeviceWatchHandler XenPCI --> XenPci_DeviceWatchHandler XenPCI <-- XenPci_DeviceWatchHandler XenPCI --> XenPci_UpdateBackendState XenPCI Backend State Changed to Connected XenPCI <-- XenPci_ChangeFrontendState XenPCI <-- XenPci_ChangeFrontendStateMap XenPCI <-- XenPci_UpdateBackendState XenPCI --> XenPci_ChangeFrontendStateMap XenPCI <-- XenPci_ChangeFrontendStateMap XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers XenPCI <-- XenPciPdo_EvtDeviceD0Entry XenVbd --> XenVbd_HwScsiFindAdapter XenVbd IRQL = 0 XenVbd xvdd = 899B3004 XenVbd BusInterruptLevel = 28 XenVbd BusInterruptVector = 01c XenVbd NumberOfAccessRanges = 1 XenVbd RangeStart = 1f322000, RangeLength = 00001000 XenVbd XEN_INIT_TYPE_VECTORS XenVbd XEN_INIT_TYPE_DEVICE_STATE - 89819D0C XenVbd XEN_INIT_TYPE_RING - ring-ref = 898BD000 XenVbd XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 7 XenVbd XEN_INIT_TYPE_READ_STRING - device-type = disk XenVbd device-type = Disk XenVbd XEN_INIT_TYPE_READ_STRING - mode = w XenVbd mode = w XenVbd XEN_INIT_TYPE_READ_STRING - sectors = 104857600 XenVbd XEN_INIT_TYPE_READ_STRING - sector-size = 512 XenVbd XEN_INIT_TYPE_GRANT_ENTRIES - entries = 11 XenVbd qemu_hide_flags_value = 3 XenVbd aligned_buffer_data = 899B4F78 XenVbd aligned_buffer = 899B5000 XenVbd ConfigInfo->MaximumTransferLength = 45056 XenVbd ConfigInfo->NumberOfPhysicalBreaks = 10 XenVbd ConfigInfo->CachesData was initialised to 0 XenVbd Dma64BitAddresses not supported XenVbd <-- XenVbd_HwScsiFindAdapter XenVbd --> XenVbd_HwScsiInitialize XenVbd IRQL = 9 XenVbd dump_mode = 0 XenVbd <-- XenVbd_HwScsiInitialize XenVbd --> XenVbd_HwScsiAdapterControl XenVbd ring_detect_state = 1, index = 0, operation = ff, id = 0, status = 0 XenVbd req_prod = 2, rsp_prod = 2, rsp_cons = 0 XenVbd ring_detect_state = 2, index = 1, operation = 0, id = ff, status = 0 XenVbd req_prod = 2, rsp_prod = 2, rsp_cons = 0 XenVbd switching to 'other' ring size XenVbd IRQL = 0 XenVbd xvdd = 899B3004 XenVbd ScsiQuerySupportedControlTypes (Max = 5) XenVbd <-- XenVbd_HwScsiAdapterControl XenVbd SRB_FUNCTION_IO_CONTROL XenVbd SCSIOP_MODE_SENSE llbaa = 0, dbd = 0, page_code = 28, allocation_length = 192 XenVbd EXECUTE_SCSI Command = 1A returned error 00 XenVbd SCSIOP_MODE_SENSE llbaa = 0, dbd = 0, page_code = 63, allocation_length = 192 XenVbd SCSIOP_MODE_SENSE llbaa = 0, dbd = 0, page_code = 63, allocation_length = 12 XenNet --> DriverEntry XenNet DriverObject = 89967CE0, RegistryPath = 8996E000 XenNet NdisGetVersion = 50001 XenNet ndis_wrapper_handle = 00000000 XenNet ndis_wrapper_handle = 8984D3E8 XenNet NdisMInitializeWrapper succeeded XenNet MajorNdisVersion = 5, MinorNdisVersion = 1 XenNet about to call NdisMRegisterMiniport XenNet called NdisMRegisterMiniport XenNet <-- DriverEntry XenPCI --> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE XenPCI device/vif/0 XenPCI CmResourceTypeMemory (0) XenPCI Start = f2000000, Length = 0 XenPCI pfn[0] = 0001f2e2 XenPCI New Start = 000000001f2e2000, Length = 4096 XenPCI CmResourceTypeMemory (1) XenPCI Start = f2000001, Length = 0 XenPCI <-- XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE XenPCI --> XenPciPdo_EvtDevicePrepareHardware XenPCI <-- XenPciPdo_EvtDevicePrepareHardware XenPCI --> XenPciPdo_EvtDeviceD0Entry XenPCI path = device/vif/0 XenPCI WdfPowerDeviceD3Final XenPCI --> XenPci_GetBackendAndAddWatch XenPCI <-- XenPci_GetBackendAndAddWatch XenPCI --> XenPci_UpdateBackendState XenPCI --> XenConfig_InitConfigPage XenPCI Backend State Changed to InitWait XenPCI fdo_driver_object = 89967CE0 XenPCI <-- XenPci_UpdateBackendState XenPCI fdo_driver_extension = 00000000 XenPCI fdo_driver_object = 89D68490 XenPCI fdo_driver_extension = 00000000 XenPCI <-- XenConfig_InitConfigPage XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers XenPCI --> XenPci_ChangeFrontendStateMap XenPCI <-- XenPci_ChangeFrontendStateMap XenPCI --> XenPci_ChangeFrontendStateMap XenPCI <-- XenPci_ChangeFrontendStateMap XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers XenPCI <-- XenPciPdo_EvtDeviceD0Entry XenNet --> XenNet_Init XenNet IRQL = 0 XenNet nrl_length = 40 XenNet irq_vector = 01c, irq_level = 01c, irq_mode = NdisInterruptLevelSensitive XenNet XEN_INIT_TYPE_13 XenNet XEN_INIT_TYPE_VECTORS XenNet XEN_INIT_TYPE_DEVICE_STATE - 89818C7C ScatterGather = 1 LargeSendOffload = 61440 ChecksumOffload = 1 ChecksumOffloadRxCheck = 1 MTU = 1500 RxInterruptModeration = 0 Could not read NetworkAddress value (c0000001) or value is invalid XenNet --> XenNet_D0Entry XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers XenPCI XEN_INIT_TYPE_RING - tx-ring-ref = 89A25000 XenPCI XEN_INIT_TYPE_RING - tx-ring-ref = 16222 XenPCI --> XenPci_DeviceWatchHandler XenPCI XEN_INIT_TYPE_RING - rx-ring-ref = 89825000 XenPCI <-- XenPci_DeviceWatchHandler XenPCI XEN_INIT_TYPE_RING - rx-ring-ref = 16189 XenPCI --> XenPci_DeviceWatchHandler XenPCI XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 8 XenPCI <-- XenPci_DeviceWatchHandler XenPCI --> EvtChn_Bind XenPCI --> XenPci_DeviceWatchHandler XenPCI <-- EvtChn_Bind XenPCI <-- XenPci_DeviceWatchHandler XenPCI --> XenPci_DeviceWatchHandler XenPCI <-- XenPci_DeviceWatchHandler XenPCI --> XenPci_DeviceWatchHandler XenPCI <-- XenPci_DeviceWatchHandler XenPCI --> XenPci_DeviceWatchHandler XenPCI <-- XenPci_DeviceWatchHandler XenPCI --> XenPci_ChangeFrontendStateMap XenPCI --> XenPci_DeviceWatchHandler XenPCI <-- XenPci_ChangeFrontendStateMap XenPCI <-- XenPci_DeviceWatchHandler XenPCI --> XenPci_DeviceWatchHandler XenPCI <-- XenPci_DeviceWatchHandler XenPCI --> XenPci_ChangeFrontendStateMap XenPCI --> XenPci_ChangeFrontendState XenPCI --> XenPci_DeviceWatchHandler XenPCI <-- XenPci_DeviceWatchHandler XenPCI --> XenPci_UpdateBackendState XenPCI Backend State Changed to Connected XenPCI <-- XenPci_UpdateBackendState XenPCI <-- XenPci_ChangeFrontendState XenPCI <-- XenPci_ChangeFrontendStateMap XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers XenNet --> XenNet_ConnectBackend XenNet XEN_INIT_TYPE_13 XenNet XEN_INIT_TYPE_VECTORS XenNet XEN_INIT_TYPE_DEVICE_STATE - 89818C7C XenNet XEN_INIT_TYPE_RING - tx-ring-ref = 89A25000 XenNet XEN_INIT_TYPE_RING - rx-ring-ref = 89825000 XenNet XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 8 XenNet XEN_INIT_TYPE_READ_STRING - mac = 00:16:3e:01:b3:c1 XenNet XEN_INIT_TYPE_READ_STRING - feature-sg = 1 XenNet XEN_INIT_TYPE_READ_STRING - feature-gso-tcpv4 = 1 XenNet XEN_INIT_TYPE_17 XenNet <-- XenNet_ConnectBackend XenNet --> XenNet_RxInit XenNet <-- XenNet_RxInit XenNet <-- XenNet_D0Entry Get Unknown OID 0x10202 XenNet --> XenNet_PnPEventNotify XenNet NdisDevicePnPEventPowerProfileChanged XenNet <-- XenNet_PnPEventNotify Get Unknown OID 0x10201 Get Unknown OID 0xfc010210 Get OID_TCP_TASK_OFFLOAD XenNet (BUFFER_TOO_SHORT 100 > 28) Get OID_TCP_TASK_OFFLOAD config_csum enabled nto = 89A4F5F4 nto->Size = 24 nto->TaskBufferLength = 16 config_gso enabled nto = 89A4F618 nto->Size = 24 nto->TaskBufferLength = 16 &(nttls->IpOptions) = 89A4F639 Set OID_TCP_TASK_OFFLOAD TcpIpChecksumNdisTask V4Transmit.IpOptionsSupported = 0 V4Transmit.TcpOptionsSupported = 1 V4Transmit.TcpChecksum = 1 V4Transmit.UdpChecksum = 0 V4Transmit.IpChecksum = 0 V4Receive.IpOptionsSupported = 0 V4Receive.TcpOptionsSupported = 0 V4Receive.TcpChecksum = 1 V4Receive.UdpChecksum = 0 V4Receive.IpChecksum = 0 V6Transmit.IpOptionsSupported = 0 V6Transmit.TcpOptionsSupported = 0 V6Transmit.TcpChecksum = 0 V6Transmit.UdpChecksum = 0 V6Receive.IpOptionsSupported = 0 V6Receive.TcpOptionsSupported = 0 V6Receive.TcpChecksum = 0 V6Receive.UdpChecksum = 0 TcpLargeSendNdisTask MaxOffLoadSize = 61440 MinSegmentCount = 4 TcpOptions = 0 IpOptions = 0 Get OID_PNP_CAPABILITIES Set Unknown OID 0x10119 Set OID_GEN_CURRENT_LOOKAHEAD 128 (89735000) Set OID_GEN_CURRENT_PACKET_FILTER (xi = 89735000) NDIS_PACKET_TYPE_DIRECTED NDIS_PACKET_TYPE_MULTICAST NDIS_PACKET_TYPE_BROADCAST XenNet (BUFFER_TOO_SHORT 152 > 0) Get Unknown OID 0x10117 XenPCI --> XenPci_EvtDeviceUsageNotification XenPCI notification_type = Paging, flag = 1 XenPCI <-- XenPci_EvtDeviceUsageNotification XenPCI --> XenPciPdo_EvtDeviceUsageNotification XenPCI path = device/vbd/768 XenPCI notification_type = Paging, flag = 1 XenPCI <-- XenPciPdo_EvtDeviceUsageNotification XenPCI --> XenPci_EvtDeviceUsageNotification XenPCI notification_type = Dump, flag = 1 XenPCI <-- XenPci_EvtDeviceUsageNotification XenPCI --> XenPciPdo_EvtDeviceUsageNotification XenPCI path = device/vbd/768 XenPCI notification_type = Dump, flag = 1 XenPCI <-- XenPciPdo_EvtDeviceUsageNotification XenPCI --> XenPci_EvtDeviceUsageNotification XenPCI notification_type = Paging, flag = 1 XenPCI <-- XenPci_EvtDeviceUsageNotification XenPCI --> XenPciPdo_EvtDeviceUsageNotification XenPCI path = device/vbd/768 XenPCI notification_type = Paging, flag = 1 XenPCI <-- XenPciPdo_EvtDeviceUsageNotification XenNet (BUFFER_TOO_SHORT 152 > 0) Set OID_802_3_MULTICAST_LIST Length = 6 Entries = 1 Set Unknown OID 0x10118 Set Unknown OID 0xfd010103 Set Unknown OID 0xfd010103 Set OID_802_3_MULTICAST_LIST Length = 12 Entries = 2 Set Unknown OID 0xfd010103 XenVbd --> XenVbd_HwScsiResetBus XenVbd IRQL = 9 XenVbd <-- XenVbd_HwScsiResetBus XenVbd --> XenVbd_HwScsiResetBus XenVbd IRQL = 9 XenVbd <-- XenVbd_HwScsiResetBus XenVbd --> DriverEntry XenVbd IRQL = 31 XenVbd DriverObject = 00000000, RegistryPath = 00000000 XenVbd --> XenVbd_HwScsiFindAdapter XenVbd IRQL = 31 XenVbd xvdd = 892E6300 XenVbd BusInterruptLevel = 28 XenVbd BusInterruptVector = 01c XenVbd NumberOfAccessRanges = 1 XenVbd RangeStart = 1f322000, RangeLength = 00001000 XenVbd XEN_INIT_TYPE_VECTORS XenVbd XEN_INIT_TYPE_DEVICE_STATE - 89819D0C XenVbd XEN_INIT_TYPE_RING - ring-ref = 898BD000 XenVbd XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 7 XenVbd cached_use_other = 1 XenVbd XEN_INIT_TYPE_READ_STRING - device-type = disk XenVbd device-type = Disk XenVbd XEN_INIT_TYPE_READ_STRING - mode = w XenVbd mode = w XenVbd XEN_INIT_TYPE_READ_STRING - sectors = 104857600 XenVbd XEN_INIT_TYPE_READ_STRING - sector-size = 512 XenVbd XEN_INIT_TYPE_GRANT_ENTRIES - entries = 11 XenVbd qemu_hide_flags_value = 3 XenVbd aligned_buffer_data = 892E8274 XenVbd aligned_buffer = 892E9000 XenVbd ConfigInfo->MaximumTransferLength = 4096 XenVbd ConfigInfo->NumberOfPhysicalBreaks = 0 XenVbd ConfigInfo->CachesData was initialised to 0 XenVbd Dma64BitAddresses not supported XenVbd <-- XenVbd_HwScsiFindAdapter XenVbd --> XenVbd_HwScsiInitialize XenVbd IRQL = 31 XenVbd dump_mode = 1 XenVbd <-- XenVbd_HwScsiInitialize XenVbd Command = INQUIRY XenVbd --> XenVbd_HwScsiResetBus XenVbd IRQL = 31 XenVbd <-- XenVbd_HwScsiResetBus XenVbd Command = SCSIOP_START_STOP_UNIT XenVbd Command = READ_CAPACITY XenVbd <-- DriverEntry XenVbd max_dump_mode_blocks = 8 XenVbd max_dump_mode_length = 4096 *** Assertion failed: srb != NULL *** Source File: e:\download\win-pvdrivers.hg\xenvbd\xenvbd_scsiport.c, line 988 XenNet --> XenNet_Shutdown XenNet <-- XenNet_Shutdown XenPCI Bug check 0x0000008E (0x80000003, 0x80878113, 0xBACD0DE8, 0x00000000) [-- Attachment #3: qemu-dm-w3.MR_cp6.vhd.log.crash --] [-- Type: application/octet-stream, Size: 22935 bytes --] domid: 19 Watching /local/domain/0/device-model/19/logdirty/cmd Watching /local/domain/0/device-model/19/command char device redirected to /dev/pts/19 qemu_map_cache_init nr_buckets = 10000 size 4194304 shared page at pfn feffd buffered io page at pfn feffb Guest uuid = 1e2b63e4-7661-648b-3e09-a4bbd073f417 Time offset set 0 populating video RAM at ff000000 mapping video RAM from ff000000 Register xen platform. Done register platform. platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state. xs_read(/local/domain/0/device-model/19/xen_extended_power_mgmt): read error xs_read(): vncpasswd get error. /vm/1e2b63e4-7661-648b-3e09-a4bbd073f417/vncpasswd. Log-dirty: no command yet. I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 xs_read(/local/domain/19/log-throttling): read error qemu: ignoring not-understood drive `/local/domain/19/log-throttling' medium change watch on `/local/domain/19/log-throttling' - unknown device, ignored cirrus vga map change while on lfb mode mapping vram to f0000000 - f0400000 platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state. platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro state. XenPCI <-- XenPci_HighSyncCallFunctionN XenPCI <-- XenPci_HighSyncCallFunction0 XenPCI Waiting for highsync_complete_event XenPCI <-- XenPci_HighSync XenPCI --> XenPci_InitialBalloonDown XenPCI base = 0x40000000, Xen Signature = XenVMMXenVMM, EAX = 0x40000003 XenPCI Hypercall area at 89DB5000 XenPCI XENMEM_maximum_reservation = 525312 XenPCI XENMEM_current_reservation = 131288 XenPCI Trying to give 1540 MB to Xen XenPCI <-- XenPci_InitialBalloonDown XenPCI KeInitializeCrashDumpHeader status = 00000000, size = 4096 XenPCI GPLPV 0.10.0.0 XenPCI --> XenPci_FixLoadOrder XenPCI dummy_group_index = 1 XenPCI wdf_load_group_index = 2 XenPCI xenpci_group_index = 3 XenPCI boot_bus_extender_index = 4 XenPCI <-- XenPci_FixLoadOrder XenPCI Version = 1 Unknown PV product 2 loaded in guest PV driver build 1 XenPCI Disabled qemu devices 03 XenPCI <-- DriverEntry XenPCI Xen PCI device found - must be fdo XenPCI --> XenPci_EvtDeviceAdd_XenPci XenPCI <-- XenPci_EvtDeviceAdd_XenPci XenPCI --> XenPci_EvtDevicePrepareHardware XenPCI IoPort Address(c000) Length: 256 XenPCI Private Data: 0x01 0x00 0x00 XenPCI Memory mapped CSR:(f2000000:0) Length:(16777216) XenPCI Memory flags = 0004 XenPCI Private Data: 0x01 0x01 0x00 XenPCI irq_number = 01c XenPCI irq_vector = 1a3 XenPCI irq_level = 009 XenPCI irq_mode = LevelSensitive XenPCI ShareDisposition = CmResourceShareShared XenPCI <-- XenPci_EvtDevicePrepareHardware XenPCI --> XenPci_EvtDeviceD0Entry XenPCI WdfPowerDeviceD3Final XenPCI --> XenPci_Init XenPCI base = 0x40000000, Xen Signature = XenVMMXenVMM, EAX = 0x40000003 XenPCI Hypercall area at 89B62000 XenPCI shared_info_area_unmapped.QuadPart = f2000000 XenPCI gpfn = f2000 XenPCI hypervisor memory op (XENMAPSPACE_shared_info) ret = 0 XenPCI <-- XenPci_Init XenPCI --> GntTbl_Init XenPCI grant_frames = 32 XenPCI grant_entries = 16384 XenPCI pfn = 9828 XenPCI Calling HYPERVISOR_memory_op - pfn = 9828 XenPCI decreased 1 pages for grant table frame 0 XenPCI pfn = 9829 XenPCI Calling HYPERVISOR_memory_op - pfn = 9829 XenPCI decreased 1 pages for grant table frame 1 XenPCI pfn = 982a XenPCI Calling HYPERVISOR_memory_op - pfn = 982a XenPCI decreased 1 pages for grant table frame 2 XenPCI pfn = 982b XenPCI Calling HYPERVISOR_memory_op - pfn = 982b XenPCI decreased 1 pages for grant table frame 3 XenPCI pfn = 982c XenPCI Calling HYPERVISOR_memory_op - pfn = 982c XenPCI decreased 1 pages for grant table frame 4 XenPCI pfn = 982d XenPCI Calling HYPERVISOR_memory_op - pfn = 982d XenPCI decreased 1 pages for grant table frame 5 XenPCI pfn = 982e XenPCI Calling HYPERVISOR_memory_op - pfn = 982e XenPCI decreased 1 pages for grant table frame 6 XenPCI pfn = 982f XenPCI Calling HYPERVISOR_memory_op - pfn = 982f XenPCI decreased 1 pages for grant table frame 7 XenPCI pfn = 9830 XenPCI Calling HYPERVISOR_memory_op - pfn = 9830 XenPCI decreased 1 pages for grant table frame 8 XenPCI pfn = 9831 XenPCI Calling HYPERVISOR_memory_op - pfn = 9831 XenPCI decreased 1 pages for grant table frame 9 XenPCI pfn = 9832 XenPCI Calling HYPERVISOR_memory_op - pfn = 9832 XenPCI decreased 1 pages for grant table frame 10 XenPCI pfn = 9833 XenPCI Calling HYPERVISOR_memory_op - pfn = 9833 XenPCI decreased 1 pages for grant table frame 11 XenPCI pfn = 9834 XenPCI Calling HYPERVISOR_memory_op - pfn = 9834 XenPCI decreased 1 pages for grant table frame 12 XenPCI pfn = 9835 XenPCI Calling HYPERVISOR_memory_op - pfn = 9835 XenPCI decreased 1 pages for grant table frame 13 XenPCI pfn = 9836 XenPCI Calling HYPERVISOR_memory_op - pfn = 9836 XenPCI decreased 1 pages for grant table frame 14 XenPCI pfn = 9837 XenPCI Calling HYPERVISOR_memory_op - pfn = 9837 XenPCI decreased 1 pages for grant table frame 15 XenPCI pfn = 9838 XenPCI Calling HYPERVISOR_memory_op - pfn = 9838 XenPCI decreased 1 pages for grant table frame 16 XenPCI pfn = 9839 XenPCI Calling HYPERVISOR_memory_op - pfn = 9839 XenPCI decreased 1 pages for grant table frame 17 XenPCI pfn = 983a XenPCI Calling HYPERVISOR_memory_op - pfn = 983a XenPCI decreased 1 pages for grant table frame 18 XenPCI pfn = 983b XenPCI Calling HYPERVISOR_memory_op - pfn = 983b XenPCI decreased 1 pages for grant table frame 19 XenPCI pfn = 983c XenPCI Calling HYPERVISOR_memory_op - pfn = 983c XenPCI decreased 1 pages for grant table frame 20 XenPCI pfn = 983d XenPCI Calling HYPERVISOR_memory_op - pfn = 983d XenPCI decreased 1 pages for grant table frame 21 XenPCI pfn = 983e XenPCI Calling HYPERVISOR_memory_op - pfn = 983e XenPCI decreased 1 pages for grant table frame 22 XenPCI pfn = 983f XenPCI Calling HYPERVISOR_memory_op - pfn = 983f XenPCI decreased 1 pages for grant table frame 23 XenPCI pfn = 9840 XenPCI Calling HYPERVISOR_memory_op - pfn = 9840 XenPCI decreased 1 pages for grant table frame 24 XenPCI pfn = 9841 XenPCI Calling HYPERVISOR_memory_op - pfn = 9841 XenPCI decreased 1 pages for grant table frame 25 XenPCI pfn = 9842 XenPCI Calling HYPERVISOR_memory_op - pfn = 9842 XenPCI decreased 1 pages for grant table frame 26 XenPCI pfn = 9843 XenPCI Calling HYPERVISOR_memory_op - pfn = 9843 XenPCI decreased 1 pages for grant table frame 27 XenPCI pfn = 9844 XenPCI Calling HYPERVISOR_memory_op - pfn = 9844 XenPCI decreased 1 pages for grant table frame 28 XenPCI pfn = 9845 XenPCI Calling HYPERVISOR_memory_op - pfn = 9845 XenPCI decreased 1 pages for grant table frame 29 XenPCI pfn = 9846 XenPCI Calling HYPERVISOR_memory_op - pfn = 9846 XenPCI decreased 1 pages for grant table frame 30 XenPCI pfn = 9847 XenPCI Calling HYPERVISOR_memory_op - pfn = 9847 XenPCI decreased 1 pages for grant table frame 31 XenPCI --> GntTbl_Map XenPCI <-- GntTbl_Map XenPCI <-- GntTbl_Init XenPCI --> EvtChn_Init XenPCI --> _hvm_set_parameter XenPCI HYPERVISOR_hvm_op retval = 0 XenPCI <-- _hvm_set_parameter XenPCI hvm_set_parameter(HVM_PARAM_CALLBACK_IRQ, 28) = 0 XenPCI --> EvtChn_AllocIpi XenPCI <-- EvtChn_AllocIpi XenPCI --> EvtChn_BindDpc XenPCI <-- EvtChn_BindDpc XenPCI pdo_event_channel = 5 XenPCI <-- EvtChn_Init XenPCI <-- XenPci_EvtDeviceD0Entry XenPCI --> EvtChn_EvtInterruptEnable XenPCI <-- EvtChn_EvtInterruptEnable XenPCI --> XenPci_EvtDeviceD0EntryPostInterruptsEnabled XenPCI --> XenBus_Init XenPCI --> _hvm_get_parameter XenPCI HYPERVISOR_hvm_op retval = 0 XenPCI <-- _hvm_get_parameter XenPCI --> _hvm_get_parameter XenPCI HYPERVISOR_hvm_op retval = 0 XenPCI <-- _hvm_get_parameter XenPCI --> EvtChn_BindDpc XenPCI <-- EvtChn_BindDpc XenPCI <-- XenBus_Init XenPCI suspend event channel = 6 XenPCI --> EvtChn_BindDpc XenPCI <-- EvtChn_BindDpc XenPCI --> XenPci_SysrqHandler XenPCI SysRq Value = (null) XenPCI <-- XenPci_SysrqHandler XenPCI --> XenPci_ShutdownHandler Error reading shutdown path - ENOENT XenPCI <-- XenPci_ShutdownHandler XenPCI --> XenPci_DeviceWatchHandler XenPCI <-- XenPci_DeviceWatchHandler XenPCI Initial Memory Value = 512 (524288) XenPCI --> XenPci_BalloonThreadProc XenPCI --> XenPci_BalloonHandler XenPCI low_mem_event = 89D7E030, state = 0 XenPCI <-- XenPci_EvtDeviceD0EntryPostInterruptsEnabled XenPCI --> XenPci_EvtChildListScanForChildren XenPCI target memory value = 512 (524288) XenPCI <-- XenPci_BalloonHandler XenPCI Got balloon event, current = 512, target = 512 XenPCI Found path = device/vbd/768 XenPCI No change to memory XenPCI Found path = device/vif/0 XenPCI <-- XenPci_EvtChildListScanForChildren XenPCI --> XenPci_EvtChildListCreateDevice XenPCI device = 'vbd', index = '768', path = 'device/vbd/768' XenPCI <-- XenPci_EvtChildListCreateDevice XenPCI --> XenPci_EvtChildListCreateDevice XenPCI device = 'vif', index = '0', path = 'device/vif/0' XenPCI <-- XenPci_EvtChildListCreateDevice XenVbd --> DriverEntry XenVbd IRQL = 0 XenVbd DriverObject = 8990AE40, RegistryPath = 80090C00 XenVbd <-- DriverEntry XenPCI --> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE XenPCI device/vbd/768 XenPCI CmResourceTypeMemory (0) XenPCI Start = f2000000, Length = 0 XenPCI pfn[0] = 0001f366 XenPCI New Start = 000000001f366000, Length = 4096 XenPCI CmResourceTypeMemory (1) XenPCI Start = f2000001, Length = 0 XenPCI <-- XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE XenPCI --> XenPciPdo_EvtDevicePrepareHardware XenPCI <-- XenPciPdo_EvtDevicePrepareHardware XenPCI --> XenPciPdo_EvtDeviceD0Entry XenPCI path = device/vbd/768 XenPCI WdfPowerDeviceD3Final XenPCI --> XenPci_GetBackendAndAddWatch XenPCI <-- XenPci_GetBackendAndAddWatch XenPCI --> XenPci_UpdateBackendState XenPCI --> XenConfig_InitConfigPage XenPCI Backend State Changed to InitWait XenPCI fdo_driver_object = 8990AE40 XenPCI <-- XenPci_UpdateBackendState XenPCI fdo_driver_extension = 8990E008 XenPCI <-- XenConfig_InitConfigPage XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers XenPCI XEN_INIT_TYPE_RING - ring-ref = 89B50000 XenPCI XEN_INIT_TYPE_RING - ring-ref = 16383 XenPCI XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 7 XenPCI --> XenPci_DeviceWatchHandler XenPCI <-- XenPci_DeviceWatchHandler XenPCI --> XenPci_DeviceWatchHandler XenPCI <-- XenPci_DeviceWatchHandler XenPCI --> EvtChn_BindIrq XenPCI <-- EvtChn_BindIrq XenPCI --> XenPci_ChangeFrontendStateMap XenPCI --> XenPci_ChangeFrontendState XenPCI --> XenPci_DeviceWatchHandler XenPCI <-- XenPci_DeviceWatchHandler XenPCI --> XenPci_UpdateBackendState XenPCI state unchanged XenPCI --> XenPci_UpdateBackendState XenPCI Still waiting for 4 (currently 2)... XenPCI Backend State Changed to Connected XenPCI <-- XenPci_ChangeFrontendState XenPCI <-- XenPci_UpdateBackendState XenPCI <-- XenPci_ChangeFrontendStateMap XenPCI --> XenPci_ChangeFrontendStateMap XenPCI <-- XenPci_ChangeFrontendStateMap XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers XenPCI <-- XenPciPdo_EvtDeviceD0Entry XenVbd --> XenVbd_HwScsiFindAdapter XenVbd IRQL = 0 XenVbd xvdd = 8980C004 XenVbd BusInterruptLevel = 28 XenVbd BusInterruptVector = 01c XenVbd NumberOfAccessRanges = 1 XenVbd RangeStart = 1f366000, RangeLength = 00001000 XenVbd XEN_INIT_TYPE_VECTORS XenVbd XEN_INIT_TYPE_DEVICE_STATE - 899073CC XenVbd XEN_INIT_TYPE_RING - ring-ref = 89B50000 XenVbd XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 7 XenVbd XEN_INIT_TYPE_READ_STRING - device-type = disk XenVbd device-type = Disk XenVbd XEN_INIT_TYPE_READ_STRING - mode = w XenVbd mode = w XenVbd XEN_INIT_TYPE_READ_STRING - sectors = 104857600 XenVbd XEN_INIT_TYPE_READ_STRING - sector-size = 512 XenVbd XEN_INIT_TYPE_GRANT_ENTRIES - entries = 11 XenVbd qemu_hide_flags_value = 3 XenVbd aligned_buffer_data = 8980DF78 XenVbd aligned_buffer = 8980E000 XenVbd ConfigInfo->MaximumTransferLength = 45056 XenVbd ConfigInfo->NumberOfPhysicalBreaks = 10 XenVbd ConfigInfo->CachesData was initialised to 0 XenVbd Dma64BitAddresses not supported XenVbd <-- XenVbd_HwScsiFindAdapter XenVbd --> XenVbd_HwScsiInitialize XenVbd IRQL = 9 XenVbd dump_mode = 0 XenVbd <-- XenVbd_HwScsiInitialize XenVbd --> XenVbd_HwScsiAdapterControl XenVbd ring_detect_state = 1, index = 0, operation = ff, id = 0, status = 0 XenVbd req_prod = 2, rsp_prod = 2, rsp_cons = 0 XenVbd ring_detect_state = 2, index = 1, operation = 0, id = ff, status = 0 XenVbd req_prod = 2, rsp_prod = 2, rsp_cons = 0 XenVbd switching to 'other' ring size XenVbd IRQL = 0 XenVbd xvdd = 8980C004 XenVbd ScsiQuerySupportedControlTypes (Max = 5) XenVbd <-- XenVbd_HwScsiAdapterControl XenVbd SRB_FUNCTION_IO_CONTROL XenVbd SCSIOP_MODE_SENSE llbaa = 0, dbd = 0, page_code = 28, allocation_length = 192 XenVbd EXECUTE_SCSI Command = 1A returned error 00 XenVbd SCSIOP_MODE_SENSE llbaa = 0, dbd = 0, page_code = 63, allocation_length = 192 XenVbd SCSIOP_MODE_SENSE llbaa = 0, dbd = 0, page_code = 63, allocation_length = 12 XenNet --> DriverEntry XenNet DriverObject = 89A07CA0, RegistryPath = 8976D000 XenNet NdisGetVersion = 50001 XenNet ndis_wrapper_handle = 00000000 XenNet ndis_wrapper_handle = 89A07BF0 XenNet NdisMInitializeWrapper succeeded XenNet MajorNdisVersion = 5, MinorNdisVersion = 1 XenNet about to call NdisMRegisterMiniport XenNet called NdisMRegisterMiniport XenNet <-- DriverEntry XenPCI --> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE XenPCI device/vif/0 XenPCI CmResourceTypeMemory (0) XenPCI Start = f2000000, Length = 0 XenPCI pfn[0] = 0001f326 XenPCI New Start = 000000001f326000, Length = 4096 XenPCI CmResourceTypeMemory (1) XenPCI Start = f2000001, Length = 0 XenPCI <-- XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE XenPCI --> XenPciPdo_EvtDevicePrepareHardware XenPCI <-- XenPciPdo_EvtDevicePrepareHardware XenPCI --> XenPciPdo_EvtDeviceD0Entry XenPCI path = device/vif/0 XenPCI WdfPowerDeviceD3Final XenPCI --> XenPci_GetBackendAndAddWatch XenPCI <-- XenPci_GetBackendAndAddWatch XenPCI --> XenConfig_InitConfigPage XenPCI --> XenPci_UpdateBackendState XenPCI fdo_driver_object = 89A07CA0 XenPCI fdo_driver_extension = 00000000 XenPCI fdo_driver_object = 89D68490 XenPCI Backend State Changed to InitWait XenPCI fdo_driver_extension = 00000000 XenPCI <-- XenPci_UpdateBackendState XenPCI <-- XenConfig_InitConfigPage XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers XenPCI --> XenPci_ChangeFrontendStateMap XenPCI <-- XenPci_ChangeFrontendStateMap XenPCI --> XenPci_ChangeFrontendStateMap XenPCI <-- XenPci_ChangeFrontendStateMap XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers XenPCI <-- XenPciPdo_EvtDeviceD0Entry XenNet --> XenNet_Init XenNet IRQL = 0 XenNet nrl_length = 40 XenNet irq_vector = 01c, irq_level = 01c, irq_mode = NdisInterruptLevelSensitive XenNet XEN_INIT_TYPE_13 XenNet XEN_INIT_TYPE_VECTORS XenNet XEN_INIT_TYPE_DEVICE_STATE - 89906FB4 ScatterGather = 1 LargeSendOffload = 61440 ChecksumOffload = 1 ChecksumOffloadRxCheck = 1 MTU = 1500 RxInterruptModeration = 0 Could not read NetworkAddress value (c0000001) or value is invalid XenNet --> XenNet_D0Entry XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers XenPCI XEN_INIT_TYPE_RING - tx-ring-ref = 89727000 XenPCI XEN_INIT_TYPE_RING - tx-ring-ref = 16130 XenPCI XEN_INIT_TYPE_RING - rx-ring-ref = 899B5000 XenPCI --> XenPci_DeviceWatchHandler XenPCI XEN_INIT_TYPE_RING - rx-ring-ref = 16311 XenPCI <-- XenPci_DeviceWatchHandler XenPCI XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 8 XenPCI --> XenPci_DeviceWatchHandler XenPCI <-- XenPci_DeviceWatchHandler XenPCI --> EvtChn_Bind XenPCI --> XenPci_DeviceWatchHandler XenPCI <-- XenPci_DeviceWatchHandler XenPCI <-- EvtChn_Bind XenPCI --> XenPci_DeviceWatchHandler XenPCI <-- XenPci_DeviceWatchHandler XenPCI --> XenPci_DeviceWatchHandler XenPCI <-- XenPci_DeviceWatchHandler XenPCI --> XenPci_DeviceWatchHandler XenPCI --> XenPci_ChangeFrontendStateMap XenPCI <-- XenPci_DeviceWatchHandler XenPCI <-- XenPci_ChangeFrontendStateMap XenPCI --> XenPci_DeviceWatchHandler XenPCI <-- XenPci_DeviceWatchHandler XenPCI --> XenPci_DeviceWatchHandler XenPCI <-- XenPci_DeviceWatchHandler XenPCI --> XenPci_ChangeFrontendStateMap XenPCI --> XenPci_ChangeFrontendState XenPCI --> XenPci_DeviceWatchHandler XenPCI <-- XenPci_DeviceWatchHandler XenPCI --> XenPci_UpdateBackendState XenPCI Backend State Changed to Connected XenPCI <-- XenPci_UpdateBackendState XenPCI <-- XenPci_ChangeFrontendState XenPCI <-- XenPci_ChangeFrontendStateMap XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers XenNet --> XenNet_ConnectBackend XenNet XEN_INIT_TYPE_13 XenNet XEN_INIT_TYPE_VECTORS XenNet XEN_INIT_TYPE_DEVICE_STATE - 89906FB4 XenNet XEN_INIT_TYPE_RING - tx-ring-ref = 89727000 XenNet XEN_INIT_TYPE_RING - rx-ring-ref = 899B5000 XenNet XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 8 XenNet XEN_INIT_TYPE_READ_STRING - mac = 00:16:3e:37:52:42 XenNet XEN_INIT_TYPE_READ_STRING - feature-sg = 1 XenNet XEN_INIT_TYPE_READ_STRING - feature-gso-tcpv4 = 1 XenNet XEN_INIT_TYPE_17 XenNet <-- XenNet_ConnectBackend XenNet --> XenNet_RxInit XenNet <-- XenNet_RxInit XenNet <-- XenNet_D0Entry Get Unknown OID 0x10202 XenNet --> XenNet_PnPEventNotify XenNet NdisDevicePnPEventPowerProfileChanged XenNet <-- XenNet_PnPEventNotify Get Unknown OID 0x10201 Get Unknown OID 0xfc010210 Get OID_TCP_TASK_OFFLOAD XenNet (BUFFER_TOO_SHORT 100 > 28) Get OID_TCP_TASK_OFFLOAD config_csum enabled nto = 8942B43C nto->Size = 24 nto->TaskBufferLength = 16 config_gso enabled nto = 8942B460 nto->Size = 24 nto->TaskBufferLength = 16 &(nttls->IpOptions) = 8942B481 Set OID_TCP_TASK_OFFLOAD TcpIpChecksumNdisTask V4Transmit.IpOptionsSupported = 0 V4Transmit.TcpOptionsSupported = 1 V4Transmit.TcpChecksum = 1 V4Transmit.UdpChecksum = 0 V4Transmit.IpChecksum = 0 V4Receive.IpOptionsSupported = 0 V4Receive.TcpOptionsSupported = 0 V4Receive.TcpChecksum = 1 V4Receive.UdpChecksum = 0 V4Receive.IpChecksum = 0 V6Transmit.IpOptionsSupported = 0 V6Transmit.TcpOptionsSupported = 0 V6Transmit.TcpChecksum = 0 V6Transmit.UdpChecksum = 0 V6Receive.IpOptionsSupported = 0 V6Receive.TcpOptionsSupported = 0 V6Receive.TcpChecksum = 0 V6Receive.UdpChecksum = 0 TcpLargeSendNdisTask MaxOffLoadSize = 61440 MinSegmentCount = 4 TcpOptions = 0 IpOptions = 0 Get OID_PNP_CAPABILITIES Set Unknown OID 0x10119 Set OID_GEN_CURRENT_LOOKAHEAD 128 (899B6000) Set OID_GEN_CURRENT_PACKET_FILTER (xi = 899B6000) NDIS_PACKET_TYPE_DIRECTED NDIS_PACKET_TYPE_MULTICAST NDIS_PACKET_TYPE_BROADCAST XenNet (BUFFER_TOO_SHORT 152 > 0) Get Unknown OID 0x10117 XenPCI --> XenPci_EvtDeviceUsageNotification XenPCI notification_type = Paging, flag = 1 XenPCI <-- XenPci_EvtDeviceUsageNotification XenPCI --> XenPciPdo_EvtDeviceUsageNotification XenPCI path = device/vbd/768 XenPCI notification_type = Paging, flag = 1 XenPCI <-- XenPciPdo_EvtDeviceUsageNotification XenPCI --> XenPci_EvtDeviceUsageNotification XenPCI notification_type = Dump, flag = 1 XenPCI <-- XenPci_EvtDeviceUsageNotification XenPCI --> XenPciPdo_EvtDeviceUsageNotification XenPCI path = device/vbd/768 XenPCI notification_type = Dump, flag = 1 XenPCI <-- XenPciPdo_EvtDeviceUsageNotification XenPCI --> XenPci_EvtDeviceUsageNotification XenPCI notification_type = Paging, flag = 1 XenPCI <-- XenPci_EvtDeviceUsageNotification XenPCI --> XenPciPdo_EvtDeviceUsageNotification XenPCI path = device/vbd/768 XenPCI notification_type = Paging, flag = 1 XenPCI <-- XenPciPdo_EvtDeviceUsageNotification XenNet (BUFFER_TOO_SHORT 152 > 0) Set OID_802_3_MULTICAST_LIST Length = 6 Entries = 1 Set Unknown OID 0x10118 Set Unknown OID 0xfd010103 Set Unknown OID 0xfd010103 Set OID_802_3_MULTICAST_LIST Length = 12 Entries = 2 Set Unknown OID 0xfd010103 XenVbd --> XenVbd_HwScsiResetBus XenVbd IRQL = 9 XenVbd <-- XenVbd_HwScsiResetBus XenVbd --> XenVbd_HwScsiResetBus XenVbd IRQL = 9 XenVbd <-- XenVbd_HwScsiResetBus XenVbd --> XenVbd_HwScsiResetBus XenVbd IRQL = 9 XenVbd <-- XenVbd_HwScsiResetBus XenVbd --> XenVbd_HwScsiResetBus XenVbd IRQL = 9 XenVbd <-- XenVbd_HwScsiResetBus XenVbd --> XenVbd_HwScsiResetBus XenVbd IRQL = 9 XenVbd <-- XenVbd_HwScsiResetBus XenVbd --> DriverEntry XenVbd IRQL = 31 XenVbd DriverObject = 00000000, RegistryPath = 00000000 XenVbd --> XenVbd_HwScsiFindAdapter XenVbd IRQL = 31 XenVbd xvdd = 892ED300 XenVbd BusInterruptLevel = 28 XenVbd BusInterruptVector = 01c XenVbd NumberOfAccessRanges = 1 XenVbd RangeStart = 1f366000, RangeLength = 00001000 XenVbd XEN_INIT_TYPE_VECTORS XenVbd XEN_INIT_TYPE_DEVICE_STATE - 899073CC XenVbd XEN_INIT_TYPE_RING - ring-ref = 89B50000 XenVbd XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 7 XenVbd cached_use_other = 1 XenVbd XEN_INIT_TYPE_READ_STRING - device-type = disk XenVbd device-type = Disk XenVbd XEN_INIT_TYPE_READ_STRING - mode = w XenVbd mode = w XenVbd XEN_INIT_TYPE_READ_STRING - sectors = 104857600 XenVbd XEN_INIT_TYPE_READ_STRING - sector-size = 512 XenVbd XEN_INIT_TYPE_GRANT_ENTRIES - entries = 11 XenVbd qemu_hide_flags_value = 3 XenVbd aligned_buffer_data = 892EF274 XenVbd aligned_buffer = 892F0000 XenVbd ConfigInfo->MaximumTransferLength = 4096 XenVbd ConfigInfo->NumberOfPhysicalBreaks = 0 XenVbd ConfigInfo->CachesData was initialised to 0 XenVbd Dma64BitAddresses not supported XenVbd <-- XenVbd_HwScsiFindAdapter XenVbd --> XenVbd_HwScsiInitialize XenVbd IRQL = 31 XenVbd dump_mode = 1 XenVbd <-- XenVbd_HwScsiInitialize XenVbd Command = INQUIRY XenVbd --> XenVbd_HwScsiResetBus XenVbd IRQL = 31 XenVbd <-- XenVbd_HwScsiResetBus XenVbd Command = SCSIOP_START_STOP_UNIT XenVbd Command = READ_CAPACITY XenVbd <-- DriverEntry XenVbd max_dump_mode_blocks = 8 XenVbd max_dump_mode_length = 4096 XenVbd max_dump_mode_blocks = 64 XenVbd max_dump_mode_length = 32768 [-- Attachment #4: qemu-dm-w3.MR_cp7.vhd.log.normal --] [-- Type: application/octet-stream, Size: 21023 bytes --] domid: 22 Watching /local/domain/0/device-model/22/logdirty/cmd Watching /local/domain/0/device-model/22/command char device redirected to /dev/pts/22 qemu_map_cache_init nr_buckets = 10000 size 4194304 shared page at pfn feffd buffered io page at pfn feffb Guest uuid = bb37852d-eeeb-c898-adfc-b2aff2631540 Time offset set 0 populating video RAM at ff000000 mapping video RAM from ff000000 Register xen platform. Done register platform. platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state. xs_read(/local/domain/0/device-model/22/xen_extended_power_mgmt): read error xs_read(): vncpasswd get error. /vm/bb37852d-eeeb-c898-adfc-b2aff2631540/vncpasswd. Log-dirty: no command yet. I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 xs_read(/local/domain/22/log-throttling): read error qemu: ignoring not-understood drive `/local/domain/22/log-throttling' medium change watch on `/local/domain/22/log-throttling' - unknown device, ignored cirrus vga map change while on lfb mode mapping vram to f0000000 - f0400000 platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state. platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro state. XenPCI <-- XenPci_HighSyncCallFunctionN XenPCI <-- XenPci_HighSyncCallFunction0 XenPCI Waiting for highsync_complete_event XenPCI <-- XenPci_HighSync XenPCI --> XenPci_InitialBalloonDown XenPCI base = 0x40000000, Xen Signature = XenVMMXenVMM, EAX = 0x40000003 XenPCI Hypercall area at 89DB5000 XenPCI XENMEM_maximum_reservation = 525312 XenPCI XENMEM_current_reservation = 131288 XenPCI Trying to give 1540 MB to Xen XenPCI <-- XenPci_InitialBalloonDown XenPCI KeInitializeCrashDumpHeader status = 00000000, size = 4096 XenPCI GPLPV 0.10.0.0 XenPCI --> XenPci_FixLoadOrder XenPCI dummy_group_index = 1 XenPCI wdf_load_group_index = 2 XenPCI xenpci_group_index = 3 XenPCI boot_bus_extender_index = 4 XenPCI <-- XenPci_FixLoadOrder XenPCI Version = 1 Unknown PV product 2 loaded in guest PV driver build 1 XenPCI Disabled qemu devices 03 XenPCI <-- DriverEntry XenPCI Xen PCI device found - must be fdo XenPCI --> XenPci_EvtDeviceAdd_XenPci XenPCI <-- XenPci_EvtDeviceAdd_XenPci XenPCI --> XenPci_EvtDevicePrepareHardware XenPCI IoPort Address(c000) Length: 256 XenPCI Private Data: 0x01 0x00 0x00 XenPCI Memory mapped CSR:(f2000000:0) Length:(16777216) XenPCI Memory flags = 0004 XenPCI Private Data: 0x01 0x01 0x00 XenPCI irq_number = 01c XenPCI irq_vector = 1a3 XenPCI irq_level = 009 XenPCI irq_mode = LevelSensitive XenPCI ShareDisposition = CmResourceShareShared XenPCI <-- XenPci_EvtDevicePrepareHardware XenPCI --> XenPci_EvtDeviceD0Entry XenPCI WdfPowerDeviceD3Final XenPCI --> XenPci_Init XenPCI base = 0x40000000, Xen Signature = XenVMMXenVMM, EAX = 0x40000003 XenPCI Hypercall area at 89B62000 XenPCI shared_info_area_unmapped.QuadPart = f2000000 XenPCI gpfn = f2000 XenPCI hypervisor memory op (XENMAPSPACE_shared_info) ret = 0 XenPCI <-- XenPci_Init XenPCI --> GntTbl_Init XenPCI grant_frames = 32 XenPCI grant_entries = 16384 XenPCI pfn = 99ff XenPCI Calling HYPERVISOR_memory_op - pfn = 99ff XenPCI decreased 1 pages for grant table frame 0 XenPCI pfn = 9a00 XenPCI Calling HYPERVISOR_memory_op - pfn = 9a00 XenPCI decreased 1 pages for grant table frame 1 XenPCI pfn = 9a01 XenPCI Calling HYPERVISOR_memory_op - pfn = 9a01 XenPCI decreased 1 pages for grant table frame 2 XenPCI pfn = 9a02 XenPCI Calling HYPERVISOR_memory_op - pfn = 9a02 XenPCI decreased 1 pages for grant table frame 3 XenPCI pfn = 9a03 XenPCI Calling HYPERVISOR_memory_op - pfn = 9a03 XenPCI decreased 1 pages for grant table frame 4 XenPCI pfn = 9a04 XenPCI Calling HYPERVISOR_memory_op - pfn = 9a04 XenPCI decreased 1 pages for grant table frame 5 XenPCI pfn = 9a05 XenPCI Calling HYPERVISOR_memory_op - pfn = 9a05 XenPCI decreased 1 pages for grant table frame 6 XenPCI pfn = 9a06 XenPCI Calling HYPERVISOR_memory_op - pfn = 9a06 XenPCI decreased 1 pages for grant table frame 7 XenPCI pfn = 9a07 XenPCI Calling HYPERVISOR_memory_op - pfn = 9a07 XenPCI decreased 1 pages for grant table frame 8 XenPCI pfn = 9a08 XenPCI Calling HYPERVISOR_memory_op - pfn = 9a08 XenPCI decreased 1 pages for grant table frame 9 XenPCI pfn = 9a09 XenPCI Calling HYPERVISOR_memory_op - pfn = 9a09 XenPCI decreased 1 pages for grant table frame 10 XenPCI pfn = 9a0a XenPCI Calling HYPERVISOR_memory_op - pfn = 9a0a XenPCI decreased 1 pages for grant table frame 11 XenPCI pfn = 9a0b XenPCI Calling HYPERVISOR_memory_op - pfn = 9a0b XenPCI decreased 1 pages for grant table frame 12 XenPCI pfn = 9a0c XenPCI Calling HYPERVISOR_memory_op - pfn = 9a0c XenPCI decreased 1 pages for grant table frame 13 XenPCI pfn = 9a0d XenPCI Calling HYPERVISOR_memory_op - pfn = 9a0d XenPCI decreased 1 pages for grant table frame 14 XenPCI pfn = 9a0e XenPCI Calling HYPERVISOR_memory_op - pfn = 9a0e XenPCI decreased 1 pages for grant table frame 15 XenPCI pfn = 9a0f XenPCI Calling HYPERVISOR_memory_op - pfn = 9a0f XenPCI decreased 1 pages for grant table frame 16 XenPCI pfn = 9a10 XenPCI Calling HYPERVISOR_memory_op - pfn = 9a10 XenPCI decreased 1 pages for grant table frame 17 XenPCI pfn = 9a11 XenPCI Calling HYPERVISOR_memory_op - pfn = 9a11 XenPCI decreased 1 pages for grant table frame 18 XenPCI pfn = 9a12 XenPCI Calling HYPERVISOR_memory_op - pfn = 9a12 XenPCI decreased 1 pages for grant table frame 19 XenPCI pfn = 9a13 XenPCI Calling HYPERVISOR_memory_op - pfn = 9a13 XenPCI decreased 1 pages for grant table frame 20 XenPCI pfn = 9a14 XenPCI Calling HYPERVISOR_memory_op - pfn = 9a14 XenPCI decreased 1 pages for grant table frame 21 XenPCI pfn = 9a15 XenPCI Calling HYPERVISOR_memory_op - pfn = 9a15 XenPCI decreased 1 pages for grant table frame 22 XenPCI pfn = 9a16 XenPCI Calling HYPERVISOR_memory_op - pfn = 9a16 XenPCI decreased 1 pages for grant table frame 23 XenPCI pfn = 9a17 XenPCI Calling HYPERVISOR_memory_op - pfn = 9a17 XenPCI decreased 1 pages for grant table frame 24 XenPCI pfn = 9a18 XenPCI Calling HYPERVISOR_memory_op - pfn = 9a18 XenPCI decreased 1 pages for grant table frame 25 XenPCI pfn = 9a19 XenPCI Calling HYPERVISOR_memory_op - pfn = 9a19 XenPCI decreased 1 pages for grant table frame 26 XenPCI pfn = 9a1a XenPCI Calling HYPERVISOR_memory_op - pfn = 9a1a XenPCI decreased 1 pages for grant table frame 27 XenPCI pfn = 9a1b XenPCI Calling HYPERVISOR_memory_op - pfn = 9a1b XenPCI decreased 1 pages for grant table frame 28 XenPCI pfn = 9a1c XenPCI Calling HYPERVISOR_memory_op - pfn = 9a1c XenPCI decreased 1 pages for grant table frame 29 XenPCI pfn = 9a1d XenPCI Calling HYPERVISOR_memory_op - pfn = 9a1d XenPCI decreased 1 pages for grant table frame 30 XenPCI pfn = 9a1e XenPCI Calling HYPERVISOR_memory_op - pfn = 9a1e XenPCI decreased 1 pages for grant table frame 31 XenPCI --> GntTbl_Map XenPCI <-- GntTbl_Map XenPCI <-- GntTbl_Init XenPCI --> EvtChn_Init XenPCI --> _hvm_set_parameter XenPCI HYPERVISOR_hvm_op retval = 0 XenPCI <-- _hvm_set_parameter XenPCI hvm_set_parameter(HVM_PARAM_CALLBACK_IRQ, 28) = 0 XenPCI --> EvtChn_AllocIpi XenPCI <-- EvtChn_AllocIpi XenPCI --> EvtChn_BindDpc XenPCI <-- EvtChn_BindDpc XenPCI pdo_event_channel = 5 XenPCI <-- EvtChn_Init XenPCI <-- XenPci_EvtDeviceD0Entry XenPCI --> EvtChn_EvtInterruptEnable XenPCI <-- EvtChn_EvtInterruptEnable XenPCI --> XenPci_EvtDeviceD0EntryPostInterruptsEnabled XenPCI --> XenBus_Init XenPCI --> _hvm_get_parameter XenPCI HYPERVISOR_hvm_op retval = 0 XenPCI <-- _hvm_get_parameter XenPCI --> _hvm_get_parameter XenPCI HYPERVISOR_hvm_op retval = 0 XenPCI <-- _hvm_get_parameter XenPCI --> EvtChn_BindDpc XenPCI <-- EvtChn_BindDpc XenPCI <-- XenBus_Init XenPCI suspend event channel = 6 XenPCI --> EvtChn_BindDpc XenPCI <-- EvtChn_BindDpc XenPCI --> XenPci_SysrqHandler XenPCI SysRq Value = (null) XenPCI <-- XenPci_SysrqHandler XenPCI --> XenPci_ShutdownHandler Error reading shutdown path - ENOENT XenPCI <-- XenPci_ShutdownHandler XenPCI --> XenPci_DeviceWatchHandler XenPCI Initial Memory Value = 512 (524288) XenPCI <-- XenPci_DeviceWatchHandler XenPCI --> XenPci_BalloonThreadProc XenPCI low_mem_event = 89D82350, state = 0 XenPCI --> XenPci_BalloonHandler XenPCI <-- XenPci_EvtDeviceD0EntryPostInterruptsEnabled XenPCI --> XenPci_EvtChildListScanForChildren XenPCI target memory value = 512 (524288) XenPCI <-- XenPci_BalloonHandler XenPCI Got balloon event, current = 512, target = 512 XenPCI Found path = device/vbd/768 XenPCI No change to memory XenPCI Found path = device/vif/0 XenPCI <-- XenPci_EvtChildListScanForChildren XenPCI --> XenPci_EvtChildListCreateDevice XenPCI device = 'vbd', index = '768', path = 'device/vbd/768' XenPCI <-- XenPci_EvtChildListCreateDevice XenPCI --> XenPci_EvtChildListCreateDevice XenPCI device = 'vif', index = '0', path = 'device/vif/0' XenPCI <-- XenPci_EvtChildListCreateDevice XenVbd --> DriverEntry XenVbd IRQL = 0 XenVbd DriverObject = 898C4DB8, RegistryPath = 80090C00 XenVbd <-- DriverEntry XenPCI --> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE XenPCI device/vbd/768 XenPCI CmResourceTypeMemory (0) XenPCI Start = f2000000, Length = 0 XenPCI pfn[0] = 0001f361 XenPCI New Start = 000000001f361000, Length = 4096 XenPCI CmResourceTypeMemory (1) XenPCI Start = f2000001, Length = 0 XenPCI <-- XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE XenPCI --> XenPciPdo_EvtDevicePrepareHardware XenPCI <-- XenPciPdo_EvtDevicePrepareHardware XenPCI --> XenPciPdo_EvtDeviceD0Entry XenPCI path = device/vbd/768 XenPCI WdfPowerDeviceD3Final XenPCI --> XenPci_GetBackendAndAddWatch XenPCI --> XenPci_UpdateBackendState XenPCI <-- XenPci_GetBackendAndAddWatch XenPCI --> XenConfig_InitConfigPage XenPCI fdo_driver_object = 898C4DB8 XenPCI fdo_driver_extension = 89AD9008 XenPCI <-- XenConfig_InitConfigPage XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers XenPCI XEN_INIT_TYPE_RING - ring-ref = 89A9C000 XenPCI XEN_INIT_TYPE_RING - ring-ref = 16383 XenPCI Backend State Changed to InitWait XenPCI <-- XenPci_UpdateBackendState XenPCI --> XenPci_DeviceWatchHandler XenPCI XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 7 XenPCI <-- XenPci_DeviceWatchHandler XenPCI --> EvtChn_BindIrq XenPCI --> XenPci_DeviceWatchHandler XenPCI <-- EvtChn_BindIrq XenPCI <-- XenPci_DeviceWatchHandler XenPCI --> XenPci_ChangeFrontendStateMap XenPCI --> XenPci_ChangeFrontendState XenPCI --> XenPci_DeviceWatchHandler XenPCI <-- XenPci_DeviceWatchHandler XenPCI --> XenPci_UpdateBackendState XenPCI state unchanged XenPCI --> XenPci_UpdateBackendState XenPCI Still waiting for 4 (currently 2)... XenPCI Backend State Changed to Connected XenPCI <-- XenPci_UpdateBackendState XenPCI <-- XenPci_ChangeFrontendState XenPCI <-- XenPci_ChangeFrontendStateMap XenPCI --> XenPci_ChangeFrontendStateMap XenPCI <-- XenPci_ChangeFrontendStateMap XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers XenPCI <-- XenPciPdo_EvtDeviceD0Entry XenVbd --> XenVbd_HwScsiFindAdapter XenVbd IRQL = 0 XenVbd xvdd = 898B6004 XenVbd BusInterruptLevel = 28 XenVbd BusInterruptVector = 01c XenVbd NumberOfAccessRanges = 1 XenVbd RangeStart = 1f361000, RangeLength = 00001000 XenVbd XEN_INIT_TYPE_VECTORS XenVbd XEN_INIT_TYPE_DEVICE_STATE - 899ECFB4 XenVbd XEN_INIT_TYPE_RING - ring-ref = 89A9C000 XenVbd XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 7 XenVbd XEN_INIT_TYPE_READ_STRING - device-type = disk XenVbd device-type = Disk XenVbd XEN_INIT_TYPE_READ_STRING - mode = w XenVbd mode = w XenVbd XEN_INIT_TYPE_READ_STRING - sectors = 104857600 XenVbd XEN_INIT_TYPE_READ_STRING - sector-size = 512 XenVbd XEN_INIT_TYPE_GRANT_ENTRIES - entries = 11 XenVbd qemu_hide_flags_value = 3 XenVbd aligned_buffer_data = 898B7F78 XenVbd aligned_buffer = 898B8000 XenVbd ConfigInfo->MaximumTransferLength = 45056 XenVbd ConfigInfo->NumberOfPhysicalBreaks = 10 XenVbd ConfigInfo->CachesData was initialised to 0 XenVbd Dma64BitAddresses not supported XenVbd <-- XenVbd_HwScsiFindAdapter XenVbd --> XenVbd_HwScsiInitialize XenVbd IRQL = 9 XenVbd dump_mode = 0 XenVbd <-- XenVbd_HwScsiInitialize XenVbd --> XenVbd_HwScsiAdapterControl XenVbd ring_detect_state = 1, index = 0, operation = ff, id = 0, status = 0 XenVbd req_prod = 2, rsp_prod = 2, rsp_cons = 0 XenVbd ring_detect_state = 2, index = 1, operation = 0, id = ff, status = 0 XenVbd req_prod = 2, rsp_prod = 2, rsp_cons = 0 XenVbd switching to 'other' ring size XenVbd IRQL = 0 XenVbd xvdd = 898B6004 XenVbd ScsiQuerySupportedControlTypes (Max = 5) XenVbd <-- XenVbd_HwScsiAdapterControl XenVbd SRB_FUNCTION_IO_CONTROL XenVbd SCSIOP_MODE_SENSE llbaa = 0, dbd = 0, page_code = 28, allocation_length = 192 XenVbd EXECUTE_SCSI Command = 1A returned error 00 XenVbd SCSIOP_MODE_SENSE llbaa = 0, dbd = 0, page_code = 63, allocation_length = 192 XenVbd SCSIOP_MODE_SENSE llbaa = 0, dbd = 0, page_code = 63, allocation_length = 12 XenNet --> DriverEntry XenNet DriverObject = 8992A278, RegistryPath = 897DB000 XenNet NdisGetVersion = 50001 XenNet ndis_wrapper_handle = 00000000 XenNet ndis_wrapper_handle = 8982F9C8 XenNet NdisMInitializeWrapper succeeded XenNet MajorNdisVersion = 5, MinorNdisVersion = 1 XenNet about to call NdisMRegisterMiniport XenNet called NdisMRegisterMiniport XenNet <-- DriverEntry XenPCI --> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE XenPCI device/vif/0 XenPCI CmResourceTypeMemory (0) XenPCI Start = f2000000, Length = 0 XenPCI pfn[0] = 0001f321 XenPCI New Start = 000000001f321000, Length = 4096 XenPCI CmResourceTypeMemory (1) XenPCI Start = f2000001, Length = 0 XenPCI <-- XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE XenPCI --> XenPciPdo_EvtDevicePrepareHardware XenPCI <-- XenPciPdo_EvtDevicePrepareHardware XenPCI --> XenPciPdo_EvtDeviceD0Entry XenPCI path = device/vif/0 XenPCI WdfPowerDeviceD3Final XenPCI --> XenPci_GetBackendAndAddWatch XenPCI <-- XenPci_GetBackendAndAddWatch XenPCI --> XenConfig_InitConfigPage XenPCI fdo_driver_object = 8992A278 XenPCI --> XenPci_UpdateBackendState XenPCI fdo_driver_extension = 00000000 XenPCI fdo_driver_object = 89D68490 XenPCI Backend State Changed to InitWait XenPCI fdo_driver_extension = 00000000 XenPCI <-- XenPci_UpdateBackendState XenPCI <-- XenConfig_InitConfigPage XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers XenPCI --> XenPci_ChangeFrontendStateMap XenPCI <-- XenPci_ChangeFrontendStateMap XenPCI --> XenPci_ChangeFrontendStateMap XenPCI <-- XenPci_ChangeFrontendStateMap XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers XenPCI <-- XenPciPdo_EvtDeviceD0Entry XenNet --> XenNet_Init XenNet IRQL = 0 XenNet nrl_length = 40 XenNet irq_vector = 01c, irq_level = 01c, irq_mode = NdisInterruptLevelSensitive XenNet XEN_INIT_TYPE_13 XenNet XEN_INIT_TYPE_VECTORS XenNet XEN_INIT_TYPE_DEVICE_STATE - 898C6DDC ScatterGather = 1 LargeSendOffload = 61440 ChecksumOffload = 1 ChecksumOffloadRxCheck = 1 MTU = 1500 RxInterruptModeration = 0 Could not read NetworkAddress value (c0000001) or value is invalid XenNet --> XenNet_D0Entry XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers XenPCI XEN_INIT_TYPE_RING - tx-ring-ref = 897BE000 XenPCI XEN_INIT_TYPE_RING - tx-ring-ref = 16316 XenPCI --> XenPci_DeviceWatchHandler XenPCI <-- XenPci_DeviceWatchHandler XenPCI XEN_INIT_TYPE_RING - rx-ring-ref = 897BD000 XenPCI XEN_INIT_TYPE_RING - rx-ring-ref = 16122 XenPCI --> XenPci_DeviceWatchHandler XenPCI XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 8 XenPCI <-- XenPci_DeviceWatchHandler XenPCI --> XenPci_DeviceWatchHandler XenPCI <-- XenPci_DeviceWatchHandler XenPCI --> EvtChn_Bind XenPCI <-- EvtChn_Bind XenPCI --> XenPci_DeviceWatchHandler XenPCI <-- XenPci_DeviceWatchHandler XenPCI --> XenPci_DeviceWatchHandler XenPCI <-- XenPci_DeviceWatchHandler XenPCI --> XenPci_DeviceWatchHandler XenPCI <-- XenPci_DeviceWatchHandler XenPCI --> XenPci_DeviceWatchHandler XenPCI <-- XenPci_DeviceWatchHandler XenPCI --> XenPci_DeviceWatchHandler XenPCI <-- XenPci_DeviceWatchHandler XenPCI --> XenPci_ChangeFrontendStateMap XenPCI <-- XenPci_ChangeFrontendStateMap XenPCI --> XenPci_ChangeFrontendStateMap XenPCI --> XenPci_ChangeFrontendState XenPCI --> XenPci_DeviceWatchHandler XenPCI <-- XenPci_DeviceWatchHandler XenPCI --> XenPci_UpdateBackendState XenPCI Backend State Changed to Connected XenPCI <-- XenPci_UpdateBackendState XenPCI <-- XenPci_ChangeFrontendState XenPCI <-- XenPci_ChangeFrontendStateMap XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers XenNet --> XenNet_ConnectBackend XenNet XEN_INIT_TYPE_13 XenNet XEN_INIT_TYPE_VECTORS XenNet XEN_INIT_TYPE_DEVICE_STATE - 898C6DDC XenNet XEN_INIT_TYPE_RING - tx-ring-ref = 897BE000 XenNet XEN_INIT_TYPE_RING - rx-ring-ref = 897BD000 XenNet XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 8 XenNet XEN_INIT_TYPE_READ_STRING - mac = 00:16:3e:26:45:46 XenNet XEN_INIT_TYPE_READ_STRING - feature-sg = 1 XenNet XEN_INIT_TYPE_READ_STRING - feature-gso-tcpv4 = 1 XenNet XEN_INIT_TYPE_17 XenNet <-- XenNet_ConnectBackend XenNet --> XenNet_RxInit XenNet <-- XenNet_RxInit XenNet <-- XenNet_D0Entry Get Unknown OID 0x10202 XenNet --> XenNet_PnPEventNotify XenNet NdisDevicePnPEventPowerProfileChanged XenNet <-- XenNet_PnPEventNotify Get Unknown OID 0x10201 Get Unknown OID 0xfc010210 Get OID_TCP_TASK_OFFLOAD XenNet (BUFFER_TOO_SHORT 100 > 28) Get OID_TCP_TASK_OFFLOAD config_csum enabled nto = 894258C4 nto->Size = 24 nto->TaskBufferLength = 16 config_gso enabled nto = 894258E8 nto->Size = 24 nto->TaskBufferLength = 16 &(nttls->IpOptions) = 89425909 Set OID_TCP_TASK_OFFLOAD TcpIpChecksumNdisTask V4Transmit.IpOptionsSupported = 0 V4Transmit.TcpOptionsSupported = 1 V4Transmit.TcpChecksum = 1 V4Transmit.UdpChecksum = 0 V4Transmit.IpChecksum = 0 V4Receive.IpOptionsSupported = 0 V4Receive.TcpOptionsSupported = 0 V4Receive.TcpChecksum = 1 V4Receive.UdpChecksum = 0 V4Receive.IpChecksum = 0 V6Transmit.IpOptionsSupported = 0 V6Transmit.TcpOptionsSupported = 0 V6Transmit.TcpChecksum = 0 V6Transmit.UdpChecksum = 0 V6Receive.IpOptionsSupported = 0 V6Receive.TcpOptionsSupported = 0 V6Receive.TcpChecksum = 0 V6Receive.UdpChecksum = 0 TcpLargeSendNdisTask MaxOffLoadSize = 61440 MinSegmentCount = 4 TcpOptions = 0 IpOptions = 0 Get OID_PNP_CAPABILITIES Set Unknown OID 0x10119 Set OID_GEN_CURRENT_LOOKAHEAD 128 (897BF000) Set OID_GEN_CURRENT_PACKET_FILTER (xi = 897BF000) NDIS_PACKET_TYPE_DIRECTED NDIS_PACKET_TYPE_MULTICAST NDIS_PACKET_TYPE_BROADCAST XenNet (BUFFER_TOO_SHORT 152 > 0) Get Unknown OID 0x10117 XenPCI --> XenPci_EvtDeviceUsageNotification XenPCI notification_type = Paging, flag = 1 XenPCI <-- XenPci_EvtDeviceUsageNotification XenPCI --> XenPciPdo_EvtDeviceUsageNotification XenPCI path = device/vbd/768 XenPCI notification_type = Paging, flag = 1 XenPCI <-- XenPciPdo_EvtDeviceUsageNotification XenPCI --> XenPci_EvtDeviceUsageNotification XenPCI notification_type = Dump, flag = 1 XenPCI <-- XenPci_EvtDeviceUsageNotification XenPCI --> XenPciPdo_EvtDeviceUsageNotification XenPCI path = device/vbd/768 XenPCI notification_type = Dump, flag = 1 XenPCI <-- XenPciPdo_EvtDeviceUsageNotification XenPCI --> XenPci_EvtDeviceUsageNotification XenPCI notification_type = Paging, flag = 1 XenPCI <-- XenPci_EvtDeviceUsageNotification XenPCI --> XenPciPdo_EvtDeviceUsageNotification XenPCI path = device/vbd/768 XenPCI notification_type = Paging, flag = 1 XenPCI <-- XenPciPdo_EvtDeviceUsageNotification XenNet (BUFFER_TOO_SHORT 152 > 0) Set OID_802_3_MULTICAST_LIST Length = 6 Entries = 1 Set Unknown OID 0x10118 Set Unknown OID 0xfd010103 Set Unknown OID 0xfd010103 Set OID_802_3_MULTICAST_LIST Length = 12 Entries = 2 Set Unknown OID 0xfd010103 XenVbd --> XenVbd_HwScsiResetBus XenVbd IRQL = 9 XenVbd <-- XenVbd_HwScsiResetBus XenVbd --> XenVbd_HwScsiResetBus XenVbd IRQL = 9 XenVbd <-- XenVbd_HwScsiResetBus XenVbd --> XenVbd_HwScsiResetBus XenVbd IRQL = 9 XenVbd <-- XenVbd_HwScsiResetBus [-- Attachment #5: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: blue screen in windows balloon driver 2011-03-01 7:14 ` MaoXiaoyun @ 2011-03-01 9:36 ` James Harper [not found] ` <AEC6C66638C05B468B556EA548C1A77D01C55AC5@trantor> 1 sibling, 0 replies; 26+ messages in thread From: James Harper @ 2011-03-01 9:36 UTC (permalink / raw) To: MaoXiaoyun, xen devel > Attached are three logs. (I started test PV in debug mode) > > qemu-dm-w3.MR_cp7.vhd.log.normal: > is the VM not crash > > > qemu-dm-w3.MR_cp23.vhd.log.crash: > is the vm crashed, but the log show a Assertion failed. > *** Assertion failed: srb != NULL > *** Source File: e:\download\win-pvdrivers.hg\xenvbd\xenvbd_scsiport.c, line > 988 > Blue screen on "NO_PAGES_AVAILABLE" > ***STOP: 0x0000004D (0x0001566c,0x0001566c,0x00000000,0x00000000) > > > qemu-dm-w3.MR_cp6.vhd.log.crash: is the vm crashed, bug no special error in > log > Blue screen on "NO_PAGES_AVAILABLE" > ***STOP: 0x0000004D (0x0001590f,0x0001590f,0x00000000,0x00000000) > I have checked both your bug checks. Both of them have some scsi resets just before the crash, eg: XenVbd --> XenVbd_HwScsiResetBus XenVbd IRQL = 9 XenVbd <-- XenVbd_HwScsiResetBus XenVbd --> XenVbd_HwScsiResetBus XenVbd IRQL = 9 XenVbd <-- XenVbd_HwScsiResetBus So I'm wondering if xenvbd is stuck. If that happened, Windows would be able to write out to the pagefile, which is more in line with the documentation of Bug Check 0x4D. James ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <AEC6C66638C05B468B556EA548C1A77D01C55AC5@trantor>]
* RE: blue screen in windows balloon driver [not found] ` <AEC6C66638C05B468B556EA548C1A77D01C55AC5@trantor> @ 2011-03-01 9:51 ` MaoXiaoyun 2011-03-01 9:54 ` James Harper 0 siblings, 1 reply; 26+ messages in thread From: MaoXiaoyun @ 2011-03-01 9:51 UTC (permalink / raw) To: xen devel; +Cc: james.harper [-- Attachment #1.1: Type: text/plain, Size: 9169 bytes --] I am testing windows 2003, and the pvdriver msi is build in XP env. Well, I check all other not crashed VMS, all of them has the XenVbd_HwScsiResetBus. What does this mean? Is it reasonable. I will run the debug mode pv on the other two physical to see if the log exists. (Since not blue srceen ever happen on those two hosts). Also, how to check whether xenvbd is stuck? many thanks. > Subject: RE: blue screen in windows balloon driver > Date: Tue, 1 Mar 2011 20:41:18 +1100 > From: james.harper@bendigoit.com.au > To: tinnycloud@hotmail.com > > Are you testing under Windows 2008? > > When you build the drivers under the windows 2008 build environment, you > should get a storport xenvbd driver, not a scsiport xenvbd driver, but > in your logs I see scsiport. > > This shouldn't affect the crash we are seeing though. > > James > > > -----Original Message----- > > From: MaoXiaoyun [mailto:tinnycloud@hotmail.com] > > Sent: Tuesday, 1 March 2011 18:14 > > To: xen devel > > Cc: James Harper > > Subject: RE: blue screen in windows balloon driver > > > > Hi James: > > > > Attached are three logs. (I started test PV in debug mode) > > > > qemu-dm-w3.MR_cp7.vhd.log.normal: > > is the VM not crash > > > > > > qemu-dm-w3.MR_cp23.vhd.log.crash: > > is the vm crashed, but the log show a Assertion failed. > > *** Assertion failed: srb != NULL > > *** Source File: > e:\download\win-pvdrivers.hg\xenvbd\xenvbd_scsiport.c, line > > 988 > > Blue screen on "NO_PAGES_AVAILABLE" > > ***STOP: 0x0000004D (0x0001566c,0x0001566c,0x00000000,0x00000000) > > > > > > qemu-dm-w3.MR_cp6.vhd.log.crash: is the vm crashed, bug no special > error in > > log > > Blue screen on "NO_PAGES_AVAILABLE" > > ***STOP: 0x0000004D (0x0001590f,0x0001590f,0x00000000,0x00000000) > > > > thanks. > > > > > Subject: Re: blue screen in windows balloon driver > > > From: james.harper@bendigoit.com.au > > > Date: Tue, 1 Mar 2011 16:01:46 +1100 > > > To: tinnycloud@hotmail.com > > > CC: xen-devel@lists.xensource.com > > > > > > Please send logs and bug check codes for any future crashes > > > > > > Can you also send me your memhog program? > > > > > > Sent from my iPhone > > > > > > On 01/03/2011, at 13:37, "MaoXiaoyun" <tinnycloud@hotmail.com> > wrote: > > > > > > > Thanks James. > > > > > > > > Well, what if the memory is balloon dow already? > > > > In my test, the eat memory process(named memhog) is started after > the > > server starts, > > > > (that is all VMs have already ballooned down to 512M) > > > > It looks like the "balloon down threads " is not working at that > time. > > > > > > > > One more question is, if memhog eat process at very fast speed, > will it > > consume the > > > > NopagePool memory? (I am not whether NopagePool and Page Pool is > seperate > > pool). > > > > If so, if the memory is exhausted, some other places > > like"ExAllocatePoolWithTag(NonPagedPool,...)", > > > > will gets no memory, and could it cause bluescreen? > > > > > > > > I will have the latest driver tested, thanks. > > > > > > > > > > > > > Subject: RE: blue screen in windows balloon driver > > > > > Date: Tue, 1 Mar 2011 10:45:52 +1100 > > > > > From: james.harper@bendigoit.com.au > > > > > To: tinnycloud@hotmail.com; xen-devel@lists.xensource.com > > > > > > > > > > I have just pushed a change to check the > > > > > "\KernelObjects\LowMemoryCondition" event before allocating > memory for > > > > > ballooning, and waiting if the event is set. This may resolve > the > > > > > problems you are seeing. > > > > > > > > > > What I have seen is that initially the event gets set, but then > as > > > > > Windows pages some active memory out the event gets cleared > again and > > > > > further ballooning down is possible. It may prevent you > ballooning down > > > > > quite as low as you could before, but if it stops windows > crashing then > > > > > I think it is good. > > > > > > > > > > James > > > > > > > > > > > -----Original Message----- > > > > > > From: MaoXiaoyun [mailto:tinnycloud@hotmail.com] > > > > > > Sent: Monday, 28 February 2011 19:30 > > > > > > To: xen devel > > > > > > Cc: James Harper > > > > > > Subject: RE: blue screen in windows balloon driver > > > > > > > > > > > > Hi James: > > > > > > > > > > > > Unfortunately, We still hit the blue screen on the stress > test. > > > > > > (Start total 24 HVMS on a single 16core, 24G host, > > > > > > each HVM owns 2G Memory, start with memory=512M, > > > > > > and inside two eating memory processes, each of which will > each > > > > > 1G > > > > > > memory) > > > > > > > > > > > > As I go though the code, I noticed that all memory allocation > > > > > relates to > > > > > > "ExAllocatePoolWithTag(NonPagedPool,...)", which is from > > > > > NonePaged Pool, > > > > > > As I know, the NonePagePool memory is the memory could not be > > > > > paged out, > > > > > > and that is limited, and for the blue screen VMS, I also found > > > > > the free > > > > > > memory > > > > > > is quite low, only about hundreds KB left. > > > > > > > > > > > > So, when memory overcommit, some of the VM will not got enough > > > > > memory, > > > > > > and if most of its Memory is occupied by eating memory > process, then > > > > > > ExAllocatePoolWithTag > > > > > > will fail, thus caused "NO_PAGES_AVALIABLE" blue screen. Is > this > > > > > possible? > > > > > > > > > > > > Meanwhile, I will have your PVdriver tested to see if blue > > > > > exists, > > > > > > thanks. > > > > > > > > > > > > > > > > > > >From: tinnycloud@hotmail.com > > > > > > >To: tinnycloud@hotmail.com > > > > > > >Subject: FW: blue screen in windows balloon driver > > > > > > >Date: Mon, 28 Feb 2011 16:16:59 +0800 > > > > > > > > > > > > > > > > > > > > >Thanks for fixing the POD. It's is better make it earlier to > avoid > > > > > crash. > > > > > > > > > > > > > >The meminfo is written every 1 seconds into xenstore dir > > > > > > /local/domain/did/memory/meminfo. > > > > > > >And to avoid to many writes, only the memory changes large > than 5M, > > > > > the > > > > > > thread will do the write. > > > > > > > > > > > > > >As for userspace daemon, it is our first choice, but we found > it > > > > > xenstore > > > > > > daemon in dom0 comsume > > > > > > >many CPU(we test in linux only), so we decide to move it into > driver. > > > > > > > > > > > > > >I've done merge my code with latest changeset 866, and do the > stree > > > > > test > > > > > > later. > > > > > > > > > > > > > >many thanks. > > > > > > > > > > > > > >> Subject: RE: RE: blue screen in windows balloon driver > > > > > > >> Date: Sun, 27 Feb 2011 22:25:28 +1100 > > > > > > >> From: james.harper@bendigoit.com.au > > > > > > >> To: tinnycloud@hotmail.com; xen-devel@lists.xensource.com > > > > > > >> CC: george.dunlap@eu.citrix.com > > > > > > >> > > > > > > >> > Thanks James. > > > > > > >> > > > > > > > >> > I think it is GPLPV. The driver is from > > > > > > >> http://xenbits.xen.org/ext/win- > > > > > > >> > pvdrivers.hg > > > > > > >> > But, I have done some other things > > > > > > >> > > > > > > > >> > 1) Add pod support > > > > > > >> > 2) enable a meminfo thread, periodically write VM meminfo > into > > > > > > >> xenstore > > > > > > >> > We use info of Current Memory, Free memory, and Committed > memory, > > > > > > >> retrived > > > > > > >> > through NativeAPI > > > > > > >> > 3) our code is based from changeset 823, attached is the > diff of > > > > > my > > > > > > >> current > > > > > > >> > code with changset of 853. > > > > > > >> > > > > > > > >> > Maybe I need add my code to 853, and test again. > > > > > > >> > Thanks. > > > > > > >> > > > > > > > >> > > > > > > >> As per other post, I have just committed some patches and > PoD > > > > > should now > > > > > > >> be working properly. I can start a DomU with 4GB of maxmem > but only > > > > > > >> 128MB of populated memory without any problems. This now > works > > > > > because I > > > > > > >> do the initial balloon down in DriverEntry, way before > xenpci does > > > > > > >> anything else. Before it would blow up in DriverEntry. I > think I > > > > > > >> determine the amount to initially balloon down a little > differently > > > > > from > > > > > > >> you too. > > > > > > >> > > > > > > >> It takes a while to balloon down the memory though... I > think > > > > > Windows > > > > > > >> tends to delay large allocations or something, because > ballooning > > > > > up > > > > > > >> again is pretty much instant. > > > > > > >> > > > > > > >> How often are you writing meminfo stuff into xenstore? > Could you do > > > > > that > > > > > > >> in userspace (the interface to xenstore exists and seems to > work > > > > > well > > > > > > >> although it's a little tedious)? You would then be able to > just run > > > > > it > > > > > > >> as a service and not need to patch GPLPV. > > > > > > >> > > > > > > >> James > > > > > > > > [-- Attachment #1.2: Type: text/html, Size: 17154 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: blue screen in windows balloon driver 2011-03-01 9:51 ` MaoXiaoyun @ 2011-03-01 9:54 ` James Harper 0 siblings, 0 replies; 26+ messages in thread From: James Harper @ 2011-03-01 9:54 UTC (permalink / raw) To: MaoXiaoyun, xen devel > > I am testing windows 2003, and the pvdriver msi is build in XP env. > > Well, I check all other not crashed VMS, all of them has the > XenVbd_HwScsiResetBus. > What does this mean? Is it reasonable. > > I will run the debug mode pv on the other two physical to see if the log > exists. > (Since not blue srceen ever happen on those two hosts). > > Also, how to check whether xenvbd is stuck? > I'm just making some changes now to test this. I will make HwScsiResetBus print out all the outstanding requests. HwScsiResetBus is called when Windows hasn't received a response to a scsi request (eg a read or a write). Either the request is stuck in my driver or it is stuck somewhere else. James ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2011-03-01 12:35 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <SNT0-MC4-F15TlpsWqi0002f5ac@snt0-mc4-f15.Snt0.hotmail.com>
2010-12-17 3:24 ` Win2003 got blue Screen when ballooning with serial out put: "Iomem mapping not permitted" tinnycloud
2010-12-17 8:53 ` Paul Durrant
2010-12-17 9:20 ` James Harper
2010-12-20 2:06 ` tinnycloud
2011-01-05 13:11 ` Could the page sharing inside domain? (memory_sharing on xen) xiaoyun.maoxy
2011-02-25 5:56 ` TODO in windows balloon driver tinnycloud
2011-02-26 12:17 ` James Harper
2011-02-26 13:35 ` MaoXiaoyun
2011-02-27 1:43 ` James Harper
2011-02-27 3:35 ` James Harper
2011-02-26 11:20 ` blue screen " xiaoyun.maoxy
[not found] ` <000301cbd5a7$3245a1b0$96d0e510$@maoxy@aliyun-inc.com>
2011-02-26 11:59 ` James Harper
2010-12-17 9:39 ` Win2003 got blue Screen when ballooning with serial out put: "Iomem mapping not permitted" tinnycloud
2011-02-26 13:01 re:RE: blue screen in windows balloon driver MaoXiaoyun
2011-02-27 11:25 ` James Harper
2011-02-28 4:33 ` MaoXiaoyun
[not found] ` <BLU157-w3689F78415A43CC5997DD7DADE0@phx.gbl>
2011-02-28 8:29 ` MaoXiaoyun
2011-02-28 11:45 ` James Harper
2011-02-28 23:45 ` James Harper
2011-03-01 2:37 ` MaoXiaoyun
2011-03-01 5:01 ` James Harper
2011-03-01 5:28 ` MaoXiaoyun
[not found] ` <AEC6C66638C05B468B556EA548C1A77D01C55AC7@trantor>
[not found] ` <BLU157-w655070D9CFE092D78C011DDAC10@phx.gbl>
[not found] ` <AEC6C66638C05B468B556EA548C1A77D01C55ACA@trantor>
2011-03-01 12:34 ` MaoXiaoyun
2011-03-01 12:35 ` James Harper
2011-03-01 7:14 ` MaoXiaoyun
2011-03-01 9:36 ` James Harper
[not found] ` <AEC6C66638C05B468B556EA548C1A77D01C55AC5@trantor>
2011-03-01 9:51 ` MaoXiaoyun
2011-03-01 9:54 ` James Harper
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).