Re: TianoCore KVM Port: Status Update
On Fri, Mar 28, 2014 at 08:57:15PM -0400, Michael Casadevall wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > On 03/28/2014 08:17 PM, Christoffer Dall wrote: > > On Fri, Mar 28, 2014 at 07:17:49PM -0400, Michael Casadevall > > wrote: > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > >> > >> > >> > >> On 03/28/2014 05:29 PM, Christoffer Dall wrote: > >>> On Fri, Mar 28, 2014 at 05:08:03PM -0400, Michael Casadevall > >>> wrote: > >> > >>> if you run the interrupt handler you are not stuck in wfi, but > >>> re-execute it, and it's your software wait condition which is > >>> the problem - likely related to the missing rtc? > >>> > >> > >> The pc returns to the wfi instruction after executing the > >> interrupt handler; this is in a bit of assembly, and not in C > >> code. > > > > It shouldn't. It should return to the instruction after the wfi > > instruction. > > > > Which is why I think there's a bug somewhere :-) This was what I was > banging my head on at LC until I commented it out. Obviously thats not > the correct thing to do, but I'm unsure if this is KVM or EFI doing > something it shouldn't. As I said, I'm not convinced the GIC driver in > EFI is 100% correct. If your exception return is directly to the WFI instruction (and it's not because you do another iteration of the loop), then it sounds like the exception handler in UEFI is written incorrectly. KVM should not be involved at all in an RFE from EL0 to EL1. Also reading the virtual counter happens directly without trapping, so I would be equally surprised there. Sounds to me like you need to trace the execution of UEFI exactly and figure out what it's doing. If you can write up a guide on how to reproduce your results and where to look in the UEFI code, then I can try taking a look. (Writing such a guide may be needed and useful in any case). -Christoffer ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: TianoCore KVM Port: Status Update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/28/2014 08:17 PM, Christoffer Dall wrote: > On Fri, Mar 28, 2014 at 07:17:49PM -0400, Michael Casadevall > wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> >> >> On 03/28/2014 05:29 PM, Christoffer Dall wrote: >>> On Fri, Mar 28, 2014 at 05:08:03PM -0400, Michael Casadevall >>> wrote: >> >>> if you run the interrupt handler you are not stuck in wfi, but >>> re-execute it, and it's your software wait condition which is >>> the problem - likely related to the missing rtc? >>> >> >> The pc returns to the wfi instruction after executing the >> interrupt handler; this is in a bit of assembly, and not in C >> code. > > It shouldn't. It should return to the instruction after the wfi > instruction. > Which is why I think there's a bug somewhere :-) This was what I was banging my head on at LC until I commented it out. Obviously thats not the correct thing to do, but I'm unsure if this is KVM or EFI doing something it shouldn't. As I said, I'm not convinced the GIC driver in EFI is 100% correct. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTNhprAAoJEGKVRgSEnX1QbyAIAI4kIlHVAfK+Kj1aAW+ROun/ oVyU49EAjq1vttmk5MHousH5DrA68N+IpNJf1RRBCk2yANfVxvIgjwhGXZsLeJZP rz+asuI+Nx3o/LmcCn99sjAq4QkD0tftlURAznJ5Bg4yo9xxAC4xIo1YxyMf3Jh1 PNYrPAwMeCP5lwlcl7L/l7vs/XWIle1mVuQby7MqdxVTfuxrxazLVmFqfovtqmSq rdrMhFqzbAtbU7S6uOjiSVUFpHqSehOm+f8K9rdxuQl+EJHRcxJixISeRyKKBS/V 1o7iHqsl4M4gbBYLqyBD9NKRHUQv0kTpN3zwPNMUIu0/buGNbwXzNDDurhjTm+Y= =5D4b -END PGP SIGNATURE- ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: TianoCore KVM Port: Status Update
On Fri, Mar 28, 2014 at 07:17:49PM -0400, Michael Casadevall wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > On 03/28/2014 05:29 PM, Christoffer Dall wrote: > > On Fri, Mar 28, 2014 at 05:08:03PM -0400, Michael Casadevall > > wrote: > > > if you run the interrupt handler you are not stuck in wfi, but > > re-execute it, and it's your software wait condition which is the > > problem - likely related to the missing rtc? > > > > The pc returns to the wfi instruction after executing the interrupt > handler; this is in a bit of assembly, and not in C code. It shouldn't. It should return to the instruction after the wfi instruction. -Christoffer ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: TianoCore KVM Port: Status Update
On 28 March 2014 19:38, Michael Casadevall wrote: > On 03/28/2014 02:09 PM, Christoffer Dall wrote: >> On Fri, Mar 28, 2014 at 04:26:59AM -0400, Michael Casadevall >> wrote: >>> Previous attempts to debug assets shows that EFI does "odd" >>> things to the stack when we hit an exception, making walking it >>> with GDB impossible. I need to figure out what madness EFI does >>> with my SP so I can get the entire stack on an explosion, but >>> this remains at best hopeful thinking. >> >> This sounds very strange - could it be that because you take an >> exception, you use a SP from a different mode and everything just >> messes up? >> > > This could be GDB just being unhappy. I've had issues walking the > stack in KVM in general, but even if I walk the stack by hand, I don't > see a pointer to the next frame when we're in an exception. To my > knowledge, UEFI uses the standard AArch64 C ABI, but this might be a > faulty exception on my part. There's a bug in QEMU's AArch64 KVM support which means we don't do the right thing with SP on syncing state to/from the kernel, so don't trust that (Fixed either in master or in my a64-system patchset, I forget which). thanks -- PMM ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: TianoCore KVM Port: Status Update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/28/2014 05:29 PM, Christoffer Dall wrote: > On Fri, Mar 28, 2014 at 05:08:03PM -0400, Michael Casadevall > wrote: > if you run the interrupt handler you are not stuck in wfi, but > re-execute it, and it's your software wait condition which is the > problem - likely related to the missing rtc? > The pc returns to the wfi instruction after executing the interrupt handler; this is in a bit of assembly, and not in C code. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTNgMdAAoJEGKVRgSEnX1QINEIAI8tEIjR3jReF/DzFlNqMmYw 1MYlgd1+WVhwPnBZrBMw9G+TBiHpNN+8b9Dzf0JPkNcXX2efkQYpn6ZFMAkVkKIF INlYepocXW9lW9jl23JIsvYBkIUta+63XT9zP803ZS9p+FPq1ycmjkC2JIx8PRBF Psbn6QeA+6Y3Nh4GqRU5ziKT2csS4SetYTH3RluhJJJP21k1pumDvUhne+38EPKM Ii0CVXCLcSX0z9cih2pejkagKV10SzUvIUrB5fU8DQUlaQyZdo0RJ8uBjP0yC3dY pTQE1GGRJ+Kt02V/9y6No8VWnnGz5gFw0u8v6gu79JE3b39F73nbFPtKvBI0rb8= =idUs -END PGP SIGNATURE- ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: TianoCore KVM Port: Status Update
On Fri, Mar 28, 2014 at 05:08:03PM -0400, Michael Casadevall wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> On 03/28/2014 05:02 PM, Christoffer Dall wrote:
> > On Fri, Mar 28, 2014 at 04:08:52PM -0400, Michael Casadevall
> > wrote:
> >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
> >>
> >>
> >>
> >> On 03/28/2014 03:47 PM, Christoffer Dall wrote:
> >>> On Fri, Mar 28, 2014 at 03:38:28PM -0400, Michael Casadevall
> >>> wrote:
> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>
>
>
> On 03/28/2014 02:09 PM, Christoffer Dall wrote:
> > On Fri, Mar 28, 2014 at 04:26:59AM -0400, Michael
> > Casadevall wrote:
> >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
> >>
> >> As I've made a fair bit of headway since LinaroConnect,
> >> I wanted to drop a line on my current progress with
> >> porting TianoCore to KVM
> >>
> >> Summary (tl;dr version):
> >>
> >> KVM can start TianoCore, and boot all the way to shell,
> >> and access HDDs via VirtioBlk. We can start grub and
> >> successfully retrieve files from ext partitions, load a
> >> device tree, and start the kernel. The kernel runs
> >> through most of the EFI stub, but falls over during
> >> ExitBootServices()
> >
> > Thanks for providing this status!
> >
> >>
> >> Long Version:
> >>
> >> So, after much blood sweat and tears, we're finally at
> >> the point of trying to actually start a kernel, though
> >> this (for the moment) remains an elusive goal. The
> >> current problem is that once we call EBS(), we get an
> >> exception from EFI with no Image information, which means
> >> the exception handler doesn't know where it came from.
> >> After several seconds, we get a second exception from
> >> within DxeCore, and then EFI falls over.
> >>
> >> Debugging EFI is difficult and error prone, combined with
> >> limited debug facilities from the gdb-stub in QEMU (no
> >> breakpoints), and no decent way to load all of EFI
> >> itself (you have to run add-symbol-file manually with the
> >> output of commands printed on the console; supposedly its
> >> possible to generate a giant GdbSyms.dll file to import
> >> in a single go, but I haven't succeeded at this). This is
> >> further complicated that it appears we're asserting
> >> somewhere in a driver, and short of adding printfs to
> >> *every* driver, its impossible to know which is
> >> asseting.
> >
> > Maybe it's worth adding a hack-support-gdb-in-kvm
> > implementation for this. If we go down this road, I can
> > probably find time to help you out there.
> >
> > Can you do some scripting to replace assert statements with
> > "{ print("%s:%d\n", __FILE__, __LINE__); orig_assert(); }"
> > type hack?
> >
>
> That's probably a decent idea if I can find where ASSERT()
> is defined. I'll try that in a bit.
>
> >>
> >> Previous attempts to debug assets shows that EFI does
> >> "odd" things to the stack when we hit an exception,
> >> making walking it with GDB impossible. I need to figure
> >> out what madness EFI does with my SP so I can get the
> >> entire stack on an explosion, but this remains at best
> >> hopeful thinking.
> >
> > This sounds very strange - could it be that because you
> > take an exception, you use a SP from a different mode and
> > everything just messes up?
> >
>
> This could be GDB just being unhappy. I've had issues
> walking the stack in KVM in general, but even if I walk the
> stack by hand, I don't see a pointer to the next frame when
> we're in an exception. To my knowledge, UEFI uses the
> standard AArch64 C ABI, but this might be a faulty exception
> on my part.
>
> >>
> >> Further complicating things is that during EBS, my print
> >> debugging goes away. I might just cheat and roll a
> >> simple assembly function to bang out messages through
> >> serial without calling anything else. Ugly as sin, but
> >> this should let me get useful debug output through the
> >> EBS framework. Complicating matters is that I need to
> >> locate each and all EBS() event functions, which are
> >> spread *everywhere* in TianoCore, and then debug them
> >> each individually.
> >
> > I'm a little confused no knowing UEFI, is EBS() not a
> > single function and what does it matter that it's called
> > from multiple places?
> >
>
> So, drivers and applications can enlist to get notification
> of when ExitBootServices are called. This pushes a pointer to
> a function into an array when is then iterated through and
> this pointer is then called so drivers can unregister
> themselves from boot services, etc.
>
> Complicating
Re: TianoCore KVM Port: Status Update
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/28/2014 05:02 PM, Christoffer Dall wrote:
> On Fri, Mar 28, 2014 at 04:08:52PM -0400, Michael Casadevall
> wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>>
>>
>> On 03/28/2014 03:47 PM, Christoffer Dall wrote:
>>> On Fri, Mar 28, 2014 at 03:38:28PM -0400, Michael Casadevall
>>> wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
On 03/28/2014 02:09 PM, Christoffer Dall wrote:
> On Fri, Mar 28, 2014 at 04:26:59AM -0400, Michael
> Casadevall wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> As I've made a fair bit of headway since LinaroConnect,
>> I wanted to drop a line on my current progress with
>> porting TianoCore to KVM
>>
>> Summary (tl;dr version):
>>
>> KVM can start TianoCore, and boot all the way to shell,
>> and access HDDs via VirtioBlk. We can start grub and
>> successfully retrieve files from ext partitions, load a
>> device tree, and start the kernel. The kernel runs
>> through most of the EFI stub, but falls over during
>> ExitBootServices()
>
> Thanks for providing this status!
>
>>
>> Long Version:
>>
>> So, after much blood sweat and tears, we're finally at
>> the point of trying to actually start a kernel, though
>> this (for the moment) remains an elusive goal. The
>> current problem is that once we call EBS(), we get an
>> exception from EFI with no Image information, which means
>> the exception handler doesn't know where it came from.
>> After several seconds, we get a second exception from
>> within DxeCore, and then EFI falls over.
>>
>> Debugging EFI is difficult and error prone, combined with
>> limited debug facilities from the gdb-stub in QEMU (no
>> breakpoints), and no decent way to load all of EFI
>> itself (you have to run add-symbol-file manually with the
>> output of commands printed on the console; supposedly its
>> possible to generate a giant GdbSyms.dll file to import
>> in a single go, but I haven't succeeded at this). This is
>> further complicated that it appears we're asserting
>> somewhere in a driver, and short of adding printfs to
>> *every* driver, its impossible to know which is
>> asseting.
>
> Maybe it's worth adding a hack-support-gdb-in-kvm
> implementation for this. If we go down this road, I can
> probably find time to help you out there.
>
> Can you do some scripting to replace assert statements with
> "{ print("%s:%d\n", __FILE__, __LINE__); orig_assert(); }"
> type hack?
>
That's probably a decent idea if I can find where ASSERT()
is defined. I'll try that in a bit.
>>
>> Previous attempts to debug assets shows that EFI does
>> "odd" things to the stack when we hit an exception,
>> making walking it with GDB impossible. I need to figure
>> out what madness EFI does with my SP so I can get the
>> entire stack on an explosion, but this remains at best
>> hopeful thinking.
>
> This sounds very strange - could it be that because you
> take an exception, you use a SP from a different mode and
> everything just messes up?
>
This could be GDB just being unhappy. I've had issues
walking the stack in KVM in general, but even if I walk the
stack by hand, I don't see a pointer to the next frame when
we're in an exception. To my knowledge, UEFI uses the
standard AArch64 C ABI, but this might be a faulty exception
on my part.
>>
>> Further complicating things is that during EBS, my print
>> debugging goes away. I might just cheat and roll a
>> simple assembly function to bang out messages through
>> serial without calling anything else. Ugly as sin, but
>> this should let me get useful debug output through the
>> EBS framework. Complicating matters is that I need to
>> locate each and all EBS() event functions, which are
>> spread *everywhere* in TianoCore, and then debug them
>> each individually.
>
> I'm a little confused no knowing UEFI, is EBS() not a
> single function and what does it matter that it's called
> from multiple places?
>
So, drivers and applications can enlist to get notification
of when ExitBootServices are called. This pushes a pointer to
a function into an array when is then iterated through and
this pointer is then called so drivers can unregister
themselves from boot services, etc.
Complicating the issue is I can't use printf once
GetMemoryMap() is called without breaking EBS() (I think this
is a bug in UEFI, leif, 2 cents?, but I think I can twiddle
the serial port directly without breaking shit.
>>>
>>> yeah, just writing to the pl011 out should be trivial, or add
>>> an hvc
Re: TianoCore KVM Port: Status Update
On Fri, Mar 28, 2014 at 04:08:52PM -0400, Michael Casadevall wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> On 03/28/2014 03:47 PM, Christoffer Dall wrote:
> > On Fri, Mar 28, 2014 at 03:38:28PM -0400, Michael Casadevall
> > wrote:
> >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
> >>
> >>
> >>
> >> On 03/28/2014 02:09 PM, Christoffer Dall wrote:
> >>> On Fri, Mar 28, 2014 at 04:26:59AM -0400, Michael Casadevall
> >>> wrote:
> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>
> As I've made a fair bit of headway since LinaroConnect, I
> wanted to drop a line on my current progress with porting
> TianoCore to KVM
>
> Summary (tl;dr version):
>
> KVM can start TianoCore, and boot all the way to shell, and
> access HDDs via VirtioBlk. We can start grub and
> successfully retrieve files from ext partitions, load a
> device tree, and start the kernel. The kernel runs through
> most of the EFI stub, but falls over during
> ExitBootServices()
> >>>
> >>> Thanks for providing this status!
> >>>
>
> Long Version:
>
> So, after much blood sweat and tears, we're finally at the
> point of trying to actually start a kernel, though this (for
> the moment) remains an elusive goal. The current problem is
> that once we call EBS(), we get an exception from EFI with no
> Image information, which means the exception handler doesn't
> know where it came from. After several seconds, we get a
> second exception from within DxeCore, and then EFI falls
> over.
>
> Debugging EFI is difficult and error prone, combined with
> limited debug facilities from the gdb-stub in QEMU (no
> breakpoints), and no decent way to load all of EFI itself
> (you have to run add-symbol-file manually with the output of
> commands printed on the console; supposedly its possible to
> generate a giant GdbSyms.dll file to import in a single go,
> but I haven't succeeded at this). This is further complicated
> that it appears we're asserting somewhere in a driver, and
> short of adding printfs to *every* driver, its impossible to
> know which is asseting.
> >>>
> >>> Maybe it's worth adding a hack-support-gdb-in-kvm
> >>> implementation for this. If we go down this road, I can
> >>> probably find time to help you out there.
> >>>
> >>> Can you do some scripting to replace assert statements with "{
> >>> print("%s:%d\n", __FILE__, __LINE__); orig_assert(); }" type
> >>> hack?
> >>>
> >>
> >> That's probably a decent idea if I can find where ASSERT() is
> >> defined. I'll try that in a bit.
> >>
>
> Previous attempts to debug assets shows that EFI does "odd"
> things to the stack when we hit an exception, making walking
> it with GDB impossible. I need to figure out what madness EFI
> does with my SP so I can get the entire stack on an
> explosion, but this remains at best hopeful thinking.
> >>>
> >>> This sounds very strange - could it be that because you take an
> >>> exception, you use a SP from a different mode and everything
> >>> just messes up?
> >>>
> >>
> >> This could be GDB just being unhappy. I've had issues walking
> >> the stack in KVM in general, but even if I walk the stack by
> >> hand, I don't see a pointer to the next frame when we're in an
> >> exception. To my knowledge, UEFI uses the standard AArch64 C ABI,
> >> but this might be a faulty exception on my part.
> >>
>
> Further complicating things is that during EBS, my print
> debugging goes away. I might just cheat and roll a simple
> assembly function to bang out messages through serial
> without calling anything else. Ugly as sin, but this should
> let me get useful debug output through the EBS framework.
> Complicating matters is that I need to locate each and all
> EBS() event functions, which are spread *everywhere* in
> TianoCore, and then debug them each individually.
> >>>
> >>> I'm a little confused no knowing UEFI, is EBS() not a single
> >>> function and what does it matter that it's called from
> >>> multiple places?
> >>>
> >>
> >> So, drivers and applications can enlist to get notification of
> >> when ExitBootServices are called. This pushes a pointer to a
> >> function into an array when is then iterated through and this
> >> pointer is then called so drivers can unregister themselves from
> >> boot services, etc.
> >>
> >> Complicating the issue is I can't use printf once GetMemoryMap()
> >> is called without breaking EBS() (I think this is a bug in UEFI,
> >> leif, 2 cents?, but I think I can twiddle the serial port
> >> directly without breaking shit.
> >
> > yeah, just writing to the pl011 out should be trivial, or add an
> > hvc temporary hack to KVM, I've done things like that when
> > originally debugging kernel boot under KVM.
> >
>
> Just for the rec
Re: TianoCore KVM Port: Status Update
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/28/2014 03:47 PM, Christoffer Dall wrote:
> On Fri, Mar 28, 2014 at 03:38:28PM -0400, Michael Casadevall
> wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>>
>>
>> On 03/28/2014 02:09 PM, Christoffer Dall wrote:
>>> On Fri, Mar 28, 2014 at 04:26:59AM -0400, Michael Casadevall
>>> wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
As I've made a fair bit of headway since LinaroConnect, I
wanted to drop a line on my current progress with porting
TianoCore to KVM
Summary (tl;dr version):
KVM can start TianoCore, and boot all the way to shell, and
access HDDs via VirtioBlk. We can start grub and
successfully retrieve files from ext partitions, load a
device tree, and start the kernel. The kernel runs through
most of the EFI stub, but falls over during
ExitBootServices()
>>>
>>> Thanks for providing this status!
>>>
Long Version:
So, after much blood sweat and tears, we're finally at the
point of trying to actually start a kernel, though this (for
the moment) remains an elusive goal. The current problem is
that once we call EBS(), we get an exception from EFI with no
Image information, which means the exception handler doesn't
know where it came from. After several seconds, we get a
second exception from within DxeCore, and then EFI falls
over.
Debugging EFI is difficult and error prone, combined with
limited debug facilities from the gdb-stub in QEMU (no
breakpoints), and no decent way to load all of EFI itself
(you have to run add-symbol-file manually with the output of
commands printed on the console; supposedly its possible to
generate a giant GdbSyms.dll file to import in a single go,
but I haven't succeeded at this). This is further complicated
that it appears we're asserting somewhere in a driver, and
short of adding printfs to *every* driver, its impossible to
know which is asseting.
>>>
>>> Maybe it's worth adding a hack-support-gdb-in-kvm
>>> implementation for this. If we go down this road, I can
>>> probably find time to help you out there.
>>>
>>> Can you do some scripting to replace assert statements with "{
>>> print("%s:%d\n", __FILE__, __LINE__); orig_assert(); }" type
>>> hack?
>>>
>>
>> That's probably a decent idea if I can find where ASSERT() is
>> defined. I'll try that in a bit.
>>
Previous attempts to debug assets shows that EFI does "odd"
things to the stack when we hit an exception, making walking
it with GDB impossible. I need to figure out what madness EFI
does with my SP so I can get the entire stack on an
explosion, but this remains at best hopeful thinking.
>>>
>>> This sounds very strange - could it be that because you take an
>>> exception, you use a SP from a different mode and everything
>>> just messes up?
>>>
>>
>> This could be GDB just being unhappy. I've had issues walking
>> the stack in KVM in general, but even if I walk the stack by
>> hand, I don't see a pointer to the next frame when we're in an
>> exception. To my knowledge, UEFI uses the standard AArch64 C ABI,
>> but this might be a faulty exception on my part.
>>
Further complicating things is that during EBS, my print
debugging goes away. I might just cheat and roll a simple
assembly function to bang out messages through serial
without calling anything else. Ugly as sin, but this should
let me get useful debug output through the EBS framework.
Complicating matters is that I need to locate each and all
EBS() event functions, which are spread *everywhere* in
TianoCore, and then debug them each individually.
>>>
>>> I'm a little confused no knowing UEFI, is EBS() not a single
>>> function and what does it matter that it's called from
>>> multiple places?
>>>
>>
>> So, drivers and applications can enlist to get notification of
>> when ExitBootServices are called. This pushes a pointer to a
>> function into an array when is then iterated through and this
>> pointer is then called so drivers can unregister themselves from
>> boot services, etc.
>>
>> Complicating the issue is I can't use printf once GetMemoryMap()
>> is called without breaking EBS() (I think this is a bug in UEFI,
>> leif, 2 cents?, but I think I can twiddle the serial port
>> directly without breaking shit.
>
> yeah, just writing to the pl011 out should be trivial, or add an
> hvc temporary hack to KVM, I've done things like that when
> originally debugging kernel boot under KVM.
>
Just for the record, hvc?
>>
>> Having slept on it, its probably easy to print out the pointers
>> as we go through them, so I can get an idea of whats listening
>> for EBS and try and narrow down my list of candidates.
>>
>
> yes, add a function that side-steps all the UEFI-weirdness (should
> be a few lines sta
Re: TianoCore KVM Port: Status Update
On Fri, Mar 28, 2014 at 03:38:28PM -0400, Michael Casadevall wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> On 03/28/2014 02:09 PM, Christoffer Dall wrote:
> > On Fri, Mar 28, 2014 at 04:26:59AM -0400, Michael Casadevall
> > wrote:
> >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
> >>
> >> As I've made a fair bit of headway since LinaroConnect, I wanted
> >> to drop a line on my current progress with porting TianoCore to
> >> KVM
> >>
> >> Summary (tl;dr version):
> >>
> >> KVM can start TianoCore, and boot all the way to shell, and
> >> access HDDs via VirtioBlk. We can start grub and successfully
> >> retrieve files from ext partitions, load a device tree, and start
> >> the kernel. The kernel runs through most of the EFI stub, but
> >> falls over during ExitBootServices()
> >
> > Thanks for providing this status!
> >
> >>
> >> Long Version:
> >>
> >> So, after much blood sweat and tears, we're finally at the point
> >> of trying to actually start a kernel, though this (for the
> >> moment) remains an elusive goal. The current problem is that once
> >> we call EBS(), we get an exception from EFI with no Image
> >> information, which means the exception handler doesn't know where
> >> it came from. After several seconds, we get a second exception
> >> from within DxeCore, and then EFI falls over.
> >>
> >> Debugging EFI is difficult and error prone, combined with
> >> limited debug facilities from the gdb-stub in QEMU (no
> >> breakpoints), and no decent way to load all of EFI itself (you
> >> have to run add-symbol-file manually with the output of commands
> >> printed on the console; supposedly its possible to generate a
> >> giant GdbSyms.dll file to import in a single go, but I haven't
> >> succeeded at this). This is further complicated that it appears
> >> we're asserting somewhere in a driver, and short of adding
> >> printfs to *every* driver, its impossible to know which is
> >> asseting.
> >
> > Maybe it's worth adding a hack-support-gdb-in-kvm implementation
> > for this. If we go down this road, I can probably find time to
> > help you out there.
> >
> > Can you do some scripting to replace assert statements with "{
> > print("%s:%d\n", __FILE__, __LINE__); orig_assert(); }" type hack?
> >
>
> That's probably a decent idea if I can find where ASSERT() is defined.
> I'll try that in a bit.
>
> >>
> >> Previous attempts to debug assets shows that EFI does "odd"
> >> things to the stack when we hit an exception, making walking it
> >> with GDB impossible. I need to figure out what madness EFI does
> >> with my SP so I can get the entire stack on an explosion, but
> >> this remains at best hopeful thinking.
> >
> > This sounds very strange - could it be that because you take an
> > exception, you use a SP from a different mode and everything just
> > messes up?
> >
>
> This could be GDB just being unhappy. I've had issues walking the
> stack in KVM in general, but even if I walk the stack by hand, I don't
> see a pointer to the next frame when we're in an exception. To my
> knowledge, UEFI uses the standard AArch64 C ABI, but this might be a
> faulty exception on my part.
>
> >>
> >> Further complicating things is that during EBS, my print
> >> debugging goes away. I might just cheat and roll a simple
> >> assembly function to bang out messages through serial without
> >> calling anything else. Ugly as sin, but this should let me get
> >> useful debug output through the EBS framework. Complicating
> >> matters is that I need to locate each and all EBS() event
> >> functions, which are spread *everywhere* in TianoCore, and then
> >> debug them each individually.
> >
> > I'm a little confused no knowing UEFI, is EBS() not a single
> > function and what does it matter that it's called from multiple
> > places?
> >
>
> So, drivers and applications can enlist to get notification of when
> ExitBootServices are called. This pushes a pointer to a function into
> an array when is then iterated through and this pointer is then called
> so drivers can unregister themselves from boot services, etc.
>
> Complicating the issue is I can't use printf once GetMemoryMap() is
> called without breaking EBS() (I think this is a bug in UEFI, leif, 2
> cents?, but I think I can twiddle the serial port directly without
> breaking shit.
yeah, just writing to the pl011 out should be trivial, or add an hvc
temporary hack to KVM, I've done things like that when originally
debugging kernel boot under KVM.
>
> Having slept on it, its probably easy to print out the pointers as we
> go through them, so I can get an idea of whats listening for EBS and
> try and narrow down my list of candidates.
>
yes, add a function that side-steps all the UEFI-weirdness (should be a
few lines static function) that can print the pointers of the functions
you're calling.
> >>
> >> I'm open to ideas on how best to accomplish this.
> >>
> >> On a larger scale, there are a couple of other bugs
Re: TianoCore KVM Port: Status Update
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/28/2014 02:09 PM, Christoffer Dall wrote:
> On Fri, Mar 28, 2014 at 04:26:59AM -0400, Michael Casadevall
> wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> As I've made a fair bit of headway since LinaroConnect, I wanted
>> to drop a line on my current progress with porting TianoCore to
>> KVM
>>
>> Summary (tl;dr version):
>>
>> KVM can start TianoCore, and boot all the way to shell, and
>> access HDDs via VirtioBlk. We can start grub and successfully
>> retrieve files from ext partitions, load a device tree, and start
>> the kernel. The kernel runs through most of the EFI stub, but
>> falls over during ExitBootServices()
>
> Thanks for providing this status!
>
>>
>> Long Version:
>>
>> So, after much blood sweat and tears, we're finally at the point
>> of trying to actually start a kernel, though this (for the
>> moment) remains an elusive goal. The current problem is that once
>> we call EBS(), we get an exception from EFI with no Image
>> information, which means the exception handler doesn't know where
>> it came from. After several seconds, we get a second exception
>> from within DxeCore, and then EFI falls over.
>>
>> Debugging EFI is difficult and error prone, combined with
>> limited debug facilities from the gdb-stub in QEMU (no
>> breakpoints), and no decent way to load all of EFI itself (you
>> have to run add-symbol-file manually with the output of commands
>> printed on the console; supposedly its possible to generate a
>> giant GdbSyms.dll file to import in a single go, but I haven't
>> succeeded at this). This is further complicated that it appears
>> we're asserting somewhere in a driver, and short of adding
>> printfs to *every* driver, its impossible to know which is
>> asseting.
>
> Maybe it's worth adding a hack-support-gdb-in-kvm implementation
> for this. If we go down this road, I can probably find time to
> help you out there.
>
> Can you do some scripting to replace assert statements with "{
> print("%s:%d\n", __FILE__, __LINE__); orig_assert(); }" type hack?
>
That's probably a decent idea if I can find where ASSERT() is defined.
I'll try that in a bit.
>>
>> Previous attempts to debug assets shows that EFI does "odd"
>> things to the stack when we hit an exception, making walking it
>> with GDB impossible. I need to figure out what madness EFI does
>> with my SP so I can get the entire stack on an explosion, but
>> this remains at best hopeful thinking.
>
> This sounds very strange - could it be that because you take an
> exception, you use a SP from a different mode and everything just
> messes up?
>
This could be GDB just being unhappy. I've had issues walking the
stack in KVM in general, but even if I walk the stack by hand, I don't
see a pointer to the next frame when we're in an exception. To my
knowledge, UEFI uses the standard AArch64 C ABI, but this might be a
faulty exception on my part.
>>
>> Further complicating things is that during EBS, my print
>> debugging goes away. I might just cheat and roll a simple
>> assembly function to bang out messages through serial without
>> calling anything else. Ugly as sin, but this should let me get
>> useful debug output through the EBS framework. Complicating
>> matters is that I need to locate each and all EBS() event
>> functions, which are spread *everywhere* in TianoCore, and then
>> debug them each individually.
>
> I'm a little confused no knowing UEFI, is EBS() not a single
> function and what does it matter that it's called from multiple
> places?
>
So, drivers and applications can enlist to get notification of when
ExitBootServices are called. This pushes a pointer to a function into
an array when is then iterated through and this pointer is then called
so drivers can unregister themselves from boot services, etc.
Complicating the issue is I can't use printf once GetMemoryMap() is
called without breaking EBS() (I think this is a bug in UEFI, leif, 2
cents?, but I think I can twiddle the serial port directly without
breaking shit.
Having slept on it, its probably easy to print out the pointers as we
go through them, so I can get an idea of whats listening for EBS and
try and narrow down my list of candidates.
>>
>> I'm open to ideas on how best to accomplish this.
>>
>> On a larger scale, there are a couple of other bugs and odds and
>> ends which currently affect us:
>>
>> * wfi doesn't work
>>
>> THis is probably the biggest w.r.t. to functionality that should
>> work, but doesn't. The EFI event loop is built on checking the
>> timer, then calling wfi to check the timer later. The problem
>> here is we call wfi ... and UEFI never comes back despite events
>> firing (I can put print code in the interrupt handler to confirm
>> this). This may be related to the VGIC errors I get running kvm
>> under foundation, but haven't taken the time to properly nail
>> down the bug here.
>
> So if I understand it, the expected sequenc
Re: TianoCore KVM Port: Status Update
On Fri, Mar 28, 2014 at 04:26:59AM -0400, Michael Casadevall wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> As I've made a fair bit of headway since LinaroConnect, I wanted to
> drop a line on my current progress with porting TianoCore to KVM
>
> Summary (tl;dr version):
>
> KVM can start TianoCore, and boot all the way to shell, and access
> HDDs via VirtioBlk. We can start grub and successfully retrieve files
> from ext partitions, load a device tree, and start the kernel. The
> kernel runs through most of the EFI stub, but falls over during
> ExitBootServices()
Thanks for providing this status!
>
> Long Version:
>
> So, after much blood sweat and tears, we're finally at the point of
> trying to actually start a kernel, though this (for the moment)
> remains an elusive goal. The current problem is that once we call
> EBS(), we get an exception from EFI with no Image information, which
> means the exception handler doesn't know where it came from. After
> several seconds, we get a second exception from within DxeCore, and
> then EFI falls over.
>
> Debugging EFI is difficult and error prone, combined with limited
> debug facilities from the gdb-stub in QEMU (no breakpoints), and no
> decent way to load all of EFI itself (you have to run add-symbol-file
> manually with the output of commands printed on the console;
> supposedly its possible to generate a giant GdbSyms.dll file to import
> in a single go, but I haven't succeeded at this). This is further
> complicated that it appears we're asserting somewhere in a driver, and
> short of adding printfs to *every* driver, its impossible to know
> which is asseting.
Maybe it's worth adding a hack-support-gdb-in-kvm implementation for
this. If we go down this road, I can probably find time to help you out
there.
Can you do some scripting to replace assert statements with "{
print("%s:%d\n", __FILE__, __LINE__); orig_assert(); }" type hack?
>
> Previous attempts to debug assets shows that EFI does "odd" things to
> the stack when we hit an exception, making walking it with GDB
> impossible. I need to figure out what madness EFI does with my SP so I
> can get the entire stack on an explosion, but this remains at best
> hopeful thinking.
This sounds very strange - could it be that because you take an
exception, you use a SP from a different mode and everything just messes
up?
>
> Further complicating things is that during EBS, my print debugging
> goes away. I might just cheat and roll a simple assembly function to
> bang out messages through serial without calling anything else. Ugly
> as sin, but this should let me get useful debug output through the EBS
> framework. Complicating matters is that I need to locate each and all
> EBS() event functions, which are spread *everywhere* in TianoCore, and
> then debug them each individually.
I'm a little confused no knowing UEFI, is EBS() not a single function
and what does it matter that it's called from multiple places?
>
> I'm open to ideas on how best to accomplish this.
>
> On a larger scale, there are a couple of other bugs and odds and ends
> which currently affect us:
>
> * wfi doesn't work
>
> THis is probably the biggest w.r.t. to functionality that should work,
> but doesn't. The EFI event loop is built on checking the timer, then
> calling wfi to check the timer later. The problem here is we call wfi
> ... and UEFI never comes back despite events firing (I can put print
> code in the interrupt handler to confirm this). This may be related to
> the VGIC errors I get running kvm under foundation, but haven't taken
> the time to properly nail down the bug here.
So if I understand it, the expected sequence of events are:
1. check timer (arch timer counter?)
2. WFI
3. virtual arch timer interrupt, causes wake-up from WFI
4. go to 1->
But you seem to get stuck at (2)?
When you say "print code in the interrupt handler" is that the UEFI
interrupt handler? In that case, you do wake up from the WFI...?
Do you see stuff happening in virt/kvm/arm/arch_timer.c:
kvm_timer_inject_irq()?
That should call kvm_vgic_inject_irq(), which should
vgic_kick_vcpus(kvm), which is what wakes you up from your WFI.
>
> This was worked around by commenting out the wfi, turning event loop
> into a busy loop, but this has to be resolved before we can ever
> consider merging it
>
> * No RTC
>
> I looked through virt.c in KVM, and as best I can tell, I've got no
> RTC at all (no PL031). It also appears that the kernel can't get RTC
> as running a kernel gets me a 1970 clock. I'm not sure if this is by
> design or not, but it causes GetTime() to return EFI_ERROR, and I
> suspect may be one of the exceptions I'm getting avoid (Shell prints a
> ton of warnings that GetTime is busted).
The only thing you can use to tell passing of time in mach-virt is the
arch-timer counter and use a fixed starting point.
-Christoffer
___
linaro-dev mailing list
linaro
[PATCH] idlestat: run a command with idlestat
From: Daniel Lezcano
Add the support to run a command line with idlestat:
./idlestat -o out.dat -- /bin/sleep 3
Without the '-t' option, idlestat will blindly use the current buffer
size which may not fit with the 'command' duration and lead to a buffer
overflow.
With the example, it would make sense to set the buffer size:
./idlestat -o out.dat -t 3 -- /bin/sleep 3
This is a workaround, until we find a way to set the buffer size automatically.
Signed-off-by: Daniel Lezcano
---
idlestat.c | 49 +++--
1 file changed, 43 insertions(+), 6 deletions(-)
diff --git a/idlestat.c b/idlestat.c
index 53ca1c7..f0c6467 100644
--- a/idlestat.c
+++ b/idlestat.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include
#include "idlestat.h"
@@ -112,6 +113,7 @@ static int display_states(struct cpuidle_cstates *cstates,
(c->min_time == DBL_MAX ? 0. : c->min_time),
c->max_time);
}
+
if (pstates) {
for (j = 0; j < pstates->max; j++) {
struct cpufreq_pstate *p = &(pstates->pstate[j]);
@@ -1022,7 +1024,7 @@ int getoptions(int argc, char *argv[], struct
idledebug_options *options)
return -1;
}
- return 0;
+ return optind;
}
static int idlestat_file_for_each_line(const char *path, void *data,
@@ -1108,14 +1110,47 @@ static int idlestat_wake_all(void)
return 0;
}
-int main(int argc, char *argv[])
+static int execute(int argc, char *argv[], char *const envp[],
+ struct idledebug_options *options)
+{
+ pid_t pid;
+ int status;
+
+ /* Nothing to execute, just wait an amount of time */
+ if (!argc)
+ return sleep(options->duration);
+
+ pid = fork();
+ if (pid < 0) {
+ perror("fork");
+ return -1;
+ }
+
+ if (pid == 0 && execve(argv[0], argv, envp)) {
+ perror("execv");
+ exit(1);
+ }
+
+ if (pid) {
+ waitpid(pid, &status, 0);
+
+ if (WIFEXITED(status) && !WEXITSTATUS(status))
+ return 0;
+ }
+
+ return -1;
+}
+
+int main(int argc, char *argv[], char *const envp[])
{
struct cpuidle_datas *datas;
struct cpuidle_datas *cluster;
struct idledebug_options options;
struct rusage rusage;
+ int args;
- if (getoptions(argc, argv, &options))
+ args = getoptions(argc, argv, &options);
+ if (args <= 0)
return 1;
/* We have to manipulate some files only accessible to root */
@@ -1128,7 +1163,7 @@ int main(int argc, char *argv[])
init_cpu_topo_info();
/* Acquisition time specified means we will get the traces */
- if (options.duration) {
+ if (options.duration || args < argc) {
/* Read cpu topology info from sysfs */
read_sysfs_cpu_topo();
@@ -1151,14 +1186,16 @@ int main(int argc, char *argv[])
/* Start the recording */
if (idlestat_trace_enable(true))
return -1;
+
/* We want to prevent to begin the acquisition with a cpu in
* idle state because we won't be able later to close the
* state and to determine which state it was. */
if (idlestat_wake_all())
return -1;
- /* Do nothing */
- sleep(options.duration);
+ /* Execute the command or wait a specified delay */
+ if (execute(argc - args, &argv[args], envp, &options))
+ return -1;
/* Wake up all cpus again to account for last idle state */
if (idlestat_wake_all())
--
1.7.9.5
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
TianoCore KVM Port: Status Update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As I've made a fair bit of headway since LinaroConnect, I wanted to drop a line on my current progress with porting TianoCore to KVM Summary (tl;dr version): KVM can start TianoCore, and boot all the way to shell, and access HDDs via VirtioBlk. We can start grub and successfully retrieve files from ext partitions, load a device tree, and start the kernel. The kernel runs through most of the EFI stub, but falls over during ExitBootServices() Long Version: So, after much blood sweat and tears, we're finally at the point of trying to actually start a kernel, though this (for the moment) remains an elusive goal. The current problem is that once we call EBS(), we get an exception from EFI with no Image information, which means the exception handler doesn't know where it came from. After several seconds, we get a second exception from within DxeCore, and then EFI falls over. Debugging EFI is difficult and error prone, combined with limited debug facilities from the gdb-stub in QEMU (no breakpoints), and no decent way to load all of EFI itself (you have to run add-symbol-file manually with the output of commands printed on the console; supposedly its possible to generate a giant GdbSyms.dll file to import in a single go, but I haven't succeeded at this). This is further complicated that it appears we're asserting somewhere in a driver, and short of adding printfs to *every* driver, its impossible to know which is asseting. Previous attempts to debug assets shows that EFI does "odd" things to the stack when we hit an exception, making walking it with GDB impossible. I need to figure out what madness EFI does with my SP so I can get the entire stack on an explosion, but this remains at best hopeful thinking. Further complicating things is that during EBS, my print debugging goes away. I might just cheat and roll a simple assembly function to bang out messages through serial without calling anything else. Ugly as sin, but this should let me get useful debug output through the EBS framework. Complicating matters is that I need to locate each and all EBS() event functions, which are spread *everywhere* in TianoCore, and then debug them each individually. I'm open to ideas on how best to accomplish this. On a larger scale, there are a couple of other bugs and odds and ends which currently affect us: * wfi doesn't work THis is probably the biggest w.r.t. to functionality that should work, but doesn't. The EFI event loop is built on checking the timer, then calling wfi to check the timer later. The problem here is we call wfi ... and UEFI never comes back despite events firing (I can put print code in the interrupt handler to confirm this). This may be related to the VGIC errors I get running kvm under foundation, but haven't taken the time to properly nail down the bug here. This was worked around by commenting out the wfi, turning event loop into a busy loop, but this has to be resolved before we can ever consider merging it * No RTC I looked through virt.c in KVM, and as best I can tell, I've got no RTC at all (no PL031). It also appears that the kernel can't get RTC as running a kernel gets me a 1970 clock. I'm not sure if this is by design or not, but it causes GetTime() to return EFI_ERROR, and I suspect may be one of the exceptions I'm getting avoid (Shell prints a ton of warnings that GetTime is busted). * No terminfo support (not ARM specific) EFI assumes its working against a real console or terminal. As such, it doesn't respect anything like termcap or such, and output gets jumbled due to incorrect escape sequencies and such. This isn't specific to ARM as I get identical behavior with OVMF running on stdio or over telnet. Backspace for instance requires me to type ^H into the console manually As we expect to have this usable remotely, we need to determine how to handle the terminal and escape sequences properly so we're not printing garbage to the screen. A "dumb" mode might just be the best way to handle this, but something like grub do display fancy graphics. Ideas welcome. If anyone wants to play with it, my code is on git, but requires a bit of setup to get running, and you need a patch to KVM to successfully start UEFI at the moment. Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTNTJTAAoJEGKVRgSEnX1Qm2YH/jzWQjB/DPSHdv33hUlxVuIm j2AGElid7HM+3gp5U/ILdXvCyP9LFg8RATsvUa7bSHdwFZxRdAqYUWzm/Jxg6ZYV kyTzTDuPhbXp8koVLF14H/oGlpwnEH5rhzNa3UeRZTNYnNp3UMeZ1NXgGu9ziCfk hMGGteTMfV/6fGD6AETtlpD99KKwFiprD198QAil2rpVRi4WZBcgp7Y9/c/+cLfy sJD7p+zN8jBh9r9njpxh0o5rrQoG3N1NAemPGbSAc+qMMYCDOmjasGLwYiJuuMDy apRBM9+pbYsEgBGxM1z3XGywBJWBaLGzizk8vfPN2kN70/F7RW89X1rqG/95Ais= =OwC0 -END PGP SIGNATURE- ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
