sravan/system76-edk2
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

OvmfPkg: strip trailing whitespace

Browse Source 
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien.grall@arm.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
This commit is contained in:
Leif Lindholm
2019-09-19 13:05:00 +01:00
parent ba39402f34
commit 4040754daf
27 changed files with 301 additions and 301 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen-x86_32.h
View File

@@ -1,8 +1,8 @@
/******************************************************************************
* xen-x86_32.h
*
*
* Guest OS interface to x86 32-bit Xen.
*
*
* SPDX-License-Identifier: MIT
*
* Copyright (c) 2004-2007, K A Fraser

4
OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen-x86_64.h
View File

@@ -1,8 +1,8 @@
/******************************************************************************
* xen-x86_64.h
*
*
* Guest OS interface to x86 64-bit Xen.
*
*
* SPDX-License-Identifier: MIT
*
* Copyright (c) 2004-2006, K A Fraser

4
OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen.h
View File

@@ -1,8 +1,8 @@
/******************************************************************************
* arch-x86/xen.h
*
*
* Guest OS interface to x86 Xen.
*
*
* SPDX-License-Identifier: MIT
*
* Copyright (c) 2004-2006, K A Fraser

2
OvmfPkg/Include/IndustryStandard/Xen/hvm/params.h
View File

@@ -103,7 +103,7 @@
*/
#define HVM_PARAM_ACPI_IOPORTS_LOCATION 19
/* Enable blocking memory events, async or sync (pause vcpu until response)
/* Enable blocking memory events, async or sync (pause vcpu until response)
* onchangeonly indicates messages only on a change of value */
#define HVM_PARAM_MEMORY_EVENT_CR0 20
#define HVM_PARAM_MEMORY_EVENT_CR3 21

2
OvmfPkg/Include/IndustryStandard/Xen/io/protocols.h
View File

@@ -1,6 +1,6 @@
/******************************************************************************
* protocols.h
*
*
* SPDX-License-Identifier: MIT
*/

34
OvmfPkg/Include/IndustryStandard/Xen/io/ring.h
View File

@@ -1,6 +1,6 @@
/******************************************************************************
* ring.h
*
*
* Shared producer-consumer ring macros.
*
* SPDX-License-Identifier: MIT
@@ -31,7 +31,7 @@ typedef UINT32 RING_IDX;
/*
* Calculate size of a shared ring, given the total available space for the
* ring and indexes (_sz), and the name tag of the request/response structure.
* A ring contains as many entries as will fit, rounded down to the nearest
* A ring contains as many entries as will fit, rounded down to the nearest
* power of two (so we can mask with (size-1) to loop around).
*/
#define __CONST_RING_SIZE(_s, _sz) \
@@ -45,7 +45,7 @@ typedef UINT32 RING_IDX;
/*
* Macros to make the correct C datatypes for a new kind of ring.
*
*
* To make a new ring datatype, you need to have two message structures,
* let's say request_t, and response_t already defined.
*
@@ -55,7 +55,7 @@ typedef UINT32 RING_IDX;
*
* These expand out to give you a set of types, as you can see below.
* The most important of these are:
*
*
* mytag_sring_t - The shared ring.
* mytag_front_ring_t - The 'front' half of the ring.
* mytag_back_ring_t - The 'back' half of the ring.
@@ -123,15 +123,15 @@ typedef struct __name##_back_ring __name##_back_ring_t
/*
* Macros for manipulating rings.
*
* FRONT_RING_whatever works on the "front end" of a ring: here
*
* FRONT_RING_whatever works on the "front end" of a ring: here
* requests are pushed on to the ring and responses taken off it.
*
* BACK_RING_whatever works on the "back end" of a ring: here
*
* BACK_RING_whatever works on the "back end" of a ring: here
* requests are taken off the ring and responses put on.
*
* N.B. these macros do NO INTERLOCKS OR FLOW CONTROL.
* This is OK in 1-for-1 request-response situations where the
*
* N.B. these macros do NO INTERLOCKS OR FLOW CONTROL.
* This is OK in 1-for-1 request-response situations where the
* requestor (front end) never has more than RING_SIZE()-1
* outstanding requests.
*/
@@ -219,26 +219,26 @@ typedef struct __name##_back_ring __name##_back_ring_t
/*
* Notification hold-off (req_event and rsp_event):
*
*
* When queueing requests or responses on a shared ring, it may not always be
* necessary to notify the remote end. For example, if requests are in flight
* in a backend, the front may be able to queue further requests without
* notifying the back (if the back checks for new requests when it queues
* responses).
*
*
* When enqueuing requests or responses:
*
*
* Use RING_PUSH_{REQUESTS,RESPONSES}_AND_CHECK_NOTIFY(). The second argument
* is a boolean return value. True indicates that the receiver requires an
* asynchronous notification.
*
*
* After dequeuing requests or responses (before sleeping the connection):
*
*
* Use RING_FINAL_CHECK_FOR_REQUESTS() or RING_FINAL_CHECK_FOR_RESPONSES().
* The second argument is a boolean return value. True indicates that there
* are pending messages on the ring (i.e., the connection should not be put
* to sleep).
*
*
* These macros will set the req_event/rsp_event field to trigger a
* notification on the very next message that is enqueued. If you want to
* create batches of work (i.e., only receive a notification after several

4
OvmfPkg/Include/IndustryStandard/Xen/memory.h
View File

@@ -1,8 +1,8 @@
/******************************************************************************
* memory.h
*
*
* Memory reservation and information.
*
*
* SPDX-License-Identifier: MIT
*
* Copyright (c) 2005, Keir Fraser <keir@xensource.com>

4
OvmfPkg/Include/IndustryStandard/Xen/xen-compat.h
View File

@@ -1,8 +1,8 @@
/******************************************************************************
* xen-compat.h
*
*
* Guest OS interface to Xen. Compatibility layer.
*
*
* SPDX-License-Identifier: MIT
*
* Copyright (c) 2006, Christian Limpach

10
OvmfPkg/Include/IndustryStandard/Xen/xen.h
View File

@@ -1,8 +1,8 @@
/******************************************************************************
* xen.h
*
*
* Guest OS interface to Xen.
*
*
* SPDX-License-Identifier: MIT
*
* Copyright (c) 2004, K A Fraser
@@ -203,7 +203,7 @@ typedef struct vcpu_time_info vcpu_time_info_t;
struct vcpu_info {
/*
* 'evtchn_upcall_pending' is written non-zero by Xen to indicate
* a pending notification for a particular VCPU. It is then cleared
* a pending notification for a particular VCPU. It is then cleared
* by the guest OS /before/ checking for pending work, thus avoiding
* a set-and-check race. Note that the mask is only accessed by Xen
* on the CPU that is currently hosting the VCPU. This means that the
@@ -266,7 +266,7 @@ struct shared_info {
* 3. Virtual interrupts ('events'). A domain can bind an event-channel
* port to a virtual interrupt source, such as the virtual-timer
* device or the emergency console.
*
*
* Event channels are addressed by a "port index". Each channel is
* associated with two bits of information:
* 1. PENDING -- notifies the domain that there is a pending notification
@@ -277,7 +277,7 @@ struct shared_info {
* becomes pending while the channel is masked then the 'edge' is lost
* (i.e., when the channel is unmasked, the guest must manually handle
* pending notifications as no upcall will be scheduled by Xen).
*
*
* To expedite scanning of pending notifications, any 0->1 pending
* transition on an unmasked channel causes a corresponding bit in a
* per-vcpu selector word to be set. Each bit in the selector covers a

2
OvmfPkg/Include/Register/QemuSmramSaveStateMap.h
View File

@@ -1,7 +1,7 @@
/** @file
SMRAM Save State Map Definitions.
SMRAM Save State Map definitions based on contents of the
SMRAM Save State Map definitions based on contents of the
Intel(R) 64 and IA-32 Architectures Software Developer's Manual
Volume 3C, Section 34.4 SMRAM
Volume 3C, Section 34.5 SMI Handler Execution Environment