Re: [edk2] ShellPkg: Fix duplicate String IDs

2014-06-16 Thread Bjorge, Erik C 
Reviewed-by: Erik Bjorge 

From: Carsey, Jaben
Sent: Monday, June 16, 2014 2:42 PM
To: Bjorge, Erik C
Cc: edk2-devel@lists.sourceforge.net; Carsey, Jaben
Subject: ShellPkg: Fix duplicate String IDs

Erik,

Can you review?
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Issues with GenFds when FDF BaseAddress is 0x0

2014-06-16 Thread Laszlo Ersek 
On 06/16/14 22:07, Michael Casadevall wrote:
> That did the trick, thanks. Haven't tested to see if it works yet, but
> at least I got a branch instruction at the start of the FD.
> 
> I think we're still in a position that we can change AArch64's layout if
> loading at 0x0 is really a bad idea; as defined, there are two seperate
> NOR devices in the early boot space, and we could make an argument to
> place Tiano in the other one which would get it out of 0x0, but I'm not
> sure I understand the logic on why this is necessarily bad; nothing says
> 0x0 has to be NULL, especially when dealing with bare-metal programming.
> At least on AArch32, the ISR table is at 0x0, which is always a series
> of branch instructions.

Well since I made the argument "against", I should probably make the
"for" one as well -- from a superficial grep (and Harry's response of
course) it looks like the code already deals with a zero base address.
My concern is likely safe to ignore in practice.

Thanks
Laszlo


--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Issues with GenFds when FDF BaseAddress is 0x0

2014-06-16 Thread Michael Casadevall 
That did the trick, thanks. Haven't tested to see if it works yet, but at
least I got a branch instruction at the start of the FD.

I think we're still in a position that we can change AArch64's layout if
loading at 0x0 is really a bad idea; as defined, there are two seperate NOR
devices in the early boot space, and we could make an argument to place
Tiano in the other one which would get it out of 0x0, but I'm not sure I
understand the logic on why this is necessarily bad; nothing says 0x0 has
to be NULL, especially when dealing with bare-metal programming. At least
on AArch32, the ISR table is at 0x0, which is always a series of branch
instructions.


On 16 June 2014 08:03, Harry Liebel  wrote:

> Hi Michael.
>
> I think what you are really looking for is the 'Force rebase' option
> that goes into the fdf file. It is a workaround in the Basetool as it
> normally skips some image creation operations if the image Base address
> is set to 0x0.
>
> So in your fdf file you can try something like this (taken from the
> ArmVExpress-FVP-AArch64.fdf):
> ---
>   [FV.FVMAIN_SEC]
>   FvBaseAddress  = 0x0  # Secure ROM
>   FvForceRebase  = TRUE
>   FvAlignment= 16
>   ERASE_POLARITY = 1
> ---
>
> The 'FvForceRebase' option forces the tool to process the image even if
> the base address is set to 0x0.
>
>
> To answer the other part of the question. The initial jump instruction
> lives here:
> BaseTools/Source/C/GenFv/GenFvInternalLib.c :
> UpdateArmResetVectorIfNeeded()
>
> Regards,
> Harry
>
>
> On 16/06/14 07:14, Michael Casadevall wrote:
> > Hey all,
> >
> > I've been working on porting TianoCore to KVM on AArch64, and I've
> > recently run into an issue which I'm hoping someone can help me to
> > debug. Recent proposed changes to KVM place the address space for
> > BootROMs and persistent storage from 0x0-0x800, with the early
> > boot code for Tiano startng at 0x0. My problem is that when the FDF is
> > set to generate an image for this load location, it appears to create
> > a malformed FD file.
> >
> > Under normal circumstances, the very first bits of the .fd file are a
> > branch instruction to the start of the PEI. This generates correctly
> > when the FDF is set to any BaseAddress that != 0x0.
> >
> > For example:
> >
> > Here's a known good image
> > $ hexdump
> > Build/AArch64Virtualization-KVM/DEBUG_ARMLINUXGCC/FV/KVM_EFI.fd | head
> > 000 01e2 1400      
> > 010 e578 8c8c 8a3d 4f1c 3599 6189 c385 d32d
> >
> > The same code, compiled with my updated FDF generates the following:
> > $ hexdump
> > Build/AArch64Virtualization-KVM/DEBUG_ARMLINUXGCC/FV/KVM_EFI.fd | head
> > 000        
> > 010 e578 8c8c 8a3d 4f1c 3599 6189 c385 d32d
> >
> > I've tried and failed to locate the code responsible for writing out
> > the initial branch statement, so I'm hoping somewhere here can get me
> > a pointer on where to look. The relevant bit of my FDF is inline below.
> >
> > [FD.KVM_EFI]
> > BaseAddress   = 0x000|gArmTokenSpaceGuid.PcdFdBaseAddress  # KVM
> > assigns 0 - 0x800 for a BootROM
> > Size  = 0x800|gArmTokenSpaceGuid.PcdFdSize # The
> > size in bytes of the FLASH Device
> > ErasePolarity = 1
> >
> > # This one is tricky, it must be: BlockSize * NumBlocks = Size
> > BlockSize = 0x1000
> > NumBlocks = 0x8000
> >
> > As best I can tell, GenFds appears to be the relevant utility, but
> > nothing in the code jumps out as relevent, and I admit I'm completely
> > unfamiliar with this area of the tree.
> >
> > Thanks in advance,
> > Michael
>
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium.  Thank you.
>
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> Registered in England & Wales, Company No:  2557590
> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> Registered in England & Wales, Company No:  2548782
>
>
>
> --
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Op

[edk2] NON_FFS_FILE Not Supported

2014-06-16 Thread Tim Lewis 
Just as a follow on to my previous question about binary-only module 
deliverables for EDK2.


1.   The current FDF specification (1.22d) incorrectly states that there is 
an option NON_FFS_FILE (see  which is, in fact, not supported and, even 
if it were supported, would be pretty useless since it uses Options2 which 
makes it basically the same as RAW or FREEFORM, as far as I can tell. I think 
this was originally intended for use with OEM-defined file types but does not 
give the option for either an OEM file type (or GUID, if it will construct the 
extended header entry for the OEM file type).

2.   If you could add a FFS file (product of the build tools) directly to 
the FV, an unintended side effect is that Dynamic/DynamicEx PCDs will not get 
placed into the PCD database, because the PCD database is constructed based on 
INF content references (in the [Pcd] sections) and FDF files don't give such 
references. Of course, I can add these manually in an INF file, but I haven't 
found a good automated way to use a FDF-centric build solution for this.

Tim
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Issues with GenFds when FDF BaseAddress is 0x0

2014-06-16 Thread Laszlo Ersek 
On 06/16/14 17:54, Andrew Fish wrote:
> 
> On Jun 16, 2014, at 5:11 AM, Laszlo Ersek  > wrote:
> 
>> On 06/16/14 08:14, Michael Casadevall wrote:
>>> Hey all,
>>>
>>> I've been working on porting TianoCore to KVM on AArch64, and I've
>>> recently run into an issue which I'm hoping someone can help me to
>>> debug. Recent proposed changes to KVM place the address space for
>>> BootROMs and persistent storage from 0x0-0x800, with the early boot
>>> code for Tiano startng at 0x0.
>>
>> Looks like a spectacularly bad idea. The C standard guarantees that any
>> pointer to a function, and any pointer to an object, will compare
>> unequal to a null pointer. On edk2 platforms, null pointers have
>> all-bits-zero representation. If you place an object at address zero,
>> then the above guarantee is breached.
>>
> 
> Well PCs (and lots of other devices) have memory/ROM at address zero. In
> this case it is an assembly branch instruction that lives at zero, so no
> harm done to the C language. 

I agree.

> Dereferencing NULL is undefined behavior in C. While it is not
> pedantically defined in C a volatile variable can be used to write to
> address zero. There may be a real reason to do this, like to init the ECC. 
> 
> This is a good description of undefined behavior in C.
> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html

My point was not about writing to the zero address. My point was about
null pointers never aliasing an object or a function.

6.3.2.3 Pointers

 3  An integer constant expression with the value 0, or such an
expression cast to type void *, is called a /null pointer constant/.
If a null pointer constant is converted to a pointer type, the
resulting pointer, called a /null pointer/, is guaranteed to
compare unequal to a pointer to any object or function.

Consider the following C code (hypothetical, not sure if anything like
this exists in the edk2 C code, but it could):

{
  SOME_STRUCT *Ptr;

  Ptr = (VOID *)(UINTN)PcdGet32 (PcdFdBaseAddress);
  if (Ptr == NULL) {
//
// does not point to an object, bail
//
return EFI_WHATEVER;
  }

  SomeFunction (Ptr->Field1);
  return EFI_SOMETHING_ELSE;
}

Such code is right to think that (Ptr == NULL) implies that Ptr does not
point to a SOME_STRUCT object, because the C standard guarantees that.
Assuming that PcdGet32() expands to 0 (-->FixedAtBuild), the

  (VOID *)(UINTN)PcdGet32 (PcdFdBaseAddress)

expression is an "integer constant expression" cast to void *.  Hence
the above citation directly applies; the expression is a null pointer
constant, which is then (in the assignment to Ptr) converted to the
pointer-to-SOME_STRUCT type. The resultant pointer is a null pointer.


Let's see another example (assuming little endian, and 32-bit or 64-bit
pointer size).

