I am trying to run Windows XP in a Xen DomU virtual machine with a PCIe device, for which there are no Linux drivers, being passed through from a Debian Squeeze Dom0. My hardware supports virtualization and it is active in the bios. If I run grep -E "(vmx|svm)" --color=always /proc/cpuinfo when I boot from the standard kernel I can see my processor supports vmx, although when I boot the Xen kernel, vmx doesn''t show up. I have followed the setup in http://wiki.xen.org/wiki/Xen_Beginners_Guide. The guide basically creates a minimal Debain Squeeze install as Dom0, a PV Debian Squeeze DomU and a HVM Windows DomU running on an LVM volume. I have followed the guide essentially to the letter with the only differences being my network bridge is different and I didn''t install a Debian PV DomU. I currently have a DomU on an LVM volume that is running a fully updated version of Windows XP with the GPLPV drivers. I am now trying to pass the PCI device, but am running into problems. If I compare the output of lspci with and without the PCIe card that I am trying to pass I see the following two new entries: 05:00.0 PCI bridge: PLX Technology, Inc. PEX 8111 PCI Express-to-PCI Bridge (rev 21) 06:04.0 Bridge: Device 4550:9054 (rev 01) I also see that another entry has changed its address from 06:00.0 IDE interface: Marvell Technology Group Ltd. 88SE6121 SATA II Controller (rev b2) to 07:00.0 IDE interface: Marvell Technology Group Ltd. 88SE6121 SATA II Controller (rev b2) I modified /etc/default/grub to include either GRUB_CMDLINE_XEN="xen-pciback.hide=(05:00.0)(06:04.0)" or GRUB_CMDLINE_XEN="pciback.hide=(05:00.0)(06:04.0)" and run update-grub and update-grub2 after making the change and then fully powered down and rebooted. This doesn''t appear to do anything and nothing shows up with xm pci-list-assignable-devices Looking at the Xen wiki guide http://wiki.xen.org/wiki/Xen_PCI_Passthrough I have tried things like echo 0000:05:00.0 > /sys/bus/pci/devices/0000:05:00.0/driver/unbind echo 0000:05:00.0 > /sys/bus/pci/drivers/pciback/new_slot echo 0000:05:00.0 > /sys/bus/pci/drivers/pciback/bind and some other stuff related to pci-stub. Sometimes my random fiddling results in xm pci-list-assignable-devices listing 05:00.0 and 06:04.0. If I modify my .cfg file to include pci = [''05:00.0'', ''06:04.0''] I get an error about pci-stub not owning the 05:00.0 device. If I only try and pass 06:04.0 the DomU won''t boot. Any ideas how to get pci passthrough working? Dan This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.
On 08.11.2012 19:36, Daniel E. Shub wrote:> I modified /etc/default/grub to include either > GRUB_CMDLINE_XEN="xen-pciback.hide=(05:00.0)(06:04.0)" > > or > GRUB_CMDLINE_XEN="pciback.hide=(05:00.0)(06:04.0)" > > and run update-grub and update-grub2 after making the changeWhat shows #grep hide /boot/grub/grub.cfg on your dom0? Greetings, Paul
#grep hide /boot/grub/grub.cfg Returns two lines of multiboot /boot/xen-4.0-amd64.gz placeholder xen-pciback.hide(05:00.0)(06:04.0) I am not sure where you are going, but after a reboot #xm dmesg | grep hide Returns placeholder xen-pciback.hide(05:00.0)(06:04.0) And #dmesg | grep "pic 0000:05" Returns a bunch of stuff On 9 Nov 2012, at 07:03, "Paul Muster" <paul@muster.dyndns.info> wrote:> On 08.11.2012 19:36, Daniel E. Shub wrote: > >> I modified /etc/default/grub to include either >> GRUB_CMDLINE_XEN="xen-pciback.hide=(05:00.0)(06:04.0)" >> >> or >> GRUB_CMDLINE_XEN="pciback.hide=(05:00.0)(06:04.0)" >> >> and run update-grub and update-grub2 after making the change > > What shows > > #grep hide /boot/grub/grub.cfg > > on your dom0? > > > Greetings, > > Paul > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-usersThis message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.
On Thu, 2012-11-08 at 18:36 +0000, Daniel E. Shub wrote:> I am trying to run Windows XP in a Xen DomU virtual machine with a PCIe > device, for which there are no Linux drivers, being passed through from a > Debian Squeeze Dom0. My hardware supports virtualization and it is active in > the bios. If I run > grep -E "(vmx|svm)" --color=always /proc/cpuinfo > > when I boot from the standard kernel I can see my processor supports vmx, > although when I boot the Xen kernel, vmx doesn''t show up.I think this is normal -- since Xen uses the vmx/svm capability it is not available to dom0 and therefore is masked.> I have followed the setup in http://wiki.xen.org/wiki/Xen_Beginners_Guide. The > guide basically creates a minimal Debain Squeeze install as Dom0, a PV Debian > Squeeze DomU and a HVM Windows DomU running on an LVM volume. I have followed > the guide essentially to the letter with the only differences being my network > bridge is different and I didn''t install a Debian PV DomU. > I currently have a DomU on an LVM volume that is running a fully updated > version of Windows XP with the GPLPV drivers. I am now trying to pass the PCI > device, but am running into problems. If I compare the output of lspci with > and without the PCIe card that I am trying to pass I see the following two new > entries: > 05:00.0 PCI bridge: PLX Technology, Inc. PEX 8111 PCI Express-to-PCI Bridge > (rev 21) > 06:04.0 Bridge: Device 4550:9054 (rev 01) > I also see that another entry has changed its address fromChanged compared to what?> 06:00.0 IDE interface: Marvell Technology Group Ltd. 88SE6121 SATA II > Controller (rev b2) > to > 07:00.0 IDE interface: Marvell Technology Group Ltd. 88SE6121 SATA II > Controller (rev b2) > I modified /etc/default/grub to include either > GRUB_CMDLINE_XEN="xen-pciback.hide=(05:00.0)(06:04.0)" > > or > GRUB_CMDLINE_XEN="pciback.hide=(05:00.0)(06:04.0)"Which dom0 kernel version are you running? Are you certain the the pciback module is enabled and builtin (not a module)? This syntax (exactly which depends on the kernel version) only works for when pciback is statically compiled. If it is modular then you need the bind/unbind dance which you described below.> and run update-grub and update-grub2 after making the change and then fully > powered down and rebooted. This doesn''t appear to do anything and nothing > shows up with > xm pci-list-assignable-devices > > Looking at the Xen wiki guide http://wiki.xen.org/wiki/Xen_PCI_Passthrough I > have tried things likeFor the purposes of trouble shooting it would be useful to include the actual literal commands you ran rather than something "like" them.> echo 0000:05:00.0 > /sys/bus/pci/devices/0000:05:00.0/driver/unbind > echo 0000:05:00.0 > /sys/bus/pci/drivers/pciback/new_slot > echo 0000:05:00.0 > /sys/bus/pci/drivers/pciback/bind > > and some other stuff related to pci-stub. Sometimes my random fiddling results > in > xm pci-list-assignable-devices > > listing 05:00.0 and 06:04.0. If I modify my .cfg file to include > pci = [''05:00.0'', ''06:04.0''] > > I get an error about pci-stub not owning the 05:00.0 device. If I only try and > pass 06:04.0 the DomU won''t boot.Did you repeat the above bind/unbind commands for 06:04.0?> Any ideas how to get pci passthrough working?You don''t say which version of Xen you are running but if it is 4.2 then you may have more luck using the xl toolstack, and in particular the "xl pci-assignable-add" commands. It maybe that the presence of the bridge device is confusing things. What is your pci topology like (lspci -t I think). TBH I''m not sure how pci passthrough interacts with PCI bridges but my intuition is that in general you do not want to pass thr bridge through, unless perhaps you are passing *every* device which is behind it to the same guest.> > > Dan > > > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment > may still contain software viruses which could damage your computer system: > you are advised to perform your own checks. Email communications with the > University of Nottingham may be monitored as permitted by UK legislation. > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users
On Fri, 2012-11-09 at 09:07 +0000, Daniel Shub wrote:> #grep hide /boot/grub/grub.cfg > > Returns two lines of > > multiboot /boot/xen-4.0-amd64.gz placeholder xen-pciback.hide(05:00.0)(06:04.0)Shouldn''t there be a "=" in this line? Here-------------------^> #dmesg | grep "pic 0000:05" > > Returns a bunch of stuffDoes it really? Because that command line appears to include a typo. Perhaps telling what the "bunch of stuff" is would be useful though? (else why mention it?) Ian.> > On 9 Nov 2012, at 07:03, "Paul Muster" <paul@muster.dyndns.info> wrote: > > > On 08.11.2012 19:36, Daniel E. Shub wrote: > > > >> I modified /etc/default/grub to include either > >> GRUB_CMDLINE_XEN="xen-pciback.hide=(05:00.0)(06:04.0)" > >> > >> or > >> GRUB_CMDLINE_XEN="pciback.hide=(05:00.0)(06:04.0)" > >> > >> and run update-grub and update-grub2 after making the change > > > > What shows > > > > #grep hide /boot/grub/grub.cfg > > > > on your dom0? > > > > > > Greetings, > > > > Paul > > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xen.org > > http://lists.xen.org/xen-users > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment > may still contain software viruses which could damage your computer system: > you are advised to perform your own checks. Email communications with the > University of Nottingham may be monitored as permitted by UK legislation. > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users
> -----Original Message----- > From: xen-users-bounces@lists.xen.org [mailto:xen-users- > bounces@lists.xen.org] On Behalf Of Ian Campbell > Sent: 9. november 2012 10:13 > To: Daniel Shub > Cc: xen-users@lists.xen.org; Paul Muster > Subject: Re: [Xen-users] PCI passthrough to Windows XP > > On Fri, 2012-11-09 at 09:07 +0000, Daniel Shub wrote: > > #grep hide /boot/grub/grub.cfg > > > > Returns two lines of > > > > multiboot /boot/xen-4.0-amd64.gz placeholder > > xen-pciback.hide(05:00.0)(06:04.0)Shouldn''t this line be on the kernel line in grub and not the xen.gz line? In my understanding it is the xen-pciback module in the linux kernel who does the hiding.> Shouldn''t there be a "=" in this line? Here-------------------^ > > > #dmesg | grep "pic 0000:05" > > > > Returns a bunch of stuff > > Does it really? Because that command line appears to include a typo. > Perhaps telling what the "bunch of stuff" is would be useful though? > (else why mention it?) > > Ian. > > > > > On 9 Nov 2012, at 07:03, "Paul Muster" <paul@muster.dyndns.info> wrote: > > > > > On 08.11.2012 19:36, Daniel E. Shub wrote: > > > > > >> I modified /etc/default/grub to include either > > >> GRUB_CMDLINE_XEN="xen-pciback.hide=(05:00.0)(06:04.0)" > > >> > > >> or > > >> GRUB_CMDLINE_XEN="pciback.hide=(05:00.0)(06:04.0)" > > >> > > >> and run update-grub and update-grub2 after making the change > > > > > > What shows > > > > > > #grep hide /boot/grub/grub.cfg > > > > > > on your dom0? > > > > > > > > > Greetings, > > > > > > Paul > > > > > > _______________________________________________ > > > Xen-users mailing list > > > Xen-users@lists.xen.org > > > http://lists.xen.org/xen-users > > This message and any attachment are intended solely for the addressee > and may contain confidential information. If you have received this message > in error, please send it back to me, and immediately delete it. Please do not > use, copy or disclose the information contained in this message or in any > attachment. Any views or opinions expressed by the author of this email do > not necessarily reflect the views of the University of Nottingham. > > > > This message has been checked for viruses but the contents of an > > attachment may still contain software viruses which could damage your > computer system: > > you are advised to perform your own checks. Email communications with > > the University of Nottingham may be monitored as permitted by UK > legislation. > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xen.org > > http://lists.xen.org/xen-users > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users
> -----Original Message----- > From: Daniel Shub [mailto:Daniel.Shub@nottingham.ac.uk] > Sent: 9. november 2012 10:51 > To: Kristian Hagsted Rasmussen > Subject: RE: [Xen-users] PCI passthrough to Windows XP > > > You grub.cfg should read something like multiboot > > /boot/xen-4.0-amd64.gz placeholder > > module /boot/vmlinuz-2.6.32.10 xen- > > pciback.hide=(05:00.0)(06:04.0) > > > > not > > multiboot /boot/xen-4.0-amd64.gz placeholder xen- > > pciback.hide=(05:00.0)(06:04.0) > > module /boot/vmlinuz-2.6.32.10 > > > > which grub do you use? > > I use grub2 in Debian Squeeze. The problem is that /boot/grub/grub.cfg is > automatically generated from /etc/default/grub where I have added the line > > GRUB_CMDLINE_XEN="xen-pciback.hide=(05:00.0)(06:04.0)"I am use my own 06_xen file so are not used to the syntax, but is there a line called something like GRUB_CMDLINE_XEN_LINUXOr GRUB_CMDLINE_XEN_LINUX_DEFAULTThen move the "xen-pciback.hide=(05:00.0)(06:04.0)" to that one, update grub and do the #grep hide /boot/grub/grub.cfg To see if the line now starts with Module /boot/vm-linuz...> > And then did an update-grub. I am not sure I can manually update > /boot/grub/grub.cfg in Debian. > This message and any attachment are intended solely for the addressee and > may contain confidential information. If you have received this message in > error, please send it back to me, and immediately delete it. Please do not > use, copy or disclose the information contained in this message or in any > attachment. Any views or opinions expressed by the author of this email do > not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an > attachment may still contain software viruses which could damage your > computer system: > you are advised to perform your own checks. Email communications with the > University of Nottingham may be monitored as permitted by UK legislation.
> -----Original Message----- > From: Ian Campbell [mailto:Ian.Campbell@citrix.com] > Sent: Friday, November 09, 2012 9:10 AM > To: Daniel E. Shub > Cc: xen-users@lists.xen.org > Subject: Re: [Xen-users] PCI passthrough to Windows XP > > > when I boot from the standard kernel I can see my processor supports > > vmx, although when I boot the Xen kernel, vmx doesn''t show up. > > I think this is normal -- since Xen uses the vmx/svm capability it is > not available to dom0 and therefore is masked.Thank you for that clarification> > I also see that another entry has changed its address from > > Changed compared to what? >I put that on the next lines ...> > 06:00.0 IDE interface: Marvell Technology Group Ltd. 88SE6121 SATA II > > Controller (rev b2) > > to > > 07:00.0 IDE interface: Marvell Technology Group Ltd. 88SE6121 SATA II > > Controller (rev b2)> Which dom0 kernel version are you running? Are you certain the the > pciback module is enabled and builtin (not a module)? This syntax > (exactly which depends on the kernel version) only works for when > pciback is statically compiled. If it is modular then you need the > bind/unbind dance which you described below.I believe I am running 2.6.32 and Xen 4.0. It is the standard kernel provided when you install Xen from Debian Squeeze. I am not sure if the pciback is statically compiled. How do I find this out?> > Looking at the Xen wiki guide > > http://wiki.xen.org/wiki/Xen_PCI_Passthrough I have tried things like > > > > echo 0000:05:00.0 > /sys/bus/pci/devices/0000:05:00.0/driver/unbind > > echo 0000:05:00.0 > /sys/bus/pci/drivers/pciback/new_slot > > echo 0000:05:00.0 > /sys/bus/pci/drivers/pciback/bind > > > > For the purposes of trouble shooting it would be useful to include the > actual literal commands you ran rather than something "like" them. > Did you repeat the above bind/unbind commands for 06:04.0?I wasn''t sure I was on the right path with the above so I tried a bunch of different things at different times (always preceded by a full power down and reboot). I tried it with just 05:00.0, just 06:04.0, and both. I tried it with pciback and pcistub.> > > Any ideas how to get pci passthrough working? > > You don''t say which version of Xen you are running but if it is 4.2 > then you may have more luck using the xl toolstack, and in particular > the "xl pci-assignable-add" commands.Debian Squeeze only has 4.0 installed which is what the wiki beginner walk through is based on. I also tried upgrading to Debian Sid/unstable which has 3.x kernel and Xen 4.1. I looked at Arch Linux which tends to have bleeding edge software and a great wiki and they are only in the process of getting 4.2 working. Is there a distro that supports 4.2 and has a walk through?> > It maybe that the presence of the bridge device is confusing things. > What is your pci topology like (lspci -t I think). TBH I''m not sure how > pci passthrough interacts with PCI bridges but my intuition is that in > general you do not want to pass thr bridge through, unless perhaps you > are passing *every* device which is behind it to the same guest. >#lspci -t -[0000:00]-+-00.0 +-01.0-[01]-- +-03.0-[02]--+-00.0 | \-00.1 +-07.0-[03]-- +-10.0 +-10.1 +-14.0 +-14.1 +-14.2 +-14.3 +-19.0 +-1a.0 +-1a.1 +-1a.2 +-1a.7 +-1c.0-[04]-- +-1c.1-[05-06]----00.0-[06]----04.0 +-1c.4-[07]----00.0 +-1d.0 +-1d.1 +-1d.2 +-1d.7 +-1e.0-[08]-- +-1f.0 +-1f.2 \-1f.3 Which means nothing to me ... Thanks for the help. Dan This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.
> > I use grub2 in Debian Squeeze. The problem is that > /boot/grub/grub.cfg > > is automatically generated from /etc/default/grub where I have added > > the line > > > > GRUB_CMDLINE_XEN="xen-pciback.hide=(05:00.0)(06:04.0)" > I am use my own 06_xen file so are not used to the syntax, but is there > a line called something like GRUB_CMDLINE_XEN_LINUX= Or > GRUB_CMDLINE_XEN_LINUX_DEFAULT= Then move the "xen- > pciback.hide=(05:00.0)(06:04.0)" to that one, update grub and do the > #grep hide /boot/grub/grub.cfg To see if the line now starts with > Module /boot/vm-linuz...There are no lines with CMDLINE_XEN in them. I had to add the GRUB_CMDLINE_XEN line. If I add GRUB_CMDLINE_XEN_LINUX="xen-pciback.hide=(05:00.0)(06:04.0)" Or GRUB_CMDLINE_XEN_LINUX_DEFAULT="xen-pciback.hide=(05:00.0)(06:04.0)" And do an update-grub and then #grep hide /boot/grub/grub.cfg I get nothing. This doesn''t surprise me since if I look at my /etc/grub.d/09_linux_xen it seems to want GRUB_CMDLINE_XEN and GRUB_CMDLINE_XEN_DEFAULT. This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.
> -----Original Message----- > From: Daniel Shub [mailto:Daniel.Shub@nottingham.ac.uk] > Sent: 9. november 2012 11:12 > To: Kristian Hagsted Rasmussen; Daniel Shub > Cc: xen-users@lists.xen.org > Subject: RE: [Xen-users] PCI passthrough to Windows XP > > > > I use grub2 in Debian Squeeze. The problem is that > > /boot/grub/grub.cfg > > > is automatically generated from /etc/default/grub where I have added > > > the line > > > > > > GRUB_CMDLINE_XEN="xen-pciback.hide=(05:00.0)(06:04.0)" > > I am use my own 06_xen file so are not used to the syntax, but is > > there a line called something like GRUB_CMDLINE_XEN_LINUX= Or > > GRUB_CMDLINE_XEN_LINUX_DEFAULT= Then move the "xen- > > pciback.hide=(05:00.0)(06:04.0)" to that one, update grub and do the > > #grep hide /boot/grub/grub.cfg To see if the line now starts with > > Module /boot/vm-linuz... > There are no lines with CMDLINE_XEN in them. I had to add the > GRUB_CMDLINE_XEN line. If I add > > GRUB_CMDLINE_XEN_LINUX="xen-pciback.hide=(05:00.0)(06:04.0)" > > Or > > GRUB_CMDLINE_XEN_LINUX_DEFAULT="xen- > pciback.hide=(05:00.0)(06:04.0)" > > And do an update-grub and then > > #grep hide /boot/grub/grub.cfg > > I get nothing. This doesn''t surprise me since if I look at my > /etc/grub.d/09_linux_xen it seems to want GRUB_CMDLINE_XEN and > GRUB_CMDLINE_XEN_DEFAULT.It seems that you then have to put it on GRUB_CMDLINE_LINUX As the parameter must be passed to the linux kernel and not the xen.gz> This message and any attachment are intended solely for the addressee and > may contain confidential information. If you have received this message in > error, please send it back to me, and immediately delete it. Please do not > use, copy or disclose the information contained in this message or in any > attachment. Any views or opinions expressed by the author of this email do > not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an > attachment may still contain software viruses which could damage your > computer system: > you are advised to perform your own checks. Email communications with the > University of Nottingham may be monitored as permitted by UK legislation.
On Fri, 2012-11-09 at 09:28 +0000, Kristian Hagsted Rasmussen wrote:> > > -----Original Message----- > > From: xen-users-bounces@lists.xen.org [mailto:xen-users- > > bounces@lists.xen.org] On Behalf Of Ian Campbell > > Sent: 9. november 2012 10:13 > > To: Daniel Shub > > Cc: xen-users@lists.xen.org; Paul Muster > > Subject: Re: [Xen-users] PCI passthrough to Windows XP > > > > On Fri, 2012-11-09 at 09:07 +0000, Daniel Shub wrote: > > > #grep hide /boot/grub/grub.cfg > > > > > > Returns two lines of > > > > > > multiboot /boot/xen-4.0-amd64.gz placeholder > > > xen-pciback.hide(05:00.0)(06:04.0) > Shouldn''t this line be on the kernel line in grub and not the xen.gz line? > In my understanding it is the xen-pciback module in the linux kernel who does the hiding.I missed this -- you are absolutely correct that this option should be passed to the dom0 kernel. If using update-grub with the standard grub.d snippets hten it should be added /etc/default/grub in the GRUB_CMDLINE_LINUX_XEN_REPLACE or GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT variables (which may need to be created). Alternatively GRUB_CMDLINE_LINUX_DEFAULT/GRUB_CMDLINE_LINUX would work (and be harmless, I think, when booting native). GRUB_CMDLINE_XEN_DEFAULT and GRUB_CMDLINE_LINUX_DEFAULT are both the wrong place to add this new option.
On Fri, 2012-11-09 at 09:28 +0000, Kristian Hagsted Rasmussen wrote:> > > -----Original Message----- > > From: xen-users-bounces@lists.xen.org [mailto:xen-users- > > bounces@lists.xen.org] On Behalf Of Ian Campbell > > Sent: 9. november 2012 10:13 > > To: Daniel Shub > > Cc: xen-users@lists.xen.org; Paul Muster > > Subject: Re: [Xen-users] PCI passthrough to Windows XP > > > > On Fri, 2012-11-09 at 09:07 +0000, Daniel Shub wrote: > > > #grep hide /boot/grub/grub.cfg > > > > > > Returns two lines of > > > > > > multiboot /boot/xen-4.0-amd64.gz placeholder > > > xen-pciback.hide(05:00.0)(06:04.0) > Shouldn''t this line be on the kernel line in grub and not the xen.gz line? > In my understanding it is the xen-pciback module in the linux kernel who does the hiding.I missed this -- you are absolutely correct that this option should be passed to the dom0 kernel. If using update-grub with the standard grub.d snippets hten it should be added /etc/default/grub in the GRUB_CMDLINE_LINUX_XEN_REPLACE or GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT. Or GRUB_CMDLINE_LINUX_DEFAULT/GRUB_CMDLINE_LINUX would work (and be harmless, I think, when booting native). GRUB_CMDLINE_XEN_DEFAULT and GRUB_CMDLINE_LINUX_DEFAULT are both the wrong place to add this new option.
> > > > #grep hide /boot/grub/grub.cfg > > > > > > > > Returns two lines of > > > > > > > > multiboot /boot/xen-4.0-amd64.gz placeholder > > > > xen-pciback.hide(05:00.0)(06:04.0) > > Shouldn''t this line be on the kernel line in grub and not the xen.gz > line? > > In my understanding it is the xen-pciback module in the linux kernel > who does the hiding. > > I missed this -- you are absolutely correct that this option should be > passed to the dom0 kernel. > > If using update-grub with the standard grub.d snippets hten it should > be added /etc/default/grub in the GRUB_CMDLINE_LINUX_XEN_REPLACE or > GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT. Or > GRUB_CMDLINE_LINUX_DEFAULT/GRUB_CMDLINE_LINUX would work (and be > harmless, I think, when booting native). > > GRUB_CMDLINE_XEN_DEFAULT and GRUB_CMDLINE_LINUX_DEFAULT are both the > wrong place to add this new option. >I am confused. At first you say GRUB_CMDLINE_LINUX_DEFAULT "would work (and be harmless)", but then say it is "the wrong place to add this new option". Adding to GRUB_CMDLINE_LINUX_XEN_REPLACE or GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT doesn''t work (nothing gets added to /boot/grub/grub.cfg). Adding to GRUB_CMDLINE_LINUX results in #grep hide /boot/grub/grub.cfg module /boot/vmlinuz-2.6.32-5-xen-amd64 placeholder root=UUID=2c69309c-05ce-4e2d-b9f9-d651e65342ae ro xen-pciback.hide(05:00.0)(06:04.0) quiet module /boot/vmlinuz-2.6.32-5-xen-amd64 placeholder root=UUID=2c69309c-05ce-4e2d-b9f9-d651e65342ae ro single xen-pciback.hide(05:00.0)(06:04.0) linux /boot/vmlinuz-2.6.32-5-xen-amd64 root=UUID=2c69309c-05ce-4e2d-b9f9-d651e65342ae ro xen-pciback.hide(05:00.0)(06:04.0) quiet linux /boot/vmlinuz-2.6.32-5-xen-amd64 root=UUID=2c69309c-05ce-4e2d-b9f9-d651e65342ae ro single xen-pciback.hide(05:00.0)(06:04.0) linux /boot/vmlinuz-2.6.32-5-amd64 root=UUID=2c69309c-05ce-4e2d-b9f9-d651e65342ae ro xen-pciback.hide(05:00.0)(06:04.0) quiet linux /boot/vmlinuz-2.6.32-5-amd64 root=UUID=2c69309c-05ce-4e2d-b9f9-d651e65342ae ro single xen-pciback.hide(05:00.0)(06:04.0) but I am still unable to use the pci passthrough. At this point I am still not sure that the Debain Squeeze kernel supports xen-pciback or if I need to load a module. I also do not know if I should be using xen-pciback or just pciback (I have been trying everything with both). This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.
On Fri, 2012-11-09 at 10:44 +0000, Daniel Shub wrote:> > > > > #grep hide /boot/grub/grub.cfg > > > > > > > > > > Returns two lines of > > > > > > > > > > multiboot /boot/xen-4.0-amd64.gz placeholder > > > > > xen-pciback.hide(05:00.0)(06:04.0) > > > Shouldn''t this line be on the kernel line in grub and not the xen.gz > > line? > > > In my understanding it is the xen-pciback module in the linux kernel > > who does the hiding. > > > > I missed this -- you are absolutely correct that this option should be > > passed to the dom0 kernel. > > > > If using update-grub with the standard grub.d snippets hten it should > > be added /etc/default/grub in the GRUB_CMDLINE_LINUX_XEN_REPLACE or > > GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT. Or > > GRUB_CMDLINE_LINUX_DEFAULT/GRUB_CMDLINE_LINUX would work (and be > > harmless, I think, when booting native). > > > > GRUB_CMDLINE_XEN_DEFAULT and GRUB_CMDLINE_LINUX_DEFAULT are both the > > wrong place to add this new option. > > > I am confused. At first you say GRUB_CMDLINE_LINUX_DEFAULT "would work > (and be harmless)", but then say it is "the wrong place to add this > new option".Sorry. cut-n-paste the wrong thing. Good: GRUB_CMDLINE_LINUX_XEN_REPLACE GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT GRUB_CMDLINE_LINUX GRUB_CMDLINE_LINUX_DEFAULT Bad: GRUB_CMDLINE_XEN GRUB_CMDLINE_XEN_DEFAULT> Adding to GRUB_CMDLINE_LINUX_XEN_REPLACE or GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT doesn''t work (nothing gets added to /boot/grub/grub.cfg). Adding to GRUB_CMDLINE_LINUX results in > > #grep hide /boot/grub/grub.cfg > module /boot/vmlinuz-2.6.32-5-xen-amd64 placeholder root=UUID=2c69309c-05ce-4e2d-b9f9-d651e65342ae ro xen-pciback.hide(05:00.0)(06:04.0) quiet > module /boot/vmlinuz-2.6.32-5-xen-amd64 placeholder root=UUID=2c69309c-05ce-4e2d-b9f9-d651e65342ae ro single xen-pciback.hide(05:00.0)(06:04.0) > linux /boot/vmlinuz-2.6.32-5-xen-amd64 root=UUID=2c69309c-05ce-4e2d-b9f9-d651e65342ae ro xen-pciback.hide(05:00.0)(06:04.0) quiet > linux /boot/vmlinuz-2.6.32-5-xen-amd64 root=UUID=2c69309c-05ce-4e2d-b9f9-d651e65342ae ro single xen-pciback.hide(05:00.0)(06:04.0) > linux /boot/vmlinuz-2.6.32-5-amd64 root=UUID=2c69309c-05ce-4e2d-b9f9-d651e65342ae ro xen-pciback.hide(05:00.0)(06:04.0) quiet > linux /boot/vmlinuz-2.6.32-5-amd64 root=UUID=2c69309c-05ce-4e2d-b9f9-d651e65342ae ro single xen-pciback.hide(05:00.0)(06:04.0) > > but I am still unable to use the pci passthrough.You seem to still be missing the "=" after the xen-pciback.hide.> At this point I am still not sure that the Debain Squeeze kernel > supports xen-pciback or if I need to load a module. I also do not know > if I should be using xen-pciback or just pciback (I have been trying > everything with both).I don''t have a Squeeze box handy to check. "find /lib/modules/$(uname -r) -name \*pciback\*" will find you the module (and therefore its name) if it exists. "grep PCIBACK /boot/config-$(uname -r)" should give you a =y or =m answer if it is static or modular. You can probably aloso find some files with the name under /sys somewhere. You could also just try modprobe pciback ; modprobe xen-pciback and see what it loads. Ian.
> -----Original Message----- > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]> You seem to still be missing the "=" after the xen-pciback.hide.I fixed that. I was adding the wrong thing to GRUB_CMDLINE_LINUX. GRUB_CMDLINE_LINUX="xen-pciback.hide=(05:00.0)(06:04.0)" Followed by an update-grub and a reboot and #xm pci-list-assignable-devices Shows the two "devices". That is progress, but I still cannot boot my virtual machine with pci = [''05:00.0'', ''06:04.0''] in the .cfg file> > > At this point I am still not sure that the Debain Squeeze kernel > > supports xen-pciback or if I need to load a module. I also do not > know > > if I should be using xen-pciback or just pciback (I have been trying > > everything with both). > > I don''t have a Squeeze box handy to check. >I get nothing with either #find /lib/modules/$(uname -r) -name \*pciback\* or #grep PCIBACK /boot/config-$(uname -r) If instead I go a little more general #find / -name \*pciback\* /sys/bus/pci/drivers/pciback /sys/bus/xen-backend/drivers/pciback /sys/module/xen_pciback /sys/module/xen_pciback/drivers/pci:pciback /sys/module/xen_pciback/drivers/xen-backend:pciback #grep PCI /boot/config-$(uname -r) CONFIG_PCI_QUIRKS=y CONFIG_XEN_DOM0_PCI=y # CONFIG_XEN_PCI_PASSTHROUGH is not set CONFIG_ACPI_PCI_SLOT=m # Bus options (PCI etc.) CONFIG_PCI=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_XEN=y CONFIG_PCI_DOMAINS=y CONFIG_PCIEPORTBUS=y CONFIG_HOTPLUG_PCI_PCIE=m CONFIG_PCIEAER=y # CONFIG_PCIE_ECRC is not set CONFIG_PCIEAER_INJECT=m CONFIG_PCIEASPM=y # CONFIG_PCIEASPM_DEBUG is not set CONFIG_PCI_MSI=y CONFIG_PCI_LEGACY=y # CONFIG_PCI_DEBUG is not set CONFIG_PCI_STUB=m CONFIG_XEN_PCIDEV_FRONTEND=y CONFIG_PCI_IOV=y CONFIG_HOTPLUG_PCI=m CONFIG_HOTPLUG_PCI_FAKE=m CONFIG_HOTPLUG_PCI_ACPI=m CONFIG_HOTPLUG_PCI_ACPI_IBM=m CONFIG_HOTPLUG_PCI_CPCI=y CONFIG_HOTPLUG_PCI_CPCI_ZT5550=m CONFIG_HOTPLUG_PCI_CPCI_GENERIC=m CONFIG_HOTPLUG_PCI_SHPC=m CONFIG_CAN_EMS_PCI=m CONFIG_CAN_KVASER_PCI=m CONFIG_MTD_PCI=m # PCI IDE chipsets support CONFIG_BLK_DEV_IDEPCI=y CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_PATA_CMD640_PCI is not set CONFIG_ARCNET_COM20020_PCI=m CONFIG_NET_PCI=y CONFIG_B44_PCI_AUTOSELECT=y CONFIG_B44_PCICORE_AUTOSELECT=y CONFIG_B44_PCI=y CONFIG_NE2K_PCI=m CONFIG_TMSPCI=m CONFIG_PCI_ATMEL=m CONFIG_P54_PCI=m CONFIG_HOSTAP_PCI=m CONFIG_B43_PCI_AUTOSELECT=y CONFIG_B43_PCICORE_AUTOSELECT=y CONFIG_B43LEGACY_PCI_AUTOSELECT=y CONFIG_B43LEGACY_PCICORE_AUTOSELECT=y CONFIG_RT2400PCI=m CONFIG_RT2500PCI=m CONFIG_RT61PCI=m CONFIG_RT2X00_LIB_PCI=m CONFIG_PCI_HERMES=m CONFIG_PCI200SYN=m CONFIG_DSCC4_PCISYNC=y CONFIG_DSCC4_PCI_RST=y CONFIG_MISDN_HFCPCI=m CONFIG_HISAX_TELESPCI=y CONFIG_HISAX_FRITZPCI=y CONFIG_HISAX_HFC_PCI=y CONFIG_HISAX_ENTERNOW_PCI=y CONFIG_HISAX_FRITZ_PCIPNP=m CONFIG_ISDN_DRV_AVMB1_B1PCI=m CONFIG_ISDN_DRV_AVMB1_B1PCIV4=y CONFIG_ISDN_DRV_AVMB1_T1PCI=m CONFIG_ISDN_DIVAS_BRIPCI=y CONFIG_ISDN_DIVAS_PRIPCI=y CONFIG_SERIO_PCIPS2=m CONFIG_SERIAL_8250_PCI=y # PCI-based Watchdog Cards CONFIG_PCIPCWATCHDOG=m CONFIG_WDTPCI=m CONFIG_SSB_PCIHOST_POSSIBLE=y CONFIG_SSB_PCIHOST=y CONFIG_SSB_B43_PCI_BRIDGE=y CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y CONFIG_SSB_DRIVER_PCICORE=y CONFIG_RADIO_GEMTEK_PCI=m # Supported SAA7146 based PCI Adapters CONFIG_TTPCI_EEPROM=m CONFIG_DVB_B2C2_FLEXCOP_PCI=m CONFIG_FB_MB862XX_PCI_GDC=y CONFIG_SND_PCI=y CONFIG_SND_CMIPCI=m CONFIG_SND_YMFPCI=m CONFIG_MMC_SDHCI_PCI=m CONFIG_UIO_PCI_GENERIC=m CONFIG_XEN_PCIDEV_BACKEND=y CONFIG_XEN_PCIDEV_BACKEND_VPCI=y # CONFIG_XEN_PCIDEV_BACKEND_PASS is not set # CONFIG_XEN_PCIDEV_BACKEND_SLOT is not set # CONFIG_XEN_PCIDEV_BACKEND_CONTROLLER is not set # CONFIG_XEN_PCIDEV_BE_DEBUG is not set CONFIG_XEN_PLATFORM_PCI=y CONFIG_BRCM80211_PCI=y CONFIG_COMEDI_PCI_DRIVERS=m # CONFIG_ALTERA_PCIE_CHDMA is not set CONFIG_VIRTIO_PCI=m I am a little worried about the line # CONFIG_XEN_PCI_PASSTHROUGH is not set> You could also just try modprobe pciback ; modprobe xen-pciback and see > what it loads.#modprobe pciback FATAL: Module pciback not found. #modprobe xen-pciback FATAL: MODULE xen_pciback not found. Note it converted xen-pciback to xen_pciback. I also tried #modprobe xen_pciback FATAL: MODULE xen_pciback not found. #modprobe pci-stub It appears pci-stub works This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.
So I think I am making progress. I decided to try and pass a PCIe network card
(04:00.0) and a PCI sound card (08:02.0) to see if I could get that working. I
added the following line to my /etc/default/grub
GRUB_CMDLINE_LINUX="xen-pciback.hide=(04:00.0)(08:02.0)(05:00.0)(06:04.0)"
and after a update-grub the relevant portion of my /boot/grub/grub.cfg is
menuentry ''Debian GNU/Linux, with Linux 2.6.32-5-xen-amd64 and XEN
4.0-amd64''
--class debian --class gnu-linux --class gnu --class os --class xen {
insmod part_msdos
insmod ext2
set root=''(hd0,msdos1)''
search --no-floppy --fs-uuid --set 2c69309c-05ce-4e2d-b9f9-d651e65342ae
echo ''Loading Linux 2.6.32-5-xen-amd64 ...''
multiboot /boot/xen-4.0-amd64.gz placeholder
module /boot/vmlinuz-2.6.32-5-xen-amd64 placeholder
root=UUID=2c69309c-05ce-4e2d-b9f9-d651e65342ae ro xen-pciback.hide=(04:00.0)
(08:02.0)(05:00.0)(06:04.0) quiet
echo ''Loading initial ramdisk ...''
module /boot/initrd.img-2.6.32-5-xen-amd64
}
After a reboot
#xm pci-list-assignable-devices
shows the 4 device ids. If I then add the following to the .cfg file for my
virtual Windows XP machine
pci = [''04:00.0'', ''08:02.0'']
the virtual machine boots and the network card and sound card appear to work
fine. So it seems like I can get PCI passthrough to work. If I add the card I
am interested in
pci = [''04:00.0'', ''08:02.0'',
''05:00.0'', ''06:04.0'']
or
pci = [''04:00.0'', ''08:02.0'',
''05:00.0'']
and try and create the VM, I get
Error: pci: PCI Backend and pci-stub don''t own device 0000:05:00.0
If I only have
pci = [''04:00.0'', ''08:02.0'',
''06:04.0'']
then
xm create windows.cfg doesn''t give me an error, but the VM is not
created.
Potentially relevant are
#lspci -t
-[0000:00]-+-00.0
+-01.0-[01]--
+-03.0-[02]--+-00.0
| \-00.1
+-07.0-[03]--
+-10.0
+-10.1
+-14.0
+-14.1
+-14.2
+-14.3
+-19.0
+-1a.0
+-1a.1
+-1a.2
+-1a.7
+-1c.0-[04]----00.0
+-1c.1-[05-06]----00.0-[06]----04.0
+-1c.4-[07]----00.0
+-1d.0
+-1d.1
+-1d.2
+-1d.7
+-1e.0-[08]----02.0
+-1f.0
+-1f.2
\-1f.3
which shows the PCIe card I am having trouble with is a "bridged"
device.
#dmesg | grep pciback
[ 0.000000] Command line: placeholder root=UUID=2c69309c-05ce-4e2d-b9f9-
d651e65342ae ro xen-pciback.hide=(04:00.0)(08:02.0)(05:00.0)(06:04.0) quiet
[ 1.607196] Kernel command line: placeholder root=UUID=2c69309c-05ce-4e2d-
b9f9-d651e65342ae ro xen-pciback.hide=(04:00.0)(08:02.0)(05:00.0)(06:04.0)
quiet
[ 1.779586] pciback 0000:04:00.0: seizing device
[ 1.779591] pciback 0000:05:00.0: seizing device
[ 1.779594] pciback 0000:06:04.0: seizing device
[ 1.779601] pciback 0000:08:02.0: seizing device
[ 1.783149] pciback 0000:04:00.0: BAR 6: no parent found for of device
[0xfffe0000-0xffffffff]
[ 1.783354] pciback 0000:05:00.0: PCI bridge, secondary bus 0000:06
[ 1.783359] pciback 0000:05:00.0: IO window: 0x3000-0x3fff
[ 1.783370] pciback 0000:05:00.0: MEM window: 0xd0100000-0xd01fffff
[ 1.783378] pciback 0000:05:00.0: PREFETCH window: disabled
[ 1.783644] pciback 0000:05:00.0: PCI INT A -> GSI 17 (level, low) ->
IRQ
17
[ 1.783652] pciback 0000:05:00.0: setting latency timer to 64
[ 1.846611] pciback 0000:08:02.0: PCI INT A -> GSI 18 (level, low) ->
IRQ
18
[ 1.846618] pciback 0000:08:02.0: PCI INT A disabled
[ 1.846689] pciback 0000:06:04.0: PCI INT A -> GSI 17 (level, low) ->
IRQ
17
[ 1.846698] pciback 0000:06:04.0: PCI INT A disabled
[ 1.846837] pciback 0000:04:00.0: PCI INT A -> GSI 16 (level, low) ->
IRQ
16
[ 1.846849] pciback 0000:04:00.0: PCI INT A disabled
which does mean anything to me.
#xm dmesg
(XEN) Xen version 4.0.1 (Debian 4.0.1-5.4) (ultrotter@debian.org) (gcc version
4.4.5 (Debian 4.4.5-8) ) Sat Sep 8 19:15:46 UTC 2012
(XEN) Bootloader: GRUB 1.98+20100804-14+squeeze1
(XEN) Command line: placeholder
(XEN) Video information:
(XEN) VGA is text mode 80x25, font 8x16
(XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN) Found 1 MBR signatures
(XEN) Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN) 0000000000000000 - 000000000008f000 (usable)
(XEN) 000000000008f000 - 0000000000090000 (reserved)
(XEN) 0000000000090000 - 000000000009d000 (usable)
(XEN) 000000000009d000 - 00000000000a0000 (reserved)
(XEN) 00000000000e0000 - 0000000000100000 (reserved)
(XEN) 0000000000100000 - 00000000cf49d000 (usable)
(XEN) 00000000cf49d000 - 00000000cf4bf000 (reserved)
(XEN) 00000000cf4bf000 - 00000000cf664000 (usable)
(XEN) 00000000cf664000 - 00000000cf7bf000 (ACPI NVS)
(XEN) 00000000cf7bf000 - 00000000cf7db000 (usable)
(XEN) 00000000cf7db000 - 00000000cf7ff000 (ACPI data)
(XEN) 00000000cf7ff000 - 00000000cf800000 (usable)
(XEN) 00000000cf800000 - 00000000d0000000 (reserved)
(XEN) 00000000f8000000 - 00000000fd000000 (reserved)
(XEN) 00000000ffe00000 - 0000000100000000 (reserved)
(XEN) 0000000100000000 - 00000001b0000000 (usable)
(XEN) ACPI: RSDP 000FE020, 0024 (r2 INTEL )
(XEN) ACPI: XSDT CF7FE120, 0074 (r1 INTEL DX58SO 1599 1000013)
(XEN) ACPI: FACP CF7FD000, 00F4 (r3 INTEL DX58SO 1599 MSFT 100000D)
(XEN) ACPI Warning (tbfadt-0444): Optional field "Pm2ControlBlock" has
zero
address or length: 0000000000000450/0 [20070126]
(XEN) ACPI: DSDT CF7F8000, 4617 (r2 INTEL DX58SO 1599 MSFT 100000D)
(XEN) ACPI: FACS CF72A000, 0040
(XEN) ACPI: APIC CF7F7000, 0138 (r2 INTEL DX58SO 1599 MSFT 100000D)
(XEN) ACPI: WDDT CF7F6000, 0040 (r1 INTEL DX58SO 1599 MSFT 100000D)
(XEN) ACPI: MCFG CF7F5000, 003C (r1 INTEL DX58SO 1599 MSFT 100000D)
(XEN) ACPI: ASF! CF7F4000, 00AC (r32 INTEL DX58SO 1599 MSFT 100000D)
(XEN) ACPI: HPET CF7F3000, 0038 (r1 INTEL DX58SO 1599 MSFT 100000D)
(XEN) ACPI: SSDT CF7DE000, 12344 (r1 INTEL SSDT PM 1599 MSFT 100000D)
(XEN) ACPI: DMAR CF7DB000, 0168 (r1 INTEL DX58SO 1599 MSFT 100000D)
(XEN) ACPI: WDTT CF7F1000, 020C (r2 INTEL DX58SO 1599 MSFT 100000D)
(XEN) ACPI: ASPT CF7F2000, 0034 (r4 INTEL PerfTune 1599 MSFT 100000D)
(XEN) System RAM: 6133MB (6281196kB)
(XEN) Domain heap initialised
(XEN) Processor #0 7:10 APIC version 21
(XEN) Processor #2 7:10 APIC version 21
(XEN) Processor #4 7:10 APIC version 21
(XEN) Processor #6 7:10 APIC version 21
(XEN) Processor #1 7:10 APIC version 21
(XEN) Processor #3 7:10 APIC version 21
(XEN) Processor #5 7:10 APIC version 21
(XEN) Processor #7 7:10 APIC version 21
(XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
(XEN) Enabling APIC mode: Flat. Using 1 I/O APICs
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 3108.037 MHz processor.
(XEN) Initing memory sharing.
(XEN) VMX: Supported advanced features:
(XEN) - APIC MMIO access virtualisation
(XEN) - APIC TPR shadow
(XEN) - Extended Page Tables (EPT)
(XEN) - Virtual-Processor Identifiers (VPID)
(XEN) - Virtual NMI
(XEN) - MSR direct-access bitmap
(XEN) EPT supports 2MB super page.
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging detected.
(XEN) Intel VT-d Snoop Control supported.
(XEN) Intel VT-d DMA Passthrough not supported.
(XEN) Intel VT-d Queued Invalidation supported.
(XEN) Intel VT-d Interrupt Remapping supported.
(XEN) I/O virtualisation enabled
(XEN) - Dom0 mode: Relaxed
(XEN) Total of 8 processors activated.
(XEN) ENABLING IO-APIC IRQs
(XEN) -> Using new ACK method
(XEN) TSC is reliable, synchronization unnecessary
(XEN) Platform timer is 14.318MHz HPET
(XEN) Allocated console ring of 16 KiB.
(XEN) Brought up 8 CPUs
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Xen kernel: 64-bit, lsb, compat32
(XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1708000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN) Dom0 alloc.: 00000001a4000000->00000001a8000000 (1498406 pages to be
allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN) Loaded kernel: ffffffff81000000->ffffffff81708000
(XEN) Init. ramdisk: ffffffff81708000->ffffffff8332a400
(XEN) Phys-Mach map: ffffffff8332b000->ffffffff83eb9930
(XEN) Start info: ffffffff83eba000->ffffffff83eba4b4
(XEN) Page tables: ffffffff83ebb000->ffffffff83ede000
(XEN) Boot stack: ffffffff83ede000->ffffffff83edf000
(XEN) TOTAL: ffffffff80000000->ffffffff84000000
(XEN) ENTRY ADDRESS: ffffffff81531200
(XEN) Dom0 has maximum 8 VCPUs
(XEN) Scrubbing Free RAM: .done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type \047CTRL-a\047 three times to switch
input to Xen)
(XEN) Freed 176kB init memory.
The "(XEN) Intel VT-d DMA Passthrough not supported." entry stands out
to me,
but doesn''t mean anything.
Any ideas?
This message and any attachment are intended solely for the addressee and may
contain confidential information. If you have received this message in error,
please send it back to me, and immediately delete it. Please do not use, copy
or disclose the information contained in this message or in any attachment. Any
views or opinions expressed by the author of this email do not necessarily
reflect the views of the University of Nottingham.
This message has been checked for viruses but the contents of an attachment
may still contain software viruses which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.