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

[Bruce Edge <bruce.edge@gmail.com>]

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

On Tue, Jul 6, 2010 at 9:24 AM, Richie <listmail@triad.rr.com> 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@ens-lyon.org <mailto:samuel.thibault@ens-lyon.org>>
>> 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@lists.xensource.com <mailto:Xen-devel@lists.xensource.com>
>>
>>    http://lists.xensource.com/xen-devel
>>
>>
>>
>

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

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

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