Re: [Xen-devel] pv-grub boot hangs when iommu=soft. Booting kernel directly with the flags works

[Bruce Edge <bruce.edge@xxxxxxxxx>]

On Tue, Jul 6, 2010 at 9:24 AM, Richie <listmail@xxxxxxxxxxxx> wrote:

Are you able to pv-grub boot while specifying iommu=soft?

The 2 options I'm playing around with are:  iommu=soft and swiotlb=force

With both:

With just iommu=soft:

close network: backend at /local/domain/0/backend/vif/29/0

port 4 still bound!

<hang>

With just iommu=soft:

close network: backend at /local/domain/0/backend/vif/29/0

port 4 still bound!

<hang>

With just swiotlb=force:

Has problems mounting rootfs. Fails inconsistenly, but always in some reference to mounting root.

With neither option:

Boots ok, but lspci shows no devices even though dom0 shows 2 PCI devices:

   (image

        (linux

            (kernel /usr/lib/xen/boot/pv-grub-x86_64.gz)

            (args '(nd)/import/tools/pxe/kaan-01-dpm/menu.lst')

            (superpages 0)

            (videoram 4)

            (pci

                ((0x0000 0x04 0x00 0x0 0x100 ())

                    (0x0000 0x04 0x00 0x1 0x100 ())

                )

            )

            (serial pty)

            (nomigrate 0)

            (tsc_mode 0)

            (notes)

        )

    )

-Bruce

 

To clarify this specific issue; the problem was that minios would produce an error message (see example, specifically: port 5 still bound!) and fail to boot the kernel.  I suspect if that if you are able to boot then the kernel would receive and make use of the parameter as it normally would.

# xm create -c ubstub.cfg

Using config file "/etc/xen/ubstub.cfg".
Started domain lucidpv (id=2)
Xen Minimal OS!
 start_info: 0xa9a000(VA)
  nr_pages: 0x20000
 shared_inf: 0xbf44d000(MA)
   pt_base: 0xa9d000(VA)
nr_pt_frames: 0x9
  mfn_list: 0x99a000(VA)
 mod_start: 0x0(VA)
   mod_len: 0
     flags: 0x0
  cmd_line: (hd0)/boot/grub/menu.lst
 stack:      0x959980-0x979980
MM: Init
    _text: 0x0(VA)
   _etext: 0x6987c(VA)
 _erodata: 0x83000(VA)
   _edata: 0x8bae0(VA)
stack start: 0x959980(VA)
     _end: 0x999f88(VA)
 start_pfn: aa9
  max_pfn: 20000
Mapping memory range 0xc00000 - 0x20000000
setting 0x0-0x83000 readonly
skipped 0x1000
MM: Initialise page allocator for ba3000(ba3000)-20000000(20000000)
MM: done
Demand map pfns at 20001000-2020001000.
Heap resides at 2020002000-4020002000.
 Booting command-list

root  (hd0)
Filesystem type is ext2fs, using whole disk
kernel  /boot/vmlinuz-2.6.32.10-xen2  root=UUID=2bb30c38-70fc-4e9d-ae69-52db68589a
2e ro iommu=soft swiotlb=force
initrd  /boot/initrd.img-2.6.32.10-xen2

block error -2 for op 2
close blk: backend=/local/domain/0/backend/vbd/2/51712 node=device/vbd/51712
port 5 still bound!

Bruce Edge wrote:

On Wed, Apr 7, 2010 at 9:57 AM, Samuel Thibault <samuel.thibault@xxxxxxxxxxxx <mailto:samuel.thibault@xxxxxxxxxxxx>> wrote:

   listmail, le Wed 07 Apr 2010 12:53:19 -0400, a écrit :
   > "If the 'iommu=soft swiotlb=force' is removed it boots"
   >
   > but in actuality,  "switotlb=force" can be left in and it boots
   ok as well.
   > From what I've see it is only when having "iommu=soft" added in that
   > exposes the issue.

   Ok, so the problem really is the combination of pv-grub and
   iommu=soft.


Any update on this problem?
I'm assuming that this is related to my inability to pass through PCI devices to a domU when using pv-grub as such requires the use of iommu=soft.

-Bruce
 

   > I understand that you have communicated that you don't have time for
   > this in near future and I respect that, however, if there is
   something
   > specific to try that would shed more light on the issue then let me
   > know.

   I have no idea off-hand.  In "I don't have time in the near future", I
   mean that other people could perhaps have a closer look at the
   issue...

   Samuel

   _______________________________________________
   Xen-devel mailing list

   Xen-devel@xxxxxxxxxxxxxxxxxxx <mailto:Xen-devel@xxxxxxxxxxxxxxxxxxx>

   http://lists.xensource.com/xen-devel

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