{
  SOME_STRUCT *Ptr;
  UINT32  Value;

  ZeroMem (&Ptr, sizeof Ptr);
  Value = PcdGet32 (PcdFdBaseAddress);
  CopyMem (&Ptr, &Value, 4);

  if (Ptr == NULL) {
//
// does not point to an object, bail
//
return EFI_WHATEVER;
  }

  SomeFunction (Ptr->Field1);
  return EFI_SOMETHING_ELSE;
}

Even this (strongly platform-dependent) code (which lacks any pointer
conversion) will break under the suggested use, because the suggested
setting results in "Ptr" containing a bit pattern that corresponds to
the internal representation of null pointers to structures.

When the patch writes "set PcdFdBaseAddress to zero", it *intends* to
say "place the image at the zero address". What it *actually* says, for
C code, is "pointers converted -- or copied -- from PcdFdBaseAddress
shall be NULL".

Thanks,
Laszlo


--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] KVM Forum 2014 Call for Participation

2014-06-16 Thread Paolo Bonzini 
=
KVM Forum 2014: Call For Participation
October 14-16, 2014 - Congress Centre Düsseldorf - Düsseldorf, Germany

(All submissions must be received before midnight July 27, 2014)
=

KVM is an industry leading open source hypervisor that provides an ideal
platform for datacenter virtualization, virtual desktop infrastructure,
and cloud computing.  Once again, it's time to bring together the
community of developers and users that define the KVM ecosystem for
our annual technical conference.  We will discuss the current state of
affairs and plan for the future of KVM, its surrounding infrastructure,
and management tools.  Mark your calendar and join us in advancing KVM.
http://events.linuxfoundation.org/events/kvm-forum/

Once again we are colocated with the Linux Foundation's LinuxCon Europe,
CloudOpen Europe, Embedded Linux Conference (ELC) Europe, and this year, the
Linux Plumbers Conference. KVM Forum attendees will be able to attend
LinuxCon + CloudOpen + ELC for a discounted rate.
http://events.linuxfoundation.org/events/kvm-forum/attend/register

We invite you to lead part of the discussion by submitting a speaking
proposal for KVM Forum 2014.
http://events.linuxfoundation.org/cfp

Suggested topics:

  KVM/Kernel
  - Scaling and optimizations
  - Nested virtualization
  - Linux kernel performance improvements
  - Resource management (CPU, I/O, memory)
  - Hardening and security
  - VFIO: SR-IOV, GPU, platform device assignment
  - Architecture ports

  QEMU
  - Management interfaces: QOM and QMP
  - New devices, new boards, new architectures
  - Scaling and optimizations
  - Desktop virtualization and SPICE
  - Virtual GPU
  - virtio and vhost, including non-Linux or non-virtualized uses
  - Hardening and security
  - New storage features
  - Live migration and fault tolerance
  - High availability and continuous backup
  - Real-time guest support
  - Emulation and TCG
  - Firmware: ACPI, UEFI, coreboot, u-Boot, etc.
  - Testing

  Management and infrastructure
  - Managing KVM: Libvirt, OpenStack, oVirt, etc.
  - Storage: glusterfs, Ceph, etc.
  - Software defined networking: Open vSwitch, OpenDaylight, etc.
  - Network Function Virtualization
  - Security
  - Provisioning
  - Performance tuning


===
SUBMITTING YOUR PROPOSAL
===
Abstracts due: July 27, 2014

Please submit a short abstract (~150 words) describing your presentation
proposal. Slots vary in length up to 45 minutes.  Also include in your 
proposal
the proposal type -- one of:
- technical talk
- end-user talk

Submit your proposal here:
http://events.linuxfoundation.org/cfp
Please only use the categories "presentation" and "panel discussion"

You will receive a notification whether or not your presentation proposal
was accepted by Aug 20th.

Speakers will receive a complimentary pass for the event. In the instance
that your submission has multiple presenters, only the primary speaker for a
proposal will receive a complementary event pass. For panel discussions, all
panelists will receive a complimentary event pass.

TECHNICAL TALKS

A good technical talk should not just report on what has happened over
the last year; it should present a concrete problem and how it impacts
the user and/or developer community. Whenever applicable, it should
focus on the work that needs to be done or the difficulties that haven't yet
been solved.  Summarizing recent developments is okay but it should
not be more than a small portion of the overall talk.

END-USER TALKS

One of the big challenges as developers is to know what, where and how
people actually use our software.  We will reserve a few slots for end
users talking about their deployment challenges and achievements.

If you are using KVM in production you are encouraged submit a speaking
proposal.  Simply mark it as an end-user talk.  As an end user, this is a
unique opportunity to get your input to developers.

HANDS-ON / BOF SESSIONS

We will reserve some time for people to get together and discuss
strategic decisions as well as other topics that are best solved within
smaller groups. This time can also be used for hands-on hacking
sessions if you have concrete code problems to solve.

These sessions will be announced during the event. If you are interested
in organizing such a session, please add it to the list at

   http://www.linux-kvm.org/page/KVM_Forum_2014_BOF

Let people you think might be interested know about it, and encourage
them to add their names to the wiki page as well. Please try to
add your ideas to the list before KVM Forum starts.

PANEL DISCUSSIONS

If you are proposing a panel discussion, please make sure that you list 
all of
your potential  panelists in your abstract. We will request full biographies
if a panel is accepted.

===
HOTEL / TRAVEL
===
The KVM Forum 2014 will be held in Düsseldorf, Germany at

Re: [edk2] Issues with GenFds when FDF BaseAddress is 0x0

2014-06-16 Thread Andrew Fish 

On Jun 16, 2014, at 5:11 AM, Laszlo Ersek  wrote:

> On 06/16/14 08:14, Michael Casadevall wrote:
>> Hey all,
>> 
>> I've been working on porting TianoCore to KVM on AArch64, and I've
>> recently run into an issue which I'm hoping someone can help me to
>> debug. Recent proposed changes to KVM place the address space for
>> BootROMs and persistent storage from 0x0-0x800, with the early boot
>> code for Tiano startng at 0x0.
> 
> Looks like a spectacularly bad idea. The C standard guarantees that any
> pointer to a function, and any pointer to an object, will compare
> unequal to a null pointer. On edk2 platforms, null pointers have
> all-bits-zero representation. If you place an object at address zero,
> then the above guarantee is breached.
> 

