Hi Ting,
The problem is solved. There was an issue in the driver code. Thanks for
your prompt reply.
Thanks,
Sajeesh.
Message: 2
Date: Mon, 11 May 2015 07:22:03 +0000
From: "Ye, Ting" <ting...@intel.com>
Subject: Re: [edk2] SW VLAN IMPLEMENTATION QUESTION
To: "edk2-devel@lists.sourceforge.net"
<edk2-devel@lists.sourceforge.net>
Message-ID:
<
bc0c045b0e2a584ca4575e779fa2c12a0a8a8...@shsmsx104.ccr.corp.intel.com>
Content-Type: text/plain; charset="utf-8"
Hi Sajeesh,
I need understand your problem at first. Could you please describe your
topology and configuration? How do you configure your VLAN ID?
And what does protocol type 0x8000 stand for? We use 0x0800 Ethernet type
for IPv4 protocol as I known. Is it a typo or a new protocol?
Best Regards,
Ye Ting
From: Sajeesh Kk [mailto:sajee...@gmail.com]
Sent: Saturday, May 09, 2015 12:48 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] SW VLAN IMPLEMENTATION QUESTION
Hello All,
I was trying SW Vlan implementation today. There is a problem i am facing.
There are some issues with respect to
protocol type field in the ethernet packet.
following are the obervations:
1. When the client receives a packet from the server, the Vlan id is
stripped by hardware.
The ProtocolType = 0x8000 instead of 0x8100 (VLAN tagged packet type).
The MNP first checks the protocol type in vlan is configured. Since it
does not match Vlan
tagged packet type, it drops the frames.
if (ProtocolType != ETHER_TYPE_VLAN) {
//
// Not a VLAN tagged frame
//
return FALSE;
}
This code snippet is present in MnpRemoveVlanTag function.
2. Modified the packet type to 0x8100, the MNP successfully finds the vlan
tag. There is a
default config data for each configured mnp instance. This config is
driven by IP. This config
data has protocol type = 0x8000. Since we have modified the protocol
type to 0x8100, the enqueueing
of the packet to IP layer fails.
In MnpMatchPacket fucntion, the code snippet copied below is dropping
frames, since
ConfigData->ProtocolTypeFilter = 0x8000 and . RxData->ProtocolType =
0x8100.
if ((ConfigData->ProtocolTypeFilter != 0) &&
(ConfigData->ProtocolTypeFilter != RxData->ProtocolType)) {
return FALSE;
}
Please let me know if my understanding is correct. all sugessions are
appreciated.
Thanks,
Sajeesh.
On Mon, May 11, 2015 at 1:06 PM, <edk2-devel-requ...@lists.sourceforge.net>
wrote:
> Send edk2-devel mailing list submissions to
> edk2-devel@lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
> or, via email, send a message with subject or body 'help' to
> edk2-devel-requ...@lists.sourceforge.net
>
> You can reach the person managing the list at
> edk2-devel-ow...@lists.sourceforge.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of edk2-devel digest..."
>
>
> Today's Topics:
>
> 1. Re: [PATCH 07/11] MdeModulePkg: SmmIplEntry(): don't suppress
> SMM core startup failure (Tian, Feng)
> 2. Re: SW VLAN IMPLEMENTATION QUESTION (Ye, Ting)
> 3. [PATCH] ArmPkg: update BdsLib to updated definition of
> EFI_LOAD_OPTION (Ard Biesheuvel)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 11 May 2015 07:07:35 +0000
> From: "Tian, Feng" <feng.t...@intel.com>
> Subject: Re: [edk2] [PATCH 07/11] MdeModulePkg: SmmIplEntry(): don't
> suppress SMM core startup failure
> To: Laszlo Ersek <ler...@redhat.com>,
> "edk2-devel@lists.sourceforge.net" <
> edk2-devel@lists.sourceforge.net>
> Message-ID:
> <
> 7f1bad85adea444d97065a60d2e97ee501d54...@shsmsx101.ccr.corp.intel.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> It looks good to me, Laszlo
>
> Just a minor comment, How about moving the local variable statement up to
> the beginning of the function for better coding style?
>
> If you agree, I will do it at check-in this patch and sign:
>
> Reviewed-by: Feng Tian <feng.t...@intel.com>
>
> Thanks
> Feng
>
> -----Original Message-----
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Saturday, May 09, 2015 02:52
> To: edk2-devel@lists.sourceforge.net
> Cc: Tian, Feng
> Subject: [PATCH 07/11] MdeModulePkg: SmmIplEntry(): don't suppress SMM
> core startup failure
>
> When the ExecuteSmmCoreFromSmram() function fails, SmmIplEntry() restores
> the SMRAM range to EFI_MEMORY_UC. However, it saves the return value of
> gDS->SetMemorySpaceAttributes() in the same Status variable that
> gDS->contains
> the return value of ExecuteSmmCoreFromSmram(). Therefore, if
> gDS->SetMemorySpaceAttributes() succeeds, the failure of
> ExecuteSmmCoreFromSmram() is masked, and Bad Things Happen (TM).
>
> Introduce a temporary variable just for the return value of
> gDS->SetMemorySpaceAttributes().
>
> Cc: Feng Tian <feng.t...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek <ler...@redhat.com>
> ---
> MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c | 14 ++++++++------
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
> b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
> index 4759579..35da454 100644
> --- a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
> +++ b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
> @@ -1213,12 +1213,14 @@ SmmIplEntry (
> // Attempt to reset SMRAM cacheability to UC
> //
> if (CpuArch != NULL) {
> - Status = gDS->SetMemorySpaceAttributes(
> - mSmramCacheBase,
> - mSmramCacheSize,
> - EFI_MEMORY_UC
> - );
> - if (EFI_ERROR (Status)) {
> + EFI_STATUS SetAttrStatus;
> +
> + SetAttrStatus = gDS->SetMemorySpaceAttributes(
> + mSmramCacheBase,
> + mSmramCacheSize,
> + EFI_MEMORY_UC
> + );
> + if (EFI_ERROR (SetAttrStatus)) {
> DEBUG ((DEBUG_WARN, "SMM IPL failed to reset SMRAM window to
> EFI_MEMORY_UC\n"));
> }
> }
> --
> 1.8.3.1
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 11 May 2015 07:22:03 +0000
> From: "Ye, Ting" <ting...@intel.com>
> Subject: Re: [edk2] SW VLAN IMPLEMENTATION QUESTION
> To: "edk2-devel@lists.sourceforge.net"
> <edk2-devel@lists.sourceforge.net>
> Message-ID:
> <
> bc0c045b0e2a584ca4575e779fa2c12a0a8a8...@shsmsx104.ccr.corp.intel.com>
>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Sajeesh,
>
> I need understand your problem at first. Could you please describe your
> topology and configuration? How do you configure your VLAN ID?
> And what does protocol type 0x8000 stand for? We use 0x0800 Ethernet type
> for IPv4 protocol as I known. Is it a typo or a new protocol?
>
> Best Regards,
> Ye Ting
>
>
> From: Sajeesh Kk [mailto:sajee...@gmail.com]
> Sent: Saturday, May 09, 2015 12:48 AM
> To: edk2-devel@lists.sourceforge.net
> Subject: [edk2] SW VLAN IMPLEMENTATION QUESTION
>
> Hello All,
>
> I was trying SW Vlan implementation today. There is a problem i am facing.
> There are some issues with respect to
> protocol type field in the ethernet packet.
>
> following are the obervations:
> 1. When the client receives a packet from the server, the Vlan id is
> stripped by hardware.
> The ProtocolType = 0x8000 instead of 0x8100 (VLAN tagged packet type).
>
> The MNP first checks the protocol type in vlan is configured. Since it
> does not match Vlan
> tagged packet type, it drops the frames.
>
> if (ProtocolType != ETHER_TYPE_VLAN) {
> //
> // Not a VLAN tagged frame
> //
> return FALSE;
> }
> This code snippet is present in MnpRemoveVlanTag function.
>
> 2. Modified the packet type to 0x8100, the MNP successfully finds the vlan
> tag. There is a
> default config data for each configured mnp instance. This config is
> driven by IP. This config
> data has protocol type = 0x8000. Since we have modified the protocol
> type to 0x8100, the enqueueing
> of the packet to IP layer fails.
> In MnpMatchPacket fucntion, the code snippet copied below is dropping
> frames, since
> ConfigData->ProtocolTypeFilter = 0x8000 and . RxData->ProtocolType
> = 0x8100.
> if ((ConfigData->ProtocolTypeFilter != 0) &&
> (ConfigData->ProtocolTypeFilter != RxData->ProtocolType)) {
> return FALSE;
> }
> Please let me know if my understanding is correct. all sugessions are
> appreciated.
> Thanks,
> Sajeesh.
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 3
> Date: Mon, 11 May 2015 09:35:58 +0200
> From: Ard Biesheuvel <ard.biesheu...@linaro.org>
> Subject: [edk2] [PATCH] ArmPkg: update BdsLib to updated definition of
> EFI_LOAD_OPTION
> To: edk2-devel@lists.sourceforge.net, olivier.mar...@arm.com
> Message-ID:
> <1431329758-17507-1-git-send-email-ard.biesheu...@linaro.org>
>
> Since there is now a formal definition of EFI_LOAD_OPTION, we can no
> longer typedef it as a UINT8*. So update the code to use the common
> definition, which is not a pointer type, hence the additional changes
> to the C code.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
> ---
>
> Hello Olivier,
>
> This fixes the currently broken build for me.
>
> Regards,
> Ard.
>
>
> ArmPkg/Include/Library/BdsLib.h | 4 +---
> ArmPkg/Library/BdsLib/BdsLoadOption.c | 8 ++++----
> ArmPlatformPkg/Bds/BootOption.c | 6 +++---
> 3 files changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/ArmPkg/Include/Library/BdsLib.h
> b/ArmPkg/Include/Library/BdsLib.h
> index eb7f8f293fb1..c6416db8ae79 100644
> --- a/ArmPkg/Include/Library/BdsLib.h
> +++ b/ArmPkg/Include/Library/BdsLib.h
> @@ -15,14 +15,12 @@
> #ifndef __BDS_ENTRY_H__
> #define __BDS_ENTRY_H__
>
> -typedef UINT8* EFI_LOAD_OPTION;
> -
> /**
> This is defined by the UEFI specs, don't change it
> **/
> typedef struct {
> UINT16 LoadOptionIndex;
> - EFI_LOAD_OPTION LoadOption;
> + EFI_LOAD_OPTION *LoadOption;
> UINTN LoadOptionSize;
>
> UINT32 Attributes;
> diff --git a/ArmPkg/Library/BdsLib/BdsLoadOption.c
> b/ArmPkg/Library/BdsLib/BdsLoadOption.c
> index be5ed41980a3..a87e7a0ff62c 100644
> --- a/ArmPkg/Library/BdsLib/BdsLoadOption.c
> +++ b/ArmPkg/Library/BdsLib/BdsLoadOption.c
> @@ -16,7 +16,7 @@
>
> EFI_STATUS
> BootOptionParseLoadOption (
> - IN EFI_LOAD_OPTION EfiLoadOption,
> + IN EFI_LOAD_OPTION *EfiLoadOption,
> IN UINTN EfiLoadOptionSize,
> IN OUT BDS_LOAD_OPTION **BdsLoadOption
> )
> @@ -73,7 +73,7 @@ BootOptionFromLoadOptionVariable (
> )
> {
> EFI_STATUS Status;
> - EFI_LOAD_OPTION EfiLoadOption;
> + EFI_LOAD_OPTION *EfiLoadOption;
> UINTN EfiLoadOptionSize;
>
> Status = GetGlobalEnvironmentVariable (BootVariableName, NULL,
> &EfiLoadOptionSize, (VOID**)&EfiLoadOption);
> @@ -141,12 +141,12 @@ BootOptionToLoadOptionVariable (
> // Allocate the memory for the EFI Load Option
> BdsLoadOption->LoadOptionSize = sizeof(UINT32) + sizeof(UINT16) +
> DescriptionSize + BdsLoadOption->FilePathListLength +
> BdsLoadOption->OptionalDataSize;
>
> - BdsLoadOption->LoadOption = (EFI_LOAD_OPTION)AllocateZeroPool
> (BdsLoadOption->LoadOptionSize);
> + BdsLoadOption->LoadOption = (EFI_LOAD_OPTION *)AllocateZeroPool
> (BdsLoadOption->LoadOptionSize);
> if (BdsLoadOption->LoadOption == NULL) {
> return EFI_OUT_OF_RESOURCES;
> }
>
> - EfiLoadOptionPtr = BdsLoadOption->LoadOption;
> + EfiLoadOptionPtr = (UINT8 *) BdsLoadOption->LoadOption;
>
> //
> // Populate the EFI Load Option and BDS Boot Option structures
> diff --git a/ArmPlatformPkg/Bds/BootOption.c
> b/ArmPlatformPkg/Bds/BootOption.c
> index 889040e3b63a..bb218f82aaf4 100644
> --- a/ArmPlatformPkg/Bds/BootOption.c
> +++ b/ArmPlatformPkg/Bds/BootOption.c
> @@ -141,7 +141,7 @@ BootOptionSetFields (
> IN UINTN OptionalDataSize
> )
> {
> - EFI_LOAD_OPTION EfiLoadOption;
> + EFI_LOAD_OPTION *EfiLoadOption;
> UINTN EfiLoadOptionSize;
> UINTN BootDescriptionSize;
> UINT16 FilePathListLength;
> @@ -168,8 +168,8 @@ BootOptionSetFields (
>
> // Allocate the memory for the EFI Load Option
> EfiLoadOptionSize = sizeof(UINT32) + sizeof(UINT16) +
> BootDescriptionSize + FilePathListLength + OptionalDataSize;
> - EfiLoadOption = (EFI_LOAD_OPTION)AllocatePool(EfiLoadOptionSize);
> - EfiLoadOptionPtr = EfiLoadOption;
> + EfiLoadOption = (EFI_LOAD_OPTION *)AllocatePool(EfiLoadOptionSize);
> + EfiLoadOptionPtr = (UINT8 *)EfiLoadOption;
>
> //
> // Populate the EFI Load Option and BDS Boot Option structures
> --
> 1.9.1
>
>
>
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>
> ------------------------------
>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
> End of edk2-devel Digest, Vol 65, Issue 99
> ******************************************
>
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
