[edk2] VS2013 build failures: unresolved external symbol __dtoui3

2014-09-04 Thread Scott Duplichan
Building AppPkg for IA32 using VS2013 fails with unresolved external symbol 
__dtoui3.
__dtoui3 is a helper function called by the generated code. It is analogous to 
the
__ftol2 helper function call generated by older Microsoft compilers. VS2013 
calls
__dtoui3 instead of __ftol2. Apparently the new function converts double to 
integer
with reduced use of the x87 fpu.

The call to __ftol2 generated by older Microsoft compilers is resolved by binary
file StdLib\LibC\Main\Ia32\ftol2.obj, an object extracted from Microsoft libs. 
The
same approach could be used for VS2013's __dtoui3 by extracting ftol3.obj and 
adding
it to EDK2. But doing so causes unresolved external symbol __except1. This can 
be
fixed by extracting fpexcept.obj from VS2013 libs and adding it to EDK2. But 
once
that is done, 12 more unresolved externals are created.

Another approach is to use /arch:SSE when building LibGdtoa for IA32 with VS2013
(default is /arch:SSE2). This causes VS2013 to generate a call to __ftol2 
instead
of __dtoui3 and resolves the build failure. I suppose this is the route to take.
Concerns are:
1) Is it OK to combine modules compiled with /arch:SSE2 and /arch:SSE?
2) Is the current EDK2 ftol2.obj binary compatible with all supported Microsoft
   compilers, including VS2013?
I will do some testing and submit a patch if it looks OK.
Thanks,
Scott




--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


Re: [edk2] Get PARTITION_PRIVATE_DATA from BlockIo.

2014-09-04 Thread Tian, Feng
This usage is wrong.

The PARTITION_PRIVATE_DATA is a hidden private data only referred by Partition 
driver internally. It’s not exposed for external user.

From: Nguyễn Văn Hiễn [mailto:nvhien1...@gmail.com]
Sent: Friday, September 05, 2014 11:48
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] Get PARTITION_PRIVATE_DATA from BlockIo.

Hi all,
I'm trying to get PARTITION_PRIVATE_DATA from *BlockIo using 
PARTITION_DEVICE_FROM_BLOCK_IO_THIS, then I access to attributes of DiskIo in 
PARTITION_PRIVATE_DATA (e.g *->DiskIo->Revision). But a synchronous exception 
error will occur if I access it.

  //Open BlockIo protocol
  Status = gBS->OpenProtocol (
BlockIoHandle,
&gEfiBlockIoProtocolGuid,
(VOID**)&BlockIo, //<=== BlockIo is OK.
gImageHandle,
NULL,
EFI_OPEN_PROTOCOL_GET_PROTOCOL
);
  if (EFI_ERROR(Status)) {
 ERROR (L"Error on opening gEfiBlockIoProtocolGuid\n");
 return Status;
  }

  PartitionPrivateData = PARTITION_DEVICE_FROM_BLOCK_IO_THIS (BlockIo);
  if (PartitionPrivateData != NULL) {
 PartitionPrivateData->DiskIo->Revision; //< an error occurs in here.
  }

Thanks for any help,
Hien
=
Ho Chi Minh City University of Technology, VN
nvhien1...@gmail.com
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


[edk2] Get PARTITION_PRIVATE_DATA from BlockIo.

2014-09-04 Thread Nguyễn Văn Hiễn
Hi all,

I'm trying to get PARTITION_PRIVATE_DATA from *BlockIo using
PARTITION_DEVICE_FROM_BLOCK_IO_THIS, then I access to attributes of DiskIo
in PARTITION_PRIVATE_DATA (e.g *->DiskIo->Revision). But a synchronous
exception error will occur if I access it.

  //Open BlockIo protocol
  Status = gBS->OpenProtocol (
BlockIoHandle,
&gEfiBlockIoProtocolGuid,
(VOID**)&BlockIo, //<=== BlockIo is OK.
gImageHandle,
NULL,
EFI_OPEN_PROTOCOL_GET_PROTOCOL
);
  if (EFI_ERROR(Status)) {
 ERROR (L"Error on opening gEfiBlockIoProtocolGuid\n");
 return Status;
  }

  PartitionPrivateData = PARTITION_DEVICE_FROM_BLOCK_IO_THIS (BlockIo);
  if (PartitionPrivateData != NULL) {
 PartitionPrivateData->DiskIo->Revision; //< an error occurs in
here.
  }

Thanks for any help,
Hien
=
Ho Chi Minh City University of Technology, VN
nvhien1...@gmail.com
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


Re: [edk2] HII ORDERED_LIST support

2014-09-04 Thread Dong, Eric
Tim,

For option, current it only has one value and one prompt string " EFI_STRING_ID 
Option; ". For below example:
  orderedlist
varid   = MyIfrNVData.BootOrder,
prompt  = STRING_TOKEN(0x006D),
help= STRING_TOKEN(0x0059),
option text = STRING_TOKEN(0x006F), value = 2, flags = 0;
option text = STRING_TOKEN(0x006E), value = 1, flags = DEFAULT;
option text = STRING_TOKEN(0x0070), value = 3, flags = 0;
  endlist;
the result shows like below, and user can change the option order.
[cid:image003.png@01CFC8F8.9B6B9F80]

If  we support buffer type for option, take below code for example:
  orderedlist
varid   = MyIfrNVData.BootOrder,
prompt  = STRING_TOKEN(0x006D),
help= STRING_TOKEN(0x0059),
option text = STRING_TOKEN(0x006F), value = 2, 1, 3, flags = 0;
  endlist;
the result shows like below, how can user to change the order for this case?
 [cid:image004.png@01CFC8F8.9B6B9F80]


For the buffer grammar in VFR, because we already has an opcode "ideqvallist" 
which has the similar format, so I follow this style to define the buffer 
grammar.
  numeric varid   = MyIfrNVData.HowOldAreYouInYearsManual,
prompt  = STRING_TOKEN(STR_NUMERIC_MANUAL_PROMPT),
help= STRING_TOKEN(STR_NUMERIC_HELP0),
minimum = 0,
maximum = 0xf0,
step= 0,
default value = questionrefval(devicepath = STRING_TOKEN 
(STR_DEVICE_PATH), guid = DRIVER_SAMPLE_FORMSET_GUID, 0x),

inconsistentif prompt = STRING_TOKEN(STR_ERROR_POPUP),
  ideqval MyIfrNVData.HowOldAreYouInYearsManual == 99
  OR
  ideqid  MyIfrNVData.HowOldAreYouInYearsManual == MyEfiVar.Field8
  OR
  ideqvallist MyIfrNVData.HowOldAreYouInYearsManual == 1 3 5 7
endif
endnumeric;


  orderedlist
varid   = MyIfrNVData.BootOrder,
prompt  = STRING_TOKEN(0x006D),
help= STRING_TOKEN(0x0059),
option text = STRING_TOKEN(0x006F), value = 2  1  3, flags = 0;
  endlist;

Thanks,
Eric
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Friday, September 05, 2014 8:09 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] HII ORDERED_LIST support

Eric -

Here is the basic idea:

typedef struct _EFI_IFR_ONE_OF_OPTION {
  EFI_IFR_OP_HEADER Header;
  EFI_STRING_ID Option;
  UINT8 Flags;
  UINT8 Type;  <<= For ORDERED_LIST, can be EFI_IFR_TYPE_NUM_SIZE_8 or 
EFI_IFR_TYPE_BUFFER
  EFI_IFR_TYPE_VALUE Value;
} EFI_IFR_ONE_OF_OPTION;

typedef struct _EFI_IFR_DEFAULT {
  EFI_IFR_OP_HEADER Header;
  UINT16 DefaultId;
  UINT8 Type;  <<= For ORDERED_LIST, can be EFI_IFR_TYPE_NUM_SIZE_8 or 
EFI_IFR_TYPE_BUFFER
  EFI_IFR_TYPE_VALUE Value;
} EFI_IFR_DEFAULT;

For EFI_IFR_ORDERED_LIST only, the nested EFI_IFR_ONE_OF_OPTION can be either 
EFI_IFR_TYPE_NUM_SIZE_8 or EFI_IFR_TYPE_BUFFER. If it is 
EFI_IFR_TYPE_NUM_SIZE_8, then the option value is only for a single container. 
But if it is EFI_IFR_TYPE_BUFFER, then it is for all containers. If 
EFI_IFR_TYPE_BUFFER and the number of bytes is smaller than the number of 
containers, then remaining containers are set to 0 (empty)

Same with EFI_IFR_DEFAULT.

BTW, I suggest that the buffer grammar in VFR be "{" byte-list "}"  and 
byte-list :=  | integer

Tim



From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Wednesday, September 03, 2014 6:31 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] HII ORDERED_LIST support

Tim,

Add my comments below.


From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Thursday, September 04, 2014 12:04 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] HII ORDERED_LIST support

Eric -

Here is what I am thinking: we can extend the UEFI specification (which I will 
do in a separate ECR), to allow either the UINT8 or the BUFFER value for 
"option" and "default" If UINT8, then it will work on a single container. If 
BUFFER then it works on all containers. It may take me a week (after IDF) to 
get the ECR written for UEFI.
[[[Eric]]] If in BUFFER type, we can create a sample like below. In this case, 
only one "text" for this option, how to show the different value for this 
orderedlist? Maybe we need to update the "text" field also? I agree it has 
value to support BUFFER type for default opcode, because in this case we can 
set default value for "orderedlist" opcode. But I don't know the value to 
support BUFFER for "option"? It will make the "option" more complicate to 
handle. Also the "option" can be used for "Oneof" opcode, we also need consider 
this opcode when we clarify the "option" opcode.
  orderedlist
varid   = MyIfrNVData.BootOrder,

[edk2] [patch] MdeModulePkg Fix XCODE Link Issue in DxeCore

2014-09-04 Thread Gao, Liming
Andrew:
  Could you help review this patch?

MdeModulePkg: Fix XCODE Link Issue in DxeCore

In XCODE tool chain, the 64-bit bit wise and operation is causing the compiler 
to emit an __umoddi3.
This patch uses BaseLib API to replace 64-bit bit operation.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gao, Liming 
CC: af...@apple.com

Index: Stall.c
===
--- Stall.c  (revision 15972)
+++ Stall.c   (working copy)
@@ -32,7 +32,7 @@
   IN UINT64  Counter
   )
{
-  while ((Counter & 0xULL) != 0) {
+  while (RShiftU64 (Counter, 32) > 0) {
 gMetronome->WaitForTick (gMetronome, 0x);
 Counter -= 0x;
   }

Thanks
Liming
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


Re: [edk2] HII ORDERED_LIST support

2014-09-04 Thread Tim Lewis
Eric -

Here is the basic idea:

typedef struct _EFI_IFR_ONE_OF_OPTION {
  EFI_IFR_OP_HEADER Header;
  EFI_STRING_ID Option;
  UINT8 Flags;
  UINT8 Type;  <<= For ORDERED_LIST, can be EFI_IFR_TYPE_NUM_SIZE_8 or 
EFI_IFR_TYPE_BUFFER
  EFI_IFR_TYPE_VALUE Value;
} EFI_IFR_ONE_OF_OPTION;

typedef struct _EFI_IFR_DEFAULT {
  EFI_IFR_OP_HEADER Header;
  UINT16 DefaultId;
  UINT8 Type;  <<= For ORDERED_LIST, can be EFI_IFR_TYPE_NUM_SIZE_8 or 
EFI_IFR_TYPE_BUFFER
  EFI_IFR_TYPE_VALUE Value;
} EFI_IFR_DEFAULT;

For EFI_IFR_ORDERED_LIST only, the nested EFI_IFR_ONE_OF_OPTION can be either 
EFI_IFR_TYPE_NUM_SIZE_8 or EFI_IFR_TYPE_BUFFER. If it is 
EFI_IFR_TYPE_NUM_SIZE_8, then the option value is only for a single container. 
But if it is EFI_IFR_TYPE_BUFFER, then it is for all containers. If 
EFI_IFR_TYPE_BUFFER and the number of bytes is smaller than the number of 
containers, then remaining containers are set to 0 (empty)

Same with EFI_IFR_DEFAULT.

BTW, I suggest that the buffer grammar in VFR be "{" byte-list "}"  and 
byte-list :=  | integer

Tim



From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Wednesday, September 03, 2014 6:31 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] HII ORDERED_LIST support

Tim,

Add my comments below.


From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Thursday, September 04, 2014 12:04 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] HII ORDERED_LIST support

Eric -

Here is what I am thinking: we can extend the UEFI specification (which I will 
do in a separate ECR), to allow either the UINT8 or the BUFFER value for 
"option" and "default" If UINT8, then it will work on a single container. If 
BUFFER then it works on all containers. It may take me a week (after IDF) to 
get the ECR written for UEFI.
[[[Eric]]] If in BUFFER type, we can create a sample like below. In this case, 
only one "text" for this option, how to show the different value for this 
orderedlist? Maybe we need to update the "text" field also? I agree it has 
value to support BUFFER type for default opcode, because in this case we can 
set default value for "orderedlist" opcode. But I don't know the value to 
support BUFFER for "option"? It will make the "option" more complicate to 
handle. Also the "option" can be used for "Oneof" opcode, we also need consider 
this opcode when we clarify the "option" opcode.
  orderedlist
varid   = MyIfrNVData.BootOrder,
prompt  = STRING_TOKEN(0x006D),
help= STRING_TOKEN(0x0059),
option text = STRING_TOKEN(0x006F), value = 2  1  3, flags = 0;
  endlist;

I think that if we document this behavior, it will be useful.

Are there any other question types where there are multiple value types 
possible? Obviously UINTx. How about CHECKBOX with integer? Or NUMERIC with 
BOOLEAN? Just thinking ahead.
[[[Eric]]] I think we don't have that question.

Tim

From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Tuesday, September 02, 2014 10:45 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] HII ORDERED_LIST support

After internal discussion, we agree default opcode can support ordered list 
opcode, I will follow up to enable it.

For your proposal, item 2 I think it's not an acceptable proposal, take below 
code for example:
  orderedlist
varid   = MyIfrNVData.BootOrder,
prompt  = STRING_TOKEN(0x006D),
help= STRING_TOKEN(0x0059),
option text = STRING_TOKEN(0x006F), value = 2, flags = 0;
option text = STRING_TOKEN(0x006E), value = 1, flags = DEFAULT;
option text = STRING_TOKEN(0x0070), value = 3, flags = 0;
  endlist;
normally, we can see option 2/option 1/option 3 for this ordered list. But base 
on your proposal, the default for this ordered list opcode is option 1/option 
1/option 1, do you think  this is an valid ordered list result? I think if 
DEFAULT flag is set, we can just skip this flag. We can use default opcode to 
set default for ordered list opcode.

For your proposal, I think you can submit an ECR for it.

Thanks,
Eric
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, September 03, 2014 10:24 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] HII ORDERED_LIST support

Again, these are EDK2 decisions. They are not limitations of the specification. 
The UEFI specification does not indicate that the EFI_IFR_ONE_OF_OPTION default 
flag cannot work for ordered list. The UEFI specification does not say that 
there is any limitation to the default opcode. It does not say that 
EFI_IFR_TYPE_BUFFER cannot be used.   These are EDK2 and VFR limitations, not 
specification limits.

So, that is why I made the proposal below: to try and clarify the behavior if 
these exist based on the UEFI specification language.

Tim

