Re: [PATCH 1/2] disk: Add support for device-specific malloc function

["Vladimir 'phcoder' Serbinenko" <phcoder@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3954 bytes --]

Le ven. 26 févr. 2016 14:48, Andrei Borzenkov <arvidjaar@gmail.com> a
écrit :

> On Fri, Feb 26, 2016 at 4:27 PM, Vladimir 'phcoder' Serbinenko
> <phcoder@gmail.com> wrote:
> > Andrei, your patch is pretty complicated and would be a subject to
> putting
> > into next branch because of its breakage potential. Issue at hand affects
> > x86 as well. Can we split the solution from radical rework of disk.c with
> > optimisations?
> >
>
> Then we need to add additional small read to for unaligned beginning
> of user supplied buffer in main agglomeration loop. It is doable I
> think.
>
It's not. If you try, then the remaining read is not sector-aligned. I like
Leif's approach: fix small reads and do copying if necessary. This fixes
most of problems and lets us fix others whenever we feel to. It also allows
us to easier use similar approach for DMA drivers. I'm thinking of having
some code to reuse user-supplied buffer for DMA when possible

>
> > Le mer. 24 févr. 2016 20:04, Andrei Borzenkov <arvidjaar@gmail.com> a
> écrit
> > :
> >>
> >> 24.02.2016 20:40, Andrei Borzenkov пишет:
> >> > 24.02.2016 16:57, Leif Lindholm пишет:
> >> >> On Wed, Feb 24, 2016 at 03:09:13PM +0300, Andrei Borzenkov wrote:
> >> >>>>> Could you test attached patch with your alignment fixes on top.
> This
> >> >>>>> implements my idea of using shared buffers. Seems to work in naive
> >> >>>>> testing.
> >> >>>>
> >> >>>> Testing this with a grub-mkstandalone image, I get:
> >> >>>>
> >> >>>> kern/dl.c:556: flushing 0x10f1 bytes at 0x9ffb5ac20
> >> >>>> kern/dl.c:649: module name: tar
> >> >>>> kern/dl.c:650: init function: 0x9ffb5b220
> >> >>>> kern/disk.c:217: Opening `memdisk'...
> >> >>>> kern/fs.c:56: Detecting tarfs...
> >> >>>>
> >> >>>> And then spectacular crash in UEFI due to an EL2 translation fault.
> >> >>>
> >> >>> To be sure - is it with my patch alone or with your patches? If some
> >> >>> more patches are used - could you send exact diff to trunk to avoid
> >> >>> misunderstanding?
> >> >>
> >> >> Double checked with only your patch on top of
> >> >> 1b782e902e69516f82158203674d4951a40c82d4 (previously running with
> >> >> _only_ my alignment fixup in efidisk.c). Same behaviour.
> >> >
> >> > I cannot reproduce it on x86_64 (also with mm-debug enabled) and I do
> >> > not know how to load standalone image on ppc; is it possible to use
> QEMU
> >> > to run ARM64 (I assume you have it)? If not what are options to test
> it?
> >> >
> >> > Anyway, there was one problem I fixed later (although I did not get
> any
> >> > issue before as well), I attach updated version. Thank you for
> testing!
> >> >
> >>
> >> I still cannot reproduce it with either patch version using current GIT
> >> QEMU + binary QEMU_EFI.fd from
> >>
> >>
> http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upstream/554/QEMU-AARCH64/RELEASE_GCC49/QEMU_EFI.fd
> ;
> >> I run it as
> >>
> >> aarch64-softmmu/qemu-system-aarch64  -m 1024 -cpu cortex-a57 -M virt
> >> -bios ~/vm/QEMU_EFI.fd -cdrom /tmp/grub.iso -serial stdio
> >>
> >> Where grub.iso is built
> >>
> >> pkgdatadir=$PWD ./grub-mkstandalone -d grub-core -O arm64-efi -o
> >> /tmp/grub.efi
> >> pkgdatadir=$PWD ./grub-mkrescue -d grub-core -o /tmp/grub.iso
> >> /grub.efi=/tmp/grub.efi
> >>
> >> and I do
> >>
> >> chainloader /grub.efi
> >> boot
> >>
> >> after that.
> >>
> >> _______________________________________________
> >> Grub-devel mailing list
> >> Grub-devel@gnu.org
> >> https://lists.gnu.org/mailman/listinfo/grub-devel
> >
> >
> > _______________________________________________
> > Grub-devel mailing list
> > Grub-devel@gnu.org
> > https://lists.gnu.org/mailman/listinfo/grub-devel
> >
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #2: Type: text/html, Size: 5913 bytes --]