[Xen-devel] [libvirt test] 50442: trouble: blocked/broken/fail/pass
flight 50442 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/50442/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm3 host-install(3) broken REGR. vs. 50368 test-amd64-amd64-libvirt-xsm 3 host-install(3) broken REGR. vs. 50368 build-i386-libvirt3 host-install(3) broken REGR. vs. 50368 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 6 xen-boot fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass version targeted for testing: libvirt 9289c85841659ba00bdc747748eb54ca8991d3a0 baseline version: libvirt 225aa80246d5e4a9e3a16ebd4c482525045da3db People who touched revisions under test: Alexander Burluka aburl...@parallels.com Andrea Bolognani abolo...@redhat.com Cédric Bosdonnat cbosdon...@suse.com Dawid Zamirski dzamir...@datto.com Dmitry Guryanov dgurya...@parallels.com Eric Blake ebl...@redhat.com Erik Skultety eskul...@redhat.com Huanle Han hanxue...@gmail.com Jiri Denemark jdene...@redhat.com John Ferlan jfer...@redhat.com Ján Tomko jto...@redhat.com Lubomir Rintel lkund...@v3.sk Luyao Huang lhu...@redhat.com Martin Kletzander mklet...@redhat.com Maxim Nestratov mnestra...@parallels.com Michael Chapman m...@very.puzzling.org Michal Privoznik mpriv...@redhat.com Pavel Hrdina phrd...@redhat.com Peter Krempa pkre...@redhat.com Richard W. M. Jones rjo...@redhat.com Serge Hallyn serge.hal...@ubuntu.com Shanzhi Yu s...@redhat.com Xing Lin xing...@cs.utah.edu jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm broken build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt broken build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-xsm broken test-armhf-armhf-libvirt-xsm fail test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/osstest/pub/logs images: /home/osstest/pub/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-step build-i386-xsm host-install(3) broken-step test-amd64-amd64-libvirt-xsm host-install(3) broken-step build-i386-libvirt host-install(3) Not pushing. (No revision log; it would be 1914 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.3-testing test] 50431: regressions - trouble: blocked/broken/fail/pass
flight 50431 xen-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/50431/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-rumpuserxen4 capture-logs!broken in 50358 [st=!broken!] build-amd64-rumpuserxen 4 capture-logs!broken in 50358 [st=!broken!] build-i386-rumpuserxen 3 host-install(3) broken in 50358 REGR. vs. 36755 build-amd64-rumpuserxen 3 host-install(3) broken in 50358 REGR. vs. 36755 test-amd64-i386-freebsd10-i386 10 guest-start fail REGR. vs. 36755 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-sedf 3 host-install(3) broken pass in 50409 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 3 host-install(3) broken pass in 50409 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail in 50358 pass in 50431 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 50409 pass in 50358 test-amd64-i386-xl-win7-amd64 12 guest-localmigrate fail pass in 50409 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-localmigrate.2 fail pass in 50409 test-amd64-i386-freebsd10-amd64 16 guest-localmigrate/x10 fail pass in 50409 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-sedf4 capture-logs(4) broken in 50358 blocked in 36755 test-armhf-armhf-xl-credit2 7 capture-logs(7) broken in 50358 blocked in 36755 test-armhf-armhf-xl-cubietruck 7 capture-logs(7) broken in 50358 blocked in 36755 test-armhf-armhf-libvirt7 capture-logs(7) broken in 50358 blocked in 36755 test-armhf-armhf-xl 7 capture-logs(7) broken in 50358 blocked in 36755 test-armhf-armhf-xl-multivcpu 7 capture-logs(7) broken in 50358 blocked in 36755 test-armhf-armhf-xl-sedf-pin 7 capture-logs(7) broken in 50358 blocked in 36755 test-armhf-armhf-xl-arndale 7 capture-logs(7) broken in 50358 blocked in 36755 test-amd64-i386-pair21 guest-migrate/src_host/dst_host fail like 36755 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail in 50358 never pass test-armhf-armhf-xl-sedf 6 xen-boot fail in 50409 never pass test-amd64-i386-xl-win7-amd64 16 guest-stop fail in 50409 never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 16 guest-stop fail in 50409 never pass test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass test-armhf-armhf-xl-credit2 6 xen-boot fail never pass test-armhf-armhf-xl-cubietruck 6 xen-boot fail never pass test-armhf-armhf-libvirt 6 xen-boot fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-winxpsp3 16 guest-stop fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 16 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 16 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 20 leak-check/check fail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 16 guest-stop fail never pass build-i386-rumpuserxen6 xen-buildfail never pass build-amd64-rumpuserxen 6 xen-buildfail never pass test-amd64-i386-xl-winxpsp3-vcpus1 16 guest-stop fail never pass test-armhf-armhf-xl 6 xen-boot fail never pass test-armhf-armhf-xl-multivcpu 6 xen-boot fail never pass test-armhf-armhf-xl-sedf-pin 6 xen-boot fail never pass test-armhf-armhf-xl-arndale 6 xen-boot fail never pass test-amd64-i386-xend-qemut-winxpsp3 20 leak-check/checkfail never pass version targeted for testing: xen 46ed0083a76efa82713ea979b312fa69250380b2 baseline version: xen c58b16ef1572176cf2f6a424b527b5ed4bb73f17 People who touched revisions under test: Andrew Cooper andrew.coop...@citrix.com Ian Campbell ian.campb...@citrix.com Ian Jackson ian.jack...@eu.citrix.com Jan Beulich jbeul...@suse.com Konrad Rzeszutek Wilk konrad.w...@oracle.com
[Xen-devel] Intercepting page access
Hi I am working in a research project
I want to incercept pages access by guest virtual machine.
My approach is setting higher priviledge in pages by setting changing
the user/sypervisor priviledge bit in page table entry associated to
this page. Here is the piece of code used
void remove_access(l1_pgentry_t *pl1e){
l1_pgentry_t ol1e;
l1_pgentry_t nl1e;
unsigned int nmfn;
if(__copy_from_user(ol1e, pl1e, sizeof(ol1e)) == 0){
nl1e = ol1e;
nmfn = l1e_get_pfn(ol1e);
if(!(l1e_get_flags(ol1e)_PAGE_GUEST_KERNEL))
{
l1e_remove_flags(nl1e, _PAGE_USER);
if(__copy_to_guest(pl1e, nl1e,
sizeof(nl1e)) != 0)
printk(entry cannot be
copied\n);
flush_tlb_all();
}
}else
printk(copy from user failed\n);
}
the pointer pl1e is obtained when PTE is updated (in do_mm_update).
in page fault handler (do_page_fault). I reset the access by this code
void reset_access(l1_pgentry_t *pl1e, l1_pgentry_t ol1e)
{
l1_pgentry_t nl1e = ol1e;
l1e_add_flags(nl1e, _PAGE_USER);
__copy_to_guest(pl1e, nl1e, sizeof(nl1e));
flush_tlb_all();
return;
}
but the problem is that my computer crash and it reboots. I don't know
what is wrong with my code. I spend 2 weeks trying to solve this problem
but I couldn't. Please I really need your help
Thank you
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Question about DMA on 1:1 mapping dom0 of arm64
On Fri, Apr 17, 2015 at 03:32:20PM +0100, Stefano Stabellini wrote:
On Fri, 17 Apr 2015, Chen Baozi wrote:
Hi all,
According to my recent experience, there might be some problems of swiotlb
dma map on 1:1 mapping arm64 dom0 with large memory. The issue is like
below:
For those arm64 server with large memory, it is possible to set dom0_mem
4G (e.g. I have one set with 16G). In this case, according to my
understanding,
there is chance that the dom0 kernel needs to map some buffers above 4G to
do
DMA operations (e.g. in snps,dwmac ethernet driver). However, most DMA
engines
support only 32-bit physical address, thus aren't able to operate directly
on
those memory. IIUC, swiotlb is implemented to solve this (using bounce
buffer),
if there is no IOMMU or IOMMU is not enabled on the system. Sadly, it seems
that xen_swiotlb_map_page in my dom0 kernel allocates
(start_dma_addr = 0x94480) the buffers for DMA above 4G which fails
dma_capable() checking and was then unable to return from
xen_swiotlb_map_page()
successfully.
If I set dom0_mem to a small value (e.g. 512M), which makes all physical
memory
of dom0 below 4G, everything goes fine.
I am not familiar with swiotlb-xen, so there would be misunderstanding about
the current situation. Fix me if I did/understood anything wrong.
Any ideas?
I think that the problem is that xen_swiotlb_init doesn't necessarely allocate
memory under 4G on arm/arm64.
xen_swiotlb_init calls __get_free_pages to allocate memory, so the pages
could easily be above 4G. Subsequently xen_swiotlb_fixup is called on
the allocated memory range, calling xen_create_contiguous_region and
passing an address_bits mask. However xen_create_contiguous_region
doesn't actually do anything at all on ARM.
I think that given that dom0 is mapped 1:1 on ARM, the easiest and best
fix would be to simply allocate memory under 4G to begin with. Something
like (maybe with an ifdef ARM around it):
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 810ad41..22ac33a 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -235,7 +235,7 @@ retry:
#define SLABS_PER_PAGE (1 (PAGE_SHIFT - IO_TLB_SHIFT))
#define IO_TLB_MIN_SLABS ((120) IO_TLB_SHIFT)
while ((SLABS_PER_PAGE order) IO_TLB_MIN_SLABS) {
- xen_io_tlb_start = (void
*)__get_free_pages(__GFP_NOWARN, order);
+ xen_io_tlb_start = (void
*)__get_free_pages(__GFP_NOWARN|__GFP_DMA32, order);
^^ __GFP_DMA works on arm64
Cheers,
Baozi.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxl: initialize vfb defbools in libxlMakeVfb
On Fri, Apr 17, Jim Fehlig wrote: On 04/17/2015 11:19 AM, Olaf Hering wrote: +libxl_defbool_set(x_vfb-vnc.enable, 0); Not shown here, but just before the switch is libxl_device_vfb_init(x_vfb); which IIUC (looking at the impl in $xensrc/tools/libxl/_libxl_types.c) should initialize the vfb struct with default values. Yes, but the default values lead to the assert. Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxl: initialize vfb defbools in libxlMakeVfb
On Fri, Apr 17, Jim Fehlig wrote: On 04/17/2015 11:59 AM, Olaf Hering wrote: On Fri, Apr 17, Olaf Hering wrote: If the domU configu has sdl enabled libvirtd crashes: libvirtd[5158]: libvirtd: libxl.c:343: libxl_defbool_val: Assertion `!libxl_defbool_is_default(db)' failed. Initialize the relevant defbool variables in libxl_device_vfb. Fix one crash, find another: Does libvirt have a representation for this one? libxl_defbool_val(vfb.sdl.opengl)); I'm not aware of any way to specify OpenGL in libvirt domXML. The qemu-dm process runs without DISPLAY=0:0, which leads to a failure if sdl is enabled. Once I will try to find the time I will see if setting DISPLAY= will actually help. xl.cfg(5) states that display= and xauthority= are currently not handled anyway. And libvirt lacks such functionality as well if I understand the docs correctly. Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] converting gatewaydev= from domU.cfg to libvirt.xml fails
On Fri, Apr 17, Jim Fehlig wrote:
On 04/17/2015 12:50 PM, Olaf Hering wrote:
How should this be converted?
/etc/init.d/boot.local
tap=xentap
tunctl -pt ${tap}
ip addr add 1.1.1.1/29 dev ${tap}
ip link set up dev ${tap}
domU.cfg
vif=[
'mac=00:16:3e:13:01:00,ip=1.1.1.2,type=vif,gatewaydev=xentap,script=vif-route'
]
The result from convert-xml xen-xl domU,cfg is:
interface type='ethernet'
mac address='00:16:3e:13:01:00'/
ip address='1.1.1.2' family='ipv4'/
script path='vif-route'/
/interface
gatewaydev= is missing, the guest will not start.
libvirt doesn't support 'gatewaydev'. I'm certainly no expert in this area,
but is it possible to convert your host config in boot.local to a libvirt
routed network [1] and then have the guest use it with something like
interface type='network'
source network='boot.local.equiv'/
...
/interface
I will have to check how this is supposed to work, but it seems the
xen-xl to xml converter should recognize this variant.
Olaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Question about DMA on 1:1 mapping dom0 of arm64
Hi Stefano,
On Fri, Apr 17, 2015 at 03:32:20PM +0100, Stefano Stabellini wrote:
On Fri, 17 Apr 2015, Chen Baozi wrote:
Hi all,
According to my recent experience, there might be some problems of swiotlb
dma map on 1:1 mapping arm64 dom0 with large memory. The issue is like
below:
For those arm64 server with large memory, it is possible to set dom0_mem
4G (e.g. I have one set with 16G). In this case, according to my
understanding,
there is chance that the dom0 kernel needs to map some buffers above 4G to
do
DMA operations (e.g. in snps,dwmac ethernet driver). However, most DMA
engines
support only 32-bit physical address, thus aren't able to operate directly
on
those memory. IIUC, swiotlb is implemented to solve this (using bounce
buffer),
if there is no IOMMU or IOMMU is not enabled on the system. Sadly, it seems
that xen_swiotlb_map_page in my dom0 kernel allocates
(start_dma_addr = 0x94480) the buffers for DMA above 4G which fails
dma_capable() checking and was then unable to return from
xen_swiotlb_map_page()
successfully.
If I set dom0_mem to a small value (e.g. 512M), which makes all physical
memory
of dom0 below 4G, everything goes fine.
I am not familiar with swiotlb-xen, so there would be misunderstanding about
the current situation. Fix me if I did/understood anything wrong.
Any ideas?
I think that the problem is that xen_swiotlb_init doesn't necessarely allocate
memory under 4G on arm/arm64.
xen_swiotlb_init calls __get_free_pages to allocate memory, so the pages
could easily be above 4G. Subsequently xen_swiotlb_fixup is called on
the allocated memory range, calling xen_create_contiguous_region and
passing an address_bits mask. However xen_create_contiguous_region
doesn't actually do anything at all on ARM.
I think that given that dom0 is mapped 1:1 on ARM, the easiest and best
fix would be to simply allocate memory under 4G to begin with. Something
like (maybe with an ifdef ARM around it):
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 810ad41..22ac33a 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -235,7 +235,7 @@ retry:
#define SLABS_PER_PAGE (1 (PAGE_SHIFT - IO_TLB_SHIFT))
#define IO_TLB_MIN_SLABS ((120) IO_TLB_SHIFT)
while ((SLABS_PER_PAGE order) IO_TLB_MIN_SLABS) {
- xen_io_tlb_start = (void
*)__get_free_pages(__GFP_NOWARN, order);
+ xen_io_tlb_start = (void
*)__get_free_pages(__GFP_NOWARN|__GFP_DMA32, order);
if (xen_io_tlb_start)
break;
order--;
I have no idea if __GFP_DMA32 on arm64 has something wrong. But It looks like
that it doesn't help...
Here is the memory info about what xen has populated to dom0 (I did some hacks
to allocate_memory_11 to make it map some low memory banks to dom0):
(XEN) Allocating 1:1 mappings totalling 16384MB for dom0:
(XEN) BANK[0] 0x008800-0x009800 (256MB)
(XEN) BANK[1] 0x00a000-0x00f800 (1408MB)
(XEN) BANK[2] 0x04-0x06 (8192MB)
(XEN) BANK[3] 0x068000-0x07 (2048MB)
(XEN) BANK[4] 0x08-0x09 (4096MB)
(XEN) BANK[5] 0x094000-0x095800 (384MB)
And Here is the printk info I got when trying to map a dma page:
enter xen_swiotlb_map_page.
phys = 0x9444e4042, dev_addr = 0x9444e4042, size = 0x600
start_dma_addr = 0x94480
virt_to_phys(xen_io_tlb_start) = 0x94480
Oh Well, have to allocate and map a bounce buffer.
map = 0x94480
dev_addr = 0x94480
*dev-dma_mask = 0x
!dma_capable(0xffc8bd384810, 0x94480, 0x600)
And the patch I used for dom0 hacking:
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 810ad41..96465cf 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -235,7 +235,7 @@ retry:
#define SLABS_PER_PAGE (1 (PAGE_SHIFT - IO_TLB_SHIFT))
#define IO_TLB_MIN_SLABS ((120) IO_TLB_SHIFT)
while ((SLABS_PER_PAGE order) IO_TLB_MIN_SLABS) {
- xen_io_tlb_start = (void
*)__get_free_pages(__GFP_NOWARN, order);
+ xen_io_tlb_start = (void
*)__get_free_pages(__GFP_NOWARN|__GFP_DMA32, order);
if (xen_io_tlb_start)
break;
order--;
@@ -391,6 +391,13 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct
page *page,
dma_addr_t dev_addr = xen_phys_to_bus(phys);
BUG_ON(dir == DMA_NONE);
+ printk(enter xen_swiotlb_map_page.\n);
+ printk(phys = 0x%lx, dev_addr = 0x%lx, size = 0x%lx\n,
+ phys, dev_addr, size);
+ printk(start_dma_addr = 0x%lx\n, start_dma_addr);
+ printk(virt_to_phys(xen_io_tlb_start) = 0x%lx\n,
+ virt_to_phys(xen_io_tlb_start));
+
/*
* If
Re: [Xen-devel] Question about DMA on 1:1 mapping dom0 of arm64
On Fri, Apr 17, 2015 at 05:13:16PM +0100, Stefano Stabellini wrote: On Fri, 17 Apr 2015, Ian Campbell wrote: On Fri, 2015-04-17 at 15:34 +0100, Stefano Stabellini wrote: If I set dom0_mem to a small value (e.g. 512M), which makes all physical memory of dom0 below 4G, everything goes fine. So you are getting allocated memory below 4G? You message on IRC suggested you weren't, did you hack around this? I think we have two options, either xen_swiotlb_init allocates pages below 4GB (e.g. __GFP_DMA) or we do something to allow xen_swiotlb_fixup to actually work even on a 1:1 dom0. I don't think that making xen_swiotlb_fixup work on ARM is a good idea: it would break the 1:1. This would actually work though, I think, because this is the swiotlb so we definitely have the opportunity to return the actual DMA address whenever we use this buffer and the device will use it in the right places for sure. The code is pretty complex as is -- I would rather avoid adding more complexity to it. For example we would need to bring back a mechanism to track dma address - pseudo-physical address mappings on arm, even though it would be far simpler of course. Also I think it makes sense to use the swiotlb buffer for its original purpose. If we could introduce a mechanism to get a lower than 4G buffer in dom0, but matching the 1:1, I think it would make the maintenance much easier on the linux side. +1 Actually, we have already had the mechanism on arm32 to populate at least one bank of memory below 4G. Thus, the only thing we have to do on the hypervisor side is to make arm32 and arm64 share the same process in allocate_memory_11(), removing the 'lowmem = is_32bit_domain(d)' related conditions. If this is acceptable, the only thing we need to do in Linux kernel is to add the __GFP_DMA flag when allocating pages for xen_io_tlb_start in xen_swiotlb_init. Baozi. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Question about DMA on 1:1 mapping dom0 of arm64
On Sat, Apr 18, 2015 at 05:08:58PM +0800, Chen Baozi wrote:
On Fri, Apr 17, 2015 at 05:13:16PM +0100, Stefano Stabellini wrote:
On Fri, 17 Apr 2015, Ian Campbell wrote:
On Fri, 2015-04-17 at 15:34 +0100, Stefano Stabellini wrote:
If I set dom0_mem to a small value (e.g. 512M), which makes all
physical memory
of dom0 below 4G, everything goes fine.
So you are getting allocated memory below 4G?
You message on IRC suggested you weren't, did you hack around this?
I think we have two options, either xen_swiotlb_init allocates pages
below 4GB (e.g. __GFP_DMA) or we do something to allow
xen_swiotlb_fixup
to actually work even on a 1:1 dom0.
I don't think that making xen_swiotlb_fixup work on ARM is a good idea:
it would break the 1:1.
This would actually work though, I think, because this is the swiotlb so
we definitely have the opportunity to return the actual DMA address
whenever we use this buffer and the device will use it in the right
places for sure.
The code is pretty complex as is -- I would rather avoid adding more
complexity to it. For example we would need to bring back a mechanism
to track dma address - pseudo-physical address mappings on arm, even
though it would be far simpler of course.
Also I think it makes sense to use the swiotlb buffer for its original
purpose.
If we could introduce a mechanism to get a lower than 4G buffer in dom0,
but matching the 1:1, I think it would make the maintenance much easier
on the linux side.
+1
Actually, we have already had the mechanism on arm32 to populate at least
one bank of memory below 4G. Thus, the only thing we have to do on the
hypervisor side is to make arm32 and arm64 share the same process in
allocate_memory_11(), removing the 'lowmem = is_32bit_domain(d)' related
conditions. If this is acceptable, the only thing we need to do in Linux
kernel is to add the __GFP_DMA flag when allocating pages for xen_io_tlb_start
in xen_swiotlb_init.
This is the hacks I'm using:
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 40a5303..d83a2b1 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -264,7 +264,7 @@ static void allocate_memory_11(struct domain *d, struct
kernel_info *kinfo)
unsigned int order = get_11_allocation_size(kinfo-unassigned_mem);
int i;
-bool_t lowmem = is_32bit_domain(d);
+bool_t lowmem = true;
unsigned int bits;
printk(Allocating 1:1 mappings totalling %ldMB for dom0:\n,
@@ -279,7 +279,7 @@ static void allocate_memory_11(struct domain *d, struct
kernel_info *kinfo)
*/
while ( order = min_low_order )
{
-for ( bits = order ; bits = (lowmem ? 32 : PADDR_BITS); bits++ )
+for ( bits = order ; bits = 32 ; bits++ )
{
pg = alloc_domheap_pages(d, order, MEMF_bits(bits));
if ( pg != NULL )
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
