Xen project Mailing List

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.

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