search for: lpae

...ives/html/xen-arm/2011-09/msg00013.html for more details. I am pleased to announce that significant progress has been made, and that we now have a nascent Xen port for Cortex-A15. The port is based on xen-unstable (HG CS 8d6edc3d26d2) and written from scratch exploiting the latest virtualization, LPAE, GIC and generic timer support in hardware. We started the work less than three months ago, but the port is already capable of booting a Linux 3.0 based virtual machine (dom0) up to a shell prompt on an ARM Architecture Envelope Model, configured to emulate an A15-based Versatile Express. In this...

...ives/html/xen-arm/2011-09/msg00013.html for more details. I am pleased to announce that significant progress has been made, and that we now have a nascent Xen port for Cortex-A15. The port is based on xen-unstable (HG CS 8d6edc3d26d2) and written from scratch exploiting the latest virtualization, LPAE, GIC and generic timer support in hardware. We started the work less than three months ago, but the port is already capable of booting a Linux 3.0 based virtual machine (dom0) up to a shell prompt on an ARM Architecture Envelope Model, configured to emulate an A15-based Versatile Express. In this...

...ives/html/xen-arm/2011-09/msg00013.html for more details. I am pleased to announce that significant progress has been made, and that we now have a nascent Xen port for Cortex-A15. The port is based on xen-unstable (HG CS 8d6edc3d26d2) and written from scratch exploiting the latest virtualization, LPAE, GIC and generic timer support in hardware. We started the work less than three months ago, but the port is already capable of booting a Linux 3.0 based virtual machine (dom0) up to a shell prompt on an ARM Architecture Envelope Model, configured to emulate an A15-based Versatile Express. In this...

On Tue, Mar 03, 2015 at 07:37:47PM -0600, Dennis Gilmore wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all, > > I was testing oz/imagefactory on 32 bit arm, you have to have > kernel-lpae installed to run kvm. while you can have the regular > kernel installed also. You end up having the system booting the regular > kernel and you do not get kvm. Ideally supermin will work with the lpae > kernel. > https://github.com/libguestfs/supermin/blob/master/src/kernel.ml#L112 &gt...

On 11/25/2016 05:17 PM, Peter Zijlstra wrote: > On Fri, Nov 25, 2016 at 04:10:04PM +0000, Mark Rutland wrote: >> On Fri, Nov 25, 2016 at 04:21:39PM +0100, Dmitry Vyukov wrote: > >>> What are use cases for such primitive that won't be OK with "read once >>> _and_ atomically"? >> >> I have none to hand. > > Whatever triggers the

On 11/25/2016 05:17 PM, Peter Zijlstra wrote: > On Fri, Nov 25, 2016 at 04:10:04PM +0000, Mark Rutland wrote: >> On Fri, Nov 25, 2016 at 04:21:39PM +0100, Dmitry Vyukov wrote: > >>> What are use cases for such primitive that won't be OK with "read once >>> _and_ atomically"? >> >> I have none to hand. > > Whatever triggers the

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I was testing oz/imagefactory on 32 bit arm, you have to have kernel-lpae installed to run kvm. while you can have the regular kernel installed also. You end up having the system booting the regular kernel and you do not get kvm. Ideally supermin will work with the lpae kernel. https://github.com/libguestfs/supermin/blob/master/src/kernel.ml#L112 explictly removes it....

...> >> lowmem yourself. You will still have to deal with remapping pages that > >> aren't currently visible to the CPU (ok this is not an issue on Jetson > >> right now as it only has 2GB of RAM), because it's in systems highmem, > >> or even in a different LPAE area. > >> > >> You really want to be sure you are aware of all the consequences of > >> this, before considering this task. > > > > Yep, that's why I am seeking advice here. My first hope is that with a > > few tweaks we will be able to keep using...

...rself. You will still have to deal with remapping pages that >>> >> aren't currently visible to the CPU (ok this is not an issue on Jetson >>> >> right now as it only has 2GB of RAM), because it's in systems highmem, >>> >> or even in a different LPAE area. >>> >> >>> >> You really want to be sure you are aware of all the consequences of >>> >> this, before considering this task. >>> > >>> > Yep, that's why I am seeking advice here. My first hope is that with a >>>...

...ching state of pages in the systems > lowmem yourself. You will still have to deal with remapping pages that > aren't currently visible to the CPU (ok this is not an issue on Jetson > right now as it only has 2GB of RAM), because it's in systems highmem, > or even in a different LPAE area. > > You really want to be sure you are aware of all the consequences of > this, before considering this task. Yep, that's why I am seeking advice here. My first hope is that with a few tweaks we will be able to keep using TTM and the current nouveau_bo implementation. But unle...

...e: > > On 11/25/2016 05:17 PM, Peter Zijlstra wrote: > > There were several cases that I found during writing the *ONCE stuff. > > For example there are some 32bit ppc variants with 64bit PTEs. Some for > > others (I think sparc). > > We have similar on 32-bit ARM w/ LPAE. LPAE implies that a naturally > aligned 64-bit access is single-copy atomic, which is what makes that > ok. > > > And the mm/ code is perfectly fine with these PTE accesses being done > > NOT atomic. > > That strikes me as surprising. Is there some mutual exclusion tha...