From: Dong, Eric [mail

Re: [edk2] ShellPkg: Update BCFG command for correct use and errors on moving

2014-09-04 Thread Bjorge, Erik C
Reviewed-by: Erik Bjorge 

From: Carsey, Jaben
Sent: Thursday, September 04, 2014 1:09 PM
To: Shah, Tapan (tapands...@hp.com); Bjorge, Erik C
Cc: edk2-devel@lists.sourceforge.net; Carsey, Jaben
Subject: ShellPkg: Update BCFG command for correct use and errors on moving

Erik and Tapan,

Can you please look at this patch?

This will be merged into both bcfg.c files (I need to refactor those into a 
separate library).

ShellPkg: Update BCFG command for correct use and errors on moving

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jaben Carsey 
mailto:jaben.car...@intel.com>>
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


Re: [edk2] ShellPkg: Update BCFG command for correct use and errors on moving

2014-09-04 Thread Shah, Tapan
Reviewed-by: Tapan Shah mailto:tapands...@hp.com>>

From: Carsey, Jaben [mailto:jaben.car...@intel.com]
Sent: Thursday, September 04, 2014 3:09 PM
To: Shah, Tapan; Bjorge, Erik C
Cc: edk2-devel@lists.sourceforge.net; Carsey, Jaben
Subject: ShellPkg: Update BCFG command for correct use and errors on moving

Erik and Tapan,

Can you please look at this patch?

This will be merged into both bcfg.c files (I need to refactor those into a 
separate library).

ShellPkg: Update BCFG command for correct use and errors on moving

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jaben Carsey 
mailto:jaben.car...@intel.com>>
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


[edk2] ShellPkg: Update BCFG command for correct use and errors on moving

2014-09-04 Thread Carsey, Jaben
Erik and Tapan,

Can you please look at this patch?

This will be merged into both bcfg.c files (I need to refactor those into a 
separate library).

ShellPkg: Update BCFG command for correct use and errors on moving

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jaben Carsey 


Bcfg.c.patch
Description: Bcfg.c.patch
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


Re: [edk2] Xcode 5 and Ovmf.

2014-09-04 Thread Sergey Isakov
Hi Andrew,
One more problem with Clang compilation.
I modified MdeModulePkg/Application/HelloWorld/HelloWorld.c with two lines
———

  Index = 1234;
  AsciiPrint("Index=%d\n", Index);

——

And compile it with GCC49 and with Clang.
First printed 1234, second printed address instead of value


Sergey

On 01 сент. 2014 г., at 21:43, Sergey Isakov  wrote:

> Hi,
> QvmfPkg compiled by XCODE5 to RELEASE works with Qemu 2.1.0 !
> Great!
> Sergey
> 
> 
> On 01 сент. 2014 г., at 11:09, Sergey Isakov  wrote:
> 
>> Hi Andrew,
>> your patches are good. I tested CpuExceptionHandler.lib and Thunk16.nasm in 
>> Ovmf+Qemu2.0 compiled by GCC49. Works fine!
>> But with XCLANG (Xcode 4.4.1) I got an error
>> --
>> qemu: fatal: Trying to execute code outside RAM or ROM at 0x000a
>> 
>> RAX= RBX=fffcc0e4 RCX=800e 
>> RDX=7ff95df8
>> RSI=fffd6104 RDI=5042 RBP=7ff5b9a0 
>> RSP=7ff5b930
>> R8 =7fe75d70 R9 =7fe75d88 R10= 
>> R11=
>> R12= R13= R14= 
>> R15=
>> RIP=0009ffbe RFL=0046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
>> ES =0008   00cf9300 DPL=0 DS   [-WA]
>> CS =0018   00af9b00 DPL=0 CS64 [-RA]
>> SS =0008   00cf9300 DPL=0 DS   [-WA]
>> DS =0008   00cf9300 DPL=0 DS   [-WA]
>> FS =0008   00cf9300 DPL=0 DS   [-WA]
>> GS =0008   00cf9300 DPL=0 DS   [-WA]
>> LDT=   8200 DPL=0 LDT
>> TR =   8b00 DPL=0 TSS64-busy
>> GDT= ff80 001f
>> IDT= 7c01fd58 021f
>> CR0=8033 CR2= CR3=7fefa000 CR4=0660
>> DR0= DR1= DR2= 
>> DR3= 
>> DR6=0ff0 DR7=0400
>> CCS= CCD= CCO=ADDB
>> EFER=0500
>> FCW=037f FSW= [ST=0] FTW=00 MXCSR=1f80
>> FPR0=  FPR1= 
>> FPR2=  FPR3= 
>> FPR4=  FPR5= 
>> FPR6=  FPR7= 
>> XMM00= XMM01=
>> XMM02= XMM03=
>> XMM04= XMM05=
>> XMM06= XMM07=
>> XMM08= XMM09=
>> XMM10= XMM11=
>> XMM12= XMM13=
>> XMM14= XMM15=
>> Abort trap: 6
>> 
>> ---
>> I will debug the issue and it will take me a time.
>> Just an error with GCC
>> -
>> X64/ExceptionHandlerAsm.iii:32: Error: alignment not a power of 2
>> -
>> Should be there align32?
>> -
>>  #EXTRN ASM_PFX(mDoFarReturnFlag):QWORD  # Do far return flag
>>  .text
>> +.align 3
>>  
>>  #
>> -
>> 
>> After that I may recommend these patches to be committed into trunk.
>> 
>> Thanks for the great work!
>> Sergey
>> 
>> 
>> On 30.08.2014, at 3:53, Andrew Fish wrote:
>> 
>>> With these 3 patches you can boot the EFI shell X64 Ovmf on Mac OS X using 
>>> Xcode 5.
>>> [edk2] [OvmfPkg][Review] Use XCODE5 toolchain for current and future OS X 
>>> versions
>>> [edk2] [SourceLevelDebugPkg] Code review: Compile/link with clang/Xcode 5
>>> [UefiCpuPkg][CpuExceptionHandlerLib] Make self modifying code work with 
>>> Xcode
>>> 
>>> OvmfPkg/build.sh -a X64
>>> OvmfPkg/build.sh -a X64 qemu -debugcon file:debug.log -global 
>>> isa-debugcon.iobase=0x402  -monitor stdio -no-reboot -no-shutdown -s 
>>> -singlestep
>>> 
>>> I was forced to install nasm, and you MUST set NASM_PREFIX to the install 
>>> location of nasm. Xcode ships with a very old version of nasm in 
>>> /usr/bin/nasm.
>>> 
>>> You get errors trying to assemble the SEC with the Xcode nasm (It looks 
>>> like it is missing some needed features).
>>> Ia32/Flat32ToFlat64.asm:38: warning: numeric constant 0x1 does not 
>>> fit in 32 bits
>>> Ia32/Flat32ToFlat64.asm:39: error: `64' is not a valid segment size; must 
>>> be 16 or 32
>>> Ia16/Real16ToFlat32.asm:40: warning: numeric constant 0x1 does not 
>>> fit in 32 bits
>>> Ia16/Real16ToFlat32.asm:62: warning: numeric constant 0x1 does not 
>>> fit in 32 bits
>>> Main.asm:78: error: `64' is not a valid segment size; must be 16 or 32
>>> 
>>> Thanks,
>>> 
>>> Andrew Fish
>>> 
>>> PS. Sorry I omitted Contributed-under, and Signed-off-by from some of the 
>>> patch ma

Re: [edk2] [PATCH v2 00/18] Introducing Xen PV block driver to OVMF

2014-09-04 Thread Laszlo Ersek
On 09/04/14 18:50, Anthony PERARD wrote:
> Hi all,
> 
> This patch series is implementing the necessary in order to access a PV block
> device. For that, one need a XenStore client, a XenBus client, and the PV 
> block
> driver.
> 
> There are two new drivers, XenbusDxe and XenPvBlkDxe. The first one implement 
> a
> bus drivers, and the second is a block drivers.
> 
> The GUID for the drivers XenBusDxe and XenPvBlkDxe and for the protocol XenBus
> have been genereted using the UefiDriverWizard.
> 
> There are quite a lot of changes by patches since this series first hit the
> mailing-list, all changes are listed in every patches, after a '---' line.
> 
> Anthony PERARD (18):
>   OvmfPkg: Add public headers from Xen Project.
>   OvmfPkg: Add basic skeleton for the XenBus bus driver.
>   OvmfPkg/XenBusDxe: Add device state struct and create an ExitBoot
> services event.
>   OvmfPkg/XenBusDxe: Add support to make Xen Hypercalls.
>   OvmfPkg/XenBusDxe: Open PciIo protocol.
>   OvmfPkg: Introduce XenBus Protocol.
>   OvmfPkg/XenBusDxe: Add InterlockedCompareExchange16.
>   OvmfPkg/XenBusDxe: Add Grant Table functions.
>   OvmfPkg/XenBusDxe: Add Event Channel Notify.
>   OvmfPkg/XenBusDxe: Add TestAndClearBit.
>   OvmfPkg/XenBusDxe: Add XenStore client implementation
>   OvmfPkg/XenBusDxe: Add an helper AsciiStrDup.
>   OvmfPkg/XenBusDxe: Add XenStore function into the XenBus protocol
>   OvmfPkg/XenBusDxe: Indroduce XenBus support itself.
>   OvmfPkg/XenBusDxe: Add Event Channel into XenBus protocol.
>   OvmfPkg/XenPvBlkDxe: Xen PV Block device, initial skeleton
>   OvmfPkg/XenPvBlkDxe: Add BlockFront client.
>   OvmfPkg/XenPvBlkDxe: Add BlockIo.
> 
>  .../IndustryStandard/Xen/arch-x86/xen-x86_32.h |  171 +++
>  .../IndustryStandard/Xen/arch-x86/xen-x86_64.h |  202 +++
>  .../Include/IndustryStandard/Xen/arch-x86/xen.h|  273 
>  .../Include/IndustryStandard/Xen/event_channel.h   |  381 +
>  OvmfPkg/Include/IndustryStandard/Xen/grant_table.h |  662 +
>  OvmfPkg/Include/IndustryStandard/Xen/hvm/hvm_op.h  |  275 
>  OvmfPkg/Include/IndustryStandard/Xen/hvm/params.h  |  150 ++
>  OvmfPkg/Include/IndustryStandard/Xen/io/blkif.h|  608 
>  .../Include/IndustryStandard/Xen/io/protocols.h|   40 +
>  OvmfPkg/Include/IndustryStandard/Xen/io/ring.h |  312 +
>  OvmfPkg/Include/IndustryStandard/Xen/io/xenbus.h   |   80 ++
>  OvmfPkg/Include/IndustryStandard/Xen/io/xs_wire.h  |  138 ++
>  OvmfPkg/Include/IndustryStandard/Xen/memory.h  |  480 +++
>  OvmfPkg/Include/IndustryStandard/Xen/sched.h   |  174 +++
>  OvmfPkg/Include/IndustryStandard/Xen/trace.h   |  310 
>  OvmfPkg/Include/IndustryStandard/Xen/xen-compat.h  |   44 +
>  OvmfPkg/Include/IndustryStandard/Xen/xen.h |  897 
>  OvmfPkg/Include/Protocol/XenBus.h  |  254 
>  OvmfPkg/OvmfPkg.dec|1 +
>  OvmfPkg/OvmfPkgX64.dsc |2 +
>  OvmfPkg/OvmfPkgX64.fdf |2 +
>  OvmfPkg/XenBusDxe/ComponentName.c  |  190 +++
>  OvmfPkg/XenBusDxe/ComponentName.h  |  110 ++
>  OvmfPkg/XenBusDxe/DriverBinding.h  |  144 ++
>  OvmfPkg/XenBusDxe/EventChannel.c   |  104 ++
>  OvmfPkg/XenBusDxe/EventChannel.h   |   98 ++
>  OvmfPkg/XenBusDxe/GrantTable.c |  217 +++
>  OvmfPkg/XenBusDxe/GrantTable.h |   68 +
>  OvmfPkg/XenBusDxe/Helpers.c|9 +
>  OvmfPkg/XenBusDxe/InterlockedCompareExchange16.h   |   15 +
>  .../XenBusDxe/InterlockedCompareExchange16Intel.c  |   32 +
>  .../XenBusDxe/X64/InterlockedCompareExchange16.asm |   41 +
>  .../XenBusDxe/X64/InterlockedCompareExchange16.c   |   41 +
>  OvmfPkg/XenBusDxe/X64/TestAndClearBit.S|   13 +
>  OvmfPkg/XenBusDxe/X64/TestAndClearBit.asm  |   16 +
>  OvmfPkg/XenBusDxe/X64/hypercall.S  |   23 +
>  OvmfPkg/XenBusDxe/X64/hypercall.asm|   27 +
>  OvmfPkg/XenBusDxe/XenBus.c |  371 +
>  OvmfPkg/XenBusDxe/XenBus.h |   67 +
>  OvmfPkg/XenBusDxe/XenBusDxe.c  |  482 +++
>  OvmfPkg/XenBusDxe/XenBusDxe.h  |  159 +++
>  OvmfPkg/XenBusDxe/XenBusDxe.inf|   78 ++
>  OvmfPkg/XenBusDxe/XenHypercall.c   |  134 ++
>  OvmfPkg/XenBusDxe/XenHypercall.h   |  100 ++
>  OvmfPkg/XenBusDxe/XenStore.c   | 1480 
> 
>  OvmfPkg/XenBusDxe/XenStore.h   |  379 +
>  OvmfPkg/XenPvBlkDxe/BlockFront.c   |  624 +
>  OvmfPkg/XenPvBlkDxe/BlockFront.h   |   87 ++
>  OvmfPkg/XenPvBlkDxe/BlockIo.c  |  292 
>  OvmfPkg/XenPvBlkDxe/BlockIo.h  |  124 ++
>  OvmfPkg/XenPvBlkDxe/ComponentName.c  

[edk2] [PATCH v2 15/18] OvmfPkg/XenBusDxe: Add Event Channel into XenBus protocol.

2014-09-04 Thread Anthony PERARD
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD 

---
Change in V2:
- coding style
- adding comment to functions
- Rename Xenbus to XenBus.
---
 OvmfPkg/Include/Protocol/XenBus.h | 27 +++
 OvmfPkg/XenBusDxe/EventChannel.c  | 55 +++
 OvmfPkg/XenBusDxe/EventChannel.h  | 48 ++
 OvmfPkg/XenBusDxe/XenBus.c|  3 +++
 4 files changed, 133 insertions(+)

diff --git a/OvmfPkg/Include/Protocol/XenBus.h 
b/OvmfPkg/Include/Protocol/XenBus.h
index f223be7..f404a81 100644
--- a/OvmfPkg/Include/Protocol/XenBus.h
+++ b/OvmfPkg/Include/Protocol/XenBus.h
@@ -76,6 +76,7 @@ typedef enum {
 
 
 #include 
+#include 
 
 ///
 /// Function prototypes
@@ -163,6 +164,28 @@ EFI_STATUS
   );
 
 typedef
+UINT32
+(EFIAPI *XENBUS_EVENT_CHANNEL_ALLOCATE) (
+  IN  XENBUS_PROTOCOL *This,
+  IN  domid_t DomainId,
+  OUT evtchn_port_t   *Port
+  );
+
+typedef
+VOID
+(EFIAPI *XENBUS_EVENT_CHANNEL_NOTIFY) (
+  IN XENBUS_PROTOCOL  *This,
+  IN evtchn_port_tPort
+  );
+
+typedef
+UINT32
+(EFIAPI *XENBUS_EVENT_CHANNEL_CLOSE) (
+  IN XENBUS_PROTOCOL  *This,
+  IN evtchn_port_tPort
+  );
+
+typedef
 XENSTORE_STATUS
 (EFIAPI *XENBUS_REGISTER_WATCH) (
   IN  XENBUS_PROTOCOL *This,
@@ -209,6 +232,10 @@ struct _XENBUS_PROTOCOL {
   XENBUS_GRANT_ACCESS   GrantAccess;
   XENBUS_GRANT_END_ACCESS   GrantEndAccess;
 
+  XENBUS_EVENT_CHANNEL_ALLOCATE EventChannelAllocate;
+  XENBUS_EVENT_CHANNEL_NOTIFY   EventChannelNotify;
+  XENBUS_EVENT_CHANNEL_CLOSEEventChannelClose;
+
   XENBUS_REGISTER_WATCH RegisterWatch;
   XENBUS_REGISTER_WATCH_BACKEND RegisterWatchBackend;
   XENBUS_UNREGISTER_WATCH   UnregisterWatch;
diff --git a/OvmfPkg/XenBusDxe/EventChannel.c b/OvmfPkg/XenBusDxe/EventChannel.c
index f34f9b8..82c4f4b 100644
--- a/OvmfPkg/XenBusDxe/EventChannel.c
+++ b/OvmfPkg/XenBusDxe/EventChannel.c
@@ -47,3 +47,58 @@ XenEventChannelNotify (
   ReturnCode = XenHypercallEventChannelOp (Dev, EVTCHNOP_send, &Send);
   ASSERT (ReturnCode == 0);
 }
+
+UINT32
+EFIAPI
+XenBusEventChannelAllocate (
+  IN  XENBUS_PROTOCOL *This,
+  IN  domid_t DomainId,
+  OUT evtchn_port_t   *Port
+  )
+{
+  XENBUS_PRIVATE_DATA *Private;
+  evtchn_alloc_unbound_t Parameter;
+  UINT32 ReturnCode;
+
+  Private = XENBUS_PRIVATE_DATA_FROM_THIS (This);
+
+  Parameter.dom = DOMID_SELF;
+  Parameter.remote_dom = DomainId;
+  ReturnCode = XenHypercallEventChannelOp (Private->Dev,
+   EVTCHNOP_alloc_unbound,
+   &Parameter);
+  if (ReturnCode != 0) {
+DEBUG ((EFI_D_ERROR, "ERROR: alloc_unbound failed with rc=%d", 
ReturnCode));
+return ReturnCode;
+  }
+  *Port = Parameter.port;
+  return ReturnCode;
+}
+
+VOID
+EFIAPI
+XenBusEventChannelNotify (
+  IN XENBUS_PROTOCOL *This,
+  IN evtchn_port_t   Port
+  )
+{
+  XENBUS_PRIVATE_DATA *Private;
+
+  Private = XENBUS_PRIVATE_DATA_FROM_THIS(This);
+  XenEventChannelNotify (Private->Dev, Port);
+}
+
+UINT32
+EFIAPI
+XenBusEventChannelClose (
+  IN XENBUS_PROTOCOL *This,
+  IN evtchn_port_t   Port
+  )
+{
+  XENBUS_PRIVATE_DATA *Private;
+  evtchn_close_t Close;
+
+  Private = XENBUS_PRIVATE_DATA_FROM_THIS (This);
+  Close.port = Port;
+  return XenHypercallEventChannelOp (Private->Dev, EVTCHNOP_close, &Close);
+}
diff --git a/OvmfPkg/XenBusDxe/EventChannel.h b/OvmfPkg/XenBusDxe/EventChannel.h
index fb2845b..2cc8266 100644
--- a/OvmfPkg/XenBusDxe/EventChannel.h
+++ b/OvmfPkg/XenBusDxe/EventChannel.h
@@ -47,4 +47,52 @@ XenEventChannelNotify (
   IN evtchn_port_t Port
   );
 
+/*
+ * XenBus protocol
+ */
+
+/**
+  Allocate a port that can be bind from domain DomainId.
+
+  @param This   A pointer to the XENBUS_PROTOCOL.
+  @param DomainId   The domain ID that can bind the newly allocated port.
+  @param Port   A pointer to a evtchn_port_t that will contain the newly
+allocated port.
+
+  @retval UINT32The return value from the hypercall, 0 if success.
+**/
+UINT32
+EFIAPI
+XenBusEventChannelAllocate (
+  IN  XENBUS_PROTOCOL *This,
+  IN  domid_t DomainId,
+  OUT evtchn_port_t   *Port
+  );
+
+/**
+  Send an event to the remote end of the channel whose local endpoint is Port.
+
+  @param This   A pointer to the XENBUS_PROTOCOL.
+  @param Port   Local port to the the event from.
+**/
+VOID
+EFIAPI
+XenBusEventChannelNotify (
+  IN XENBUS_PROTOCOL *This,
+  IN evtchn_port_t   Port
+  );
+
+/**
+  Close a local event channel Port.
+
+  @param This   A pointer to the XENBUS_PROTOCOL.
+  @param Port   The event channel to close.
+**/
+UINT32
+EFIAPI
+XenBusEventChannelClose (
+  IN XENBUS_PROTOCOL *This,
+  IN evtchn_port_t   Port
+  );
+
 #endif
diff --git a/OvmfPkg/XenBusDxe/XenBus.c b/OvmfPkg/XenBusDxe/XenBus.c
index 2e1f939..8c68809 100644
--- a/OvmfPkg/XenBusDxe/XenBus.c
+++ b/OvmfPkg/XenBusDxe/XenBus.c
@@ -355,6 +355,9 @@ STATIC XENBUS_PRIVATE_DATA gX

[edk2] [PATCH v2 18/18] OvmfPkg/XenPvBlkDxe: Add BlockIo.

2014-09-04 Thread Anthony PERARD
Install the BlockIo protocol.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD 

---
Change in V2:
- Remove blockIo2 headers.
- Fix few comment.
- file header, copyright
- Rewrite few comment and error messages
- No more callback
- Improving block read/write, increase to the max size in one request
  (instead of only 8pages)
- Fix lastblock when it's a cdrom
- Do uninitialisation when fail to install fail
- few comment
- Licenses
---
 OvmfPkg/XenPvBlkDxe/BlockIo.c   | 292 
 OvmfPkg/XenPvBlkDxe/BlockIo.h   | 124 +++
 OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.c   |  64 
 OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h   |   1 +
 OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf |   2 +
 5 files changed, 483 insertions(+)
 create mode 100644 OvmfPkg/XenPvBlkDxe/BlockIo.c
 create mode 100644 OvmfPkg/XenPvBlkDxe/BlockIo.h

diff --git a/OvmfPkg/XenPvBlkDxe/BlockIo.c b/OvmfPkg/XenPvBlkDxe/BlockIo.c
new file mode 100644
index 000..f08339b
--- /dev/null
+++ b/OvmfPkg/XenPvBlkDxe/BlockIo.c
@@ -0,0 +1,292 @@
+/** @file
+  BlockIo implementation for Xen PV Block driver.
+
+  This file is implementing the interface between the actual driver in
+  BlockFront.c to the BlockIo protocol.
+
+  Copyright (C) 2014, Citrix Ltd.
+
+  Redistribution and use in source and binary forms, with or without
+  modification, are permitted provided that the following conditions
+  are met:
+
+  * Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+  * Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+
+  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+  FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+  COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
+  BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+  LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+  CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+  LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
+  ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+  POSSIBILITY OF SUCH DAMAGE.
+
+**/
+
+#include "XenPvBlkDxe.h"
+
+#include "BlockFront.h"
+
+///
+/// Block I/O Media structure
+///
+GLOBAL_REMOVE_IF_UNREFERENCED
+EFI_BLOCK_IO_MEDIA  gXenPvBlkDxeBlockIoMedia = {
+  0,  // MediaId
+  FALSE,  // RemovableMedia
+  FALSE,  // MediaPresent
+  FALSE,  // LogicalPartition
+  TRUE,   // ReadOnly
+  FALSE,  // WriteCaching
+  512,// BlockSize
+  512,// IoAlign, BlockFront does not support less than 512 bits-aligned.
+  0,  // LastBlock
+  0,  // LowestAlignedLba
+  0,  // LogicalBlocksPerPhysicalBlock
+  0   // OptimalTransferLengthGranularity
+};
+
+///
+/// Block I/O Protocol instance
+///
+GLOBAL_REMOVE_IF_UNREFERENCED
+EFI_BLOCK_IO_PROTOCOL  gXenPvBlkDxeBlockIo = {
+  EFI_BLOCK_IO_PROTOCOL_REVISION3,  // Revision
+  &gXenPvBlkDxeBlockIoMedia,// Media
+  XenPvBlkDxeBlockIoReset,  // Reset
+  XenPvBlkDxeBlockIoReadBlocks, // ReadBlocks
+  XenPvBlkDxeBlockIoWriteBlocks,// WriteBlocks
+  XenPvBlkDxeBlockIoFlushBlocks // FlushBlocks
+};
+
+
+
+
+/**
+  Read/Write BufferSize bytes from Lba into Buffer.
+
+  This function is commun to XenPvBlkDxeBlockIoReadBlocks and
+  XenPvBlkDxeBlockIoWriteBlocks.
+
+  @param  This   Indicates a pointer to the calling context.
+  @param  MediaIdId of the media, changes every time the media is replaced.
+  @param  LbaThe starting Logical Block Address to read from/write to.
+  @param  BufferSize Size of Buffer, must be a multiple of device block size.
+  @param  Buffer A pointer to the destination/source buffer for the data.
+  @param  IsWriteIndicate if the operation is write or read.
+
+  @return See description of XenPvBlkDxeBlockIoReadBlocks and
+  XenPvBlkDxeBlockIoWriteBlocks.
+**/
+STATIC
+EFI_STATUS
+XenPvBlkDxeBlockIoReadWriteBlocks (
+  IN EFI_BLOCK_IO_PROTOCOL  *This,
+  IN UINT32 MediaId,
+  IN EFI_LBALba,
+  IN UINTN  BufferSize,
+  IN OUT VOID   *Buffer,
+  IN BOOLEANIsWrite
+  )
+{
+  XEN_BLOCK_FRONT_IO IoData;
+  EFI_BLOCK_IO_MEDIA *Media;
+  UINTN NextOffset;
+  EFI_STATUS Status;
+
+  if (Buffer == NULL) {
+return EFI_INVALID_PARAMETER;
+  }
+  if (BufferSize == 0) {
+return EFI_SUCCESS;
+  }
+
+  Media = This->Media;
+
+  if (BufferSize % Media->Bl

[edk2] [PATCH v2 17/18] OvmfPkg/XenPvBlkDxe: Add BlockFront client.

2014-09-04 Thread Anthony PERARD
This is the code that will do the actual communication between OVMF and
a PV block backend, where the block device lives.

This implementation originally comes from Mini-OS, a part of the Xen
Project.

Signed-off-by: Samuel Thibault 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD 

---
Change in V2:
- trigger CoW is probably not needed on OVMF (as opposed to Mini-OS),
  removed the test.
- comments
- renamed XenbusReadInteger to XenBusReadUint64
- remove callback from IoData, use simple status instead
- return a status from the synchronus io
- Close protocol if blockfront init fail.
- fix few debug print
- Rename XenbusIo to XenBusIo
- XenPvBlkWaitForBackendState will return an error if the new backend
  states is not the expected state.
- Add the license
---
 OvmfPkg/XenPvBlkDxe/BlockFront.c| 624 
 OvmfPkg/XenPvBlkDxe/BlockFront.h|  87 +
 OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.c   |  13 +
 OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf |   2 +
 4 files changed, 726 insertions(+)
 create mode 100644 OvmfPkg/XenPvBlkDxe/BlockFront.c
 create mode 100644 OvmfPkg/XenPvBlkDxe/BlockFront.h

diff --git a/OvmfPkg/XenPvBlkDxe/BlockFront.c b/OvmfPkg/XenPvBlkDxe/BlockFront.c
new file mode 100644
index 000..922c2ec
--- /dev/null
+++ b/OvmfPkg/XenPvBlkDxe/BlockFront.c
@@ -0,0 +1,624 @@
+/** @file
+  Minimal block driver for Mini-OS.
+
+  Copyright (c) 2007-2008 Samuel Thibault.
+  Copyright (C) 2014, Citrix Ltd.
+
+  Redistribution and use in source and binary forms, with or without
+  modification, are permitted provided that the following conditions
+  are met:
+  1. Redistributions of source code must retain the above copyright
+ notice, this list of conditions and the following disclaimer.
+  2. Redistributions in binary form must reproduce the above copyright
+ notice, this list of conditions and the following disclaimer in the
+ documentation and/or other materials provided with the distribution.
+
+  THIS SOFTWARE IS PROVIDED BY AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+  ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+  IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+  ARE DISCLAIMED.  IN NO EVENT SHALL AUTHOR OR CONTRIBUTORS BE LIABLE
+  FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+  DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+  OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+  HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+  LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+  OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+  SUCH DAMAGE.
+**/
+
+#include 
+#include 
+
+#include "BlockFront.h"
+
+#include 
+#include 
+
+//
+// Header used for UINT32_MAX and UINT16_MAX
+//
+#include "inttypes.h"
+
+/**
+  Helper to read an interger from XenStore.
+
+  @param This A pointer to a XENBUS_PROTOCOL instance.
+  @param Node The XenStore node to read from.
+  @param FromBackend  Read frontend or backend value.
+  @param ValuePtr Where to put the value.
+
+  @retval XENSTORE_STATUS_SUCCESS  If succefull, will update ValuePtr.
+  @return  Any other return value indicate the error,
+   ValuePtr is not updated in this case.
+**/
+STATIC
+XENSTORE_STATUS
+XenBusReadUint64 (
+  IN  XENBUS_PROTOCOL *This,
+  IN  CONST CHAR8 *Node,
+  IN  BOOLEAN FromBackend,
+  OUT UINT64  *ValuePtr
+  )
+{
+  XENSTORE_STATUS Status;
+  CHAR8 *p;
+
+  if (!FromBackend) {
+Status = This->XsRead (This, XST_NIL, Node, (VOID**)&p);
+  } else {
+Status = This->XsBackendRead (This, XST_NIL, Node, (VOID**)&p);
+  }
+  if (Status != XENSTORE_STATUS_SUCCESS) {
+return Status;
+  }
+  // FIXME Will ASSERT if p overflow UINT64 ...
+  *ValuePtr = AsciiStrDecimalToUint64 (p);
+  FreePool (p);
+  return Status;
+}
+
+/**
+  Free an instance of XEN_BLOCK_FRONT_DEVICE.
+
+  @param Dev  The instance to free.
+**/
+STATIC
+VOID
+XenPvBlockFree (
+  IN XEN_BLOCK_FRONT_DEVICE *Dev
+  )
+{
+  XENBUS_PROTOCOL *XenBusIo = Dev->XenBusIo;
+
+  if (Dev->RingRef != 0) {
+XenBusIo->GrantEndAccess (XenBusIo, Dev->RingRef);
+  }
+  if (Dev->Ring.sring != NULL) {
+FreePages (Dev->Ring.sring, 1);
+  }
+  if (Dev->EventChannel != 0) {
+XenBusIo->EventChannelClose (XenBusIo, Dev->EventChannel);
+  }
+  FreePool (Dev);
+}
+
+/**
+  Wait until until the backend have reach the ExpectedState.
+
+  @param DevA XEN_BLOCK_FRONT_DEVICE instance.
+  @param ExpectedState  The backend state expected.
+  @param LastStatePtr   An optionnal pointer where to right the final state.
+
+  @return Return XENSTORE_STATUS_SUCCESS if the new backend state is 
ExpectedState
+  or return an error otherwise.
+**/
+STATIC
+XENSTORE_STATUS
+XenPvBlkWaitForBackendState (
+  IN

[edk2] [PATCH v2 12/18] OvmfPkg/XenBusDxe: Add an helper AsciiStrDup.

2014-09-04 Thread Anthony PERARD
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/XenBusDxe/Helpers.c   | 9 +
 OvmfPkg/XenBusDxe/XenBusDxe.h | 5 +
 2 files changed, 14 insertions(+)
 create mode 100644 OvmfPkg/XenBusDxe/Helpers.c

diff --git a/OvmfPkg/XenBusDxe/Helpers.c b/OvmfPkg/XenBusDxe/Helpers.c
new file mode 100644
index 000..3e938b6
--- /dev/null
+++ b/OvmfPkg/XenBusDxe/Helpers.c
@@ -0,0 +1,9 @@
+#include "XenBusDxe.h"
+
+CHAR8*
+AsciiStrDup (
+  IN CONST CHAR8* Str
+  )
+{
+  return AllocateCopyPool (AsciiStrSize (Str), Str);
+}
diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.h b/OvmfPkg/XenBusDxe/XenBusDxe.h
index d690914..dc48a46 100644
--- a/OvmfPkg/XenBusDxe/XenBusDxe.h
+++ b/OvmfPkg/XenBusDxe/XenBusDxe.h
@@ -132,4 +132,9 @@ TestAndClearBit (
   IN volatile VOID *Address
   );
 
+CHAR8*
+AsciiStrDup (
+  IN CONST CHAR8* Str
+  );
+
 #endif
-- 
Anthony PERARD


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


[edk2] [PATCH v2 10/18] OvmfPkg/XenBusDxe: Add TestAndClearBit.

2014-09-04 Thread Anthony PERARD
This atomically test and clear a bit.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD 

---
Change in V2:
- Adding .asm version
- Comment the function
---
 OvmfPkg/XenBusDxe/X64/TestAndClearBit.S   | 13 +
 OvmfPkg/XenBusDxe/X64/TestAndClearBit.asm | 16 
 OvmfPkg/XenBusDxe/XenBusDxe.h | 19 +++
 OvmfPkg/XenBusDxe/XenBusDxe.inf   |  2 ++
 4 files changed, 50 insertions(+)
 create mode 100644 OvmfPkg/XenBusDxe/X64/TestAndClearBit.S
 create mode 100644 OvmfPkg/XenBusDxe/X64/TestAndClearBit.asm

diff --git a/OvmfPkg/XenBusDxe/X64/TestAndClearBit.S 
b/OvmfPkg/XenBusDxe/X64/TestAndClearBit.S
new file mode 100644
index 000..cd9c5ed
--- /dev/null
+++ b/OvmfPkg/XenBusDxe/X64/TestAndClearBit.S
@@ -0,0 +1,13 @@
+
+# INT32
+# EFIAPI
+# TestAndClearBit (
+#   IN  INT32 Bit,// rcx
+#   IN  volatile VOID* Address// rdx
+#   );
+ASM_GLOBAL ASM_PFX(TestAndClearBit)
+ASM_PFX(TestAndClearBit):
+  lock
+  btrl %ecx, (%rdx)
+  sbbl %eax, %eax
+  ret
diff --git a/OvmfPkg/XenBusDxe/X64/TestAndClearBit.asm 
b/OvmfPkg/XenBusDxe/X64/TestAndClearBit.asm
new file mode 100644
index 000..c7fc83d
--- /dev/null
+++ b/OvmfPkg/XenBusDxe/X64/TestAndClearBit.asm
@@ -0,0 +1,16 @@
+.code
+
+; INT32
+; EFIAPI
+; TestAndClearBit (
+;   IN  INT32 Bit,// rcx
+;   IN  volatile VOID* Address// rdx
+;   );
+TestAndClearBit PROC
+  lock
+  btr [rdx], ecx
+  sbb eax, eax
+  ret
+TestAndClearBit ENDP
+
+END
diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.h b/OvmfPkg/XenBusDxe/XenBusDxe.h
index 878e7c5..d690914 100644
--- a/OvmfPkg/XenBusDxe/XenBusDxe.h
+++ b/OvmfPkg/XenBusDxe/XenBusDxe.h
@@ -113,4 +113,23 @@ struct _XENBUS_DEVICE {
   shared_info_t *SharedInfo;
 };
 
+/*
+ * Helpers
+ */
+
+/**
+  Atomically test and clear a bit.
+
+  @param Bit  Bit index to test in *Address
+  @param Address  The Address to the buffer that contain the bit to test.
+
+  @return Value of the Bit before it was cleared.
+**/
+INT32
+EFIAPI
+TestAndClearBit (
+  IN INT32 Bit,
+  IN volatile VOID *Address
+  );
+
 #endif
diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.inf b/OvmfPkg/XenBusDxe/XenBusDxe.inf
index 13623bd..e8f362a 100644
--- a/OvmfPkg/XenBusDxe/XenBusDxe.inf
+++ b/OvmfPkg/XenBusDxe/XenBusDxe.inf
@@ -45,6 +45,8 @@
   X64/InterlockedCompareExchange16.c | GCC
   X64/InterlockedCompareExchange16.asm | INTEL
   InterlockedCompareExchange16Intel.c | INTEL
+  X64/TestAndClearBit.S
+  X64/TestAndClearBit.asm
 
 [LibraryClasses]
   UefiDriverEntryPoint
-- 
Anthony PERARD


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


[edk2] [PATCH v2 11/18] OvmfPkg/XenBusDxe: Add XenStore client implementation

2014-09-04 Thread Anthony PERARD
XenStore is a key/value database, which is running on another virtual
machine. It can be accessed through shared memory. This is a client
implementation.

Origin: FreeBSD 10.0

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD 

---
Change in V2:
- Change comment style, from freebsd to ovmf
- Fix type of EventChannel
- Fix debug print, no more cast
- Implement XenStoreDeinit.
- Clean up comments
- Fix few codding style issue
- Add FAIL xenstore status value.
---
 OvmfPkg/Include/Protocol/XenBus.h |   29 +
 OvmfPkg/XenBusDxe/XenBusDxe.c |5 +
 OvmfPkg/XenBusDxe/XenBusDxe.inf   |2 +
 OvmfPkg/XenBusDxe/XenStore.c  | 1320 +
 OvmfPkg/XenBusDxe/XenStore.h  |  292 
 5 files changed, 1648 insertions(+)
 create mode 100644 OvmfPkg/XenBusDxe/XenStore.c
 create mode 100644 OvmfPkg/XenBusDxe/XenStore.h

diff --git a/OvmfPkg/Include/Protocol/XenBus.h 
b/OvmfPkg/Include/Protocol/XenBus.h
index bf4a69f..b10c143 100644
--- a/OvmfPkg/Include/Protocol/XenBus.h
+++ b/OvmfPkg/Include/Protocol/XenBus.h
@@ -45,6 +45,35 @@
 ///
 typedef struct _XENBUS_PROTOCOL XENBUS_PROTOCOL;
 
+typedef enum xenbus_state XenbusState;
+
+typedef struct
+{
+  UINT32 Id;
+} XENSTORE_TRANSACTION;
+
+#define XST_NIL ((XENSTORE_TRANSACTION) { 0 })
+
+typedef enum {
+  XENSTORE_STATUS_SUCCESS = 0,
+  XENSTORE_STATUS_FAIL,
+  XENSTORE_STATUS_EINVAL,
+  XENSTORE_STATUS_EACCES,
+  XENSTORE_STATUS_EEXIST,
+  XENSTORE_STATUS_EISDIR,
+  XENSTORE_STATUS_ENOENT,
+  XENSTORE_STATUS_ENOMEM,
+  XENSTORE_STATUS_ENOSPC,
+  XENSTORE_STATUS_EIO,
+  XENSTORE_STATUS_ENOTEMPTY,
+  XENSTORE_STATUS_ENOSYS,
+  XENSTORE_STATUS_EROFS,
+  XENSTORE_STATUS_EBUSY,
+  XENSTORE_STATUS_EAGAIN,
+  XENSTORE_STATUS_EISCONN,
+  XENSTORE_STATUS_E2BIG
+} XENSTORE_STATUS;
+
 
 #include 
 
diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.c b/OvmfPkg/XenBusDxe/XenBusDxe.c
index 29aadb1..76ea67c 100644
--- a/OvmfPkg/XenBusDxe/XenBusDxe.c
+++ b/OvmfPkg/XenBusDxe/XenBusDxe.c
@@ -47,6 +47,7 @@
 
 #include "XenHypercall.h"
 #include "GrantTable.h"
+#include "XenStore.h"
 
 
 ///
@@ -344,6 +345,9 @@ XenBusDxeDriverBindingStart (
 
   XenGrantTableInit (Dev, MmioAddr);
 
+  Status = XenStoreInit (Dev);
+  ASSERT_EFI_ERROR (Status);
+
   Status = gBS->CreateEvent (EVT_SIGNAL_EXIT_BOOT_SERVICES, TPL_CALLBACK,
  NotifyExitBoot,
  (VOID*) Dev,
@@ -398,6 +402,7 @@ XenBusDxeDriverBindingStop (
   XENBUS_DEVICE *Dev = mMyDevice;
 
   gBS->CloseEvent (Dev->ExitBootEvent);
+  XenStoreDeinit (Dev);
   XenGrantTableDeinit (Dev);
 
   gBS->CloseProtocol (ControllerHandle, &gEfiPciIoProtocolGuid,
diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.inf b/OvmfPkg/XenBusDxe/XenBusDxe.inf
index e8f362a..9052967 100644
--- a/OvmfPkg/XenBusDxe/XenBusDxe.inf
+++ b/OvmfPkg/XenBusDxe/XenBusDxe.inf
@@ -38,6 +38,8 @@
   GrantTable.h
   EventChannel.c
   EventChannel.h
+  XenStore.c
+  XenStore.h
 
 [Sources.X64]
   X64/hypercall.S
diff --git a/OvmfPkg/XenBusDxe/XenStore.c b/OvmfPkg/XenBusDxe/XenStore.c
new file mode 100644
index 000..bcf6e1c
--- /dev/null
+++ b/OvmfPkg/XenBusDxe/XenStore.c
@@ -0,0 +1,1320 @@
+/** @file
+  Low-level kernel interface to the XenStore.
+
+  The XenStore interface is a simple storage system that is a means of
+  communicating state and configuration data between the Xen Domain 0
+  and the various guest domains.  All configuration data other than
+  a small amount of essential information required during the early
+  boot process of launching a Xen aware guest, is managed using the
+  XenStore.
+
+  The XenStore is ASCII string based, and has a structure and semantics
+  similar to a filesystem.  There are files and directories, the directories
+  able to contain files or other directories.  The depth of the hierachy
+  is only limited by the XenStore's maximum path length.
+
+  The communication channel between the XenStore service and other
+  domains is via two, guest specific, ring buffers in a shared memory
+  area.  One ring buffer is used for communicating in each direction.
+  The grant table references for this shared memory are given to the
+  guest either via the xen_start_info structure for a fully para-
+  virtualized guest, or via HVM hypercalls for a hardware virtualized
+  guest.
+
+  The XenStore communication relies on an event channel and thus
+  interrupts.  But under OVMF this XenStore client will pull the
+  state of the event channel.
+
+  Several Xen services depend on the XenStore, most notably the
+  XenBus used to discover and manage Xen devices.
+
+  Copyright (C) 2005 Rusty Russell, IBM Corporation
+  Copyright (C) 2009,2010 Spectra Logic Corporation
+  Copyright (C) 2014, Citrix Ltd.
+
+  This file may be distributed separately from the Linux kernel, or
+  incorporated into other software packages, subject to the following license:
+
+  Permission is hereby granted, free of charge, to any person obtaining a copy
+  of this s

[edk2] [PATCH v2 16/18] OvmfPkg/XenPvBlkDxe: Xen PV Block device, initial skeleton

2014-09-04 Thread Anthony PERARD
A ParaVirtualize block driver.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD 

---
Change in V2:
- Add minimal support for controller name
- Remove stuff about BlockIo2
- Little cleanup
- Licenses and file headers
- Rename XenbusIo into XenBusIo
---
 OvmfPkg/OvmfPkgX64.dsc  |   1 +
 OvmfPkg/OvmfPkgX64.fdf  |   1 +
 OvmfPkg/XenPvBlkDxe/ComponentName.c | 192 +
 OvmfPkg/XenPvBlkDxe/ComponentName.h | 110 
 OvmfPkg/XenPvBlkDxe/DriverBinding.h | 159 +
 OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.c   | 336 
 OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h   |  98 +++
 OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf |  76 
 8 files changed, 973 insertions(+)
 create mode 100644 OvmfPkg/XenPvBlkDxe/ComponentName.c
 create mode 100644 OvmfPkg/XenPvBlkDxe/ComponentName.h
 create mode 100644 OvmfPkg/XenPvBlkDxe/DriverBinding.h
 create mode 100644 OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.c
 create mode 100644 OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h
 create mode 100644 OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf

diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index c52d5a4..4186b92 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -433,6 +433,7 @@
   OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
   OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
   OvmfPkg/XenBusDxe/XenBusDxe.inf
+  OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
   OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf {
 
   PlatformFvbLib|OvmfPkg/Library/EmuVariableFvbLib/EmuVariableFvbLib.inf
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 6b556a2..b374183 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -228,6 +228,7 @@ INF  
OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
 INF  OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf
 INF  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
 INF  OvmfPkg/XenBusDxe/XenBusDxe.inf
+INF  OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
 
 !if $(SECURE_BOOT_ENABLE) == TRUE
   INF  SecurityPkg/VariableAuthenticated/RuntimeDxe/VariableRuntimeDxe.inf
diff --git a/OvmfPkg/XenPvBlkDxe/ComponentName.c 
b/OvmfPkg/XenPvBlkDxe/ComponentName.c
new file mode 100644
index 000..4243e24
--- /dev/null
+++ b/OvmfPkg/XenPvBlkDxe/ComponentName.c
@@ -0,0 +1,192 @@
+/** @file
+  Component Name functions implementation for XenPvBlk driver.
+
+  Copyright (C) 2014, Citrix Ltd.
+
+  Redistribution and use in source and binary forms, with or without
+  modification, are permitted provided that the following conditions
+  are met:
+
+  * Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+  * Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+
+  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+  FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+  COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
+  BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+  LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+  CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+  LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
+  ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+  POSSIBILITY OF SUCH DAMAGE.
+
+**/
+
+#include "XenPvBlkDxe.h"
+
+///
+/// Component Name Protocol instance
+///
+GLOBAL_REMOVE_IF_UNREFERENCED
+EFI_COMPONENT_NAME_PROTOCOL  gXenPvBlkDxeComponentName = {
+  (EFI_COMPONENT_NAME_GET_DRIVER_NAME)
XenPvBlkDxeComponentNameGetDriverName,
+  
(EFI_COMPONENT_NAME_GET_CONTROLLER_NAME)XenPvBlkDxeComponentNameGetControllerName,
+  "eng"
+};
+
+///
+/// Component Name 2 Protocol instance
+///
+GLOBAL_REMOVE_IF_UNREFERENCED
+EFI_COMPONENT_NAME2_PROTOCOL  gXenPvBlkDxeComponentName2 = {
+  XenPvBlkDxeComponentNameGetDriverName,
+  XenPvBlkDxeComponentNameGetControllerName,
+  "en"
+};
+
+///
+/// Table of driver names
+///
+GLOBAL_REMOVE_IF_UNREFERENCED
+EFI_UNICODE_STRING_TABLE mXenPvBlkDxeDriverNameTable[] = {
+  { "eng;en", (CHAR16 *)L"Xen PV Block Driver" },
+  { NULL, NULL }
+};
+
+///
+/// Table of controller names
+///
+GLOBAL_REMOVE_IF_UNREFERENCED
+EFI_UNICODE_STRING_TABLE mXenPvBlkDxeControllerNameTable[] = {
+  { "eng;en", (CHAR16 *)L"Xen PV Block Device" },
+  { NULL, NULL }
+};
+
+/**
+  Retrieves a Unicode string that is the user-readable name of the EFI Driver.
+
+  @param  This   A pointer to the EFI_COMPONENT_NAME_PROTOCOL instance.
+  @param  Language   A pointer 

[edk2] [PATCH v2 14/18] OvmfPkg/XenBusDxe: Indroduce XenBus support itself.

2014-09-04 Thread Anthony PERARD
This is a bus-like on top of XenStore. It will look for advertised
ParaVirtualized devices and initialize them by producing XenBus
protocol.

Origin: FreeBSD 10.0

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD 

---
Change in V2:
- comment, file header
- Fix comment style
- Error handling in the main init function
- coding style
- Fix error path in add device.
---
 OvmfPkg/Include/Protocol/XenBus.h |  11 +-
 OvmfPkg/XenBusDxe/XenBus.c| 368 ++
 OvmfPkg/XenBusDxe/XenBus.h|  67 +++
 OvmfPkg/XenBusDxe/XenBusDxe.c |  71 
 OvmfPkg/XenBusDxe/XenBusDxe.h |  19 ++
 OvmfPkg/XenBusDxe/XenBusDxe.inf   |   3 +
 6 files changed, 538 insertions(+), 1 deletion(-)
 create mode 100644 OvmfPkg/XenBusDxe/XenBus.c
 create mode 100644 OvmfPkg/XenBusDxe/XenBus.h

diff --git a/OvmfPkg/Include/Protocol/XenBus.h 
b/OvmfPkg/Include/Protocol/XenBus.h
index 99e174b..f223be7 100644
--- a/OvmfPkg/Include/Protocol/XenBus.h
+++ b/OvmfPkg/Include/Protocol/XenBus.h
@@ -45,7 +45,7 @@
 ///
 typedef struct _XENBUS_PROTOCOL XENBUS_PROTOCOL;
 
-typedef enum xenbus_state XenbusState;
+typedef enum xenbus_state XenBusState;
 
 typedef struct
 {
@@ -138,6 +138,14 @@ XENSTORE_STATUS
   );
 
 typedef
+XENSTORE_STATUS
+(EFIAPI *XENBUS_SET_STATE)(
+  IN XENBUS_PROTOCOL*This,
+  IN XENSTORE_TRANSACTION   Transaction,
+  IN XenBusStateState
+  );
+
+typedef
 EFI_STATUS
 (EFIAPI *XENBUS_GRANT_ACCESS)(
   IN  XENBUS_PROTOCOL *This,
@@ -196,6 +204,7 @@ struct _XENBUS_PROTOCOL {
   XENBUS_XS_REMOVE  XsRemove;
   XENBUS_XS_TRANSACTION_START   XsTransactionStart;
   XENBUS_XS_TRANSACTION_END XsTransactionEnd;
+  XENBUS_SET_STATE  SetState;
 
   XENBUS_GRANT_ACCESS   GrantAccess;
   XENBUS_GRANT_END_ACCESS   GrantEndAccess;
diff --git a/OvmfPkg/XenBusDxe/XenBus.c b/OvmfPkg/XenBusDxe/XenBus.c
new file mode 100644
index 000..2e1f939
--- /dev/null
+++ b/OvmfPkg/XenBusDxe/XenBus.c
@@ -0,0 +1,368 @@
+/** @file
+  XenBus Bus driver implemtation.
+
+  This file implement the necessary to discover and enumerate Xen PV devices
+  through XenStore.
+
+  Copyright (C) 2010 Spectra Logic Corporation
+  Copyright (C) 2008 Doug Rabson
+  Copyright (C) 2005 Rusty Russell, IBM Corporation
+  Copyright (C) 2005 Mike Wray, Hewlett-Packard
+  Copyright (C) 2005 XenSource Ltd
+  Copyright (C) 2014, Citrix Ltd.
+
+  This file may be distributed separately from the Linux kernel, or
+  incorporated into other software packages, subject to the following license:
+
+  Permission is hereby granted, free of charge, to any person obtaining a copy
+  of this source file (the "Software"), to deal in the Software without
+  restriction, including without limitation the rights to use, copy, modify,
+  merge, publish, distribute, sublicense, and/or sell copies of the Software,
+  and to permit persons to whom the Software is furnished to do so, subject to
+  the following conditions:
+
+  The above copyright notice and this permission notice shall be included in
+  all copies or substantial portions of the Software.
+
+  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+  FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+  IN THE SOFTWARE.
+**/
+
+#include 
+
+#include "XenBus.h"
+#include "GrantTable.h"
+#include "XenStore.h"
+#include "EventChannel.h"
+
+#include 
+
+STATIC XENBUS_PRIVATE_DATA gXenBusPrivateData;
+
+STATIC XENBUS_DEVICE_PATH gXenBusDevicePathTemplate = {
+  .Vendor.Header.Type = HARDWARE_DEVICE_PATH,
+  .Vendor.Header.SubType = HW_VENDOR_DP,
+  .Vendor.Header.Length[0] = (UINT8) sizeof (XENBUS_DEVICE_PATH),
+  .Vendor.Header.Length[1] = (UINT8) (sizeof (XENBUS_DEVICE_PATH) >> 8),
+  .Vendor.Guid = XENBUS_PROTOCOL_GUID,
+  .Type = 0,
+  .DeviceId = 0
+};
+
+
+/**
+  Search our internal record of configured devices (not the XenStore) to
+  determine if the XenBus device indicated by Node is known to the system.
+
+  @param Dev   The XENBUS_DEVICE instance to search for device children.
+  @param Node  The XenStore node path for the device to find.
+
+  @return  The XENBUS_PRIVATE_DATA of the found device if any, or NULL.
+ */
+STATIC
+XENBUS_PRIVATE_DATA *
+XenBusDeviceInitialized (
+  IN XENBUS_DEVICE *Dev,
+  IN CONST CHAR8 *Node
+  )
+{
+  LIST_ENTRY *Entry;
+  XENBUS_PRIVATE_DATA *Child;
+  XENBUS_PRIVATE_DATA *Result;
+
+  if (IsListEmpty (&Dev->ChildList)) {
+return NULL;
+  }
+
+  Result = NULL;
+  for (Entry = GetFirstNode (&Dev->ChildList);
+   !IsNodeAtEnd (&Dev->ChildList, Entry);
+   Entry = GetNextNode (&Dev->ChildList, Entry)) 

[edk2] [PATCH v2 13/18] OvmfPkg/XenBusDxe: Add XenStore function into the XenBus protocol

2014-09-04 Thread Anthony PERARD
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/Include/Protocol/XenBus.h | 103 
 OvmfPkg/XenBusDxe/XenStore.c  | 160 ++
 OvmfPkg/XenBusDxe/XenStore.h  |  87 +
 3 files changed, 350 insertions(+)

diff --git a/OvmfPkg/Include/Protocol/XenBus.h 
b/OvmfPkg/Include/Protocol/XenBus.h
index b10c143..99e174b 100644
--- a/OvmfPkg/Include/Protocol/XenBus.h
+++ b/OvmfPkg/Include/Protocol/XenBus.h
@@ -81,6 +81,62 @@ typedef enum {
 /// Function prototypes
 ///
 
+/*
+ * Return error from xs_read
+ * Return value of the node ${This->Node}/${node}
+ */
+typedef
+XENSTORE_STATUS
+(EFIAPI *XENBUS_XS_READ)(
+  IN  XENBUS_PROTOCOL   *This,
+  IN  XENSTORE_TRANSACTION  Transaction,
+  IN  CONST CHAR8   *Node,
+  OUT VOID  **Result
+  );
+
+typedef
+XENSTORE_STATUS
+(EFIAPI *XENBUS_XS_BACKEND_READ)(
+  IN  XENBUS_PROTOCOL   *This,
+  IN  XENSTORE_TRANSACTION  Transaction,
+  IN  CONST CHAR8   *Node,
+  OUT VOID  **Result
+  );
+
+typedef
+XENSTORE_STATUS
+(EFIAPI *XENBUS_XS_PRINTF) (
+  IN XENBUS_PROTOCOL*This,
+  IN XENSTORE_TRANSACTION   Transaction,
+  IN CONST CHAR8*Directory,
+  IN CONST CHAR8*Node,
+  IN CONST CHAR8*Format,
+  ...
+  );
+
+typedef
+XENSTORE_STATUS
+(EFIAPI *XENBUS_XS_REMOVE) (
+  IN XENBUS_PROTOCOL*This,
+  IN XENSTORE_TRANSACTION   Transaction,
+  IN CONST CHAR8*Node
+  );
+
+typedef
+XENSTORE_STATUS
+(EFIAPI *XENBUS_XS_TRANSACTION_START)(
+  IN  XENBUS_PROTOCOL   *This,
+  OUT XENSTORE_TRANSACTION  *Transaction
+  );
+
+typedef
+XENSTORE_STATUS
+(EFIAPI *XENBUS_XS_TRANSACTION_END) (
+  IN XENBUS_PROTOCOL*This,
+  IN XENSTORE_TRANSACTION   Transaction,
+  IN BOOLEANAbort
+  );
+
 typedef
 EFI_STATUS
 (EFIAPI *XENBUS_GRANT_ACCESS)(
@@ -98,16 +154,63 @@ EFI_STATUS
   IN grant_ref_t  Ref
   );
 
+typedef
+XENSTORE_STATUS
+(EFIAPI *XENBUS_REGISTER_WATCH) (
+  IN  XENBUS_PROTOCOL *This,
+  IN  CONST CHAR8 *Node,
+  // XENSTORE_WATCH ?
+  OUT VOID**Token
+  );
+
+typedef
+XENSTORE_STATUS
+(EFIAPI *XENBUS_REGISTER_WATCH_BACKEND) (
+  IN  XENBUS_PROTOCOL *This,
+  IN  CONST CHAR8 *Node,
+  OUT VOID**Token
+  );
+
+typedef
+VOID
+(EFIAPI *XENBUS_UNREGISTER_WATCH) (
+  IN XENBUS_PROTOCOL  *This,
+  IN VOID *Token
+  );
+
+typedef
+VOID
+(EFIAPI *XENBUS_WAIT_FOR_WATCH) (
+  IN XENBUS_PROTOCOL  *This,
+  IN VOID *Token
+  );
+
 
 ///
 /// Protocol structure
 ///
 struct _XENBUS_PROTOCOL {
+  XENBUS_XS_READXsRead;
+  XENBUS_XS_BACKEND_READXsBackendRead;
+  XENBUS_XS_PRINTF  XsPrintf;
+  XENBUS_XS_REMOVE  XsRemove;
+  XENBUS_XS_TRANSACTION_START   XsTransactionStart;
+  XENBUS_XS_TRANSACTION_END XsTransactionEnd;
+
   XENBUS_GRANT_ACCESS   GrantAccess;
   XENBUS_GRANT_END_ACCESS   GrantEndAccess;
+
+  XENBUS_REGISTER_WATCH RegisterWatch;
+  XENBUS_REGISTER_WATCH_BACKEND RegisterWatchBackend;
+  XENBUS_UNREGISTER_WATCH   UnregisterWatch;
+  XENBUS_WAIT_FOR_WATCH WaitForWatch;
   //
   // Protocol data fields
   //
+  CONST CHAR8   *Type;
+  UINT16DeviceId;
+  CONST CHAR8   *Node;
+  CONST CHAR8   *Backend;
 };
 
 extern EFI_GUID gXenBusProtocolGuid;
diff --git a/OvmfPkg/XenBusDxe/XenStore.c b/OvmfPkg/XenBusDxe/XenStore.c
index bcf6e1c..d828c06 100644
--- a/OvmfPkg/XenBusDxe/XenStore.c
+++ b/OvmfPkg/XenBusDxe/XenStore.c
@@ -892,6 +892,42 @@ XenStoreUnwatch (
   return XenStoreTalkv (XST_NIL, XS_UNWATCH, WriteRequest, 2, NULL, NULL);
 }
 
+STATIC
+VOID
+XenStoreWaitWatch (
+  VOID *Token
+  )
+{
+  XENSTORE_MESSAGE *Message;
+  LIST_ENTRY *Entry = NULL;
+  LIST_ENTRY *Last = NULL;
+
+  while (TRUE) {
+EfiAcquireLock (&xs.WatchEventsLock);
+if (IsListEmpty (&xs.WatchEvents) ||
+Last == GetFirstNode (&xs.WatchEvents)) {
+  EfiReleaseLock (&xs.WatchEventsLock);
+  XenStoreProcessMessage ();
+  continue;
+}
+
+for (Entry = GetFirstNode (&xs.WatchEvents);
+ Entry != Last && !IsNull (&xs.WatchEvents, Entry);
+ Entry = GetNextNode (&xs.WatchEvents, Entry)) {
+  Message = XENSTORE_MESSAGE_FROM_LINK (Entry);
+  if (Message->u.Watch.Handle == Token) {
+RemoveEntryList (Entry);
+EfiReleaseLock (&xs.WatchEventsLock);
+FreePool(Message->u.Watch.Vector);
+FreePool(Message);
+return;
+  }
+}
+Last = GetFirstNode (&xs.WatchEvents);
+EfiReleaseLock (&xs.WatchEventsLock);
+  }
+}
+
 VOID
 EFIAPI
 NotifyEventChannelCheckForEvent (
@@ -1318,3 +1354,127 @@ XenStoreUnregisterWatch (
   FreePool (Watch->Node);
   FreePool (Watch);
 }
+
+
+//
+// XENBUS protocol
+//
+
+VOID
+EFIAPI
+XenBusWaitForWatch (
+  IN XENBUS_PROTOCOL *This,

[edk2] [PATCH v2 03/18] OvmfPkg/XenBusDxe: Add device state struct and create an ExitBoot services event.

2014-09-04 Thread Anthony PERARD
The ExitBoot event is used to disconnect from the device before the
next operating system start using them.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/XenBusDxe/XenBusDxe.c | 38 --
 OvmfPkg/XenBusDxe/XenBusDxe.h | 11 +++
 2 files changed, 47 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.c b/OvmfPkg/XenBusDxe/XenBusDxe.c
index a272204..e125ed7 100644
--- a/OvmfPkg/XenBusDxe/XenBusDxe.c
+++ b/OvmfPkg/XenBusDxe/XenBusDxe.c
@@ -59,6 +59,8 @@ EFI_DRIVER_BINDING_PROTOCOL gXenBusDxeDriverBinding = {
 };
 
 
+XENBUS_DEVICE *mMyDevice;
+
 /**
   Unloads an image.
 
@@ -232,6 +234,19 @@ XenBusDxeDriverBindingSupported (
   return Status;
 }
 
+VOID
+EFIAPI
+NotifyExitBoot (
+  IN EFI_EVENT Event,
+  IN VOID *Context
+  )
+{
+  XENBUS_DEVICE *Dev = Context;
+
+  gBS->DisconnectController(Dev->ControllerHandle,
+Dev->This->DriverBindingHandle, NULL);
+}
+
 /**
   Starts a bus controller.
 
@@ -275,7 +290,22 @@ XenBusDxeDriverBindingStart (
   IN EFI_DEVICE_PATH_PROTOCOL *RemainingDevicePath OPTIONAL
   )
 {
-  return EFI_UNSUPPORTED;
+  EFI_STATUS Status;
+  XENBUS_DEVICE *Dev;
+
+  Dev = AllocateZeroPool (sizeof (*Dev));
+  Dev->Signature = XENBUS_DEVICE_SIGNATURE;
+  Dev->This = This;
+  Dev->ControllerHandle = ControllerHandle;
+
+  Status = gBS->CreateEvent (EVT_SIGNAL_EXIT_BOOT_SERVICES, TPL_CALLBACK,
+ NotifyExitBoot,
+ (VOID*) Dev,
+ &Dev->ExitBootEvent);
+  ASSERT_EFI_ERROR (Status);
+
+  mMyDevice = Dev;
+  return EFI_SUCCESS;
 }
 
 /**
@@ -313,5 +343,9 @@ XenBusDxeDriverBindingStop (
   IN EFI_HANDLE   *ChildHandleBuffer OPTIONAL
   )
 {
-  return EFI_UNSUPPORTED;
+  XENBUS_DEVICE *Dev = mMyDevice;
+
+  gBS->CloseEvent (Dev->ExitBootEvent);
+
+  return EFI_SUCCESS;
 }
diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.h b/OvmfPkg/XenBusDxe/XenBusDxe.h
index 4c11f60..9e4860a 100644
--- a/OvmfPkg/XenBusDxe/XenBusDxe.h
+++ b/OvmfPkg/XenBusDxe/XenBusDxe.h
@@ -90,4 +90,15 @@ extern EFI_COMPONENT_NAME_PROTOCOL  gXenBusDxeComponentName;
 #define PCI_DEVICE_ID_XEN_PLATFORM   0x0001
 
 
+typedef struct _XENBUS_DEVICE XENBUS_DEVICE;
+
+// Have the state of the driver.
+#define XENBUS_DEVICE_SIGNATURE SIGNATURE_32 ('X','B','s','t')
+struct _XENBUS_DEVICE {
+  UINT32Signature;
+  EFI_DRIVER_BINDING_PROTOCOL   *This;
+  EFI_HANDLEControllerHandle;
+  EFI_EVENT ExitBootEvent;
+};
+
 #endif
-- 
Anthony PERARD


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


[edk2] [PATCH v2 02/18] OvmfPkg: Add basic skeleton for the XenBus bus driver.

2014-09-04 Thread Anthony PERARD
This includes Component Name and Driver Binding.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD 

---
Change in V2:
- Simple support of controller name.
- Cleaning up comments, files header.
- Add Licenses
- Rename XenbusDxe to XenBusDxe.
---
 OvmfPkg/OvmfPkgX64.dsc|   1 +
 OvmfPkg/OvmfPkgX64.fdf|   1 +
 OvmfPkg/XenBusDxe/ComponentName.c | 190 +++
 OvmfPkg/XenBusDxe/ComponentName.h | 110 +
 OvmfPkg/XenBusDxe/DriverBinding.h | 144 +
 OvmfPkg/XenBusDxe/XenBusDxe.c | 317 ++
 OvmfPkg/XenBusDxe/XenBusDxe.h |  93 +++
 OvmfPkg/XenBusDxe/XenBusDxe.inf   |  56 +++
 8 files changed, 912 insertions(+)
 create mode 100644 OvmfPkg/XenBusDxe/ComponentName.c
 create mode 100644 OvmfPkg/XenBusDxe/ComponentName.h
 create mode 100644 OvmfPkg/XenBusDxe/DriverBinding.h
 create mode 100644 OvmfPkg/XenBusDxe/XenBusDxe.c
 create mode 100644 OvmfPkg/XenBusDxe/XenBusDxe.h
 create mode 100644 OvmfPkg/XenBusDxe/XenBusDxe.inf

diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 73a6460..c52d5a4 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -432,6 +432,7 @@
   OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
   OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
   OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
+  OvmfPkg/XenBusDxe/XenBusDxe.inf
   OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf {
 
   PlatformFvbLib|OvmfPkg/Library/EmuVariableFvbLib/EmuVariableFvbLib.inf
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 29382fb..6b556a2 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -227,6 +227,7 @@ INF  OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
 INF  OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
 INF  OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf
 INF  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
+INF  OvmfPkg/XenBusDxe/XenBusDxe.inf
 
 !if $(SECURE_BOOT_ENABLE) == TRUE
   INF  SecurityPkg/VariableAuthenticated/RuntimeDxe/VariableRuntimeDxe.inf
diff --git a/OvmfPkg/XenBusDxe/ComponentName.c 
b/OvmfPkg/XenBusDxe/ComponentName.c
new file mode 100644
index 000..bcf1e51
--- /dev/null
+++ b/OvmfPkg/XenBusDxe/ComponentName.c
@@ -0,0 +1,190 @@
+/** @file
+  Component Name functions implementation for XenBus Bus driver.
+
+  Copyright (C) 2014, Citrix Ltd.
+
+  Redistribution and use in source and binary forms, with or without
+  modification, are permitted provided that the following conditions
+  are met:
+
+  * Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+  * Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+
+  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+  FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+  COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
+  BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+  LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+  CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+  LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
+  ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+  POSSIBILITY OF SUCH DAMAGE.
+
+**/
+
+#include "XenBusDxe.h"
+
+///
+/// Component Name Protocol instance
+///
+GLOBAL_REMOVE_IF_UNREFERENCED
+EFI_COMPONENT_NAME_PROTOCOL  gXenBusDxeComponentName = {
+  (EFI_COMPONENT_NAME_GET_DRIVER_NAME)XenBusDxeComponentNameGetDriverName,
+  
(EFI_COMPONENT_NAME_GET_CONTROLLER_NAME)XenBusDxeComponentNameGetControllerName,
+  "eng"
+};
+
+///
+/// Component Name 2 Protocol instance
+///
+GLOBAL_REMOVE_IF_UNREFERENCED
+EFI_COMPONENT_NAME2_PROTOCOL  gXenBusDxeComponentName2 = {
+  XenBusDxeComponentNameGetDriverName,
+  XenBusDxeComponentNameGetControllerName,
+  "en"
+};
+
+///
+/// Table of driver names
+///
+GLOBAL_REMOVE_IF_UNREFERENCED
+EFI_UNICODE_STRING_TABLE mXenBusDxeDriverNameTable[] = {
+  { "eng;en", (CHAR16 *)L"XenBus Bus Driver" },
+  { NULL, NULL }
+};
+
+///
+/// Table of controller names
+///
+GLOBAL_REMOVE_IF_UNREFERENCED
+EFI_UNICODE_STRING_TABLE mXenBusDxeControllerNameTable[] = {
+  { "eng;en", (CHAR16 *)L"XenBus Controller" },
+  { NULL, NULL }
+};
+
+/**
+  Retrieves a Unicode string that is the user-readable name of the EFI Driver.
+
+  @param  This   A pointer to the EFI_COMPONENT_NAME_PROTOCOL instance.
+  @param  Language   A pointer to a three-character ISO 639-2 language 
identifier.
+

[edk2] [PATCH v2 07/18] OvmfPkg/XenBusDxe: Add InterlockedCompareExchange16.

2014-09-04 Thread Anthony PERARD
This is a copy of InterlockedCompareExchange32 from the
BaseSynchronizationLib.

The function will be used in the next patch.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD 

---
Change in V2:
- Add intel compilation code
  MSFT code is not compied over because I don't know how it works.
---
 OvmfPkg/XenBusDxe/InterlockedCompareExchange16.h   | 15 
 .../XenBusDxe/InterlockedCompareExchange16Intel.c  | 32 +
 .../XenBusDxe/X64/InterlockedCompareExchange16.asm | 41 ++
 .../XenBusDxe/X64/InterlockedCompareExchange16.c   | 41 ++
 OvmfPkg/XenBusDxe/XenBusDxe.inf|  4 +++
 5 files changed, 133 insertions(+)
 create mode 100644 OvmfPkg/XenBusDxe/InterlockedCompareExchange16.h
 create mode 100644 OvmfPkg/XenBusDxe/InterlockedCompareExchange16Intel.c
 create mode 100644 OvmfPkg/XenBusDxe/X64/InterlockedCompareExchange16.asm
 create mode 100644 OvmfPkg/XenBusDxe/X64/InterlockedCompareExchange16.c

diff --git a/OvmfPkg/XenBusDxe/InterlockedCompareExchange16.h 
b/OvmfPkg/XenBusDxe/InterlockedCompareExchange16.h
new file mode 100644
index 000..9067882
--- /dev/null
+++ b/OvmfPkg/XenBusDxe/InterlockedCompareExchange16.h
@@ -0,0 +1,15 @@
+UINT16
+EFIAPI
+InternalSyncCompareExchange16 (
+  IN  UINT16*Value,
+  IN  UINT16CompareValue,
+  IN  UINT16ExchangeValue
+  );
+
+UINT16
+EFIAPI
+InterlockedCompareExchange16 (
+  IN OUT volatile  UINT16   *Value,
+  IN  UINT16CompareValue,
+  IN  UINT16ExchangeValue
+  );
diff --git a/OvmfPkg/XenBusDxe/InterlockedCompareExchange16Intel.c 
b/OvmfPkg/XenBusDxe/InterlockedCompareExchange16Intel.c
new file mode 100644
index 000..bb40e70
--- /dev/null
+++ b/OvmfPkg/XenBusDxe/InterlockedCompareExchange16Intel.c
@@ -0,0 +1,32 @@
+#include "InterlockedCompareExchange16.h"
+
+/**
+  Performs an atomic compare exchange operation on a 16-bit unsigned integer.
+
+  Performs an atomic compare exchange operation on the 16-bit unsigned integer
+  specified by Value.  If Value is equal to CompareValue, then Value is set to
+  ExchangeValue and CompareValue is returned.  If Value is not equal to 
CompareValue,
+  then Value is returned.  The compare exchange operation must be performed 
using
+  MP safe mechanisms.
+
+  If Value is NULL, then ASSERT().
+
+  @param  Value A pointer to the 16-bit value for the compare exchange
+operation.
+  @param  CompareValue  16-bit value used in compare operation.
+  @param  ExchangeValue 16-bit value used in exchange operation.
+
+  @return The original *Value before exchange.
+
+**/
+UINT16
+EFIAPI
+InterlockedCompareExchange16 (
+  IN OUT  UINT16*Value,
+  IN  UINT16CompareValue,
+  IN  UINT16ExchangeValue
+  )
+{
+  ASSERT (Value != NULL);
+  return InternalSyncCompareExchange16 (Value, CompareValue, ExchangeValue);
+}
diff --git a/OvmfPkg/XenBusDxe/X64/InterlockedCompareExchange16.asm 
b/OvmfPkg/XenBusDxe/X64/InterlockedCompareExchange16.asm
new file mode 100644
index 000..b23e421
--- /dev/null
+++ b/OvmfPkg/XenBusDxe/X64/InterlockedCompareExchange16.asm
@@ -0,0 +1,41 @@
+;--
+;
+; Copyright (c) 2006, Intel Corporation. All rights reserved.
+; 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.
+;
+; Module Name:
+;
+;   InterlockedCompareExchange16.Asm
+;
+; Abstract:
+;
+;   InterlockedCompareExchange16 function
+;
+; Notes:
+;
+;--
+
+.code
+
+;--
+; UINT16
+; EFIAPI
+; InterlockedCompareExchange16 (
+;   IN  UINT16*Value,
+;   IN  UINT16CompareValue,
+;   IN  UINT16ExchangeValue
+;   );
+;--
+InternalSyncCompareExchange16   PROC
+mov eax, edx
+lockcmpxchg [rcx], r8w
+ret
+InternalSyncCompareExchange16   ENDP
+
+END
diff --git a/OvmfPkg/XenBusDxe/X64/InterlockedCompareExchange16.c 
b/OvmfPkg/XenBusDxe/X64/InterlockedCompareExchange16.c
new file mode 100644
index 000..64962ba
--- /dev/null
+++ b/OvmfPkg/XenBusDxe/X64/InterlockedCompareExchange16.c
@@ -0,0 +1,41 @@
+// Took from BaseSynchronizationLib, and replaced 32 by 16
+/**
+  Perfo

[edk2] [PATCH v2 06/18] OvmfPkg: Introduce XenBus Protocol.

2014-09-04 Thread Anthony PERARD
This protocol will be used for communication between a PV driver (like a
PV block driver) and the XenBus/XenStore.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD 

--
Change in V2:
- Comment, file header
- Protocol License
- Declare xen interface version earlier
- Rename protocol from Xenbus to XenBus
---
 OvmfPkg/Include/Protocol/XenBus.h | 86 +++
 OvmfPkg/OvmfPkg.dec   |  1 +
 OvmfPkg/XenBusDxe/XenBusDxe.h |  6 +++
 OvmfPkg/XenBusDxe/XenBusDxe.inf   |  1 +
 4 files changed, 94 insertions(+)
 create mode 100644 OvmfPkg/Include/Protocol/XenBus.h

diff --git a/OvmfPkg/Include/Protocol/XenBus.h 
b/OvmfPkg/Include/Protocol/XenBus.h
new file mode 100644
index 000..bf4a69f
--- /dev/null
+++ b/OvmfPkg/Include/Protocol/XenBus.h
@@ -0,0 +1,86 @@
+
+/** @file
+  XenBus protocol to be used between the XenBus bus driver and Xen PV devices.
+
+  This protocol provide the necessary for a Xen PV driver frontend to
+  communicate with the bus driver, and perform several task to
+  initialize/shutdown a PV device and perform IO with a PV backend.
+
+  Copyright (C) 2014, Citrix Ltd.
+
+  Redistribution and use in source and binary forms, with or without
+  modification, are permitted provided that the following conditions
+  are met:
+
+  * Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+  * Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+
+  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+  FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+  COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
+  BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+  LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+  CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+  LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
+  ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+  POSSIBILITY OF SUCH DAMAGE.
+
+**/
+
+#ifndef __PROTOCOL_XENBUS_H__
+#define __PROTOCOL_XENBUS_H__
+
+#define XENBUS_PROTOCOL_GUID \
+  {0x3d3ca290, 0xb9a5, 0x11e3, {0xb7, 0x5d, 0xb8, 0xac, 0x6f, 0x7d, 0x65, 
0xe6}}
+
+///
+/// Forward declaration
+///
+typedef struct _XENBUS_PROTOCOL XENBUS_PROTOCOL;
+
+
+#include 
+
+///
+/// Function prototypes
+///
+
+typedef
+EFI_STATUS
+(EFIAPI *XENBUS_GRANT_ACCESS)(
+  IN  XENBUS_PROTOCOL *This,
+  IN  domid_t DomainId,
+  IN  UINTN   Frame,
+  IN  BOOLEAN ReadOnly,
+  OUT grant_ref_t *refp
+  );
+
+typedef
+EFI_STATUS
+(EFIAPI *XENBUS_GRANT_END_ACCESS)(
+  IN XENBUS_PROTOCOL  *This,
+  IN grant_ref_t  Ref
+  );
+
+
+///
+/// Protocol structure
+///
+struct _XENBUS_PROTOCOL {
+  XENBUS_GRANT_ACCESS   GrantAccess;
+  XENBUS_GRANT_END_ACCESS   GrantEndAccess;
+  //
+  // Protocol data fields
+  //
+};
+
+extern EFI_GUID gXenBusProtocolGuid;
+
+#endif
diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index f829247..104a7b2 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -47,6 +47,7 @@
 [Protocols]
   gVirtioDeviceProtocolGuid   = {0xfa920010, 0x6785, 0x4941, {0xb6, 0xec, 
0x49, 0x8c, 0x57, 0x9f, 0x16, 0x0a}}
   gBlockMmioProtocolGuid  = {0x6b558ce3, 0x69e5, 0x4c67, {0xa6, 0x34, 
0xf7, 0xfe, 0x72, 0xad, 0xbe, 0x84}}
+  gXenBusProtocolGuid = {0x3d3ca290, 0xb9a5, 0x11e3, {0xb7, 0x5d, 
0xb8, 0xac, 0x6f, 0x7d, 0x65, 0xe6}}
 
 [PcdsFixedAtBuild]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|0x0|UINT32|0
diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.h b/OvmfPkg/XenBusDxe/XenBusDxe.h
index c16ad95..878e7c5 100644
--- a/OvmfPkg/XenBusDxe/XenBusDxe.h
+++ b/OvmfPkg/XenBusDxe/XenBusDxe.h
@@ -35,6 +35,11 @@
 #include 
 
 //
+// Xen interface version used
+//
+#define  __XEN_INTERFACE_VERSION__ 0x00040400
+
+//
 // Libraries
 //
 #include 
@@ -61,6 +66,7 @@
 //
 // Produced Protocols
 //
+#include 
 
 
 //
diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.inf b/OvmfPkg/XenBusDxe/XenBusDxe.inf
index edc3e51..aed2359 100644
--- a/OvmfPkg/XenBusDxe/XenBusDxe.inf
+++ b/OvmfPkg/XenBusDxe/XenBusDxe.inf
@@ -55,6 +55,7 @@
   gEfiPciIoProtocolGuid
   gEfiComponentName2ProtocolGuid
   gEfiComponentNameProtocolGuid
+  gXenBusProtocolGuid
 
 
 [Guids]
-- 
Anthony PERARD


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@

[edk2] [PATCH v2 04/18] OvmfPkg/XenBusDxe: Add support to make Xen Hypercalls.

2014-09-04 Thread Anthony PERARD
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD 

---
Change in V2:
- file header, copyright
- Add License
- Add push/pop instruction.
- fix types
- Comment of exported functions
- Improve coding style
- Add error handling in the main init function (of the drivers)
- Comment assembly
---
 OvmfPkg/XenBusDxe/X64/hypercall.S   |  23 +++
 OvmfPkg/XenBusDxe/X64/hypercall.asm |  27 
 OvmfPkg/XenBusDxe/XenBusDxe.c   |  22 ++
 OvmfPkg/XenBusDxe/XenBusDxe.h   |   5 ++
 OvmfPkg/XenBusDxe/XenBusDxe.inf |   6 ++
 OvmfPkg/XenBusDxe/XenHypercall.c| 134 
 OvmfPkg/XenBusDxe/XenHypercall.h| 100 +++
 7 files changed, 317 insertions(+)
 create mode 100644 OvmfPkg/XenBusDxe/X64/hypercall.S
 create mode 100644 OvmfPkg/XenBusDxe/X64/hypercall.asm
 create mode 100644 OvmfPkg/XenBusDxe/XenHypercall.c
 create mode 100644 OvmfPkg/XenBusDxe/XenHypercall.h

diff --git a/OvmfPkg/XenBusDxe/X64/hypercall.S 
b/OvmfPkg/XenBusDxe/X64/hypercall.S
new file mode 100644
index 000..3b18e48
--- /dev/null
+++ b/OvmfPkg/XenBusDxe/X64/hypercall.S
@@ -0,0 +1,23 @@
+# Hypercall with 2 arguments
+# INTN
+# EFIAPI
+# XenHypercall2 (
+#   IN VOID *HypercallAddr,
+#   IN OUT INTN Arg1,
+#   IN OUT INTN Arg2
+#   );
+ASM_GLOBAL ASM_PFX(XenHypercall2)
+ASM_PFX(XenHypercall2):
+  push %rdi
+  push %rsi
+  # Copy HypercallAddr to rax
+  movq %rcx, %rax
+  # Copy Arg1 to the register expected by Xen
+  movq %rdx, %rdi
+  # Copy Arg2 to the register expected by Xen
+  movq %r8, %rsi
+  # Call HypercallAddr
+  call *%rax
+  pop %rsi
+  pop %rdi
+  ret
diff --git a/OvmfPkg/XenBusDxe/X64/hypercall.asm 
b/OvmfPkg/XenBusDxe/X64/hypercall.asm
new file mode 100644
index 000..a39f240
--- /dev/null
+++ b/OvmfPkg/XenBusDxe/X64/hypercall.asm
@@ -0,0 +1,27 @@
+.code
+
+; Hypercall with 2 arguments
+; INTN
+; EFIAPI
+; XenHypercall2 (
+;   IN VOID *HypercallAddr,
+;   IN OUT INTN Arg1,
+;   IN OUT INTN Arg2
+;   );
+XenHypercall2 PROC
+  push rdi
+  push rsi
+  ; Copy HypercallAddr to rax
+  mov rax, rcx
+  ; Copy Arg1 to the register expected by Xen
+  mov rdi, rdx
+  ; Copy Arg2 to the register expected by Xen
+  mov rsi, r8
+  ; Call HypercallAddr
+  call rax
+  pop rsi
+  pop rdi
+  ret
+XenHypercall2 ENDP
+
+END
diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.c b/OvmfPkg/XenBusDxe/XenBusDxe.c
index e125ed7..db88cb4 100644
--- a/OvmfPkg/XenBusDxe/XenBusDxe.c
+++ b/OvmfPkg/XenBusDxe/XenBusDxe.c
@@ -45,6 +45,8 @@
 
 #include "XenBusDxe.h"
 
+#include "XenHypercall.h"
+
 
 ///
 /// Driver Binding Protocol instance
@@ -279,6 +281,8 @@ NotifyExitBoot (
   @retval EFI_SUCCESS  The device was started.
   @retval EFI_DEVICE_ERROR The device could not be started due to a 
device error.Currently not implemented.
   @retval EFI_OUT_OF_RESOURCES The request could not be completed due to a 
lack of resources.
+  @retval EFI_UNSUPPORTED  Something is missing on the system that
+   prevent to start the edvice.
   @retval Others   The driver failded to start the device.
 
 **/
@@ -298,6 +302,20 @@ XenBusDxeDriverBindingStart (
   Dev->This = This;
   Dev->ControllerHandle = ControllerHandle;
 
+  Status = XenHyperpageInit (Dev);
+  if (EFI_ERROR (Status)) {
+DEBUG ((EFI_D_ERROR, "XenBus: Unable to retrieve the hyperpage."));
+Status = EFI_UNSUPPORTED;
+goto ErrorNoHyperpage;
+  }
+
+  Status = XenGetSharedInfoPage (Dev);
+  if (EFI_ERROR (Status)) {
+DEBUG ((EFI_D_ERROR, "XenBus: Unable to get the shared info page."));
+Status = EFI_UNSUPPORTED;
+goto ErrorNoHyperpage;
+  }
+
   Status = gBS->CreateEvent (EVT_SIGNAL_EXIT_BOOT_SERVICES, TPL_CALLBACK,
  NotifyExitBoot,
  (VOID*) Dev,
@@ -306,6 +324,10 @@ XenBusDxeDriverBindingStart (
 
   mMyDevice = Dev;
   return EFI_SUCCESS;
+
+ErrorNoHyperpage:
+  FreePool (Dev);
+  return Status;
 }
 
 /**
diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.h b/OvmfPkg/XenBusDxe/XenBusDxe.h
index 9e4860a..af0510a 100644
--- a/OvmfPkg/XenBusDxe/XenBusDxe.h
+++ b/OvmfPkg/XenBusDxe/XenBusDxe.h
@@ -86,6 +86,8 @@ extern EFI_COMPONENT_NAME_PROTOCOL  gXenBusDxeComponentName;
 //
 // Other stuff
 //
+#include 
+
 #define PCI_VENDOR_ID_XEN0x5853
 #define PCI_DEVICE_ID_XEN_PLATFORM   0x0001
 
@@ -99,6 +101,9 @@ struct _XENBUS_DEVICE {
   EFI_DRIVER_BINDING_PROTOCOL   *This;
   EFI_HANDLEControllerHandle;
   EFI_EVENT ExitBootEvent;
+
+  VOID  *Hyperpage;
+  shared_info_t *SharedInfo;
 };
 
 #endif
diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.inf b/OvmfPkg/XenBusDxe/XenBusDxe.inf
index b4d7551..edc3e51 100644
--- a/OvmfPkg/XenBusDxe/XenBusDxe.inf
+++ b/OvmfPkg/XenBusDxe/XenBusDxe.inf
@@ -31,6 +31,12 @@
   DriverBinding.h
   ComponentName.c
   ComponentName.h
+  XenHypercall.c
+ 

[edk2] [PATCH v2 00/18] Introducing Xen PV block driver to OVMF

2014-09-04 Thread Anthony PERARD
Hi all,

This patch series is implementing the necessary in order to access a PV block
device. For that, one need a XenStore client, a XenBus client, and the PV block
driver.

There are two new drivers, XenbusDxe and XenPvBlkDxe. The first one implement a
bus drivers, and the second is a block drivers.

The GUID for the drivers XenBusDxe and XenPvBlkDxe and for the protocol XenBus
have been genereted using the UefiDriverWizard.

There are quite a lot of changes by patches since this series first hit the
mailing-list, all changes are listed in every patches, after a '---' line.

Anthony PERARD (18):
  OvmfPkg: Add public headers from Xen Project.
  OvmfPkg: Add basic skeleton for the XenBus bus driver.
  OvmfPkg/XenBusDxe: Add device state struct and create an ExitBoot
services event.
  OvmfPkg/XenBusDxe: Add support to make Xen Hypercalls.
  OvmfPkg/XenBusDxe: Open PciIo protocol.
  OvmfPkg: Introduce XenBus Protocol.
  OvmfPkg/XenBusDxe: Add InterlockedCompareExchange16.
  OvmfPkg/XenBusDxe: Add Grant Table functions.
  OvmfPkg/XenBusDxe: Add Event Channel Notify.
  OvmfPkg/XenBusDxe: Add TestAndClearBit.
  OvmfPkg/XenBusDxe: Add XenStore client implementation
  OvmfPkg/XenBusDxe: Add an helper AsciiStrDup.
  OvmfPkg/XenBusDxe: Add XenStore function into the XenBus protocol
  OvmfPkg/XenBusDxe: Indroduce XenBus support itself.
  OvmfPkg/XenBusDxe: Add Event Channel into XenBus protocol.
  OvmfPkg/XenPvBlkDxe: Xen PV Block device, initial skeleton
  OvmfPkg/XenPvBlkDxe: Add BlockFront client.
  OvmfPkg/XenPvBlkDxe: Add BlockIo.

 .../IndustryStandard/Xen/arch-x86/xen-x86_32.h |  171 +++
 .../IndustryStandard/Xen/arch-x86/xen-x86_64.h |  202 +++
 .../Include/IndustryStandard/Xen/arch-x86/xen.h|  273 
 .../Include/IndustryStandard/Xen/event_channel.h   |  381 +
 OvmfPkg/Include/IndustryStandard/Xen/grant_table.h |  662 +
 OvmfPkg/Include/IndustryStandard/Xen/hvm/hvm_op.h  |  275 
 OvmfPkg/Include/IndustryStandard/Xen/hvm/params.h  |  150 ++
 OvmfPkg/Include/IndustryStandard/Xen/io/blkif.h|  608 
 .../Include/IndustryStandard/Xen/io/protocols.h|   40 +
 OvmfPkg/Include/IndustryStandard/Xen/io/ring.h |  312 +
 OvmfPkg/Include/IndustryStandard/Xen/io/xenbus.h   |   80 ++
 OvmfPkg/Include/IndustryStandard/Xen/io/xs_wire.h  |  138 ++
 OvmfPkg/Include/IndustryStandard/Xen/memory.h  |  480 +++
 OvmfPkg/Include/IndustryStandard/Xen/sched.h   |  174 +++
 OvmfPkg/Include/IndustryStandard/Xen/trace.h   |  310 
 OvmfPkg/Include/IndustryStandard/Xen/xen-compat.h  |   44 +
 OvmfPkg/Include/IndustryStandard/Xen/xen.h |  897 
 OvmfPkg/Include/Protocol/XenBus.h  |  254 
 OvmfPkg/OvmfPkg.dec|1 +
 OvmfPkg/OvmfPkgX64.dsc |2 +
 OvmfPkg/OvmfPkgX64.fdf |2 +
 OvmfPkg/XenBusDxe/ComponentName.c  |  190 +++
 OvmfPkg/XenBusDxe/ComponentName.h  |  110 ++
 OvmfPkg/XenBusDxe/DriverBinding.h  |  144 ++
 OvmfPkg/XenBusDxe/EventChannel.c   |  104 ++
 OvmfPkg/XenBusDxe/EventChannel.h   |   98 ++
 OvmfPkg/XenBusDxe/GrantTable.c |  217 +++
 OvmfPkg/XenBusDxe/GrantTable.h |   68 +
 OvmfPkg/XenBusDxe/Helpers.c|9 +
 OvmfPkg/XenBusDxe/InterlockedCompareExchange16.h   |   15 +
 .../XenBusDxe/InterlockedCompareExchange16Intel.c  |   32 +
 .../XenBusDxe/X64/InterlockedCompareExchange16.asm |   41 +
 .../XenBusDxe/X64/InterlockedCompareExchange16.c   |   41 +
 OvmfPkg/XenBusDxe/X64/TestAndClearBit.S|   13 +
 OvmfPkg/XenBusDxe/X64/TestAndClearBit.asm  |   16 +
 OvmfPkg/XenBusDxe/X64/hypercall.S  |   23 +
 OvmfPkg/XenBusDxe/X64/hypercall.asm|   27 +
 OvmfPkg/XenBusDxe/XenBus.c |  371 +
 OvmfPkg/XenBusDxe/XenBus.h |   67 +
 OvmfPkg/XenBusDxe/XenBusDxe.c  |  482 +++
 OvmfPkg/XenBusDxe/XenBusDxe.h  |  159 +++
 OvmfPkg/XenBusDxe/XenBusDxe.inf|   78 ++
 OvmfPkg/XenBusDxe/XenHypercall.c   |  134 ++
 OvmfPkg/XenBusDxe/XenHypercall.h   |  100 ++
 OvmfPkg/XenBusDxe/XenStore.c   | 1480 
 OvmfPkg/XenBusDxe/XenStore.h   |  379 +
 OvmfPkg/XenPvBlkDxe/BlockFront.c   |  624 +
 OvmfPkg/XenPvBlkDxe/BlockFront.h   |   87 ++
 OvmfPkg/XenPvBlkDxe/BlockIo.c  |  292 
 OvmfPkg/XenPvBlkDxe/BlockIo.h  |  124 ++
 OvmfPkg/XenPvBlkDxe/ComponentName.c|  192 +++
 OvmfPkg/XenPvBlkDxe/ComponentName.h|  110 ++
 OvmfPkg/XenPvBlkDxe/DriverBinding.h|  159 +++
 OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.c  |  413 ++
 OvmfPkg/XenPvBl

[edk2] [PATCH v2 08/18] OvmfPkg/XenBusDxe: Add Grant Table functions.

2014-09-04 Thread Anthony PERARD
There are used to grant access of pages to other Xen domains.

This code originaly comes from the Xen Project, and more precisely from
MiniOS.

Signed-off-by: Steven Smith 
Signed-off-by: Grzegorz Milos 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD 

---
Change in V2:
- Adding locks
- Redo the file header
- Add functions comment
- Add license
---
 OvmfPkg/XenBusDxe/GrantTable.c  | 217 
 OvmfPkg/XenBusDxe/GrantTable.h  |  68 +
 OvmfPkg/XenBusDxe/XenBusDxe.c   |  15 +++
 OvmfPkg/XenBusDxe/XenBusDxe.inf |   2 +
 4 files changed, 302 insertions(+)
 create mode 100644 OvmfPkg/XenBusDxe/GrantTable.c
 create mode 100644 OvmfPkg/XenBusDxe/GrantTable.h

diff --git a/OvmfPkg/XenBusDxe/GrantTable.c b/OvmfPkg/XenBusDxe/GrantTable.c
new file mode 100644
index 000..8b08134
--- /dev/null
+++ b/OvmfPkg/XenBusDxe/GrantTable.c
@@ -0,0 +1,217 @@
+/** @file
+  Grant Table function implementation.
+
+  Grant Table are used to grant access to certain page of the current
+  VM to an other VM.
+
+  Author: Steven Smith (so...@cam.ac.uk)
+  Changes: Grzegorz Milos (gm...@cam.ac.uk)
+  Copyright (C) 2006, Cambridge University
+  Copyright (C) 2014, Citrix Ltd.
+
+  Redistribution and use in source and binary forms, with or without
+  modification, are permitted provided that the following conditions
+  are met:
+  1. Redistributions of source code must retain the above copyright
+ notice, this list of conditions and the following disclaimer.
+  2. Redistributions in binary form must reproduce the above copyright
+ notice, this list of conditions and the following disclaimer in the
+ documentation and/or other materials provided with the distribution.
+
+  THIS SOFTWARE IS PROVIDED BY AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+  ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+  IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+  ARE DISCLAIMED.  IN NO EVENT SHALL AUTHOR OR CONTRIBUTORS BE LIABLE
+  FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+  DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+  OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+  HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+  LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+  OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+  SUCH DAMAGE.
+**/
+#include "XenBusDxe.h"
+
+#include 
+
+#include "XenHypercall.h"
+
+#include "GrantTable.h"
+#include "InterlockedCompareExchange16.h"
+
+#define NR_RESERVED_ENTRIES 8
+
+/* NR_GRANT_FRAMES must be less than or equal to that configured in Xen */
+#define NR_GRANT_FRAMES 4
+#define NR_GRANT_ENTRIES (NR_GRANT_FRAMES * EFI_PAGE_SIZE / 
sizeof(grant_entry_v1_t))
+
+STATIC grant_entry_v1_t *GrantTable = NULL;
+STATIC grant_ref_t GrantList[NR_GRANT_ENTRIES];
+STATIC EFI_LOCK mGrantListLock;
+#ifdef GNT_DEBUG
+STATIC BOOLEAN GrantInUseList[NR_GRANT_ENTRIES];
+#endif
+
+STATIC
+VOID
+XenGrantTablePutFreeEntry (
+  grant_ref_t Ref
+  )
+{
+  EfiAcquireLock (&mGrantListLock);
+#ifdef GNT_DEBUG
+  ASSERT (GrantInUseList[Ref]);
+  GrantInUseList[Ref] = FALSE;
+#endif
+  GrantList[Ref] = GrantList[0];
+  GrantList[0] = Ref;
+  EfiReleaseLock (&mGrantListLock);
+}
+
+STATIC
+grant_ref_t
+XenGrantTableGetFreeEntry (
+  VOID
+  )
+{
+  UINTN Ref;
+
+  EfiAcquireLock (&mGrantListLock);
+  Ref = GrantList[0];
+  ASSERT (Ref >= NR_RESERVED_ENTRIES && Ref < NR_GRANT_ENTRIES);
+  GrantList[0] = GrantList[Ref];
+#ifdef GNT_DEBUG
+  ASSERT (!GrantInUseList[Ref]);
+  GrantInUseList[Ref] = TRUE;
+#endif
+  EfiReleaseLock (&mGrantListLock);
+  return Ref;
+}
+
+STATIC
+grant_ref_t
+XenGrantTableGrantAccess (
+  IN domid_t  DomainId,
+  IN UINTNFrame,
+  IN BOOLEAN  ReadOnly
+  )
+{
+  grant_ref_t Ref;
+  UINT32 Flags;
+
+  ASSERT (GrantTable != NULL);
+  Ref = XenGrantTableGetFreeEntry ();
+  GrantTable[Ref].frame = Frame;
+  GrantTable[Ref].domid = DomainId;
+  MemoryFence ();
+  Flags = GTF_permit_access;
+  if (ReadOnly) {
+Flags |= GTF_readonly;
+  }
+  GrantTable[Ref].flags = Flags;
+
+  return Ref;
+}
+
+STATIC
+EFI_STATUS
+XenGrantTableEndAccess (
+  grant_ref_t Ref
+  )
+{
+  UINT16 Flags, OldFlags;
+
+  ASSERT (GrantTable != NULL);
+  ASSERT (Ref >= NR_RESERVED_ENTRIES && Ref < NR_GRANT_ENTRIES);
+
+  OldFlags = GrantTable[Ref].flags;
+  do {
+if ((Flags = OldFlags) & (GTF_reading | GTF_writing)) {
+  DEBUG ((EFI_D_WARN, "WARNING: g.e. still in use! (%x)\n", Flags));
+  return EFI_NOT_READY;
+}
+OldFlags = InterlockedCompareExchange16 (&GrantTable[Ref].flags, Flags, 0);
+  } while (OldFlags != Flags);
+
+  XenGrantTablePutFreeEntry (Ref);
+  return EFI_SUCCESS;
+}
+
+VOID
+XenGrantTableInit (
+  IN XENBUS_DEVICE  *Dev,
+  IN UINT64 MmioAddr
+  )
+{
+  xen_add_to_physmap_t Parameters;
+  INTN Index;
+  IN

[edk2] [PATCH v2 05/18] OvmfPkg/XenBusDxe: Open PciIo protocol.

2014-09-04 Thread Anthony PERARD
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD 

---
Change in V2:
- Coding style
- Error handler
---
 OvmfPkg/XenBusDxe/XenBusDxe.c | 18 ++
 OvmfPkg/XenBusDxe/XenBusDxe.h |  1 +
 2 files changed, 19 insertions(+)

diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.c b/OvmfPkg/XenBusDxe/XenBusDxe.c
index db88cb4..15420c8 100644
--- a/OvmfPkg/XenBusDxe/XenBusDxe.c
+++ b/OvmfPkg/XenBusDxe/XenBusDxe.c
@@ -296,11 +296,25 @@ XenBusDxeDriverBindingStart (
 {
   EFI_STATUS Status;
   XENBUS_DEVICE *Dev;
+  EFI_PCI_IO_PROTOCOL *PciIo;
+
+  Status = gBS->OpenProtocol (
+ ControllerHandle,
+ &gEfiPciIoProtocolGuid,
+ (VOID **) &PciIo,
+ This->DriverBindingHandle,
+ ControllerHandle,
+ EFI_OPEN_PROTOCOL_BY_DRIVER
+ );
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
 
   Dev = AllocateZeroPool (sizeof (*Dev));
   Dev->Signature = XENBUS_DEVICE_SIGNATURE;
   Dev->This = This;
   Dev->ControllerHandle = ControllerHandle;
+  Dev->PciIo = PciIo;
 
   Status = XenHyperpageInit (Dev);
   if (EFI_ERROR (Status)) {
@@ -327,6 +341,8 @@ XenBusDxeDriverBindingStart (
 
 ErrorNoHyperpage:
   FreePool (Dev);
+  gBS->CloseProtocol (ControllerHandle, &gEfiPciIoProtocolGuid,
+  This->DriverBindingHandle, ControllerHandle);
   return Status;
 }
 
@@ -369,5 +385,7 @@ XenBusDxeDriverBindingStop (
 
   gBS->CloseEvent (Dev->ExitBootEvent);
 
+  gBS->CloseProtocol (ControllerHandle, &gEfiPciIoProtocolGuid,
+ This->DriverBindingHandle, ControllerHandle);
   return EFI_SUCCESS;
 }
diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.h b/OvmfPkg/XenBusDxe/XenBusDxe.h
index af0510a..c16ad95 100644
--- a/OvmfPkg/XenBusDxe/XenBusDxe.h
+++ b/OvmfPkg/XenBusDxe/XenBusDxe.h
@@ -100,6 +100,7 @@ struct _XENBUS_DEVICE {
   UINT32Signature;
   EFI_DRIVER_BINDING_PROTOCOL   *This;
   EFI_HANDLEControllerHandle;
+  EFI_PCI_IO_PROTOCOL   *PciIo;
   EFI_EVENT ExitBootEvent;
 
   VOID  *Hyperpage;
-- 
Anthony PERARD


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


[edk2] [PATCH v2 09/18] OvmfPkg/XenBusDxe: Add Event Channel Notify.

2014-09-04 Thread Anthony PERARD
This first function is used to notify the other side that there is
something to do. The other side is another Xen domain.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD 

---
Change in V2:
- file header
- coding style
- adding comment to functions
- Licenses
---
 OvmfPkg/XenBusDxe/EventChannel.c | 49 +++
 OvmfPkg/XenBusDxe/EventChannel.h | 50 
 OvmfPkg/XenBusDxe/XenBusDxe.inf  |  2 ++
 3 files changed, 101 insertions(+)
 create mode 100644 OvmfPkg/XenBusDxe/EventChannel.c
 create mode 100644 OvmfPkg/XenBusDxe/EventChannel.h

diff --git a/OvmfPkg/XenBusDxe/EventChannel.c b/OvmfPkg/XenBusDxe/EventChannel.c
new file mode 100644
index 000..f34f9b8
--- /dev/null
+++ b/OvmfPkg/XenBusDxe/EventChannel.c
@@ -0,0 +1,49 @@
+/** @file
+  Event Channel function implementation.
+
+  Event channel are use to notify of an event that happend in a shared
+  structure for example.
+
+  Copyright (C) 2014, Citrix Ltd.
+
+  Redistribution and use in source and binary forms, with or without
+  modification, are permitted provided that the following conditions
+  are met:
+
+  * Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+  * Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+
+  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+  FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+  COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
+  BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+  LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+  CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+  LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
+  ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+  POSSIBILITY OF SUCH DAMAGE.
+
+**/
+#include "EventChannel.h"
+#include "XenHypercall.h"
+
+VOID
+XenEventChannelNotify (
+  IN XENBUS_DEVICE *Dev,
+  IN evtchn_port_t Port
+  )
+{
+  INTN ReturnCode;
+  evtchn_send_t Send;
+
+  Send.port = Port;
+  ReturnCode = XenHypercallEventChannelOp (Dev, EVTCHNOP_send, &Send);
+  ASSERT (ReturnCode == 0);
+}
diff --git a/OvmfPkg/XenBusDxe/EventChannel.h b/OvmfPkg/XenBusDxe/EventChannel.h
new file mode 100644
index 000..fb2845b
--- /dev/null
+++ b/OvmfPkg/XenBusDxe/EventChannel.h
@@ -0,0 +1,50 @@
+/** @file
+  Event Channel function declaration.
+
+  Copyright (C) 2014, Citrix Ltd.
+
+  Redistribution and use in source and binary forms, with or without
+  modification, are permitted provided that the following conditions
+  are met:
+
+  * Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+  * Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+
+  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+  FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+  COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
+  BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+  LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+  CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+  LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
+  ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+  POSSIBILITY OF SUCH DAMAGE.
+
+**/
+#ifndef __XENBUS_EVENT_CHANNEL_H
+#define __XENBUS_EVENT_CHANNEL_H
+
+#include "XenBusDxe.h"
+
+#include 
+
+/**
+  Send an event to the remote end of the channel whose local endpoint is Port.
+
+  @param DevA pointer to XENBUS_DEVICE.
+  @param Port   The port to notify.
+**/
+VOID
+XenEventChannelNotify (
+  IN XENBUS_DEVICE *Dev,
+  IN evtchn_port_t Port
+  );
+
+#endif
diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.inf b/OvmfPkg/XenBusDxe/XenBusDxe.inf
index 1eca168..13623bd 100644
--- a/OvmfPkg/XenBusDxe/XenBusDxe.inf
+++ b/OvmfPkg/XenBusDxe/XenBusDxe.inf
@@ -36,6 +36,8 @@
   InterlockedCompareExchange16.h
   GrantTable.c
   GrantTable.h
+  EventChannel.c
+  EventChannel.h
 
 [Sources.X64]
   X64/hypercall.S
-- 
Anthony PERAR

[edk2] S3 with QEMU + OVMF + Windows Server 2012 R2 guest + QXL WDDM driver

2014-09-04 Thread Laszlo Ersek
Vadim Rozenfeld's QXL WDDM driver now works in Windows Server 2012 even
when the latter runs on OVMF. It has no VGA BIOS dependencies and it
supports S3. (IOW with this driver OVMF win2012 guests too can be
suspended and resumed.) Another benefit is the runtime video mode
selection; the user is no longer restricted to OVMF's PlatformDxe.

Start qemu with "-device qxl-vga,revision=4" at least (which revision is
the default in current qemu).

Binaries: http://people.redhat.com/vrozenfe/qxlwddm/qxlwddm-0.6.zip
Source:   https://github.com/vrozenfe/qxl-dod

Thank you, Vadim!

Laszlo

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


Re: [edk2] The DXE Core does not link with Xcode 5 for IA32

2014-09-04 Thread Andrew Fish

On Sep 3, 2014, at 7:12 PM, Gao, Liming  wrote:

> Andrew:
>   The original code is “while (Counter > 0x) {“, we meet with the 
> same issue in UNIXGCC tool chain. So, we change the code to “while ((Counter 
> & 0xULL) != 0) {“.  Now, you meet with this issue again in 
> XCODE tool chain. The possible fix is to use BaseLib API. The code could be 
> changed to “while (RShiftU64 (Counter, 32) > 0) {“
>  

Liming,

This fixes the clang link issue.

Thanks,

Andrew Fish

> Thanks
> Liming

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


Re: [edk2] [Patch]ShellPkg: Refine the code style and comment.

2014-09-04 Thread Carsey, Jaben
Reviewed-by: Jaben Carsey 

From: Qiu, Shumin
Sent: Thursday, September 04, 2014 6:02 AM
To: Carsey, Jaben
Cc: 'edk2-devel@lists.sourceforge.net'
Subject: [edk2][Patch]ShellPkg: Refine the code style and comment.
Importance: High

Hi Jaben,
Can you help to review this patch?  It refines the code style in ShellPkg and 
makes the number of tags in comment match function parameters.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin mailto:shumin@intel.com>>

Thanks
Shumin

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


Re: [edk2] [RFC PATCH] OVMF on QEMU's Q35

2014-09-04 Thread Laszlo Ersek
one comment

On 08/28/14 22:29, Gabriel L. Somlo wrote:
> 
> NOTE: I screwed up the mailing list address in the previous attempt,
> so please use this one to reply with feedback. Sorry about that !
> 
> 
> OvmfPkg/Library/AcpiTimerLib: Access power mgmt regs based on host bridge type
> 
> Pick the appropriate bus:dev.fn for accessing ACPI power management
> registers (00:01.3 on PIIX4 vs. 00:1f.0 on Q35) based on the DID of
> the host bridge (assumed always present at 00:00.0).
> 
> With this patch, OVMF can boot QEMU's "-machine q35" x86 machine type.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Gabriel Somlo 
> ---
> 
> I can boot Fedora20 Live with this patch applied on top of Reza's
> SATA series:
> 
> http://sourceforge.net/p/edk2/mailman/message/32743992/
> 
> using the following command line:
> 
> bin/qemu-system-x86_64 -machine q35 \
>   -device ide-drive,bus=ide.2,drive=HDC \
>   -drive id=HDC,if=none,snapshot=on,file=Fedora-Live-Desktop-x86_64-20-1.iso \
>   -enable-kvm -m 2048 -usb -device usb-kbd -device usb-mouse \
>   -bios OVMF.fd
> 
> Any comments/suggestions/feedback much appreciated.
> 
> Thanks much,
>Gabriel
> 
>  OvmfPkg/Library/AcpiTimerLib/AcpiTimerLib.c | 59 
> -
>  1 file changed, 57 insertions(+), 2 deletions(-)
> 
> diff --git a/OvmfPkg/Library/AcpiTimerLib/AcpiTimerLib.c 
> b/OvmfPkg/Library/AcpiTimerLib/AcpiTimerLib.c
> index c644128..f824283 100644
> --- a/OvmfPkg/Library/AcpiTimerLib/AcpiTimerLib.c
> +++ b/OvmfPkg/Library/AcpiTimerLib/AcpiTimerLib.c
> @@ -43,11 +43,66 @@
>  )
>  
>  //
> +// PCI Location of Q35 Power Management PCI Configuration Registers
> +//
> +#define Q35_POWER_MANAGEMENT_BUS   0x00
> +#define Q35_POWER_MANAGEMENT_DEVICE0x1f
> +#define Q35_POWER_MANAGEMENT_FUNCTION  0x00
> +
> +//
> +// Macro to access Q35 Power Management PCI Configuration Registers
> +//
> +#define Q35_PCI_POWER_MANAGEMENT_REGISTER(Register) \
> +  PCI_LIB_ADDRESS ( \
> +Q35_POWER_MANAGEMENT_BUS,   \
> +Q35_POWER_MANAGEMENT_DEVICE,\
> +Q35_POWER_MANAGEMENT_FUNCTION,  \
> +Register\
> +)
> +
> +//
> +// PCI Location of Host Bridge PCI Configuration Registers
> +//
> +#define HOST_BRIDGE_BUS   0x00
> +#define HOST_BRIDGE_DEVICE0x00
> +#define HOST_BRIDGE_FUNCTION  0x00
> +
> +//
> +// Macro to access Host Bridge Configuration Registers
> +//
> +#define HOST_BRIDGE_REGISTER(Register) \
> +  PCI_LIB_ADDRESS (\
> +HOST_BRIDGE_BUS,   \
> +HOST_BRIDGE_DEVICE,\
> +HOST_BRIDGE_FUNCTION,  \
> +Register   \
> +)
> +
> +//
> +// Host Bridge Device ID (DID) Register
> +//
> +#define HOST_BRIDGE_DID  HOST_BRIDGE_REGISTER (0x02)
> +
> +//
> +// Host Bridge DID Register values
> +//
> +#define PCI_DEVICE_ID_INTEL_824410x1237  // DID value for PIIX4
> +#define PCI_DEVICE_ID_INTEL_Q35_MCH  0x29C0  // DID value for Q35
> +
> +//
> +// Access Power Management PCI Config Regs based on Host Bridge type
> +//
> +#define PCI_POWER_MANAGEMENT_REGISTER(Register)  \
> +  (PciRead16 (HOST_BRIDGE_DID) == PCI_DEVICE_ID_INTEL_Q35_MCH) ? \
> +Q35_PCI_POWER_MANAGEMENT_REGISTER (Register) :   \
> +PIIX4_PCI_POWER_MANAGEMENT_REGISTER (Register)

Please wrap the replacement text in a pair of parens, ie. (?:) rather
than ?:. Then you can add-my

Reviewed-by: Laszlo Ersek 

Thanks
Laszlo

> +
> +//
>  // PIIX4 Power Management PCI Configuration Registers
>  //
> -#define PMBAPIIX4_PCI_POWER_MANAGEMENT_REGISTER (0x40)
> +#define PMBAPCI_POWER_MANAGEMENT_REGISTER (0x40)
>  #define   PMBA_RTE  BIT0
> -#define PMREGMISC   PIIX4_PCI_POWER_MANAGEMENT_REGISTER (0x80)
> +#define PMREGMISC   PCI_POWER_MANAGEMENT_REGISTER (0x80)
>  #define   PMIOSEBIT0
>  
>  //
> 


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


[edk2] [Patch]ShellPkg: Refine the code style and comment.

2014-09-04 Thread Qiu, Shumin
Hi Jaben,
Can you help to review this patch?  It refines the code style in ShellPkg and 
makes the number of tags in comment match function parameters.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin mailto:shumin@intel.com>>

Thanks
Shumin



Shell.patch
Description: Shell.patch
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


Re: [edk2] [PATCH] MdePkg NASM Thunk16: Work around NASM 2.09.04 - 2.10rc1 bug

2014-09-04 Thread Mike Maslenkin
Patch is good. Checked with NASM version 2.09.08.

On Wed, 2014-09-03 at 10:33 -0700, Jordan Justen wrote:
> Without this change, NASM 2.09.04 will hang with OVMF+CSM on both IA32
> and X64.
> 
> Tested on OVMF+CSM on GCC49 with NASM 2.07, 2.09.04 and 2.11.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jordan Justen 
> Cc: Mike Maslenkin 
> ---
>  MdePkg/Library/BaseLib/Ia32/Thunk16.nasm | 6 +-
>  MdePkg/Library/BaseLib/X64/Thunk16.nasm  | 6 +-
>  2 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/MdePkg/Library/BaseLib/Ia32/Thunk16.nasm 
> b/MdePkg/Library/BaseLib/Ia32/Thunk16.nasm
> index e8468a3..e3d0d4e 100644
> --- a/MdePkg/Library/BaseLib/Ia32/Thunk16.nasm
> +++ b/MdePkg/Library/BaseLib/Ia32/Thunk16.nasm
> @@ -85,7 +85,11 @@ _BackFromUserCode:
>  BITS16
>  pushss
>  pushcs
> -o32 calldword .Base ; push eip
> +;
> +; Note: We can't use o32 on the next instruction because of a bug
> +; in NASM 2.09.04 through 2.10rc1.
> +;
> +calldword .Base ; push eip
>  .Base:
>  pushfd
>  cli ; disable interrupts
> diff --git a/MdePkg/Library/BaseLib/X64/Thunk16.nasm 
> b/MdePkg/Library/BaseLib/X64/Thunk16.nasm
> index 6084fac..7c4a8d3 100644
> --- a/MdePkg/Library/BaseLib/X64/Thunk16.nasm
> +++ b/MdePkg/Library/BaseLib/X64/Thunk16.nasm
> @@ -83,7 +83,11 @@ _BackFromUserCode:
>  BITS16
>  pushss
>  pushcs
> -o32 calldword .Base ; push eip
> +;
> +; Note: We can't use o32 on the next instruction because of a bug
> +; in NASM 2.09.04 through 2.10rc1.
> +;
> +calldword .Base ; push eip
>  .Base:
>  pushdword 0 ; reserved high order 32 bits of 
> EFlags
>  pushfd



--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


Re: [edk2] [PATCH 0/9] first round of proposed fixups for "add support for AArch64 QEMU/KVM v6"

2014-09-04 Thread Laszlo Ersek
On 09/04/14 08:32, Ard Biesheuvel wrote:
> On 4 September 2014 04:09, Laszlo Ersek  wrote:
>> Hi Ard,
>>
>> I started to review your v6 patchset in reverse order -- I first created
>> a map between your v5 and v6 patches (as much as it was possible), then
>> started to look at the DSC file(s) first. The requirement to dynamically
>> determine the UART base address from the DTB is a very intrusive one,
>> unfortunately. So, the first thing that caught my eye was the various
>> new instances of the SerialPortLib class.
>>
>> As we discussed on #linaro-enterprise, "EarlyFdtPL011SerialPortLib" is
>> not appropriate for DXE_CORE, because it accesses the initial copy of
>> the DTB (at the bottom of the system DRAM), and at that point, when the
>> DXE_CORE is already running, that memory area is no longer protected
>> (because we decided to relocate it instead of protecting it in-place).
>>
>> So, I didn't get very far in the v6 review, but I do think I can propose
>> an improvement for the DXE_CORE's serial port library. Please see the
>> following patches.
>>
> 
> Looks great, thanks! I will look in more detail later today, but one
> thing comes to mind already:
> since the PcdGet() call in the constructor of the ordinary FdtPL011
> library is causing dependency hell and the need for a cloned
> UefiBootServicesTableLib, is there any reason we can't use your
> DXE_CORE version for *all* stages after DXE_CORE as well?

I'm very pleased that you too realized this possibility.

Unfortunately, it doesn't work. I tested it, and only upon seeing that
it didn't work did I elect to post this version of the fixup series.
(This is the reason I posted the series after 4AM, and not at 01:30AM.)

Namely, the HobLib class has three instances:

  HobLib|MdePkg/Library/PeiHobLib/PeiHobLib.inf
  HobLib|MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
  HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf

The PEI flavor allows linking against PEIM PEI_CORE SEC, but it doesn't
work in SEC (at least with the other lib resolutions that are used in
ArmPlatformPkg -- FWIW I didn't test it out elsewhere). It is not
relevant right now, I'm just mentioning it because originally I even
tried to set the HOB in SEC, so that *all* SerialPortLib instances would
the HOB based approach, but it didn't fly.  PeiHobLib doesn't work in
SEC, because needed PEI services are not available. And, in PEI itself,
it would be a mess to order some PEIMs (providing those services)
against other PEIMs. Hence I preserved your EarlyFdt implementation for
PEIM PEI_CORE SEC; it works fine.

The DxeCoreHobLib instance is only usable with DXE_CORE, and it has no
CONSTRUCTOR. (You do see where this is going!) This allows the
DxeCoreSerialPortLib instance I posted to work "automagically", even
though it depends on HobLib. (Because, DxeCoreHobLib depends on DebugLib
depends on DxeCoreSerialPortLib...) It all works because DxeCoreHobLib
uses "gHobList", without a constructor, which just comes from
"MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.c". IOW we do
exploit that we're in the DXE_CORE -- the DXE_CORE has a special HobLib
instance.

No such luck with DxeHobLib. That one has a CONSTRUCTOR, and BuildTools
immediately detect a circular dependency involving DxeHobLib (depending
on DebugLib depending on this new SerialPortLib depending on HobLib). If
I update the new, HOB-dependent SerialPortLib instance, removing its
constructor, and initializing it in its SerialPortInitialize() function
instead, then BuildTools don't detect a cycle -- and upon realizing
this, I *mistakenly* posted "I've seen the light" in the other thread.
Except it doesn't work, because the *exact same* constructor call order
problem hits. Namely, in the VirtFdtDxe module, DebugLib's constructor
calls SerialPortInitialize() manually, which calls GetFirstGuidHob(),
and that blows up because DxeHobLib's CONSTRUCTOR has not yet run.

This is a pity because this approach otherwise allowed me to completely
remove both PcdPL011BaseAddress and the forked UefiBootServicesTableLib.
To my dismay however, replacing our dependency on dynamic PCDs in
SerialPortLib with a dependency on HOBs reintroduces the exact same kind
of circular mess. This clearly shows that SerialPortLib had always been
designed to be 100% self-contained, and we're violating that by trying
to use dynamic PCDs *or* HOBs in it, generally. We only get lucky in
DXE_CORE with HOBs (because there a HOB dependency happens to work), and
in the other (later) DXE module types with dynamic PCDs (because you
hacked around the construction order with your forked
UefiBootServicesTableLib).

My proposal is to go with this mixed approach (and pray that the above
luck not run out), or to own up to the design constraints of
SerialPortLib, and stick with a FixedAtBuild UART base address.
(Honestly, I don't perceive that to be a grave limitation.)

> Getting the
> base address from a HOB and caching it doesn't seem more heavy weight
> than getting it from a Dyn

Re: [edk2] [BaseTools] [Patch] Update AutoGen to copy binary files to output directory only when the binary module is a library

2014-09-04 Thread Liu, Yingke D
Hi Hess,

The patch looks good to me.
Reviewed-by: Yingke Liu 

Dennis

From: Chen, Hesheng [mailto:hesheng.c...@intel.com]
Sent: Wednesday, September 03, 2014 3:20 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [BaseTools] [Patch] Update AutoGen to copy binary files to 
output directory only when the binary module is a library

Hello All,
Could you help review this patch? Thank you

BaseTools/AutoGen: Remove redundant copy action for binary module

Remove redundant copy action for binary module to copy binary files to output 
directory only when the binary module is a library


Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Hess Chen mailto:hesheng.c...@intel.com>>
Best Regards,
Chen, Hess
Intel China Software Center
Tel: +86-21-6116-6740
Email: hesheng.c...@intel.com

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel