[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xen-devel Digest, Vol 93, Issue 79



Re: PCI/VGA passthrough on >Xen-4.2 - (XEN) AMD-Vi:
      IO_PAGE_FAULT: (Hans Mueller)
OMG, why do most messages only show up in the daily batch but not individually?

@Hans
As far as I can tell, the guest is running fine until we see the IO_PAGE_FAULT.  The machine is still pingable, but I suppose there's not much I can do to verify the DomU's state.
Going to try running the newer qemu with Xen 4.1 and then Xen-4.2/4.3 with the older qemu-dm today.


On Sat, Nov 10, 2012 at 4:00 AM, <xen-devel-request@xxxxxxxxxxxxx> wrote:
Send Xen-devel mailing list submissions to
        xen-devel@xxxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel
or, via email, send a message with subject or body 'help' to
        xen-devel-request@xxxxxxxxxxxxx

You can reach the person managing the list at
        xen-devel-owner@xxxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Xen-devel digest..."


Today's Topics:

   1. Re: PCI/VGA passthrough on >Xen-4.2 - (XEN) AMD-Vi:
      IO_PAGE_FAULT: (Hans Mueller)
   2. Re: Dom0 physical networking/swiotlb/something issue in
      3.7-rc1 (Jan Beulich)
   3. Re: Bugs in xl that affect stubdom+tapdisk2, and others
      (Matt Wilson)
   4. [xen-unstable test] 14377: tolerable FAIL (xen.org)
   5. .vhd will not boot in VM (Juan Lorenzana)


----------------------------------------------------------------------

Message: 1
Date: Fri, 09 Nov 2012 18:14:39 +0100
From: Hans Mueller <mcbeagle@xxxxxx>
To: xen-devel@xxxxxxxxxxxxx
Subject: Re: [Xen-devel] PCI/VGA passthrough on >Xen-4.2 - (XEN)
        AMD-Vi: IO_PAGE_FAULT:
Message-ID: <1871003.0Pup8WfsfS@sheik-lin>
Content-Type: text/plain; charset="us-ascii"

On Friday, 9. November 2012 16:33:47 Ian Campbell wrote:
> On Fri, 2012-11-09 at 16:25 +0000, Hans Mueller wrote:
> > On Thursday, 8. November 2012 20:02:51 feral wrote:
> > > Upgraded from Xen-4.1 to 4.2/4.3/4.3-unstable.  Tested against all
> > > three.
> > >
> > > VGA passthrough previously working with 4.1 is no longer working with
> > > >4.2.
> > >
> > > Setup - Working:
> > > Mint13, kernel-3.2.0-32, Xen-4.1 (from Ubuntu-Precise repos),
> > > libvirt-bin,
> > > xend
> > > Asus Radeon HD 7870 DirectCU.
> > > Works perfect.  Benches on par with bare metal.
> > >
> > > Setup - Broken:
> > > Mint13, kernel-3.2.0-32, Xen-4.2,Xen-4.3,Xen-4.3-unstable (from GIT), xl
> > > toolstack.
> > > Asus Radeon HD 7870 DirectCU.
> > > Some times the guest boots correctly but display is never enabled.
> > >
> > >  Sometimes BSOD, doesn't seem to be any rhyme or reason?
> > >
> > > No errors in logs.   Found the following in 'xl dmesg':
> > > (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 2, device id = 0x600, fault
> > > address =
> > > 0x1ac800000, flags = 0
> >
> > I had a similar problem since hg revision 25818:50adc933faaf which changes
> > the qemu tag.
> > It looks like the qemu commit
> > 3e66da7266c84638c0e22a09c9d2b07529802576
> > (qemu-xen-trad: fix msi_translate with PV event delivery)
> > causes this behavior.
> >
> > I solved the problem for me by using 'pci_msitranslate=0' in the domU
> > config.
> I don't follow this stuff closely but I could have sworn we had disabled
> msitranslate by default.
>
> In any case I don't think that changeset was intended to cause anything
> like this -- Stefano?
>
> > In addition I had to reboot (perhaps poweroff?) the dom0 once the
> > IO_PAGE_FAULT occured.

One more info for you - afair i noticed that it was not only the IO_PAGE_FAULT
which occured but also the qemu process in dom0 crashed w/o any messages in
the logs, perhaps feral can confirm this?




------------------------------

Message: 2
Date: Fri, 09 Nov 2012 17:34:35 +0000
From: "Jan Beulich" <jbeulich@xxxxxxxx>
To: <konrad.wilk@xxxxxxxxxx>
Cc: Ian.Campbell@xxxxxxxxxx, xen-devel@xxxxxxxxxxxxx
Subject: Re: [Xen-devel] Dom0 physical networking/swiotlb/something
        issue in 3.7-rc1
Message-ID: <509D3EAB020000780008F4B6@xxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=US-ASCII

>>> Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> 11/09/12 2:48 PM >>>
>On Fri, Nov 09, 2012 at 11:43:39AM +0000, Jan Beulich wrote:
>> >>> On 09.11.12 at 11:36, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>> > In the forward ported kernels, those two checks are however
>> > accompanied by range_needs_mapping() (aka
>> > range_straddles_page_boundary()) checks, which ought to
>> > take care of this. There is brokenness there with the invocations
>> > of gnttab_dma_map_page(), but only if the initial offset is at
>> > least PAGE_SIZE - will have to check whether that occurs.
>>
>> And indeed, fixing this also makes the problem go away when
>> the allocation order doesn't get forced to zero. So presumably
>> there's also only that one problem I had pointed out in pv-ops.
>
>The pvops one has this in the map-page variant (xen_swiotlb_map_page):
>
>351         if (dma_capable(dev, dev_addr, size) &&
>352             !range_straddles_page_boundary(phys, size) && !swiotlb_force)
>353                 return dev_addr;
>
>and in the sg variant:
>
>494                 if (swiotlb_force ||
>495                     !dma_capable(hwdev, dev_addr, sg->length) ||
>496                     range_straddles_page_boundary(paddr, sg->length)) {
>497                         void *map = swiotlb_tbl_map_single(hwdev,

Oh, right, I forgot that there's yet another clone of that code under drivers/xen/.

>So I think that check is OK. There is no gnttab_dma_map_page call - so that
>can't be the issue.

Indeed.

Jan




------------------------------

Message: 3
Date: Fri, 9 Nov 2012 11:55:55 -0800
From: Matt Wilson <msw@xxxxxxxxxx>
To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Cc: "george.dunlap@xxxxxxxxxxxxx" <george.dunlap@xxxxxxxxxxxxx>,
        "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>,        John
        Weekes <lists.xen@xxxxxxxxxxxxxxxxxx>,  Roger Pau Monne
        <roger.pau@xxxxxxxxxx>
Subject: Re: [Xen-devel] Bugs in xl that affect stubdom+tapdisk2, and
        others
Message-ID:
        <20121109195553.GA11023@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"

On Fri, Nov 09, 2012 at 01:29:04PM +0000, Ian Campbell wrote:
> On Thu, 2012-11-08 at 20:45 +0000, John Weekes wrote:
> > As an additional note about 4.2 -- this isn't an "xl" issue, but rather
> > a build problem -- even though I use "./configure --libdir=/usr/lib64",
> > the build is still creating a "dist/install/usr/lib" directory, and
> > because of this, running ./install.sh nukes my system's "/usr/lib" ->
> > "/usr/lib64" softlink (which in turn causes all sorts of other problems
> > until it's corrected). Files that are being put in that tree:
> >
> > xen-4.2-testing.hg # find dist/install/usr/lib
> > dist/install/usr/lib
>
> This is an interesting one. I'm not sure how we can avoid this
> behaviour, perhaps there is a tar option to cause it to follow rather
> than clobber synlinks?
>
> The only other choice I can think of is to change install.sh to use a
> (long) explicit list of $(FOO_DIR)/* entries instead of the single * to
> avoid including system directories, or to otherwise make install.sh more
> fragile and prone to bitrot :-(

Oh dear. If we find that there's not a good reason for it anymore, I'd
think it would be better to remove install.sh instead.

> I must confess I didn't realise anyone used install.sh -- is there some
> advantage to it over make foo-install?
>
> OOI which distro has this lib->lib64 link and what issues does removing
> it create?
>
> > dist/install/usr/lib/xen
>
> This is $(XENFIRMWAREDIR). I have a feeling there is a reason this is
> not using $(LIBDIR), but I don't recall what it was -- Roget/Matt do you
> remember?

There's no need for these files to be multilib compatible, as they are
not runtime DSOs. They're internal to Xen and I think that they should
be moved to $LIBEXECDIR instead, like /usr/libexec/xen/. Unfortunately
there's not much agreement on the usefulness of /usr/libexec, so we'll
need to make sure that packagers can adjust the paths for their
systems' standards.

For 4.2 we didn't want to change where these files were being placed,
and I believe they've bin in $PREFIX/lib/ for quite some time.

Matt

> Thanks again for reporting all these.
>
> Ian.
>
> > dist/install/usr/lib/xen/boot
> > dist/install/usr/lib/xen/boot/xenstore-stubdom.gz
> > dist/install/usr/lib/xen/boot/ioemu-stubdom.gz
> > dist/install/usr/lib/xen/boot/pv-grub-x86_64.gz
> > dist/install/usr/lib/xen/boot/hvmloader
> > dist/install/usr/lib/xen/boot/pv-grub-x86_32.gz
> > dist/install/usr/lib/xen/bin
> > dist/install/usr/lib/xen/bin/stubdom-dm
> > dist/install/usr/lib/xen/bin/qemu-io
> > dist/install/usr/lib/xen/bin/qemu-nbd
> > dist/install/usr/lib/xen/bin/qemu-img
> > dist/install/usr/lib/xen/bin/xenpaging
> > dist/install/usr/lib/xen/bin/qemu-dm
> > dist/install/usr/lib/xen/bin/qemu-system-i386
> > dist/install/usr/lib/xen/bin/qemu-ga
> > dist/install/usr/lib/xen/bin/stubdompath.sh



------------------------------

Message: 4
Date: Sat, 10 Nov 2012 05:53:35 +0000
From: xen.org <ian.jackson@xxxxxxxxxxxxx>
To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Cc: ian.jackson@xxxxxxxxxxxxx
Subject: [Xen-devel] [xen-unstable test] 14377: tolerable FAIL
Message-ID: <osstest-14377-mainreport@xxxxxxx>
Content-Type: text/plain

flight 14377 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14377/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14376
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14376
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14376
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14376

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  62885b3c34c8
baseline version:
 xen                  62885b3c34c8

jobs:
 build-amd64                                                  pass
 build-i386                                                   pass
 build-amd64-oldkern                                          pass
 build-i386-oldkern                                           pass
 build-amd64-pvops                                            pass
 build-i386-pvops                                             pass
 test-amd64-amd64-xl                                          pass
 test-amd64-i386-xl                                           pass
 test-amd64-i386-rhel6hvm-amd                                 pass
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail
 test-amd64-amd64-xl-win7-amd64                               fail
 test-amd64-i386-xl-win7-amd64                                fail
 test-amd64-i386-xl-credit2                                   pass
 test-amd64-amd64-xl-pcipt-intel                              fail
 test-amd64-i386-rhel6hvm-intel                               pass
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass
 test-amd64-i386-xl-multivcpu                                 pass
 test-amd64-amd64-pair                                        pass
 test-amd64-i386-pair                                         pass
 test-amd64-amd64-xl-sedf-pin                                 fail
 test-amd64-amd64-pv                                          pass
 test-amd64-i386-pv                                           pass
 test-amd64-amd64-xl-sedf                                     fail
 test-amd64-i386-win-vcpus1                                   fail
 test-amd64-i386-xl-win-vcpus1                                fail
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail
 test-amd64-amd64-win                                         fail
 test-amd64-i386-win                                          fail
 test-amd64-amd64-xl-win                                      fail
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail
 test-amd64-i386-xend-winxpsp3                                fail
 test-amd64-amd64-xl-winxpsp3                                 fail


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.




------------------------------

Message: 5
Date: Fri, 9 Nov 2012 04:01:36 -0700
From: "Juan Lorenzana" <juan@xxxxxxxxxxxxxx>
To: <xen-devel@xxxxxxxxxxxxx>
Subject: [Xen-devel] .vhd will not boot in VM
Message-ID: <F2EF84CA5BCF824AA4197956E124073848F4AE@xxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"

We had a XCP 1.5 pool with 2 machines as hosts.  The storage pool which
as NFS mounted lost its ability to export the filesystem with the VM
images on it.



We contacted the vendor and we were able to restore it.  However, they
had recommended that we delete the XCP Pool, recreate it, add the hosts
back in, and then mount the storage.



That is where we are at now.  We can see the storage and the VM images.
However in XCP Xen Center when looking at the images is clear that the
metadata is lost.  So we can not see which image or snap shot belongs to
which VM.  The names all are blank when we look at the storage.



Also, if I randomly mount an image to a VM, it does not boot.  It
produces an error that says:



Traceback (most recent call last): - File "/usr/binpygrub", line 808, in
? - fs = fsimage.open(file,part_offs[0[, bootfsoptions) - IOError:
[Errno 95] Operation not supported.



The system kept the VM information as we destroyed the pool and then
created a new one but it looks like we only see snapshots through
XenCenter.  Its like the real .vhd that were running are not showing up.



I know it is pretty bad.  We should not have listened to the storage
guys.



Does anyone know someone that can help?



Juan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xen.org/archives/html/xen-devel/attachments/20121109/a085ab22/attachment.html>

------------------------------

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


End of Xen-devel Digest, Vol 93, Issue 79
*****************************************



--
_____
Fact:
1. Ninjas are mammals.
2. Ninjas fight ALL the time.
3. The purpose of the ninja is to flip out and kill people.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.