Well PCs (and lots of other devices) have memory/ROM at address zero. In this 
case it is an assembly branch instruction that lives at zero, so no harm done 
to the C language. 

Dereferencing NULL is undefined behavior in C. While it is not pedantically 
defined in C a volatile variable can be used to write to address zero. There 
may be a real reason to do this, like to init the ECC. 

This is a good description of undefined behavior in C. 
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html

Clang is very aggressive about dumping undefined behavior in the optimizer. 
~/work/Compiler>cat null.c
// test()
int test ()
{
   int *x = (int *)0;
  *x = 2;
   return *x;
}

~/work/Compiler>clang -S -Os null.c
~/work/Compiler>cat null.S
.section__TEXT,__text,regular,pure_instructions
.globl  _test
_test:  ## @test
.cfi_startproc
## BB#0:
pushq   %rbp
Ltmp2:
.cfi_def_cfa_offset 16
Ltmp3:
.cfi_offset %rbp, -16
movq%rsp, %rbp
Ltmp4:
.cfi_def_cfa_register %rbp
ud2
.cfi_endproc


.subsections_via_symbols

As you can see the compiler just punts and places a trap in the code. 


>> My problem is that when the FDF is set to
>> generate an image for this load location, it appears to create a
>> malformed FD file.
>> 
>> Under normal circumstances, the very first bits of the .fd file are a
>> branch instruction to the start of the PEI. This generates correctly
>> when the FDF is set to any BaseAddress that != 0x0.
>> 
>> For example:
>> 
>> Here's a known good image
>> $ hexdump
>> Build/AArch64Virtualization-KVM/DEBUG_ARMLINUXGCC/FV/KVM_EFI.fd | head
>> 000 01e2 1400      
>> 010 e578 8c8c 8a3d 4f1c 3599 6189 c385 d32d
>> 
>> The same code, compiled with my updated FDF generates the following:
>> $ hexdump
>> Build/AArch64Virtualization-KVM/DEBUG_ARMLINUXGCC/FV/KVM_EFI.fd | head
>> 000        
>> 010 e578 8c8c 8a3d 4f1c 3599 6189 c385 d32d
> 
> (In the second line of each of these dumps, you can see
> EFI_FIRMWARE_FILE_SYSTEM2_GUID. But this is just a side note, not
> particularly important.)
> 
>> 
>> I've tried and failed to locate the code responsible for writing out the
>> initial branch statement, so I'm hoping somewhere here can get me a
>> pointer on where to look. The relevant bit of my FDF is inline below.
>> 

https://svn.code.sf.net/p/edk2/code/trunk/edk2/BaseTools/Source/C/GenFv/GenFvInternalLib.c
 UpdateArmResetVectorIfNeeded()

This code patches the zero vector at the start of the FV. There is an assembly 
branch instruction to the SEC entry point, followed by the address of the PEI 
Core entry point. 

Thanks,

Andrew Fish

>> [FD.KVM_EFI]
>> BaseAddress   = 0x000|gArmTokenSpaceGuid.PcdFdBaseAddress  # KVM
>> assigns 0 - 0x800 for a BootROM
>> Size  = 0x800|gArmTokenSpaceGuid.PcdFdSize # The
>> size in bytes of the FLASH Device
>> ErasePolarity = 1
>> 
>> # This one is tricky, it must be: BlockSize * NumBlocks = Size
>> BlockSize = 0x1000
>> NumBlocks = 0x8000
>> 
>> As best I can tell, GenFds appears to be the relevant utility, but
>> nothing in the code jumps out as relevent, and I admit I'm completely
>> unfamiliar with this area of the tree.
> 
> Please save your build log and upload it somewhere. My guess is the
> following -- see "BaseTools/UserManuals/GenFds_Utility_Man_Page.rtf" --
> GenFv is likely called with --baseaddr=0 (equivalently, with -r 0),
> which leads the code to believe that --baseaddr has not been passed at
> all. See:
> 
> $ GenFv --help
> 
>  -r Address, --baseaddr Address
>Address is the rebase start address for drivers that
>run in Flash. It supports DEC or HEX digital format.
>If it is set to zero, no rebase action will be taken
> 
> And/or, please see GenVtf ("generate volume top file") too:
> 
> $ GenVtf --help
> 
>  -r BaseAddress,  --baseaddr BaseAddress
>  BaseAddress is the starting address of Firmware Volume
>  where Boot Strapped Image will reside.
> 
> main() in "BaseTools/Source/C/Gen

[edk2] [PATCH] - ShellPkg: Some improvements in space handling, "if" command and user input reading

2014-06-16 Thread Leandro Becker 
Hello,
 
I made some improvements in ShellPkg that I think would be nice for the
community.

===
ShellPkg: Improvements in space handling, "if" command also accepts
directory and user input reading.

1. Improvements in space handling at command lines to accept tab (\t)
as a space;
2. "If" command also accepts a directory when checking if a file
exists;
3. When waiting for user input, support some cases when a key event is
generated
but the device is not ready when the keystroke is read. 
Just ignore the event and wait again for another key.
 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leandro G. B. Becker 
===

Best regards to all!

Leandro G. B. Becker
Positivo Informática S.A.

--- a/ShellPkg/Application/Shell/FileHandleWrappers.c   Thu Jan 16 13:53:56 2014
+++ b/ShellPkg/Application/Shell/FileHandleWrappers.c   Mon Jun 16 10:16:53 2014
@@ -414,8 +414,15 @@
 //
 // Read a key
 //
-gBS->WaitForEvent (1, &gST->ConIn->WaitForKey, &EventIndex);
-Status = gST->ConIn->ReadKeyStroke (gST->ConIn, &Key);
+// Patch for some BIOSes that generates and key event but then the device 
is not ready yet
+// Ignore it and wait again
+do {
+  gBS->WaitForEvent (1, &gST->ConIn->WaitForKey, &EventIndex);
+  Status = gST->ConIn->ReadKeyStroke (gST->ConIn, &Key);
+}
+while (Status == EFI_NOT_READY);
+  
 if (EFI_ERROR (Status)) {
   break;
 }
@@ -571,7 +578,7 @@
   break;
 
 default:
-  if (Key.UnicodeChar >= ' ') {
+  if (Key.UnicodeChar >= ' ' && Key.UnicodeChar < 0x7F) {
 //
 // If we are at the buffer's end, drop the key
 //
--- a/ShellPkg/Library/UefiShellLevel1CommandsLib/If.c  Thu Nov 21 13:17:29 2013
+++ a/ShellPkg/Library/UefiShellLevel1CommandsLib/If.c  Mon Jan 27 17:25:10 2014
@@ -398,8 +398,23 @@
   // is what remains a file in CWD???
   //
   OperationResult = 
(BOOLEAN)(ShellFileExists(StatementWalker)==EFI_SUCCESS);
+  // Checks also if is a directory
+  if (!OperationResult) { 
+if (ShellIsDirectory(StatementWalker)==EFI_SUCCESS)
+  OperationResult = TRUE;
+  }
 } else if (StatementWalker[0] == CHAR_NULL && StartParameterNumber+1 == 
EndParameterNumber) {
-  OperationResult = 
(BOOLEAN)(ShellFileExists(gEfiShellParametersProtocol->Argv[++StartParameterNumber])==EFI_SUCCESS);
+  CHAR16* path = gEfiShellParametersProtocol->Argv[++StartParameterNumber];
+  OperationResult = (BOOLEAN)(ShellFileExists(path)==EFI_SUCCESS);
+  // Checks also if is a directory
+  if (!OperationResult) {
+if (ShellIsDirectory(path)==EFI_SUCCESS)
+  OperationResult = TRUE;
+  }
 } else {
   ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_SYNTAX_IN), 
gShellLevel1HiiHandle, L"exist(s)");
   Status = EFI_INVALID_PARAMETER;