...t; You could put a WARN in there to easily find them. >> >> There were several cases that I found during writing the *ONCE stuff. >> For example there are some 32bit ppc variants with 64bit PTEs. Some for >> others (I think sparc). > > We have similar on 32-bit ARM w/ LPAE. LPAE implies that a naturally > aligned 64-bit access is single-copy atomic, which is what makes that > ok. > >> And the mm/ code is perfectly fine with these PTE accesses being done >> NOT atomic. > > That strikes me as surprising. Is there some mutual exclusion that...

...32bit. > > > > You could put a WARN in there to easily find them. > > There were several cases that I found during writing the *ONCE stuff. > For example there are some 32bit ppc variants with 64bit PTEs. Some for > others (I think sparc). We have similar on 32-bit ARM w/ LPAE. LPAE implies that a naturally aligned 64-bit access is single-copy atomic, which is what makes that ok. > And the mm/ code is perfectly fine with these PTE accesses being done > NOT atomic. That strikes me as surprising. Is there some mutual exclusion that prevents writes from occuring whe...

...ages in the systems >> lowmem yourself. You will still have to deal with remapping pages that >> aren't currently visible to the CPU (ok this is not an issue on Jetson >> right now as it only has 2GB of RAM), because it's in systems highmem, >> or even in a different LPAE area. >> >> You really want to be sure you are aware of all the consequences of >> this, before considering this task. > > Yep, that's why I am seeking advice here. My first hope is that with a > few tweaks we will be able to keep using TTM and the current nouveau_b...

...9;t shock me if someone wants to negotiate this for >> virtio_mmio some day, but that might be more of a device tree thing. >> I have no idea how that works, but I think it can wait until someone >> wants it. > > At one point I wanted VirtIO-MMIO to not fail miserably on ARM LPAE systems. > > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/241613.html > Since I know nothing about LPAE, I'll leave this to you :) But I'll cc you on patch v2 soon, and please tell me whether my code makes sense on ARM. (My attempt to boot-test s390 failed be...

...9;t shock me if someone wants to negotiate this for >> virtio_mmio some day, but that might be more of a device tree thing. >> I have no idea how that works, but I think it can wait until someone >> wants it. > > At one point I wanted VirtIO-MMIO to not fail miserably on ARM LPAE systems. > > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/241613.html > Since I know nothing about LPAE, I'll leave this to you :) But I'll cc you on patch v2 soon, and please tell me whether my code makes sense on ARM. (My attempt to boot-test s390 failed be...

...-a15 -enable-kvm -m 512 -kernel mach-virt-guest-3.11-zImage -display none -serial stdio -netdev type=user,id=mynet -device virtio-net-device,netdev=mynet -drive index=0,id=mydrive,file=saucy-server-cloudimg-armhf.img -device virtio-blk-device,drive=mydrive -initrd saucy-server-cloudimg-armhf-initrd-lpae -append "console=ttyAMA0 root=/dev/vda" Does anyone have any suggestions for converting the rest of it, specifically the -netdev, -drive, and -device params? Here is what domxml-from-native gives: <domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0&...

...; lowmem yourself. You will still have to deal with remapping pages that >> >> aren't currently visible to the CPU (ok this is not an issue on Jetson >> >> right now as it only has 2GB of RAM), because it's in systems highmem, >> >> or even in a different LPAE area. >> >> >> >> You really want to be sure you are aware of all the consequences of >> >> this, before considering this task. >> > >> > Yep, that's why I am seeking advice here. My first hope is that with a >> > few tweaks we will...

...ill still have to deal with remapping pages that >>>> >> aren't currently visible to the CPU (ok this is not an issue on Jetson >>>> >> right now as it only has 2GB of RAM), because it's in systems highmem, >>>> >> or even in a different LPAE area. >>>> >> >>>> >> You really want to be sure you are aware of all the consequences of >>>> >> this, before considering this task. >>>> > >>>> > Yep, that's why I am seeking advice here. My first hope is that...

...) started in HYP mode. > [ 0.053111] CPU: Virtualization extensions available. > [ 1.572315] ledtrig-cpu: registered to indicate activity on CPUs > [ 1.575670] ThumbEE CPU extension supported. > root@cubietruck:~# dmesg | grep SMP > [ 0.000000] Linux version 4.3.0-1-armmp-lpae > (debian-kernel@lists.debian.org) (gcc version 4.9.3 (Debian 4.9.3-11) ) #1 > SMP Debian 4.3.5-1 (2016-02-06) > [ 0.000000] Forcing write-allocate cache policy for SMP > [ 0.053098] SMP: Total of 2 processors activated (96.00 BogoMIPS). > root@cubietruck:~# dmesg | grep kvm &g...