Laszlo go ahead for the v5 to make the change you would like to see. I have
really appreciated the amount of time you have spent on reviewing the
patchset. Making your own changes would save you some of your time.
Jordan, I think your coding style comment has been lost in the review
process. I hav
On 11/27/13 12:48, Olivier Martin wrote:
> Laszlo go ahead for the v5 to make the change you would like to see. I have
> really appreciated the amount of time you have spent on reviewing the
> patchset. Making your own changes would save you some of your time.
Thank you very much! I'll seek to sen
On Tue, Nov 26, 2013 at 10:26:12PM +, Kinney, Michael D wrote:
> Wei,
>
> I recommend you put the declaration of the new PCD in the next section if
> MdeModulePkg.dec so it supports PatchableInModule as well.
>
Thanks Mike. I will do this.
Wei.
On Tue, Nov 26, 2013 at 02:47:13PM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 26, 2013 at 07:25:58PM +, Wei Liu wrote:
> > E820 definitions copied from IntelFrameworkModulePkg/Csm/
> > LegacyBiosDxe/LegacyBiosInterface.h.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
>
On 11/27/13 14:52, Markus Armbruster wrote:
> Jordan Justen writes:
>
>> On Tue, Nov 26, 2013 at 5:32 AM, Laszlo Ersek wrote:
>>> On 11/26/13 13:36, Markus Armbruster wrote:
>>>
Your stated purpose for multiple -pflash:
This accommodates the following use case: suppose that OV
On 11/27/13 14:49, Markus Armbruster wrote:
> Laszlo Ersek writes:
>
>> On 11/26/13 13:53, Markus Armbruster wrote:
>>
>>> Thus, we grab *all* if=pflash drives for this purpose.
>>>
>>> Your stated use case wants just two.
>>>
>>> Hmm. Are we sure we'll never want to map an if=pflash device some
On 11/27/13 15:45, Markus Armbruster wrote:
> Laszlo Ersek writes:
>
>> On 11/27/13 14:52, Markus Armbruster wrote:
>>> Jordan Justen writes:
>>>
On Tue, Nov 26, 2013 at 5:32 AM, Laszlo Ersek wrote:
> On 11/26/13 13:36, Markus Armbruster wrote:
>
>> Your stated purpose for mult
On 11/27/13 18:22, Markus Armbruster wrote:
> Perhaps the proper way to back partially writable flash contents isn't
> splitting it into two devices, but backing a single device with a COW.
> The backing file has initial contents (say BIOS image), the delta may
> have additional contents (say non-
From: Olivier Martin
This definition is specific to VirtIo over PCI.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin
Reviewed-by: Jordan Justen
Signed-off-by: Laszlo Ersek
---
OvmfPkg/Include/IndustryStandard/Virtio.h | 18 --
1 file chan
From: Olivier Martin
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin
v5:
- For uniformity, add the empty driver to
ArmVExpress-RTSM-AEMv8Ax4-foundation.* too in this patch, not just
ArmVExpress-RTSM-AEMv8Ax4.*. V4 added the empty driver to
ArmVExpress
From: Olivier Martin
Right now the ARM Platform driver does not do much, but
I expect to move most platform specific code into platform
specific driver in the future.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin
v5:
- ensure / document that the VIRTIO_B
From: Olivier Martin
This protocol introduces an abstraction to access the VirtIo
Configuration and Device spaces.
The registers in these spaces are located at a different offset and have
a different width whether the transport layer is either PCI or MMIO. This
protocol would also allow to suppor
Testing:
- OvmfPkg, X64:
- VirtioNetDxe:
- PXE boot on libvirt's virtual network
- DataSource socket utility from AppPkg (guest to host)
- VirtioBlkDxe: booted
- Fedora 19
- Windows 2012 R2
- Windows 2008 R2 (SeaBIOS CSM build of OVMF)
- VirtioScsiDxe: booted
- RHEL-6
From: Olivier Martin
Why is the virtio-mmio implementation of the protocol a library,
instead of a driver binary?
The UEFI driver model would encourage to create a virtio-mmio driver
instead of a library. But the reasons why I created a library are:
- A virtio-mmio driver would imply an addition
From: Olivier Martin
This change implements the VIRTIO_DEVICE_PROTOCOL for the PCI transport
layer.
The VirtIo device drivers will interact with the PCI-based VirtIo devices
through this protocol implementation.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Marti
From: Olivier Martin
These functions did not provide much more than the new protocol functions
VIRTIO_DEVICE_PROTOCOL.ReadDevice() / VIRTIO_DEVICE_PROTOCOL.WriteDevice().
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin
Reviewed-by: Jordan Justen
Signed-off
On Wed, Nov 27, 2013 at 4:22 AM, Wei Liu wrote:
> On Tue, Nov 26, 2013 at 02:47:13PM -0500, Konrad Rzeszutek Wilk wrote:
>> On Tue, Nov 26, 2013 at 07:25:58PM +, Wei Liu wrote:
>> > E820 definitions copied from IntelFrameworkModulePkg/Csm/
>> > LegacyBiosDxe/LegacyBiosInterface.h.
>> >
>> > Co
On Wed, Nov 27, 2013 at 04:18:38PM -0800, Jordan Justen wrote:
> On Wed, Nov 27, 2013 at 4:22 AM, Wei Liu wrote:
> > On Tue, Nov 26, 2013 at 02:47:13PM -0500, Konrad Rzeszutek Wilk wrote:
> >> On Tue, Nov 26, 2013 at 07:25:58PM +, Wei Liu wrote:
> >> > E820 definitions copied from IntelFramewo
Below is quoted from the EDKII coding standard spec:
7.3.2 Copyright Notice
The first line of the last paragraph of the file description is made up of the
copyright
notice. The copyright notice must consist of the following text with the FIRST
and
LAST symbols replaced with the year the file was
On Tue, Nov 26, 2013 at 11:25 AM, Wei Liu wrote:
> EFI_XEN_OVMF_INFO is defined to accept configurations from hvmloader. It
> must match the definition on Xen side.
>
> XenInfo is extended to include necessary bits as well. Currently only E820
> map is in use.
>
> Contributed-under: TianoCore Cont
On Wed, Nov 27, 2013 at 5:09 PM, Jordan Justen wrote:
> On Tue, Nov 26, 2013 at 11:25 AM, Wei Liu wrote:
>> EFI_XEN_OVMF_INFO is defined to accept configurations from hvmloader. It
>> must match the definition on Xen side.
>>
>> XenInfo is extended to include necessary bits as well. Currently onl
On Wed, Nov 27, 2013 at 05:36:01PM -0800, Jordan Justen wrote:
> On Wed, Nov 27, 2013 at 5:09 PM, Jordan Justen wrote:
> > On Tue, Nov 26, 2013 at 11:25 AM, Wei Liu wrote:
> >> EFI_XEN_OVMF_INFO is defined to accept configurations from hvmloader. It
> >> must match the definition on Xen side.
> >
On Thu, Nov 28, 2013 at 12:42:27AM +, Tian, Hot wrote:
> Below is quoted from the EDKII coding standard spec:
>
Sorry I can understand the above paragraph, but I still cannot get the
expection for non-Intel copyright line.
> 7.3.2 Copyright Notice
> The first line of the last paragraph of the
You may follow your company's legal guidance on copyright format.
-Original Message-
From: Wei Liu [mailto:wei.l...@citrix.com]
Sent: Thursday, November 28, 2013 10:35 AM
To: Tian, Hot
Cc: Jordan Justen; Wei Liu; Konrad Rzeszutek Wilk;
edk2-devel@lists.sourceforge.net; xen-devel; Justen,
24 matches
Mail list logo