@@ -524,6 +539,12 @@
   BinOp = OperatorLessOrEqual;
 } else if (IsNextFragment((CONST CHAR16**)(&StatementWalker), L"==")) {
   BinOp = OperatorEqual;
+}
+else if (IsNextFragment((CONST CHAR16**)(&StatementWalker), L"!=")) {
+  BinOp = OperatorNotEqual;
 } else if (IsNextFragment((CONST CHAR16**)(&StatementWalker), L"ugt")) {
   BinOp = OperatorUnisgnedGreaterThan;
 } else if (IsNextFragment((CONST CHAR16**)(&StatementWalker), L"ult")) {
--- a/ShellPkg/Application/Shell/ShellParametersProtocol.c  Mon Jan 27 
16:13:56 2014
+++ b/ShellPkg/Application/Shell/ShellParametersProtocol.c  Tue Jan 28 
09:54:22 2014
@@ -49,7 +49,7 @@
   //
   // make sure we dont have any leading spaces
   //
-  while ((*Walker)[0] == L' ') {
+  while ((*Walker)[0] == L' ' || (*Walker)[0] == L'\t') {
 (*Walker)++;
   }
 
@@ -120,10 +120,10 @@
 CopyMem(NextDelim, NextDelim+1, StrSize(NextDelim) - 
sizeof(NextDelim[0]));
   }
 }
-while ((*TempParameter)[StrLen(*TempParameter)-1] == L' ') {
+while ((*TempParameter)[StrLen(*TempParameter)-1] == L' ' || 
(*TempParameter)[StrLen(*TempParameter)-1] == L'\t') {
   (*TempParameter)[StrLen(*TempParameter)-1] = CHAR_NULL;
 }
-while ((*TempParameter)[0] == L' ') {
+while ((*TempParameter)[0] == L' ' || (*TempParameter)[0] == L'\t') {
   CopyMem(*TempParameter, (*TempParameter)+1, StrSize(*TempParameter) - 
sizeof((*TempParameter)[0]));
 }
   }
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH v2 4/4] OvmfPkg: AcpiPlatformDxe: don't rely on unstable QEMU interface

2014-06-16 Thread Laszlo Ersek 
The fw_cfg file "etc/acpi/tables" is not a stable guest interface -- QEMU
could rename it in the future, and/or introduce additional fw_cfg files
with ACPI payload. Only the higher-level "etc/table-loader" file is
considered stable, which contains a sequence of commands to assist
firmware with reading QEMU ACPI tables from the FwCfg interface.

Because edk2 provides publishing support for ACPI tables, OVMF only uses
the Allocate command to find the names of FwCfg files to read and publish
as ACPI tables.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Jordan Justen 
---

Notes:
v2:
- incorporated suggested wording in commit message [Jordan]
- documented origin of QEMU_LOADER_FNAME_SIZE by rebasing it on new
  fw_cfg macro introduced in v2 1/4 (this follows the qemu source code,
  see "hw/i386/bios-linker-loader.c") [Jordan]
- added comment before the QEMU_LOADER_COMMAND_TYPE enum type that we
  only care about Allocate [Jordan]

 OvmfPkg/AcpiPlatformDxe/QemuLoader.h | 90 
 OvmfPkg/AcpiPlatformDxe/Qemu.c   | 54 --
 2 files changed, 139 insertions(+), 5 deletions(-)
 create mode 100644 OvmfPkg/AcpiPlatformDxe/QemuLoader.h

diff --git a/OvmfPkg/AcpiPlatformDxe/QemuLoader.h 
b/OvmfPkg/AcpiPlatformDxe/QemuLoader.h
new file mode 100644
index 000..6d1dfa3
--- /dev/null
+++ b/OvmfPkg/AcpiPlatformDxe/QemuLoader.h
@@ -0,0 +1,90 @@
+/** @file
+  Command structures for the QEMU linker/loader interface.
+
+  Copyright (C) 2014, Red Hat, Inc.
+
+  This program and the accompanying materials are licensed and made available
+  under the terms and conditions of the BSD License which accompanies this
+  distribution.  The full text of the license may be found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
+  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __QEMU_LOADER_H__
+#define __QEMU_LOADER_H__
+
+#include 
+#include 
+
+//
+// The types and the documentation reflects the SeaBIOS interface. In OVMF we
+// use a minimal subset of it.
+//
+#define QEMU_LOADER_FNAME_SIZE QEMU_FW_CFG_FNAME_SIZE
+
+//
+// We only look at the Allocate command, and only to get FwCfg filenames.
+//
+typedef enum {
+  QemuLoaderCmdAllocate = 1,
+  QemuLoaderCmdAddPointer,
+  QemuLoaderCmdAddChecksum
+} QEMU_LOADER_COMMAND_TYPE;
+
+typedef enum {
+  QemuLoaderAllocHigh = 1,
+  QemuLoaderAllocFSeg
+} QEMU_LOADER_ALLOC_ZONE;
+
+#pragma pack (1)
+//
+// QemuLoaderCmdAllocate: download the fw_cfg file named File, to a buffer
+// allocated in the zone specified by Zone, aligned at a multiple of Alignment.
+//
+typedef struct {
+  UINT8  File[QEMU_LOADER_FNAME_SIZE]; // NUL-terminated
+  UINT32 Alignment;// power of two
+  UINT8  Zone; // QEMU_LOADER_ALLOC_ZONE values
+} QEMU_LOADER_ALLOCATE;
+
+//
+// QemuLoaderCmdAddPointer: the bytes at
+// [PointerOffset..PointerOffset+PointerSize) in the file PointerFile contain a
+// relative pointer (an offset) into PointeeFile. Increment the relative
+// pointer's value by the base address of where PointeeFile's contents have
+// been placed (when QemuLoaderCmdAllocate has been executed for PointeeFile).
+//
+typedef struct {
+  UINT8  PointerFile[QEMU_LOADER_FNAME_SIZE]; // NUL-terminated
+  UINT8  PointeeFile[QEMU_LOADER_FNAME_SIZE]; // NUL-terminated
+  UINT32 PointerOffset;
+  UINT8  PointerSize; // one of 1, 2, 4, 8
+} QEMU_LOADER_ADD_POINTER;
+
+//
+// QemuLoaderCmdAddChecksum: calculate the UINT8 checksum (as per
+// CalculateChecksum8()) of the range [Start..Start+Length) in File. Store the
+// UINT8 result at ResultOffset in the same File.
+//
+typedef struct {
+  UINT8  File[QEMU_LOADER_FNAME_SIZE]; // NUL-terminated
+  UINT32 ResultOffset;
+  UINT32 Start;
+  UINT32 Length;
+} QEMU_LOADER_ADD_CHECKSUM;
+
+typedef struct {
+  UINT32 Type; // QEMU_LOADER_COMMAND_TYPE values
+  union {
+QEMU_LOADER_ALLOCATE Allocate;
+QEMU_LOADER_ADD_POINTER  AddPointer;
+QEMU_LOADER_ADD_CHECKSUM AddChecksum;
+UINT8Padding[124];
+  } Command;
+} QEMU_LOADER_ENTRY;
+#pragma pack ()
+
+#endif
diff --git a/OvmfPkg/AcpiPlatformDxe/Qemu.c b/OvmfPkg/AcpiPlatformDxe/Qemu.c
index 5a96d76..70f3ff6 100644
--- a/OvmfPkg/AcpiPlatformDxe/Qemu.c
+++ b/OvmfPkg/AcpiPlatformDxe/Qemu.c
@@ -15,8 +15,9 @@
 
 **/
 
 #include "AcpiPlatform.h"
+#include "QemuLoader.h"
 #include 
 #include 
 #include 
 #include 
