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@lists.xen.org> wrote:
> Send Xen-devel mailing list submissions to
> xen-devel@lists.xen.org
>
> 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@lists.xen.org
>
> You can reach the person managing the list at
> xen-devel-owner@lists.xen.org
>
> 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@gmx.de>
> To: xen-devel@lists.xen.org
> 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@suse.com>
> To: <konrad.wilk@oracle.com>
> Cc: Ian.Campbell@citrix.com, xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] Dom0 physical networking/swiotlb/something
> issue in 3.7-rc1
> Message-ID: <509D3EAB020000780008F4B6@nat28.tlf.novell.com>
> Content-Type: text/plain; charset=US-ASCII
>
> >>> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 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@suse.com> 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@amazon.com>
> To: Ian Campbell <Ian.Campbell@citrix.com>
> Cc: "george.dunlap@eu.citrix.com"
<george.dunlap@eu.citrix.com>,
> "xen-devel@lists.xensource.com"
<xen-devel@lists.xensource.com>,
> John
> Weekes <lists.xen@nuclearfallout.net>, Roger Pau Monne
> <roger.pau@citrix.com>
> Subject: Re: [Xen-devel] Bugs in xl that affect stubdom+tapdisk2, and
> others
> Message-ID:
> <20121109195553.GA11023@u109add4315675089e695.ant.amazon.com>
> 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@eu.citrix.com>
> To: <xen-devel@lists.xensource.com>
> Cc: ian.jackson@eu.citrix.com
> Subject: [Xen-devel] [xen-unstable test] 14377: tolerable FAIL
> Message-ID: <osstest-14377-mainreport@xen.org>
> 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@jelsupport.com>
> To: <xen-devel@lists.xen.org>
> Subject: [Xen-devel] .vhd will not boot in VM
> Message-ID: <F2EF84CA5BCF824AA4197956E124073848F4AE@server.jel.local>
> 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@lists.xen.org
> 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@lists.xen.org
http://lists.xen.org/xen-devel
Can''t run Xen-4.3 unstable kernel with old xm tools:
WARING: Can''t find version unstable of xen utils, fallback to default
version!
Error: Unable to connect to xend: No such file or directory. Is xend
running?
Guessing the same will be true of running the older 4.1 kernel with the new
xl toolstack, so not sure how to proceed in testing.
I should mention that the only reason I was testing 4.3 was because there
is a bug in usb-linux.c compiled into qemu-dm from 4.1 where you are unable
to attach a usb device which has a serial interface (eg: game controller
with analog controls). My Logitech Driving Force GT wheel works fine in
4.1 but some Xbox controller couldn''t be successfully passed through to
the
DomU.
Perhaps I should be investigating some other avenue?
I suppose this is very unlikely to be a big deal for anyone. I''m not
using
the controller, was just testing usb-passthrough of devices I knew would
have a serial interface riding on top of usb.
Problem was solved in KVM qemu with a very simple patch and was wondering
if Xen had applied the same patch.
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 11:42 AM, feral <blistovmhz@gmail.com> wrote:
> 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@lists.xen.org>
wrote:
>
>> Send Xen-devel mailing list submissions to
>> xen-devel@lists.xen.org
>>
>> 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@lists.xen.org
>>
>> You can reach the person managing the list at
>> xen-devel-owner@lists.xen.org
>>
>> 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@gmx.de>
>> To: xen-devel@lists.xen.org
>> 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@suse.com>
>> To: <konrad.wilk@oracle.com>
>> Cc: Ian.Campbell@citrix.com, xen-devel@lists.xen.org
>> Subject: Re: [Xen-devel] Dom0 physical networking/swiotlb/something
>> issue in 3.7-rc1
>> Message-ID: <509D3EAB020000780008F4B6@nat28.tlf.novell.com>
>> Content-Type: text/plain; charset=US-ASCII
>>
>> >>> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
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@suse.com> 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@amazon.com>
>> To: Ian Campbell <Ian.Campbell@citrix.com>
>> Cc: "george.dunlap@eu.citrix.com"
<george.dunlap@eu.citrix.com>,
>> "xen-devel@lists.xensource.com"
<xen-devel@lists.xensource.com>,
>> John
>> Weekes <lists.xen@nuclearfallout.net>, Roger Pau Monne
>> <roger.pau@citrix.com>
>> Subject: Re: [Xen-devel] Bugs in xl that affect stubdom+tapdisk2, and
>> others
>> Message-ID:
>>
<20121109195553.GA11023@u109add4315675089e695.ant.amazon.com>
>> 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@eu.citrix.com>
>> To: <xen-devel@lists.xensource.com>
>> Cc: ian.jackson@eu.citrix.com
>> Subject: [Xen-devel] [xen-unstable test] 14377: tolerable FAIL
>> Message-ID: <osstest-14377-mainreport@xen.org>
>> 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@jelsupport.com>
>> To: <xen-devel@lists.xen.org>
>> Subject: [Xen-devel] .vhd will not boot in VM
>> Message-ID:
<F2EF84CA5BCF824AA4197956E124073848F4AE@server.jel.local>
>> 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@lists.xen.org
>> 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.
>
--
_____
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@lists.xen.org
http://lists.xen.org/xen-devel
On Sat, 2012-11-10 at 19:42 +0000, feral wrote:> 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?Because you appear to have turned on the option to receive the digest version of the list. If you want individual messages then you need to login to your account at http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel and turn off that option. In any case please don''t quote the *entire* digest when replying, it is doubly important to trim your quotes in this case. In this case you included thousands of pointless lines of quotes. Ian.
Please trim your quotes, especially when replying to the digest. You should adjust the subject line to reference the actual mail you are replying to and avoid top posting too. This is all covered in http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions. On Sat, 2012-11-10 at 20:11 +0000, feral wrote:> Can''t run Xen-4.3 unstable kernel with old xm tools: > WARING: Can''t find version unstable of xen utils, fallback to default > version! > Error: Unable to connect to xend: No such file or directory. Is xend > running? > > > Guessing the same will be true of running the older 4.1 kernel with > the new xl toolstack, so not sure how to proceed in testing.You always need to have a matched pair of hypervisor and tools, regardless of whether you are using xl or xm. You just need to install the tools at the same time as you install the hypervisor. Ian.