@@ -794,10 +795,9 @@ InstallQemuLinkedTables (
 
   @retval  EFI_OUT_OF_RESOURCES  Memory allocation failed, or more than
  INSTALLED_TABLES_MAX tables found.
 
-  @retval  EFI_PROTOCOL_ERRORFound truncated or invalid ACPI table header
- in the fw_cfg contents.
+  @re

[edk2] [PATCH v2 3/4] OvmfPkg: AcpiPlatformDxe: exclude RSD PTR from QEMU's fw_cfg payload

2014-06-16 Thread Laszlo Ersek 
In one of the next patches we'll start scanning all fw_cfg files that QEMU
advertises as carrying ACPI tables, not just "etc/acpi/tables".

The RSD PTR table is known to occur in the "etc/acpi/rsdp" fw_cfg file.
Since edk2 handles RSD PTR automatically, similarly to RSDT and XSDT,
let's exclude RSD PTR too from the manually installed tables.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Jordan Justen 
---

Notes:
v2:
- patch is unchanged from v1 (2/3)

 OvmfPkg/AcpiPlatformDxe/Qemu.c | 104 +
 1 file changed, 104 insertions(+)

diff --git a/OvmfPkg/AcpiPlatformDxe/Qemu.c b/OvmfPkg/AcpiPlatformDxe/Qemu.c
index df912c2..5a96d76 100644
--- a/OvmfPkg/AcpiPlatformDxe/Qemu.c
+++ b/OvmfPkg/AcpiPlatformDxe/Qemu.c
@@ -515,8 +515,82 @@ QemuInstallAcpiTable (
);
 }
 
 
+/**
+  Check if an array of bytes starts with an RSD PTR structure.
+
+  Checksum is ignored.
+
+  @param[in] Buffer The array to check.
+
+  @param[in] Size   Number of bytes in Buffer.
+
+  @param[out] RsdpSize  If the function returns EFI_SUCCESS, this parameter
+contains the size of the detected RSD PTR structure.
+
+  @retval  EFI_SUCCESS RSD PTR structure detected at the beginning of
+   Buffer, and its advertised size does not exceed
+   Size.
+
+  @retval  EFI_PROTOCOL_ERROR  RSD PTR structure detected at the beginning of
+   Buffer, but it has inconsistent size.
+
+  @retval  EFI_NOT_FOUND   RSD PTR structure not found.
+
+**/
+
+STATIC
+EFI_STATUS
+CheckRsdp (
+  IN  CONST VOID *Buffer,
+  IN  UINTN  Size,
+  OUT UINTN  *RsdpSize
+  )
+{
+  CONST UINT64   *Signature;
+  CONST EFI_ACPI_1_0_ROOT_SYSTEM_DESCRIPTION_POINTER *Rsdp1;
+  CONST EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER *Rsdp2;
+
+  if (Size < sizeof *Signature) {
+return EFI_NOT_FOUND;
+  }
+  Signature = Buffer;
+
+  if (*Signature != EFI_ACPI_1_0_ROOT_SYSTEM_DESCRIPTION_POINTER_SIGNATURE) {
+return EFI_NOT_FOUND;
+  }
+
+  //
+  // Signature found -- from this point on we can only report
+  // EFI_PROTOCOL_ERROR or EFI_SUCCESS.
+  //
+  if (Size < sizeof *Rsdp1) {
+return EFI_PROTOCOL_ERROR;
+  }
+  Rsdp1 = Buffer;
+
+  if (Rsdp1->Reserved == 0) {
+//
+// ACPI 1.0 doesn't include the Length field
+//
+*RsdpSize = sizeof *Rsdp1;
+return EFI_SUCCESS;
+  }
+
+  if (Size < sizeof *Rsdp2) {
+return EFI_PROTOCOL_ERROR;
+  }
+  Rsdp2 = Buffer;
+
+  if (Size < Rsdp2->Length || Rsdp2->Length < sizeof *Rsdp2) {
+return EFI_PROTOCOL_ERROR;
+  }
+
+  *RsdpSize = Rsdp2->Length;
+  return EFI_SUCCESS;
+}
+
 //
 // We'll be saving the keys of installed tables so that we can roll them back
 // in case of failure. 128 tables should be enough for anyone (TM).
 //
@@ -601,11 +675,41 @@ InstallQemuLinkedTables (
 
   Processed = 0;
   while (Processed < TablesFileSize) {
 UINTN   Remaining;
+UINTN   RsdpSize;
 EFI_ACPI_DESCRIPTION_HEADER *Probe;
 
 Remaining = TablesFileSize - Processed;
+
+//
+// See if we're looking at an RSD PTR structure.
+//
+RsdpSize = 0;
+Status = CheckRsdp (Tables + Processed, Remaining, &RsdpSize);
+if (Status == EFI_PROTOCOL_ERROR) {
+  //
+  // RSD PTR found but its size is inconsistent; abort processing. (Note
+  // that "RSD PTR found" excludes the NUL-padding case by definition.)
+  //
+  break;
+}
+if (!EFI_ERROR (Status)) {
+  //
+  // Consistent RSD PTR found, skip it.
+  //
+  DEBUG ((EFI_D_VERBOSE, "%a: \"%a\" offset 0x%016Lx: RSD PTR "
+"Length=0x%08x\n", __FUNCTION__, FwCfgFile, (UINT64)Processed,
+(UINT32)RsdpSize));
+  Processed += RsdpSize;
+  continue;
+}
+ASSERT (Status == EFI_NOT_FOUND);
+
+//
+// What we're looking at is not an RSD PTR structure; attempt to parse it
+// as an ACPI table.
+//
 if (Remaining < sizeof *Probe) {
   Status = EFI_PROTOCOL_ERROR;
   break;
 }
-- 
1.8.3.1



--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH v2 0/4] OvmfPkg: AcpiPlatformDxe: don't rely on unstable QEMU interface

2014-06-16 Thread Laszlo Ersek 
Version 2 of the series at
.

Patch v2 1/4 (trivial) is new.

Patches v2 2/4 and v2 3/4 are unchanged (from v1 1/3 and v1 2/3
respectively).

Patch v2 4/4 addresses Jordan's comments for v1 3/3
.

Thanks,
Laszlo

Laszlo Ersek (4):
  OvmgPkg: QemuFwCfgLib: export QEMU_FW_CFG_FNAME_SIZE
  OvmfPkg: AcpiPlatformDxe: pass FwCfgFile to InstallQemuLinkedTables()
  OvmfPkg: AcpiPlatformDxe: exclude RSD PTR from QEMU's fw_cfg payload
  OvmfPkg: AcpiPlatformDxe: don't rely on unstable QEMU interface

 OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h  |   2 +-
 OvmfPkg/AcpiPlatformDxe/QemuLoader.h|  90 +
 OvmfPkg/Include/Library/QemuFwCfgLib.h  |   6 +
 OvmfPkg/AcpiPlatformDxe/AcpiPlatform.c  |   2 +-
 OvmfPkg/AcpiPlatformDxe/Qemu.c  | 291 
 OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c |   2 +-
 6 files changed, 351 insertions(+), 42 deletions(-)
 create mode 100644 OvmfPkg/AcpiPlatformDxe/QemuLoader.h

-- 
1.8.3.1


--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH v2 2/4] OvmfPkg: AcpiPlatformDxe: pass FwCfgFile to InstallQemuLinkedTables()

2014-06-16 Thread Laszlo Ersek 
Split InstallQemuLinkedTables() in two:
- the function now takes the name of the fw_cfg file (from which ACPI
  tables are to be extracted) as a parameter,

- the new function InstallAllQemuLinkedTables() calls the former with
  fw_cfg file names, and cumulatively tracks the ACPI tables installed by
  all invocations of the former.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Jordan Justen 
---

Notes:
v2:
- patch is unchanged from v1 (1/3)

 OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h |   2 +-
 OvmfPkg/AcpiPlatformDxe/AcpiPlatform.c |   2 +-
 OvmfPkg/AcpiPlatformDxe/Qemu.c | 163 +++--
 3 files changed, 116 insertions(+), 51 deletions(-)

diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h 
b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
index c643fa1..e757233 100644
--- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
+++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
@@ -62,9 +62,9 @@ InstallXenTables (
   );
 
 EFI_STATUS
 EFIAPI
-InstallQemuLinkedTables (
+InstallAllQemuLinkedTables (
   IN   EFI_ACPI_TABLE_PROTOCOL   *AcpiProtocol
   );
 #endif
 
diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.c 
b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.c
index 084c393..11f0ca8 100644
--- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.c
+++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.c
@@ -256,9 +256,9 @@ AcpiPlatformEntryPoint (
 
   if (XenDetected ()) {
 Status = InstallXenTables (AcpiTable);
   } else {
-Status = InstallQemuLinkedTables (AcpiTable);
+Status = InstallAllQemuLinkedTables (AcpiTable);
   }
 
   if (EFI_ERROR (Status)) {
 Status = FindAcpiTablesInFv (AcpiTable);
diff --git a/OvmfPkg/AcpiPlatformDxe/Qemu.c b/OvmfPkg/AcpiPlatformDxe/Qemu.c
index e62467a..df912c2 100644
--- a/OvmfPkg/AcpiPlatformDxe/Qemu.c
+++ b/OvmfPkg/AcpiPlatformDxe/Qemu.c
@@ -2,9 +2,9 @@
   OVMF ACPI QEMU support
 
   Copyright (c) 2008 - 2012, Intel Corporation. All rights reserved.
 
-  Copyright (C) 2012, Red Hat, Inc.
+  Copyright (C) 2012-2014, Red Hat, Inc.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -515,52 +515,80 @@ QemuInstallAcpiTable (
);
 }
 
 
-/**
-  Download the ACPI table data file from QEMU and interpret it.
-
-  @param[in] AcpiProtocol  The ACPI table protocol used to install tables.
-
-  @retval  EFI_UNSUPPORTED   Firmware configuration is unavailable.
-
-  @retval  EFI_NOT_FOUND The host doesn't export the required fw_cfg
- files.
-
-  @retval  EFI_OUT_OF_RESOURCES  Memory allocation failed.
-
-  @retval  EFI_PROTOCOL_ERRORFound truncated or invalid ACPI table header
- in the fw_cfg contents.
-
-  @returnStatus codes returned by
- AcpiProtocol->InstallAcpiTable().
-
-**/
-
 //
 // We'll be saving the keys of installed tables so that we can roll them back
 // in case of failure. 128 tables should be enough for anyone (TM).
 //
 #define INSTALLED_TABLES_MAX 128
 
+/**
+  Download one ACPI table data file from QEMU and interpret it.
+
+  @param[in] FwCfgFile The NUL-terminated name of the fw_cfg file to
+   download and interpret.
+
+  @param[in] AcpiProtocol  The ACPI table protocol used to install tables.
+
+  @param[in,out] InstalledKey  On input, an array of INSTALLED_TABLES_MAX UINTN
+   elements, allocated by the caller. On output,
+   the function will have stored (appended) the
+   AcpiProtocol-internal keys of the ACPI tables
+   that the function has installed from the fw_cfg
+   file. The array reflects installed tables even
+   if the function returns with an error.
+
+  @param[in,out] NumInstalled  On input, the number of entries already used in
+   InstalledKey; it must be in [0,
+   INSTALLED_TABLES_MAX] inclusive. On output, the
+   parameter is updated to the new cumulative count
+   of the keys stored in InstalledKey; the value
+   reflects installed tables even if the function
+   returns with an error.
+
+  @retval  EFI_INVALID_PARAMETER  NumInstalled is outside the allowed range on
+  input.
+
+  @retval  EFI_UNSUPPORTEDFirmware configuration is unavailable.
+
+  @retval  EFI_NOT_FOUND  The host doesn't export the requested fw_cfg
+  file.
+
+  @retval  EFI_OUT_OF_RESOURCES   Memory allocation failed, or no more room in
+

[edk2] [PATCH v2 1/4] OvmgPkg: QemuFwCfgLib: export QEMU_FW_CFG_FNAME_SIZE

2014-06-16 Thread Laszlo Ersek 
Names of firmware configuration files always take 56 bytes (including at
least one terminating NUL byte). Expose this constant to all consumers of
QemuFwCfgLib because further interfaces may depend on it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- patch is new in v2

 OvmfPkg/Include/Library/QemuFwCfgLib.h  | 6 ++
 OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/Include/Library/QemuFwCfgLib.h 
b/OvmfPkg/Include/Library/QemuFwCfgLib.h
index 8d3b835..baaa257 100644
--- a/OvmfPkg/Include/Library/QemuFwCfgLib.h
+++ b/OvmfPkg/Include/Library/QemuFwCfgLib.h
@@ -16,8 +16,14 @@
 
 #ifndef __FW_CFG_LIB__
 #define __FW_CFG_LIB__
 
+//
+// The size, in bytes, of names of firmware configuration files, including at
+// least one terminating NUL byte.
+//
+#define QEMU_FW_CFG_FNAME_SIZE 56
+
 typedef enum {
   QemuFwCfgItemSignature= 0x,
   QemuFwCfgItemInterfaceVersion = 0x0001,
   QemuFwCfgItemSystemUuid   = 0x0002,
diff --git a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c 
b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
index 92c85c1..24424f8 100644
--- a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
+++ b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
@@ -277,9 +277,9 @@ QemuFwCfgFindFile (
   for (Idx = 0; Idx < Count; ++Idx) {
 UINT32 FileSize;
 UINT16 FileSelect;
 UINT16 FileReserved;
-CHAR8  FName[56];
+CHAR8  FName[QEMU_FW_CFG_FNAME_SIZE];
 
 FileSize = QemuFwCfgRead32 ();
 FileSelect   = QemuFwCfgRead16 ();
 FileReserved = QemuFwCfgRead16 ();
-- 
1.8.3.1



--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Issues with GenFds when FDF BaseAddress is 0x0

2014-06-16 Thread Laszlo Ersek 
On 06/16/14 08:14, Michael Casadevall wrote:
> Hey all,
> 
> I've been working on porting TianoCore to KVM on AArch64, and I've
> recently run into an issue which I'm hoping someone can help me to
> debug. Recent proposed changes to KVM place the address space for
> BootROMs and persistent storage from 0x0-0x800, with the early boot
> code for Tiano startng at 0x0.

Looks like a spectacularly bad idea. The C standard guarantees that any
pointer to a function, and any pointer to an object, will compare
unequal to a null pointer. On edk2 platforms, null pointers have
all-bits-zero representation. If you place an object at address zero,
then the above guarantee is breached.

> My problem is that when the FDF is set to
> generate an image for this load location, it appears to create a
> malformed FD file.
> 
> Under normal circumstances, the very first bits of the .fd file are a
> branch instruction to the start of the PEI. This generates correctly
> when the FDF is set to any BaseAddress that != 0x0.
> 
> For example:
> 
> Here's a known good image
> $ hexdump
> Build/AArch64Virtualization-KVM/DEBUG_ARMLINUXGCC/FV/KVM_EFI.fd | head
> 000 01e2 1400      
> 010 e578 8c8c 8a3d 4f1c 3599 6189 c385 d32d
> 
> The same code, compiled with my updated FDF generates the following:
> $ hexdump
> Build/AArch64Virtualization-KVM/DEBUG_ARMLINUXGCC/FV/KVM_EFI.fd | head
> 000        
> 010 e578 8c8c 8a3d 4f1c 3599 6189 c385 d32d

(In the second line of each of these dumps, you can see
EFI_FIRMWARE_FILE_SYSTEM2_GUID. But this is just a side note, not
particularly important.)

> 
> I've tried and failed to locate the code responsible for writing out the
> initial branch statement, so I'm hoping somewhere here can get me a
> pointer on where to look. The relevant bit of my FDF is inline below.
> 
> [FD.KVM_EFI]
> BaseAddress   = 0x000|gArmTokenSpaceGuid.PcdFdBaseAddress  # KVM
> assigns 0 - 0x800 for a BootROM
> Size  = 0x800|gArmTokenSpaceGuid.PcdFdSize # The
> size in bytes of the FLASH Device
> ErasePolarity = 1
> 
> # This one is tricky, it must be: BlockSize * NumBlocks = Size
> BlockSize = 0x1000
> NumBlocks = 0x8000
> 
> As best I can tell, GenFds appears to be the relevant utility, but
> nothing in the code jumps out as relevent, and I admit I'm completely
> unfamiliar with this area of the tree.

Please save your build log and upload it somewhere. My guess is the
following -- see "BaseTools/UserManuals/GenFds_Utility_Man_Page.rtf" --
GenFv is likely called with --baseaddr=0 (equivalently, with -r 0),
which leads the code to believe that --baseaddr has not been passed at
all. See:

$ GenFv --help

  -r Address, --baseaddr Address
Address is the rebase start address for drivers that
run in Flash. It supports DEC or HEX digital format.
If it is set to zero, no rebase action will be taken

And/or, please see GenVtf ("generate volume top file") too:

$ GenVtf --help

  -r BaseAddress,  --baseaddr BaseAddress
  BaseAddress is the starting address of Firmware Volume
  where Boot Strapped Image will reside.

main() in "BaseTools/Source/C/GenVtf/GenVtf.c" parses the value into
"StartAddress1" and "StartAddress2" (which are set to zero initially),
and passes them to GenerateVtfImage(). That function checks for zero
values (at least in case of StartAddress2.)

GenFds (BaseTools/Source/Python/GenFds) seems to be a Python program
that invokes both GenFv and GenVtf, and it appears to pass "-r" to both.

The above are not the exact cause of course, but I think they illustrate
that storing the boot code such that the null pointer points to it is a
Bad Idea (TM). I'm not sure about the alignment requirements (word?
page?) -- can you try at the next "granule" above zero?

Thanks
Laszlo

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Issues with GenFds when FDF BaseAddress is 0x0

2014-06-16 Thread Harry Liebel 
Hi Michael.

I think what you are really looking for is the 'Force rebase' option
that goes into the fdf file. It is a workaround in the Basetool as it
normally skips some image creation operations if the image Base address
is set to 0x0.

So in your fdf file you can try something like this (taken from the
ArmVExpress-FVP-AArch64.fdf):
---
  [FV.FVMAIN_SEC]
  FvBaseAddress  = 0x0  # Secure ROM
  FvForceRebase  = TRUE
  FvAlignment= 16
  ERASE_POLARITY = 1
---

The 'FvForceRebase' option forces the tool to process the image even if
the base address is set to 0x0.


To answer the other part of the question. The initial jump instruction
lives here:
BaseTools/Source/C/GenFv/GenFvInternalLib.c : UpdateArmResetVectorIfNeeded()

Regards,
Harry


On 16/06/14 07:14, Michael Casadevall wrote:
> Hey all,
>
> I've been working on porting TianoCore to KVM on AArch64, and I've
> recently run into an issue which I'm hoping someone can help me to
> debug. Recent proposed changes to KVM place the address space for
> BootROMs and persistent storage from 0x0-0x800, with the early
> boot code for Tiano startng at 0x0. My problem is that when the FDF is
> set to generate an image for this load location, it appears to create
> a malformed FD file.
>
> Under normal circumstances, the very first bits of the .fd file are a
> branch instruction to the start of the PEI. This generates correctly
> when the FDF is set to any BaseAddress that != 0x0.
>
> For example:
>
> Here's a known good image
> $ hexdump
> Build/AArch64Virtualization-KVM/DEBUG_ARMLINUXGCC/FV/KVM_EFI.fd | head
> 000 01e2 1400      
> 010 e578 8c8c 8a3d 4f1c 3599 6189 c385 d32d
>
> The same code, compiled with my updated FDF generates the following:
> $ hexdump
> Build/AArch64Virtualization-KVM/DEBUG_ARMLINUXGCC/FV/KVM_EFI.fd | head
> 000        
> 010 e578 8c8c 8a3d 4f1c 3599 6189 c385 d32d
>
> I've tried and failed to locate the code responsible for writing out
> the initial branch statement, so I'm hoping somewhere here can get me
> a pointer on where to look. The relevant bit of my FDF is inline below.
>
> [FD.KVM_EFI]
> BaseAddress   = 0x000|gArmTokenSpaceGuid.PcdFdBaseAddress  # KVM
> assigns 0 - 0x800 for a BootROM
> Size  = 0x800|gArmTokenSpaceGuid.PcdFdSize # The
> size in bytes of the FLASH Device
> ErasePolarity = 1
>
> # This one is tricky, it must be: BlockSize * NumBlocks = Size
> BlockSize = 0x1000
> NumBlocks = 0x8000
>
> As best I can tell, GenFds appears to be the relevant utility, but
> nothing in the code jumps out as relevent, and I admit I'm completely
> unfamiliar with this area of the tree.
>
> Thanks in advance,
> Michael


-- IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered 
in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
Registered in England & Wales, Company No:  2548782


--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Patches needed to compile CryptoPkg and SecurityPkg with Xcode.

2014-06-16 Thread Ye, Ting 
The patches are checked in @revision 15560 for CryptoPkg and 15561 for 
SecurityPkg. Thanks again for the updates.

Best Regards,
Ting

From: Long, Qin [mailto:qin.l...@intel.com]
Sent: Friday, June 13, 2014 4:26 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Patches needed to compile CryptoPkg and SecurityPkg with 
Xcode.

Hi, Andrew,

Thanks for the updates.
We will follow the process and check-in this patch later. .


Best Regards & Thanks,
LONG, Qin

From: Andrew Fish [mailto:af...@apple.com]
Sent: Thursday, June 12, 2014 11:38 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] Patches needed to compile CryptoPkg and SecurityPkg with Xcode.


Contributed-under: TianoCore Contribution Agreement 1.0

>git diff CryptoPkg/
diff --git a/edk2/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf 
b/edk2/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
index cdbe3ac..ab517a4 100755
--- a/edk2/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
+++ b/edk2/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
@@ -108,4 +108,5 @@
 #
 [BuildOptions]
   GCC:*_GCC44_IA32_CC_FLAGS = "-D__cdecl=__attribute__((cdecl))" 
"-D__declspec(t)=__attribute__((t))"
+  XCODE:*_*_*_CC_FLAGS = -mmmx -msse


diff --git a/edk2/CryptoPkg/Library/OpensslLib/OpensslLib.inf 
b/edk2/CryptoPkg/Library/OpensslLib/OpensslLib.inf
index e8bec20..5a2d6a5 100755
--- a/edk2/CryptoPkg/Library/OpensslLib/OpensslLib.inf
+++ b/edk2/CryptoPkg/Library/OpensslLib/OpensslLib.inf
@@ -609,3 +609,5 @@
RVCT:*_*_IA32_CC_FLAGS = $(OPENSSL_FLAGS) 
$(OPENSSL_EXFLAGS) --library_interface=aeabi_clib99 --fpu=vfpv3 -DTHIRTY_TWO_BIT
RVCT:*_*_X64_CC_FLAGS  = $(OPENSSL_FLAGS) 
$(OPENSSL_EXFLAGS) --library_interface=aeabi_clib99 --fpu=vfpv3 -DSIXTY_FOUR_BIT
RVCT:*_*_IPF_CC_FLAGS  = $(OPENSSL_FLAGS) 
$(OPENSSL_EXFLAGS) --library_interface=aeabi_clib99 --fpu=vfpv3 -DSIXTY_FOUR_BIT
+   XCODE:*_*_IA32_CC_FLAGS  = -mmmx -msse -U_WIN32 -U_WIN64 
$(OPENSSL_FLAGS) $(OPENSSL_EXFLAGS) -w -DTHIRTY_TWO_BIT
+   XCODE:*_*_X64_CC_FLAGS   = -mmmx -msse -U_WIN32 -U_WIN64 
$(OPENSSL_FLAGS) $(OPENSSL_EXFLAGS) -w -DSIXTY_FOUR_BIT



>git diff SecurityPkg/
diff --git 
a/edk2/SecurityPkg/Library/DxeDeferImageLoadLib/DxeDeferImageLoadLib.c 
b/edk2/SecurityPkg/Library/DxeDeferImageLoadLib/DxeDeferImageLoadLib.c
index 3cbd098..1729051 100644
--- a/edk2/SecurityPkg/Library/DxeDeferImageLoadLib/DxeDeferImageLoadLib.c
+++ b/edk2/SecurityPkg/Library/DxeDeferImageLoadLib/DxeDeferImageLoadLib.c
@@ -246,7 +246,7 @@ GetAccessControl (
 CheckLen  = 0;
 while (CheckLen < Info->InfoSize - sizeof (EFI_USER_INFO)) {
   Access = (EFI_USER_INFO_ACCESS_CONTROL *) ((UINT8 *) (Info + 1) + 
CheckLen);
-  if ((Access->Type == AccessType)) {
+  if (Access->Type == AccessType) {
 *AccessControl = AllocateZeroPool (Access->Size);
 ASSERT (*AccessControl != NULL);
 CopyMem (*AccessControl, Access, Access->Size);
diff --git a/edk2/SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf 
b/edk2/SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf
index 0ea5949..553dbf5 100644
--- a/edk2/SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf
+++ b/edk2/SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf
@@ -75,3 +75,6 @@


 [Depex]
   TRUE
+
+[BuildOptions]
+  XCODE:*_*_*_CC_FLAGS = -mmmx -msse

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 3/3] OvmfPkg: AcpiPlatformDxe: don't rely on unstable QEMU interface

2014-06-16 Thread Jordan Justen 
On Tue, May 20, 2014 at 3:52 PM, Laszlo Ersek  wrote:
> The fw_cfg file "etc/acpi/tables" is not a stable guest interface -- QEMU
> could rename it in the future, and/or introduce additional fw_cfg files
> with ACPI payload. Only the higher-level "etc/table-loader" file is
> considered stable, which contains a sequence of loader/linker commands, to
> be executed by the firmware.

How does this sound instead: ... "which contains a sequence of
commands to assist firmware with reading QEMU ACPI tables from the
FwCfg interface."

> Because edk2 provides automatic linking and checksumming for ACPI tables,

"automatic linking and checksumming" => "publishing support" ?

> we only handle the Allocate commands (of which the prior OVMF
> functionality is a subset).

> Even in the Allocate commands we ignore the
> allocation hints (Alignment and Zone); they only need manual handling in
> SeaBIOS.

How does this sound instead: "OVMF only uses the Allocate command to
find the names of FwCfg files to read and publish as ACPI tables."

> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> ---
>  OvmfPkg/AcpiPlatformDxe/QemuLoader.h | 86 
> 
>  OvmfPkg/AcpiPlatformDxe/Qemu.c   | 54 +++---
>  2 files changed, 135 insertions(+), 5 deletions(-)
>  create mode 100644 OvmfPkg/AcpiPlatformDxe/QemuLoader.h
>
> diff --git a/OvmfPkg/AcpiPlatformDxe/QemuLoader.h 
> b/OvmfPkg/AcpiPlatformDxe/QemuLoader.h
> new file mode 100644
> index 000..7b69f90
> --- /dev/null
> +++ b/OvmfPkg/AcpiPlatformDxe/QemuLoader.h
> @@ -0,0 +1,86 @@
> +/** @file
> +  Command structures for the QEMU linker/loader interface.
> +
> +  Copyright (C) 2014, Red Hat, Inc.
> +
> +  This program and the accompanying materials are licensed and made available
> +  under the terms and conditions of the BSD License which accompanies this
> +  distribution.  The full text of the license may be found at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, 
> WITHOUT
> +  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#ifndef __QEMU_LOADER_H__
> +#define __QEMU_LOADER_H__
> +
> +#include 
> +
> +//
> +// The types and the documentation reflects the SeaBIOS interface. In OVMF we
> +// use a minimal subset of it.
> +//
> +#define QEMU_LOADER_FNAME_SIZE 56

Where does this number come from?

> +
> +typedef enum {
> +  QemuLoaderCmdAllocate = 1,

Maybe a comment around here saying that we only look at the Allocate
command, and only to get FwCfg filenames?

With those changes:
Series Reviewed-by: Jordan Justen 

> +  QemuLoaderCmdAddPointer,
> +  QemuLoaderCmdAddChecksum
> +} QEMU_LOADER_COMMAND_TYPE;
> +
> +typedef enum {
> +  QemuLoaderAllocHigh = 1,
> +  QemuLoaderAllocFSeg
> +} QEMU_LOADER_ALLOC_ZONE;
> +
> +#pragma pack (1)
> +//
> +// QemuLoaderCmdAllocate: download the fw_cfg file named File, to a buffer
> +// allocated in the zone specified by Zone, aligned at a multiple of 
> Alignment.
> +//
> +typedef struct {
> +  UINT8  File[QEMU_LOADER_FNAME_SIZE]; // NUL-terminated
> +  UINT32 Alignment;// power of two
> +  UINT8  Zone; // QEMU_LOADER_ALLOC_ZONE values
> +} QEMU_LOADER_ALLOCATE;
> +
> +//
> +// QemuLoaderCmdAddPointer: the bytes at
> +// [PointerOffset..PointerOffset+PointerSize) in the file PointerFile 
> contain a
> +// relative pointer (an offset) into PointeeFile. Increment the relative
> +// pointer's value by the base address of where PointeeFile's contents have
> +// been placed (when QemuLoaderCmdAllocate has been executed for 
> PointeeFile).
> +//
> +typedef struct {
> +  UINT8  PointerFile[QEMU_LOADER_FNAME_SIZE]; // NUL-terminated
> +  UINT8  PointeeFile[QEMU_LOADER_FNAME_SIZE]; // NUL-terminated
> +  UINT32 PointerOffset;
> +  UINT8  PointerSize; // one of 1, 2, 4, 8
> +} QEMU_LOADER_ADD_POINTER;
> +
> +//
> +// QemuLoaderCmdAddChecksum: calculate the UINT8 checksum (as per
> +// CalculateChecksum8()) of the range [Start..Start+Length) in File. Store 
> the
> +// UINT8 result at ResultOffset in the same File.
> +//
> +typedef struct {
> +  UINT8  File[QEMU_LOADER_FNAME_SIZE]; // NUL-terminated
> +  UINT32 ResultOffset;
> +  UINT32 Start;
> +  UINT32 Length;
> +} QEMU_LOADER_ADD_CHECKSUM;
> +
> +typedef struct {
> +  UINT32 Type; // QEMU_LOADER_COMMAND_TYPE values
> +  union {
> +QEMU_LOADER_ALLOCATE Allocate;
> +QEMU_LOADER_ADD_POINTER  AddPointer;
> +QEMU_LOADER_ADD_CHECKSUM AddChecksum;
> +UINT8Padding[124];
> +  } Command;
> +} QEMU_LOADER_ENTRY;
> +#pragma pack ()
> +
> +#endif
> diff --git a/OvmfPkg/AcpiPlatformDxe/Qemu.c b/OvmfPkg/AcpiPlatformDxe/Qemu.c
> index 5a96d76..70f3ff6 100644
> --- a/OvmfPkg/AcpiPlatformDxe/Qemu.c
> +++ b/OvmfPkg/AcpiPlatformDxe/Qemu.c
> @@ -15,8 +15,9 @@
>
>  **/
>
>  #i