[Xen-devel] 3.19 + xen-devel: kernel BUG at fs/ext4/page-io.c:85!
Hi, With a 3.19 kernel + xen-devel tree pulled on top i run into this splat below. It's on a Xen PV-guest running a postgres database and doing a pg_dump at that moment in time, after running for a while (within 2 days or so). -- Sander [139595.736073] [ cut here ] [139595.736073] kernel BUG at fs/ext4/page-io.c:85! [139595.736073] invalid opcode: [#1] SMP [139595.736073] Modules linked in: [139595.736073] CPU: 0 PID: 25632 Comm: pg_dump Not tainted 3.19.0-20150209-doflr-xendevel-edid+ #1 [139595.736073] task: 8800f8fd10c0 ti: 88006bc7 task.ti: 88006bc7 [139595.736073] RIP: e030:[] [] ext4_finish_bio+0x24f/0x260 [139595.736073] RSP: e02b:8800fac03bc8 EFLAGS: 00010046 [139595.736073] RAX: 0042002c RBX: 880060fa6170 RCX: 0034 [139595.736073] RDX: RSI: ea00014a77c0 RDI: 8800f9357300 [139595.736073] RBP: 8800fac03c58 R08: 0009 R09: 00016830 [139595.736073] R10: 8800ff820680 R11: R12: [139595.736073] R13: 88006bf111a0 R14: R15: eacd1800 [139595.736073] FS: 7f623b3f7720() GS:8800fac0() knlGS: [139595.736073] CS: e033 DS: ES: CR0: 8005003b [139595.736073] CR2: ff600400 CR3: 91907000 CR4: 0660 [139595.736073] Stack: [139595.736073] 8800fac03be8 81bc11c2 83140070 8800fac03cc6 [139595.736073] 8800f9357300 1000244d0001 0040002c 0017 [139595.736073] 0002 8800fac03c98 8110582d [139595.736073] Call Trace: [139595.736073] [139595.736073] [] ? _raw_spin_unlock_irqrestore+0x52/0x90 [139595.736073] [] ? lock_acquire+0xed/0x110 [139595.736073] [] ext4_end_bio+0x58/0x110 [139595.736073] [] bio_endio+0x53/0x90 [139595.736073] [] blk_update_request+0x80/0x300 [139595.736073] [] blk_update_bidi_request+0x22/0x90 [139595.736073] [] __blk_end_bidi_request+0x1b/0x40 [139595.736073] [] __blk_end_request_all+0x1a/0x30 [139595.736073] [] blkif_interrupt+0x731/0x8c0 [139595.736073] [] handle_irq_event_percpu+0x47/0x150 [139595.736073] [] handle_irq_event+0x43/0x70 [139595.736073] [] handle_edge_irq+0x96/0x110 [139595.736073] [] generic_handle_irq+0x1d/0x40 [139595.736073] [] evtchn_fifo_handle_events+0x16a/0x170 [139595.736073] [] __xen_evtchn_do_upcall+0x47/0x90 [139595.736073] [] xen_evtchn_do_upcall+0x2f/0x50 [139595.736073] [] xen_do_hypervisor_callback+0x1e/0x30 [139595.736073] [139595.736073] Code: 45 00 a8 10 75 f6 e9 82 fe ff ff 90 e8 5b 96 e9 ff 48 83 3d cb 78 fc 00 00 74 18 48 8b 7d a0 ff 14 25 28 fb 22 82 e9 1f ff ff ff <0f> 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 1f 80 00 00 00 00 55 48 89 e5 [139595.736073] RIP [] ext4_finish_bio+0x24f/0x260 [139595.736073] RSP [139595.736073] ---[ end trace cb2ee1cb372ad9b2 ]--- [139595.736073] Kernel panic - not syncing: Fatal exception in interrupt [139595.736073] Kernel Offset: 0x0 from 0x8100 (relocation range: 0x8000-0x9fff) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Question about HLT VMExit reason
Hi, all: I was testing networking performance from DomU to DomU running on different hosts. I used xentrace and xenalyze tools to get the trace info of receive side, and found that there was a time when vcpus (which handle the receive work) were in "Blocked" state. From the information of "VMExit" reason gotten by xenalyze tool, the "HLT" is the main exit reason. I am wondering when DomU will be exited because of "HLT"? Thanks. --Best RegardsJames ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC v1 1/8] xen: make dom0 specific changes depend on XEN_DOM0
On 12/02/15 06:03, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > These are Kconfig options which are known to only make > sense with Xen dom0 support. This is as per the agreed > upon changes to Xen's kconfig changes [0]. [...] > --- a/arch/x86/xen/Kconfig > +++ b/arch/x86/xen/Kconfig > @@ -35,13 +35,13 @@ config XEN_MAX_DOMAIN_MEMORY > > config XEN_SAVE_RESTORE > bool > - depends on XEN > + depends on XEN_DOM0 > select HIBERNATE_CALLBACKS > default y This breaks save/restore of domUs. > config XEN_DEBUG_FS > bool "Enable Xen debug and tuning parameters in debugfs" > - depends on XEN && DEBUG_FS > + depends on XEN_DOM0 && DEBUG_FS > default n > help > Enable statistics output and various tuning options in debugfs. This is useful for domUs. > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig > index 08f41ad..34af197 100644 > --- a/drivers/watchdog/Kconfig > +++ b/drivers/watchdog/Kconfig > @@ -1409,7 +1409,7 @@ config WATCHDOG_RIO > > config XEN_WDT > tristate "Xen Watchdog support" > - depends on XEN > + depends on XEN_DOM0 > help > Say Y here to support the hypervisor watchdog capability provided > by Xen 4.0 and newer. The watchdog timeout period is normally one Again, useful for domUs. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC v1 2/8] xen: x86: make XEN_MAX_DOMAIN_MEMORY depend on XEN_HAVE_PVMMU
On 12/02/15 06:03, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > Although XEN currently selects XEN_HAVE_PVMMU that will not > be the case in the near future so select this requirement > explicitly as per the agreed upon Kconfig changes [0]. [...] > --- a/arch/x86/xen/Kconfig > +++ b/arch/x86/xen/Kconfig > @@ -28,7 +28,7 @@ config XEN_MAX_DOMAIN_MEMORY > int > default 500 if X86_64 > default 64 if X86_32 > - depends on XEN > + depends on XEN && XEN_HAVE_PVMMU This can be just depends on XEN_HAVE_PVMMU David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Question about HLT VMExit reason
On 12/02/15 09:24, zhangtrump wrote: > Hi, all: > > I was testing networking performance from DomU to DomU running on > different hosts. I used xentrace and xenalyze tools to get the trace > info of receive side, and found that there was a time when vcpus > (which handle the receive work) were in "Blocked" state. > From the information of "VMExit" reason gotten by xenalyze tool, > the "HLT" is the main exit reason. I am wondering when DomU will be > exited because of "HLT"? > Thanks. Yes. When one vcpu halts, Xen will schedule another vcpu in its place. There is nothing to be gained at all by letting a pcpu stay halted in guest. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST 01/12] Add support of parsing grub which has 'submenu' primitive
On Thu, Feb 12, 2015 at 02:01:59AM +, Hu, Robert wrote:
>
> > -Original Message-
> > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > Sent: Wednesday, February 11, 2015 10:44 PM
> > To: Hu, Robert
> > Cc: xen-devel@lists.xen.org; jfeh...@suse.com; wei.l...@citrix.com;
> > ian.campb...@citrix.com; Pang, LongtaoX
> > Subject: Re: [PATCH OSSTEST 01/12] Add support of parsing grub which has
> > 'submenu' primitive
> >
> > Robert Ho writes ("[PATCH OSSTEST 01/12] Add support of parsing grub which
> > has 'submenu' primitive"):
> > > From a hvm kernel build from Linux stable Kernel tree,
> > > the auto generated grub2 menu will have 'submenu' primitive, upon the
> > > 'menuentry' items. Xen boot entries will be grouped into a submenu. This
> > > patch adds capability to support such grub formats. Also, this patch
> > > adjust
> > > some indent alignments.
> >
> > Thanks for this submission. Dealing with submenus is definitely
> > something we want to do.
> >
> > I haven't looked at the code in detail yet but I have a general
> > question: we currently count menu entries and eventually write
> > GRUB_DEFAULT= into /etc/default/grub.
> >
> > Does this work properly if the entry is in a submenu ? I guess you
> > have probably tested this but I thought I should ask...
> >
> Yes, this minor change just get 'parsemenu' subroutine capability of
> recognizing 'submenu'.
> The outer layer logic isn't affected.
> Actually, the Xen boot menuentry we choose, is inside a submenu. It works and
> /etc/default/grub
> is assigned properly.
In any case this is a very useful improvement.
Out of interest what Linux are you running? If you're running Debian
and the overlay 20_linux_xen (inside $OSSTEST/overlay/etc/etc/grub.d) is
copied to your test host, there shouldn't be any submenu entries in your
grub.cfg, I think.
Wei.
> > Can you please not adjust the whitespace ? osstest in general doesn't
> > have a requirement for any particular whitespace use, and certainly if
> > there are to be any whitespace changes they ought to be in a separate
> > patch.
> I adjust those because some one in last version's reply told us that
> osstest prefers white space substitution to tab, and traditionally 4
> white space of 1 tab. (This align with my previous coding experience as well)
> And I indeed find that this hunk of code doesn't looks well in my editor.
> Its unalignment increases difficulty of reading.
> I would suggest to adjust the this hunk's indentation and use white space
> substitution to tab to have best suitability across different editors.
> >
> > Thanks,
> > Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Question about HLT VMExit reason
I think that’s an answer to why hlt is a vmexit as opposed to when it is likely to occur… This simple answer, of course, is the OS idle process will most likely the issuer of a hlt instruction and this is why you are seeing them so frequently. Give your guest some compute-bound task and you’ll mostly likely see a big fall-off in the number of hlts. Paul From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Andrew Cooper Sent: 12 February 2015 10:07 To: zhangtrump; xen-devel@lists.xen.org Subject: Re: [Xen-devel] Question about HLT VMExit reason On 12/02/15 09:24, zhangtrump wrote: Hi, all: I was testing networking performance from DomU to DomU running on different hosts. I used xentrace and xenalyze tools to get the trace info of receive side, and found that there was a time when vcpus (which handle the receive work) were in "Blocked" state. From the information of "VMExit" reason gotten by xenalyze tool, the "HLT" is the main exit reason. I am wondering when DomU will be exited because of "HLT"? Thanks. Yes. When one vcpu halts, Xen will schedule another vcpu in its place. There is nothing to be gained at all by letting a pcpu stay halted in guest. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [edk2] [PATCH] MdeModulePkg: mark completion of PCI enumeration in PciEnumeratorLight
On Thu, Feb 12, 2015 at 01:23:26AM +, Ni, Ruiyu wrote: > Wei, > No you cannot install gEfiPciEnumerationCompleteProtocolGuid in > PciEnumeratorLight(). > > For a real platform, PCI BUS is fully enumerated in PciEnumerator() > and later if reconnect happens, it's light enumerated in > PciEnumeratorLight(). The protocol should only be installed once in > PeiEnumerator(). Your fix will cause this protocol installed every > time a reconnect happens. > Makes sense. > The protocol 's meaning is that the PCI BUS is fully enumerated. If > the PCI BUS is fully enumerated before starting PciBus driver, light > PCI enumeration is used. > > For your OVMF/QEMU case, an alternative fix is to install this > protocol in a platform driver when it detects that the PCI BUS is > fully enumerated. > Cool, thanks for the pointer. Then I shall fix it inside OVMF. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem
Hi all,
I am assuming this question is in effect resolved. The proposed (and agreed)
text basically states that security advisories state whether people will be
allowed to deploy. The underlying assumption is that usually this is the case,
unless there is a very good reason not to. How the security team handles these
does not really need to be codified and could be based on whether the
deployment would allow reverse engineering the issue (this would be very rare)
and thus put everyone at risk, the discoverer stating that he/she not wanting a
deployment, or any other reasons.
Regards
Lars
> On 19 Jan 2015, at 20:36, James McKenzie wrote:
>
> On 29/10/14 13:27, James Bulpin wrote:
>> George Dunlap writes ("Security policy ambiguities - XSA-108 process
>> post-mortem"):
>>> [snip]
>>>
>>> As far as I can tell we basically have the following options:
>>>
>>> 1. Never allow people to deploy during the embargo period.
>>>
>>> 2. Always allow people to deploy during the embargo period.
>>>
>>> 3. Have the security team attempt to evaluate the risk.
>>>
>>> 4. Have individual cloud operators evaluate the risk.
>>>
>>> This seems like a recipe for disaster.
>
>
> 1 and 3 seem like a recipe for disaster as organizations and individual people
> who have become aware of issues may have legal and other obligations to their
> users, it would also add a fairly strong incentive for a large operator not
> to share any issues that they, or a contractor, had found until they had
> completed a mitigation.
>
> Perhaps:
>
> 5) Have the security team discuss with the discoverer if fixes should be
> permitted during the embargo period before the discovery is announced to
> the list.
>
> J.
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] MdeModulePkg: mark completion of PCI enumeration in PciEnumeratorLight
On 02/11/15 21:23, Wei Liu wrote:
> I had an issue when trying to boot Xen HVM guest with latest OVMF
> master. Guest crashed with memory violation, and the bisection pointed
> to 66b280df2 ("OvmfPkg: AcpiPlatformDxe: make dependency on PCI
> enumeration explicit"). That commit made AcpiPlatformDxe depend on PCI
> enumeration using gEfiPciEnumerationCompleteProtocolGuid, which is a
> very reasonable change.
>
> The real culprit is that Xen HVM is using PciEnumeratorLight which
> doesn't install gEfiPciEnumerationCompleteProtocolGuid. This, in
> combination with 66b280df2, makes AcpiPlatformDxe not able to be loaded,
> resulting in guest crash.
>
> The fix is to install gEfiPciEnumerationCompleteProtocolGuid in
> PciEnumeratorLight.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Wei Liu
> Cc: Feng Tian
> Cc: Anthony Perard
> Cc: Laszlo Ersek
> Cc: Jordan Justen
> ---
> MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
> index 9e7ac74..7659585 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
> @@ -2256,6 +2256,7 @@ PciEnumeratorLight (
> {
>
>EFI_STATUSStatus;
> + EFI_HANDLEHostBridgeHandle;
>EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL *PciRootBridgeIo;
>PCI_IO_DEVICE *RootBridgeDev;
>UINT16MinBus;
> @@ -2288,6 +2289,11 @@ PciEnumeratorLight (
> return Status;
>}
>
> + //
> + // Get the host bridge handle
> + //
> + HostBridgeHandle = PciRootBridgeIo->ParentHandle;
> +
>Status = PciRootBridgeIo->Configuration (PciRootBridgeIo, (VOID **)
> &Descriptors);
>
>if (EFI_ERROR (Status)) {
> @@ -2348,7 +2354,14 @@ PciEnumeratorLight (
> Descriptors++;
>}
>
> - return EFI_SUCCESS;
> + Status = gBS->InstallProtocolInterface (
> + &HostBridgeHandle,
> + &gEfiPciEnumerationCompleteProtocolGuid,
> + EFI_NATIVE_INTERFACE,
> + NULL
> + );
> +
> + return Status;
> }
>
> /**
>
I think this could result in several installations of
gEfiPciEnumerationCompleteProtocolGuid. See the beginning of the
PciEnumerator() function.
If gFullEnumeration is TRUE to begin with (which is the QEMU case), then
the protocol will be installed at the end of PciEnumerator() first. At
that point we flip gFullEnumeration to FALSE, which implies that further
invocations of PciEnumerator() are possible and allowed. So at the next
call gFullEnumeration will be false, ie. we'll call
PciEnumeratorLight(). With the above patch PciEnumeratorLight() would
add the 2nd (and possibly further) instances of
EfiPciEnumerationCompleteProtocol.
I'll submit an alternative patch for OvmfPkg soon.
Thanks
Laszlo
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] MdeModulePkg: mark completion of PCI enumeration in PciEnumeratorLight
On Thu, Feb 12, 2015 at 11:46:04AM +0100, Laszlo Ersek wrote:
> On 02/11/15 21:23, Wei Liu wrote:
> > I had an issue when trying to boot Xen HVM guest with latest OVMF
> > master. Guest crashed with memory violation, and the bisection pointed
> > to 66b280df2 ("OvmfPkg: AcpiPlatformDxe: make dependency on PCI
> > enumeration explicit"). That commit made AcpiPlatformDxe depend on PCI
> > enumeration using gEfiPciEnumerationCompleteProtocolGuid, which is a
> > very reasonable change.
> >
> > The real culprit is that Xen HVM is using PciEnumeratorLight which
> > doesn't install gEfiPciEnumerationCompleteProtocolGuid. This, in
> > combination with 66b280df2, makes AcpiPlatformDxe not able to be loaded,
> > resulting in guest crash.
> >
> > The fix is to install gEfiPciEnumerationCompleteProtocolGuid in
> > PciEnumeratorLight.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Wei Liu
> > Cc: Feng Tian
> > Cc: Anthony Perard
> > Cc: Laszlo Ersek
> > Cc: Jordan Justen
> > ---
> > MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c | 15 ++-
> > 1 file changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
> > b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
> > index 9e7ac74..7659585 100644
> > --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
> > +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
> > @@ -2256,6 +2256,7 @@ PciEnumeratorLight (
> > {
> >
> >EFI_STATUSStatus;
> > + EFI_HANDLEHostBridgeHandle;
> >EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL *PciRootBridgeIo;
> >PCI_IO_DEVICE *RootBridgeDev;
> >UINT16MinBus;
> > @@ -2288,6 +2289,11 @@ PciEnumeratorLight (
> > return Status;
> >}
> >
> > + //
> > + // Get the host bridge handle
> > + //
> > + HostBridgeHandle = PciRootBridgeIo->ParentHandle;
> > +
> >Status = PciRootBridgeIo->Configuration (PciRootBridgeIo, (VOID **)
> > &Descriptors);
> >
> >if (EFI_ERROR (Status)) {
> > @@ -2348,7 +2354,14 @@ PciEnumeratorLight (
> > Descriptors++;
> >}
> >
> > - return EFI_SUCCESS;
> > + Status = gBS->InstallProtocolInterface (
> > + &HostBridgeHandle,
> > + &gEfiPciEnumerationCompleteProtocolGuid,
> > + EFI_NATIVE_INTERFACE,
> > + NULL
> > + );
> > +
> > + return Status;
> > }
> >
> > /**
> >
>
> I think this could result in several installations of
> gEfiPciEnumerationCompleteProtocolGuid. See the beginning of the
> PciEnumerator() function.
>
> If gFullEnumeration is TRUE to begin with (which is the QEMU case), then
> the protocol will be installed at the end of PciEnumerator() first. At
> that point we flip gFullEnumeration to FALSE, which implies that further
> invocations of PciEnumerator() are possible and allowed. So at the next
> call gFullEnumeration will be false, ie. we'll call
> PciEnumeratorLight(). With the above patch PciEnumeratorLight() would
> add the 2nd (and possibly further) instances of
> EfiPciEnumerationCompleteProtocol.
>
Right. Xen guest starts with gFullEnumeration set to FALSE which means
that protocol never gets installed.
> I'll submit an alternative patch for OvmfPkg soon.
>
Thanks. I'm just about to write a patch as Ray suggested but now I will
wait for your patch. :-)
Wei.
> Thanks
> Laszlo
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 20/21] libxlu: introduce new APIs
On Wed, Feb 11, 2015 at 04:17:19PM +, Ian Jackson wrote:
> Wei Liu writes ("[PATCH v4 20/21] libxlu: introduce new APIs"):
> > These APIs can be used to manipulate XLU_ConfigValue and XLU_ConfigList.
> ...
> > +const char *xlu_cfg_value_get_string(const XLU_ConfigValue *value)
> > +{
> > +assert(value->type == XLU_STRING);
> > +return value->u.string;
> > +}
>
> Most of the existing xlu_cfg_... functions return null (or -1) setting
> EINVAL if the type of the supplied config item is not correct.
>
> But these new functions are not really suitable for use directly
> because they crash on incorrect configuration input.
>
> Wouldn't it be better if these functions had calling conventions
> similar to xlu_cfg_get_string et al (returning errno values, taking
> dont_warn, etc.) ?
>
Right. I will use the same convention.
Wei.
> Thanks,
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 18/21] libxlu: rework internal representation of setting
On Wed, Feb 11, 2015 at 04:12:24PM +, Ian Jackson wrote:
> Wei Liu writes ("[PATCH v4 18/21] libxlu: rework internal representation of
> setting"):
> > This patches does following things:
> ...
> > +void xlu__cfg_list_append(CfgParseContext *ctx,
> > + XLU_ConfigValue *list,
> > + char *atom)
> > +{
> > +XLU_ConfigValue **new_val = NULL;
> > +XLU_ConfigValue *val = NULL;
> > if (ctx->err) return;
> ...
> > -if (set->nvalues >= set->avalues) {
> > -int new_avalues;
> > -char **new_values;
> > -
> > -if (set->avalues > INT_MAX / 100) { ctx->err= ERANGE; return; }
> > -new_avalues= set->avalues * 4;
> > -new_values= realloc(set->values,
> > -sizeof(*new_values) * new_avalues);
> > -if (!new_values) { ctx->err= errno; free(atom); return; }
> > -set->values= new_values;
> > -set->avalues= new_avalues;
>
> This is a standard expanding-array pattern which arranges not to
> realloc the array each time.
>
> > -}
> > -set->values[set->nvalues++]= atom;
> > +new_val = realloc(list->u.list.values,
> > + sizeof(*new_val) * (list->u.list.nvalues+1));
> > +if (!new_val) goto xe;
>
> But you replace it here with one which has quadradic performance.
>
> I don't know whether people are going to specify lists with hundreds
> or thousands of elements, but it doesn't seem impossible.
>
> I think you should retain the existing avalues stuff.
>
No problem.
> Apart from that this all looks good to me.
Thanks.
Wei.
>
> Thanks,
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC v1 3/8] xen: drivers: add XEN_FRONTEND and fold front end drivers under them
On 12/02/15 06:03, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > Fold Xen front end drivers under their own Kconfig entry. > You may want to for example only enable domU guests with > pv-drivers. > > While at it make HVC_XEN_FRONTEND select HVC_XEN. [...] > --- a/drivers/xen/Kconfig > +++ b/drivers/xen/Kconfig > @@ -83,6 +83,16 @@ config XEN_BACKEND > Support for backend device drivers that provide I/O services > to other virtual machines. > > +config XEN_FRONTEND > + bool "Frontend driver support" > + select XEN > + select XEN_XENBUS_FRONTEND > + default y > + help > + Support for frontend device drivers for Xen. You want to enable > + this if you want to run Xen guests. You can for instance enable > + domU guests with pv-drivers. XEN_FRONTEND should appear before XEN_BACKEND. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC v1 5/8] xen: x86: add XEN_PV
On 12/02/15 06:03, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > This lets us rip out under the general XEN config the > XEN_HAVE_PVMMU dependency. This only exists on the x86 > universe. This is as per the agreed upon Xen Kconfig > changes [0]. [...] > @@ -52,3 +51,9 @@ config XEN_PVH > depends on X86_64 && XEN > select XEN_PVHVM > def_bool n > + > +config XEN_PV > + bool "Support for running as a PV guest" > + depends on XEN && X86 > + select XEN_HAVE_PVMMU > + def_bool n These options should be in this order: XEN_PV, XEN_PVHVM, XEN_PVH. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC v1 7/8] xen: unwrap XEN_BACKEND from XEN_DOM0
On 12/02/15 06:03, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > This unwraps XEN_BACKEND from depending on XEN_DOM0, it > instead makes it depend on the possible x86 backends and > under what scenerios its allowed under ARM. This is as per > the agreed upon Xen Kconfig changes [0]. [...] > --- a/drivers/xen/Kconfig > +++ b/drivers/xen/Kconfig > @@ -77,7 +77,8 @@ config XEN_DEV_EVTCHN > > config XEN_BACKEND > bool "Backend driver support" > - depends on XEN_DOM0 > + depends on ARM || ARM64 || (X86 && (XEN_PV || XEN_PVH || XEN_PVHVM)) You don't need X86 here. Just XEN_PV etc. is fine. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] vsprintf: Make sure argument to %pX specifier is valid
On 11/02/15 20:58, Boris Ostrovsky wrote:
> If invalid pointer (i.e. something smaller than HYPERVISOR_VIRT_START)
> is passed for %*ph/%pv/%ps/%pS format specifiers then print "(NULL)"
>
> Signed-off-by: Boris Ostrovsky
> ---
> xen/common/vsprintf.c | 23 ---
> 1 files changed, 16 insertions(+), 7 deletions(-)
>
> v2:
> * Print "(NULL)" instead of specifier-specific string
> * Consider all addresses under HYPERVISOR_VIRT_START as invalid. (I think
>this is true for both x86 and ARM but I don't have ARM platform to test).
>
>
> diff --git a/xen/common/vsprintf.c b/xen/common/vsprintf.c
> index 065cc42..b9542b5 100644
> --- a/xen/common/vsprintf.c
> +++ b/xen/common/vsprintf.c
> @@ -270,6 +270,22 @@ static char *pointer(char *str, char *end, const char
> **fmt_ptr,
> const char *fmt = *fmt_ptr, *s;
>
> /* Custom %p suffixes. See XEN_ROOT/docs/misc/printk-formats.txt */
> +
> +switch ( fmt[1] )
> +{
> +case 'h':
> +case 's':
> +case 'S':
> +case 'v':
> +++*fmt_ptr;
> +}
> +
> +if ( (unsigned long)arg < HYPERVISOR_VIRT_START )
> +{
> +char *s = "(NULL)";
> +return string(str, end, s, -1, -1, 0);
> +}
> +
> switch ( fmt[1] )
This wont function, as you have inverted the increment of *fmt_ptr and
check of fmt[1].
"(NULL)" is inappropriate for non-null pointers less than VIRT_START.
Given the VIRT check, I would just put the entire switch statement
inside an "if ( (unsigned long)arg < HYPERVISOR_VIRT_START )" block and
let it fall through to the plain number case for a bogus pointer.
~Andrew
> {
> case 'h': /* Raw buffer as hex string. */
> @@ -277,9 +293,6 @@ static char *pointer(char *str, char *end, const char
> **fmt_ptr,
> const uint8_t *hex_buffer = arg;
> unsigned int i;
>
> -/* Consumed 'h' from the format string. */
> -++*fmt_ptr;
> -
> /* Bound user count from %* to between 0 and 64 bytes. */
> if ( field_width <= 0 )
> return str;
> @@ -306,9 +319,6 @@ static char *pointer(char *str, char *end, const char
> **fmt_ptr,
> unsigned long sym_size, sym_offset;
> char namebuf[KSYM_NAME_LEN+1];
>
> -/* Advance parents fmt string, as we have consumed 's' or 'S' */
> -++*fmt_ptr;
> -
> s = symbols_lookup((unsigned long)arg, &sym_size, &sym_offset,
> namebuf);
>
> /* If the symbol is not found, fall back to printing the address */
> @@ -335,7 +345,6 @@ static char *pointer(char *str, char *end, const char
> **fmt_ptr,
> {
> const struct vcpu *v = arg;
>
> -++*fmt_ptr;
> if ( str < end )
> *str = 'd';
> str = number(str + 1, end, v->domain->domain_id, 10, -1, -1, 0);
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC] Tweaking the release process for Xen 4.6
On Wed, Feb 11, 2015 at 02:54:46PM +, Lars Kurth wrote: > > > On 11/02/2015 12:27, "Wei Liu" wrote: > > >On Wed, Feb 11, 2015 at 12:20:20PM +, Lars Kurth wrote: > >> Wei, > >> > >> this sounds reasonable. I just wanted to ensure that I understood fully? > >> Do you want me to update the presentation I sent you yesterday and which > >> is also at > >> > >>http://www.slideshare.net/xen_com_mgr/xen-project-release-and-roadmap-pro > >>ce > >> ss with some mods to outline the changes based on what you described? > >> > > > >Let's wait for one day or two before modifying. > > > >Many people are in different timezone so I would like to leave a bit > >more time for them to say if they have anything to add. > > Wei, > I added two pictures which shows my understanding of the changes Thanks. I think your new pictures are accurate. Wei. > Regards > Lars > > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC v1 0/8] xen: kconfig changes
On 12/02/15 06:03, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > Here's the first shot at the Kconfig changes for Xen as discussed > on the mailing list a little while ago [0]. Let me know if you spot > any issues or if you'd like things split differently. I tried to > make things as atomic as possible, but not being too rediculous > on the atomicity of the changes, for instance the HVC changes > were reasonable to just fold into the other change it touched. > > Haven't gone to war with testing the Kconfig changes yet given this > is just the first RFC. If things look good please look for major > issues and let me know.# Can you spin a v2 and make a git branch available, please? I would like people to be able to easily try out the changes rather than looking at the diffs. If I haven't comment on a specific patch it's because I thought it looked ok. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC] Tweaking the release process for Xen 4.6
On 12/02/2015 11:07, "Wei Liu" wrote: > >Thanks. I think your new pictures are accurate. > >Wei. In that case, I will re-upload that presentation I shared earlier. It will show the pre 4.5 workflow and new proposal Regards Lars ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC] Tweaking the release process for Xen 4.6
On Thu, Feb 12, 2015 at 11:09:52AM +, Lars Kurth wrote: > > > On 12/02/2015 11:07, "Wei Liu" wrote: > > > >Thanks. I think your new pictures are accurate. > > > >Wei. > > In that case, I will re-upload that presentation I shared earlier. It will > show the pre 4.5 workflow and new proposal I think you mean pre-4.6. Yes, showing both are good. Wei. > Regards > Lars > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 07/29] ArmVirtualizationPkg: use a HOB to store device tree blob
Instead of using a dynamic PCD, store the device tree address in a HOB so that we can also run under a configuration that does not support dynamic PCDs. This also adds MemoryAllocationLib to the [LibraryClasses] section of ArmVirtualizationPlatformLib/ArmVirtualizationPlatformLib.inf, as this dependency was formerly satisfied transitively through one of the library dependencies that were dropped. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Laszlo Ersek Reviewed-by: Olivier Martin Signed-off-by: Ard Biesheuvel --- ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec | 2 -- ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc | 3 --- ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/ArmVirtualizationPlatformLib.inf | 3 +-- ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c | 11 --- ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.inf | 4 +--- ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c | 10 -- ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf | 3 ++- EmbeddedPkg/EmbeddedPkg.dec | 2 ++ EmbeddedPkg/Include/Guid/FdtHob.h | 26 ++ 9 files changed, 48 insertions(+), 16 deletions(-) diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec index d83117fc6abe..868488906643 100644 --- a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec +++ b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec @@ -44,8 +44,6 @@ gArmVirtualizationTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress|0x0|UINT64|0x0001 [PcdsDynamic, PcdsFixedAtBuild] - gArmVirtualizationTokenSpaceGuid.PcdDeviceTreeBaseAddress|0x0|UINT64|0x0002 - # # ARM PSCI function invocations can be done either through hypervisor # calls (HVC) or secure monitor calls (SMC). diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc index 066108f66d28..f3c55b03440e 100644 --- a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc +++ b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc @@ -160,9 +160,6 @@ # System Memory Size -- 1 MB initially, actual size will be fetched from DT gArmTokenSpaceGuid.PcdSystemMemorySize|0x0010 - # location of the device tree blob passed by QEMU - gArmVirtualizationTokenSpaceGuid.PcdDeviceTreeBaseAddress|0x0 - gArmTokenSpaceGuid.PcdArmArchTimerSecIntrNum|0x0 gArmTokenSpaceGuid.PcdArmArchTimerIntrNum|0x0 gArmTokenSpaceGuid.PcdArmArchTimerVirtIntrNum|0x0 diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/ArmVirtualizationPlatformLib.inf b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/ArmVirtualizationPlatformLib.inf index 43b3c6ca1bef..2cff4b62ea0c 100644 --- a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/ArmVirtualizationPlatformLib.inf +++ b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/ArmVirtualizationPlatformLib.inf @@ -30,11 +30,10 @@ [LibraryClasses] IoLib + MemoryAllocationLib ArmLib PrintLib FdtLib - SerialPortLib - HobLib [Sources.common] Virt.c diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c b/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c index 58bc2b828dcd..c500d5964b25 100644 --- a/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c +++ b/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c @@ -22,6 +22,7 @@ #include #include +#include EFI_STATUS EFIAPI @@ -32,6 +33,7 @@ PlatformPeim ( VOID *Base; VOID *NewBase; UINTN FdtSize; + UINT64 *FdtHobData; UINT64 *UartHobData; INT32 Node, Prev; CONST CHAR8*Compatible; @@ -41,15 +43,18 @@ PlatformPeim ( UINT64 UartBase; - Base = (VOID*)(UINTN)FixedPcdGet64 (PcdDeviceTreeInitialBaseAddress); + Base = (VOID*)(UINTN)PcdGet64 (PcdDeviceTreeInitialBaseAddress); + ASSERT (Base != NULL); ASSERT (fdt_check_header (Base) == 0); FdtSize = fdt_totalsize (Base); NewBase = AllocatePages (EFI_SIZE_TO_PAGES (FdtSize)); ASSERT (NewBase != NULL); - CopyMem (NewBase, Base, FdtSize); - PcdSet64 (PcdDeviceTreeBaseAddress, (UINT64)(UINTN)NewBase); + + FdtHobData
[Xen-devel] [PATCH v4 06/29] ArmVirtualizationPkg: move early UART discovery to PlatformPeim
This is partially motivated by the desire to use PrePi in a virt
environment, and in that configuration, ArmPlatformInitializeSystemMemory()
is never called. But actually, this is a more suitable place anyway.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek
Reviewed-by: Olivier Martin
Signed-off-by: Ard Biesheuvel
---
ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/ArmVirtualizationPlatformLib.inf
| 3 ---
ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
| 46 ++
ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c
| 48
ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.inf
| 3 +++
4 files changed, 53 insertions(+), 47 deletions(-)
diff --git
a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/ArmVirtualizationPlatformLib.inf
b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/ArmVirtualizationPlatformLib.inf
index d1572882af1b..43b3c6ca1bef 100644
---
a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/ArmVirtualizationPlatformLib.inf
+++
b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/ArmVirtualizationPlatformLib.inf
@@ -62,6 +62,3 @@
gArmTokenSpaceGuid.PcdArmPrimaryCore
gArmTokenSpaceGuid.PcdFdBaseAddress
gArmTokenSpaceGuid.PcdFdSize
-
-[Guids]
- gEarlyPL011BaseAddressGuid
diff --git
a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
index 3e3074af72f1..17f268697583 100644
---
a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
+++
b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
@@ -24,9 +24,6 @@
#include
#include
#include
-#include
-#include
-#include
/**
Return the current Boot Mode
@@ -77,25 +74,13 @@ ArmPlatformInitializeSystemMemory (
INT32Node, Prev;
UINT64 NewBase;
UINT64 NewSize;
- BOOLEAN HaveMemory, HaveUART;
- UINT64 *HobData;
CONST CHAR8 *Type;
- CONST CHAR8 *Compatible;
- CONST CHAR8 *CompItem;
INT32Len;
CONST UINT64 *RegProp;
- UINT64 UartBase;
NewBase = 0;
NewSize = 0;
- HaveMemory = FALSE;
- HaveUART = FALSE;
-
- HobData = BuildGuidHob (&gEarlyPL011BaseAddressGuid, sizeof *HobData);
- ASSERT (HobData != NULL);
- *HobData = 0;
-
DeviceTreeBase = (VOID *)(UINTN)PcdGet64 (PcdDeviceTreeInitialBaseAddress);
ASSERT (DeviceTreeBase != NULL);
@@ -107,7 +92,7 @@ ArmPlatformInitializeSystemMemory (
//
// Look for a memory node
//
- for (Prev = 0; !(HaveMemory && HaveUART); Prev = Node) {
+ for (Prev = 0;; Prev = Node) {
Node = fdt_next_node (DeviceTreeBase, Prev, NULL);
if (Node < 0) {
break;
@@ -140,34 +125,7 @@ ArmPlatformInitializeSystemMemory (
DEBUG ((EFI_D_ERROR, "%a: Failed to parse FDT memory node\n",
__FUNCTION__));
}
- HaveMemory = TRUE;
- continue;
-}
-
-//
-// Check for UART node
-//
-Compatible = fdt_getprop (DeviceTreeBase, Node, "compatible", &Len);
-
-//
-// Iterate over the NULL-separated items in the compatible string
-//
-for (CompItem = Compatible; CompItem != NULL && CompItem < Compatible +
Len;
- CompItem += 1 + AsciiStrLen (CompItem)) {
-
- if (AsciiStrCmp (CompItem, "arm,pl011") == 0) {
-RegProp = fdt_getprop (DeviceTreeBase, Node, "reg", &Len);
-ASSERT (Len == 16);
-
-UartBase = fdt64_to_cpu (ReadUnaligned64 (RegProp));
-
-DEBUG ((EFI_D_INFO, "%a: PL011 UART @ 0x%lx\n", __FUNCTION__,
UartBase));
-
-*HobData = UartBase;
-
-HaveUART = TRUE;
-continue;
- }
+ break;
}
}
diff --git
a/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c
b/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c
index af0d6e87da9f..58bc2b828dcd 100644
---
a/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c
+++
b/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c
@@ -21,6 +21,8 @@
#include
#include
+#include
+
EFI_STATUS
EFIAPI
PlatformPeim (
@@ -30,6 +32,14 @@ PlatformPeim (
VOID *Base;
VOID *NewBase;
UINTN FdtSize;
+ UINT64 *UartHobData;
+ INT32 Node, Prev;
+ CONST CHAR8*Compatible;
+ CONST CHAR8*CompItem;
+ INT32 Len;
+ CONST UINT64 *RegProp;
+ UINT64 UartBase;
+
Base = (VOID*)(UINTN)FixedPcdGet64 (PcdDeviceTreeInitialBaseAddress);
ASSERT (fdt_ch
[Xen-devel] [PATCH v4 00/29] Xen/ARM guest support
This series implements support for executing Tianocore inside a Xen guest domain on 64-bit ARM systems (AArch64) The first part addresses ARM platform specifics, primarily to allow a Tianocore binary image to be runtime relocatable, and execute from DRAM. The second part refactors the XenBus support, and adds some missing device drivers that are needed to execute on ARM: a Xen PV console and a real time clock driver. Finally, patch #29 wraps it all together and implements the .dsc and .fdf platform descriptions that can be used to build the binary image. NOTES: - the Xen RTC driver is a dummy implementation, as it is a Runtime driver which is callable through Runtime Services from the OS, and this is currently not supportable under Xen, due to the need to share the shared info page between the OS and the firmware - UEFI maps the entire physical memory space as cached, and relies on Xen to use the correct stage2 mappings for regions that are backed by devices, such as the GIC or device passthrough. The reason is that the I/O console ring and grant table are backed by RAM that Xen maps as cached, which means that UEFI *must* map those as cached as well. Instead of discovering those regions early on (i.e., before enabling the MMU) it is much easier to rely on the architecturally mandated behavior that stage2 device mappings supersede stage1 cached mappings for the same region. - this code is not yet tested on x86 (still only build tested for v4) Changes since v3: - rebased onto Olivier's pending GICv3 patches - moved InterlockedCompareExchange16 () to BaseSynchronizationLib - reimplemented XenBusDxe's TestAndClearBit () using InterlockedCompareExchange16 () so that XenBusDxe itself is now completely architecture agnostic - various minor style and comment changes based on review feedback from Laszlo and Olivier - added acks and R-b's Changes since v2: - rebased onto latest upstream containing Laszlo's ARM generic timer changes, with Olivier's pending GICv3 patches applied on top; - moved the relocatable PrePi to a completely separate module, and dropped patches changing the original ARM PrePi code: all required changes have been incorporated directly into the split off version - dropped the ARM BDS entirely, only Intel BDS supported as of now - added a constructor to XenConsoleSerialPortLib, otherwise there is no output from the release build; - implemented all review comments regarding style and correctness, including cleaning up the DSC in the final patch - added acks and R-b's Changes since v1: - move to PatchableInModule PCDs for the runtime self-relocating PrePi: this is semantically more correct, and will make the build system help us spot if there are remaining instances of FixedPcdGetXX() which need attention - split some prepi and xen patches to make it easier on the reviewers - split off the PCI support from XenBusDxe instead of the frankenstein DXE from v1 - implemented review comments regarding moving of files, splitting of libraries and some EDK2 optimizations suggested by Laszlo (casting, use of specific types etc) - added some acks and R-b's Ard Biesheuvel (29): ArmPkg: allow HYP timer interrupt to be omitted ArmPkg: allow patchable PCDs for memory, FD and FV addresses ArmPlatformPkg: allow patchable PCD for FD base address ArmVirtualizationPkg: add GICv3 detection to VirtFdtDxe ArmVirtualizationPkg: allow patchable PCD for device tree base address ArmVirtualizationPkg: move early UART discovery to PlatformPeim ArmVirtualizationPkg: use a HOB to store device tree blob ArmVirtualizationPkg: add padding to FDT allocation ArmVirtualizationPkg: add a relocatable version of PrePi ArmVirtualizationPkg: implement custom MemoryInitPeiLib ArmVirtualizationPkg: allow patchable PCD for FV and DT base addresses ArmVirtualizationPkg: Xen/PV relocatable platformlib instance MdePkg/BaseSynchronizationLib: Added proper support for ARM architecture MdePkg/BaseSynchronizationLib: implement 16-bit compare-exchange Ovmf/Xen: move Xen interface version to Ovmf/Xen: fix pointer to int cast in XenBusDxe Ovmf/Xen: refactor XenBusDxe hypercall implementation Ovmf/Xen: move XenBusDxe hypercall code to separate library Ovmf/Xen: introduce XENIO_PROTOCOL Ovmf/Xen: add separate driver for Xen PCI device Ovmf/Xen: move XenBusDxe to abstract XENIO_PROTOCOL Ovmf/Xen: implement XenHypercallLib for ARM Ovmf/Xen: port XenBusDxe to other architectures Ovmf/Xen: add Xen PV console SerialPortLib driver ArmVirtualizationPkg: implement dummy RealTimeClockLib for Xen Ovfm/Xen: add a Vendor Hardware device path GUID for the XenBus root ArmVirtualizationPkg: add XenIoMmioLib ArmVirtualizationPkg/VirtFdtDxe: wire up XenBusDxe to "xen,xen" DT node ArmVirtualizationPkg: add platform description for Xen guests ArmPkg/ArmPkg.dec
[Xen-devel] [PATCH v4 04/29] ArmVirtualizationPkg: add GICv3 detection to VirtFdtDxe
This adds support for detecting the presence of a GICv3 interrupt
controller from the device tree, and recording its distributor and
redistributor base addresses in their respective PCDs.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Olivier Martin
Acked-by: Laszlo Ersek
Signed-off-by: Ard Biesheuvel
---
ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc | 1 +
ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c | 34
+-
ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf | 1 +
3 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc
b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc
index 32c8deb3b1d6..066108f66d28 100644
--- a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc
+++ b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc
@@ -172,6 +172,7 @@
# ARM General Interrupt Controller
#
gArmTokenSpaceGuid.PcdGicDistributorBase|0x0
+ gArmTokenSpaceGuid.PcdGicRedistributorsBase|0x0
gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase|0x0
## PL031 RealTimeClock
diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
index 1d44f9ba02b3..a12bd8686fcc 100644
--- a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
+++ b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
@@ -46,6 +46,7 @@ typedef enum {
PropertyTypeTimer,
PropertyTypePsci,
PropertyTypeFwCfg,
+ PropertyTypeGicV3,
} PROPERTY_TYPE;
typedef struct {
@@ -62,6 +63,7 @@ STATIC CONST PROPERTY CompatibleProperties[] = {
{ PropertyTypeTimer, "arm,armv8-timer" },
{ PropertyTypePsci,"arm,psci-0.2"},
{ PropertyTypeFwCfg, "qemu,fw-cfg-mmio"},
+ { PropertyTypeGicV3, "arm,gic-v3" },
{ PropertyTypeUnknown, ""}
};
@@ -114,7 +116,7 @@ InitializeVirtFdtDxe (
VIRTIO_TRANSPORT_DEVICE_PATH *DevicePath;
EFI_HANDLE Handle;
UINT64 RegBase;
- UINT64 DistBase, CpuBase;
+ UINT64 DistBase, CpuBase, RedistBase;
CONST INTERRUPT_PROPERTY *InterruptProp;
INT32 SecIntrNum, IntrNum, VirtIntrNum, HypIntrNum;
CONST CHAR8*PsciMethod;
@@ -256,6 +258,36 @@ InitializeVirtFdtDxe (
DEBUG ((EFI_D_INFO, "Found GIC @ 0x%Lx/0x%Lx\n", DistBase, CpuBase));
break;
+case PropertyTypeGicV3:
+ //
+ // The GIC v3 DT binding describes a series of at least 3 physical (base
+ // addresses, size) pairs: the distributor interface (GICD), at least one
+ // redistributor region (GICR) containing dedicated redistributor
+ // interfaces for all individual CPUs, and the CPU interface (GICC).
+ // Under virtualization, we assume that the first redistributor region
+ // listed covers the boot CPU. Also, our GICv3 driver only supports the
+ // system register CPU interface, so we can safely ignore the MMIO
version
+ // which is listed after the sequence of redistributor interfaces.
+ // This means we are only interested in the first two memory regions
+ // supplied, and ignore everything else.
+ //
+ ASSERT (Len >= 32);
+
+ // RegProp[0..1] == { GICD base, GICD size }
+ DistBase = fdt64_to_cpu (((UINT64 *)RegProp)[0]);
+ ASSERT (DistBase < MAX_UINT32);
+
+ // RegProp[2..3] == { GICR base, GICR size }
+ RedistBase = fdt64_to_cpu (((UINT64 *)RegProp)[2]);
+ ASSERT (RedistBase < MAX_UINT32);
+
+ PcdSet32 (PcdGicDistributorBase, (UINT32)DistBase);
+ PcdSet32 (PcdGicRedistributorsBase, (UINT32)RedistBase);
+
+ DEBUG ((EFI_D_INFO, "Found GIC v3 (re)distributor @ 0x%Lx (0x%Lx)\n",
+DistBase, RedistBase));
+ break;
+
case PropertyTypeRtc:
ASSERT (Len == 16);
diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf
b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf
index 514ce2fdf658..1ed02b6f3750 100644
--- a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf
+++ b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf
@@ -51,6 +51,7 @@
gArmVirtualizationTokenSpaceGuid.PcdFwCfgSelectorAddress
gArmVirtualizationTokenSpaceGuid.PcdFwCfgDataAddress
gArmTokenSpaceGuid.PcdGicDistributorBase
+ gArmTokenSpaceGuid.PcdGicRedistributorsBase
gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase
gArmTokenSpaceGuid.PcdArmArchTimerSecIntrNum
gArmTokenSpaceGuid.PcdArmArchTimerIntrNum
--
1.8.3.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 05/29] ArmVirtualizationPkg: allow patchable PCD for device tree base address
To allow a runtime self relocating PrePi instance to discover the base
address of the device tree at runtime, allow the use of a patchable PCD
for gArmVirtualizationTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress.
We will not be using the build time patch tool in this case, but using
a patchable PCD will make the build system aware that its value is not
a compile time constant.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Olivier Martin
Reviewed-by: Laszlo Ersek
Signed-off-by: Ard Biesheuvel
---
ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec
| 2 +-
ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec
b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec
index 99411548aff6..d83117fc6abe 100644
--- a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec
+++ b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec
@@ -34,7 +34,7 @@
gArmVirtualizationTokenSpaceGuid = { 0x0B6F5CA7, 0x4F53, 0x445A, { 0xB7,
0x6E, 0x2E, 0x36, 0x5B, 0x80, 0x63, 0x66 } }
gEarlyPL011BaseAddressGuid = { 0xB199DEA9, 0xFD5C, 0x4A84, { 0x80,
0x82, 0x2F, 0x41, 0x70, 0x78, 0x03, 0x05 } }
-[PcdsFixedAtBuild]
+[PcdsFixedAtBuild, PcdsPatchableInModule]
#
# This is the physical address where the device tree is expected to be stored
# upon first entry into UEFI. This needs to be a FixedAtBuild PCD, so that we
diff --git
a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
index aa4ced4582e8..3e3074af72f1 100644
---
a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
+++
b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
@@ -96,7 +96,7 @@ ArmPlatformInitializeSystemMemory (
ASSERT (HobData != NULL);
*HobData = 0;
- DeviceTreeBase = (VOID *)(UINTN)FixedPcdGet64
(PcdDeviceTreeInitialBaseAddress);
+ DeviceTreeBase = (VOID *)(UINTN)PcdGet64 (PcdDeviceTreeInitialBaseAddress);
ASSERT (DeviceTreeBase != NULL);
//
--
1.8.3.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 08/29] ArmVirtualizationPkg: add padding to FDT allocation
Our primary user QEMU/mach-virt presents us with a FDT blob padded to 64 KB with plenty of room to set additional properties. However, in the general case, we should only add properties after making sure there is enough room available. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Laszlo Ersek Reviewed-by: Olivier Martin Signed-off-by: Ard Biesheuvel --- ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec | 6 ++ ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c | 8 +--- ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.inf | 1 + 3 files changed, 12 insertions(+), 3 deletions(-) diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec index 868488906643..4ebfcddfa595 100644 --- a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec +++ b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec @@ -43,6 +43,12 @@ # gArmVirtualizationTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress|0x0|UINT64|0x0001 + # + # Padding in bytes to add to the device tree allocation, so that the DTB can + # be modified in place (default: 256 bytes) + # + gArmVirtualizationTokenSpaceGuid.PcdDeviceTreeAllocationPadding|256|UINT32|0x0002 + [PcdsDynamic, PcdsFixedAtBuild] # # ARM PSCI function invocations can be done either through hypervisor diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c b/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c index c500d5964b25..bdf2b57fcb1e 100644 --- a/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c +++ b/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c @@ -33,6 +33,7 @@ PlatformPeim ( VOID *Base; VOID *NewBase; UINTN FdtSize; + UINTN FdtPages; UINT64 *FdtHobData; UINT64 *UartHobData; INT32 Node, Prev; @@ -47,10 +48,11 @@ PlatformPeim ( ASSERT (Base != NULL); ASSERT (fdt_check_header (Base) == 0); - FdtSize = fdt_totalsize (Base); - NewBase = AllocatePages (EFI_SIZE_TO_PAGES (FdtSize)); + FdtSize = fdt_totalsize (Base) + PcdGet32 (PcdDeviceTreeAllocationPadding); + FdtPages = EFI_SIZE_TO_PAGES (FdtSize); + NewBase = AllocatePages (FdtPages); ASSERT (NewBase != NULL); - CopyMem (NewBase, Base, FdtSize); + fdt_open_into (Base, NewBase, EFI_PAGES_TO_SIZE (FdtPages)); FdtHobData = BuildGuidHob (&gFdtHobGuid, sizeof *FdtHobData); ASSERT (FdtHobData != NULL); diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.inf b/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.inf index 96019e4009ff..6675a1f91561 100644 --- a/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.inf +++ b/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.inf @@ -40,6 +40,7 @@ gArmTokenSpaceGuid.PcdFvBaseAddress gArmTokenSpaceGuid.PcdFvSize gArmVirtualizationTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress + gArmVirtualizationTokenSpaceGuid.PcdDeviceTreeAllocationPadding [Guids] gEarlyPL011BaseAddressGuid -- 1.8.3.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 02/29] ArmPkg: allow patchable PCDs for memory, FD and FV addresses
In order to allow a runtime self relocating PrePi instance, change the allowable PCD types for the following PCDs: gArmTokenSpaceGuid.PcdSystemMemoryBase gArmTokenSpaceGuid.PcdSystemMemorySize gArmTokenSpaceGuid.PcdFdBaseAddress gArmTokenSpaceGuid.PcdFvBaseAddress to include PcdsPatchableInModule. This makes the build system correctly distinguish fixed PCDs from PCDs whose value may be different from the assigned value at compile time. Note that this only affects platforms that explicitly mark these PCDs as PatchableInModule in the DSC. All existing platforms that use FixedPcd will not be affected by this change. Contributed-under: TianoCore Contribution Agreement 1.0 Acked-by: Laszlo Ersek Reviewed-by: Olivier Martin Signed-off-by: Ard Biesheuvel --- ArmPkg/ArmPkg.dec | 25 ++--- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec index ced392980102..87dbd11b867f 100644 --- a/ArmPkg/ArmPkg.dec +++ b/ArmPkg/ArmPkg.dec @@ -96,14 +96,6 @@ gArmTokenSpaceGuid.PcdSecureFvSize|0x0|UINT32|0x0030 # - # ARM Normal (or Non Secure) Firmware PCDs - # - gArmTokenSpaceGuid.PcdFdBaseAddress|0|UINT64|0x002B - gArmTokenSpaceGuid.PcdFdSize|0|UINT32|0x002C - gArmTokenSpaceGuid.PcdFvBaseAddress|0|UINT64|0x002D - gArmTokenSpaceGuid.PcdFvSize|0|UINT32|0x002E - - # # ARM Hypervisor Firmware PCDs # gArmTokenSpaceGuid.PcdHypFdBaseAddress|0|UINT32|0x003A @@ -130,6 +122,15 @@ # Maximum file size for TFTP servers that do not support 'tsize' extension gArmTokenSpaceGuid.PcdMaxTftpFileSize|0x0100|UINT32|0x + # + # ARM Normal (or Non Secure) Firmware PCDs + # + gArmTokenSpaceGuid.PcdFdSize|0|UINT32|0x002C + gArmTokenSpaceGuid.PcdFvSize|0|UINT32|0x002E + +[PcdsFixedAtBuild.common, PcdsPatchableInModule.common] + gArmTokenSpaceGuid.PcdFdBaseAddress|0|UINT64|0x002B + gArmTokenSpaceGuid.PcdFvBaseAddress|0|UINT64|0x002D [PcdsFixedAtBuild.ARM] # @@ -210,16 +211,18 @@ # -# These PCDs are also defined as 'PcdsDynamic' to be redefined when using UEFI in a -# context of virtual machine. +# These PCDs are also defined as 'PcdsDynamic' or 'PcdsPatchableInModule' to be +# redefined when using UEFI in a context of virtual machine. # -[PcdsFixedAtBuild.common, PcdsDynamic.common] +[PcdsFixedAtBuild.common, PcdsDynamic.common, PcdsPatchableInModule.common] + # System Memory (DRAM): These PCDs define the region of in-built system memory # Some platforms can get DRAM extensions, these additional regions will be declared # to UEFI by ArmPlatformLib gArmTokenSpaceGuid.PcdSystemMemoryBase|0|UINT64|0x0029 gArmTokenSpaceGuid.PcdSystemMemorySize|0|UINT64|0x002A +[PcdsFixedAtBuild.common, PcdsDynamic.common] # # ARM Architectural Timer # -- 1.8.3.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 12/29] ArmVirtualizationPkg: Xen/PV relocatable platformlib instance
Add a ArmPlatformLib instance that can deal with the self relocation
and truly dynamic discovery of system RAM base and size.
Contributed-under: TianoCore Contribution Agreement 1.0
Acked-by: Laszlo Ersek
Reviewed-by: Olivier Martin
Signed-off-by: Ard Biesheuvel
---
ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmXenRelocatablePlatformLib/AARCH64/MemnodeParser.S
| 237
++
ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmXenRelocatablePlatformLib/AARCH64/RelocatableVirtHelper.S
| 167 ++
ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmXenRelocatablePlatformLib/ArmXenRelocatablePlatformLib.inf
| 59 +
ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmXenRelocatablePlatformLib/RelocatableVirt.c
| 71
ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmXenRelocatablePlatformLib/XenVirtMem.c
| 83 +++
5 files changed, 617 insertions(+)
diff --git
a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmXenRelocatablePlatformLib/AARCH64/MemnodeParser.S
b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmXenRelocatablePlatformLib/AARCH64/MemnodeParser.S
new file mode 100644
index ..f919b63710f0
--- /dev/null
+++
b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmXenRelocatablePlatformLib/AARCH64/MemnodeParser.S
@@ -0,0 +1,237 @@
+/*
+ * Copyright (c) 2014, Linaro Ltd. 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.
+ */
+
+/*
+ * Theory of operation
+ * ---
+ *
+ * This code parses a Flattened Device Tree binary (DTB) to find the base of
+ * system RAM. It is written in assembly so that it can be executed before a
+ * stack has been set up.
+ *
+ * To find the base of system RAM, we have to traverse the FDT to find a memory
+ * node. In the context of this implementation, the first node that has a
+ * device_type property with the value 'memory' and a 'reg' property is
+ * acceptable, and the name of the node (memory[@xxx]) is ignored, as are any
+ * other nodes that match the above constraints.
+ *
+ * In pseudo code, this implementation does the following:
+ *
+ * for each node {
+ * have_device_type = false
+ * have_reg = false
+ *
+ * for each property {
+ * if property value == 'memory' {
+ * if property name == 'device_type' {
+ * have_device_type = true
+ * }
+ * } else {
+ * if property name == 'reg' {
+ * have_reg = true
+ * membase = property value[0]
+ * memsize = property value[1]
+ * }
+ * }
+ * }
+ * if have_device_type and have_reg {
+ * return membase and memsize
+ * }
+ * }
+ * return NOT_FOUND
+ */
+
+#define FDT_MAGIC 0xedfe0dd0
+
+#define FDT_BEGIN_NODE 0x1
+#define FDT_END_NODE 0x2
+#define FDT_PROP 0x3
+#define FDT_END0x9
+
+ xMEMSIZE.reqx0 // recorded system RAM size
+ xMEMBASE.reqx1 // recorded system RAM base
+
+ xLR .reqx8 // our preserved link register
+ xDTP.reqx9 // pointer to traverse the DT structure
+ xSTRTAB .reqx10 // pointer to the DTB string table
+ xMEMNODE.reqx11 // bit field to record found properties
+
+#define HAVE_REG 0x1
+#define HAVE_DEVICE_TYPE 0x2
+
+ .text
+ .align 3
+_memory:
+ .asciz "memory"
+_reg:
+ .asciz "reg"
+_device_type:
+ .asciz "device_type"
+
+ /*
+* Compare strings in x4 and x5, return in w7
+*/
+ .align 3
+strcmp:
+ ldrbw2, [x4], #1
+ ldrbw3, [x5], #1
+ subsw7, w2, w3
+ cbz w2, 0f
+ cbz w3, 0f
+ beq strcmp
+0: ret
+
+ .globl find_memnode
+find_memnode:
+ // preserve link register
+ mov xLR, x30
+ mov xDTP, x0
+
+ /*
+* Check the DTB magic at offset 0
+*/
+ movzw4, #:abs_g0_nc:FDT_MAGIC
+ movkw4, #:abs_g1:FDT_MAGIC
+ ldr w5, [xDTP]
+ cmp w4, w5
+ bne err_invalid_magic
+
+ /*
+* Read the string offset and store it for later use
+*/
+ ldr w4, [xDTP, #12]
+ rev w4
[Xen-devel] [PATCH v4 03/29] ArmPlatformPkg: allow patchable PCD for FD base address
This moves the reference to gArmTokenSpaceGuid.PcdFdBaseAddress from the [FixedPcd] to the [Pcd] section in the INF file of PrePiArmPlatformGlobalVariableLib so that its users may choose to use a patchable PCD instead. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Olivier Martin Signed-off-by: Ard Biesheuvel --- ArmPlatformPkg/Library/ArmPlatformGlobalVariableLib/PrePi/PrePiArmPlatformGlobalVariableLib.inf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ArmPlatformPkg/Library/ArmPlatformGlobalVariableLib/PrePi/PrePiArmPlatformGlobalVariableLib.inf b/ArmPlatformPkg/Library/ArmPlatformGlobalVariableLib/PrePi/PrePiArmPlatformGlobalVariableLib.inf index 596f5595412e..37de35e7d00e 100644 --- a/ArmPlatformPkg/Library/ArmPlatformGlobalVariableLib/PrePi/PrePiArmPlatformGlobalVariableLib.inf +++ b/ArmPlatformPkg/Library/ArmPlatformGlobalVariableLib/PrePi/PrePiArmPlatformGlobalVariableLib.inf @@ -34,7 +34,6 @@ PcdLib [FixedPcd] - gArmTokenSpaceGuid.PcdFdBaseAddress gArmTokenSpaceGuid.PcdFdSize gArmPlatformTokenSpaceGuid.PcdCPUCorePrimaryStackSize @@ -43,4 +42,5 @@ [Pcd] gArmTokenSpaceGuid.PcdSystemMemoryBase gArmTokenSpaceGuid.PcdSystemMemorySize + gArmTokenSpaceGuid.PcdFdBaseAddress -- 1.8.3.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 01/29] ArmPkg: allow HYP timer interrupt to be omitted
The DT binding for the ARM generic timer describes the secure,
non-secure, virtual and hypervisor timer interrupts, respectively.
However, under virtualization, only the virtual timer is usable, and
the device tree may omit the hypervisor timer interrupt. (Other timer
interrupts cannot be omitted simply due to the fact that the virtual
timer is listed third)
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Olivier Martin
Reviewed-by: Laszlo Ersek
Signed-off-by: Ard Biesheuvel
---
ArmPkg/Drivers/TimerDxe/TimerDxe.c | 14 +++---
ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c | 6 +++---
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/ArmPkg/Drivers/TimerDxe/TimerDxe.c
b/ArmPkg/Drivers/TimerDxe/TimerDxe.c
index d0a819fc2729..1169d426b255 100644
--- a/ArmPkg/Drivers/TimerDxe/TimerDxe.c
+++ b/ArmPkg/Drivers/TimerDxe/TimerDxe.c
@@ -369,7 +369,8 @@ TimerInitialize (
{
EFI_HANDLE Handle = NULL;
EFI_STATUS Status;
- UINTN TimerCtrlReg;
+ UINTN TimerCtrlReg;
+ UINT32 TimerHypIntrNum;
if (ArmIsArchTimerImplemented () == 0) {
DEBUG ((EFI_D_ERROR, "ARM Architectural Timer is not available in the CPU,
hence cann't use this Driver \n"));
@@ -395,8 +396,15 @@ TimerInitialize (
Status = gInterrupt->RegisterInterruptSource (gInterrupt, PcdGet32
(PcdArmArchTimerVirtIntrNum), TimerInterruptHandler);
ASSERT_EFI_ERROR (Status);
- Status = gInterrupt->RegisterInterruptSource (gInterrupt, PcdGet32
(PcdArmArchTimerHypIntrNum), TimerInterruptHandler);
- ASSERT_EFI_ERROR (Status);
+ //
+ // The hypervisor timer interrupt may be omitted by implementations that
+ // execute under virtualization.
+ //
+ TimerHypIntrNum = PcdGet32 (PcdArmArchTimerHypIntrNum);
+ if (TimerHypIntrNum != 0) {
+Status = gInterrupt->RegisterInterruptSource (gInterrupt, TimerHypIntrNum,
TimerInterruptHandler);
+ASSERT_EFI_ERROR (Status);
+ }
Status = gInterrupt->RegisterInterruptSource (gInterrupt, PcdGet32
(PcdArmArchTimerSecIntrNum), TimerInterruptHandler);
ASSERT_EFI_ERROR (Status);
diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
index 751864d4db9c..1d44f9ba02b3 100644
--- a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
+++ b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
@@ -274,7 +274,7 @@ InitializeVirtFdtDxe (
// hypervisor timers, in that order.
//
InterruptProp = fdt_getprop (DeviceTreeBase, Node, "interrupts", &Len);
- ASSERT (Len == 48);
+ ASSERT (Len == 36 || Len == 48);
SecIntrNum = fdt32_to_cpu (InterruptProp[0].Number)
+ (InterruptProp[0].Type ? 16 : 0);
@@ -282,8 +282,8 @@ InitializeVirtFdtDxe (
+ (InterruptProp[1].Type ? 16 : 0);
VirtIntrNum = fdt32_to_cpu (InterruptProp[2].Number)
+ (InterruptProp[2].Type ? 16 : 0);
- HypIntrNum = fdt32_to_cpu (InterruptProp[3].Number)
- + (InterruptProp[3].Type ? 16 : 0);
+ HypIntrNum = Len < 48 ? 0 : fdt32_to_cpu (InterruptProp[3].Number)
+ + (InterruptProp[3].Type ? 16 : 0);
DEBUG ((EFI_D_INFO, "Found Timer interrupts %d, %d, %d, %d\n",
SecIntrNum, IntrNum, VirtIntrNum, HypIntrNum));
--
1.8.3.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 09/29] ArmVirtualizationPkg: add a relocatable version of PrePi
This patch introduces a relocatable PrePi, which can execute
from arbitrary offsets in RAM. This is intendend to be run
from a boot loader which passes a description of the actual
platform in a device tree, for instance.
This module is based on the PrePi implementations residing under
ArmPlatformPkg.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Olivier Martin
Signed-off-by: Ard Biesheuvel
---
ArmPlatformPkg/ArmVirtualizationPkg/PrePi/AArch64/ArchPrePi.c|
33
ArmPlatformPkg/ArmVirtualizationPkg/PrePi/AArch64/ModuleEntryPoint.S |
180
ArmPlatformPkg/ArmVirtualizationPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf |
108 +++
ArmPlatformPkg/ArmVirtualizationPkg/PrePi/LzmaDecompress.h |
103
ArmPlatformPkg/ArmVirtualizationPkg/PrePi/PrePi.c|
203
+++
ArmPlatformPkg/ArmVirtualizationPkg/PrePi/PrePi.h|
77
ArmPlatformPkg/ArmVirtualizationPkg/PrePi/Scripts/PrePi-PIE.lds |
42
7 files changed, 746 insertions(+)
diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/PrePi/AArch64/ArchPrePi.c
b/ArmPlatformPkg/ArmVirtualizationPkg/PrePi/AArch64/ArchPrePi.c
new file mode 100644
index ..217986107e44
--- /dev/null
+++ b/ArmPlatformPkg/ArmVirtualizationPkg/PrePi/AArch64/ArchPrePi.c
@@ -0,0 +1,33 @@
+/** @file
+*
+* Copyright (c) 2011-2013, ARM Limited. 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.
+*
+**/
+
+#include "PrePi.h"
+
+#include
+
+VOID
+ArchInitialize (
+ VOID
+ )
+{
+ // Enable Floating Point
+ if (FixedPcdGet32 (PcdVFPEnabled)) {
+ArmEnableVFP ();
+ }
+
+ if (ArmReadCurrentEL () == AARCH64_EL2) {
+// Trap General Exceptions. All exceptions that would be routed to EL1 are
routed to EL2
+ArmWriteHcr (ARM_HCR_TGE);
+ }
+}
diff --git
a/ArmPlatformPkg/ArmVirtualizationPkg/PrePi/AArch64/ModuleEntryPoint.S
b/ArmPlatformPkg/ArmVirtualizationPkg/PrePi/AArch64/ModuleEntryPoint.S
new file mode 100644
index ..568d0086d662
--- /dev/null
+++ b/ArmPlatformPkg/ArmVirtualizationPkg/PrePi/AArch64/ModuleEntryPoint.S
@@ -0,0 +1,180 @@
+//
+// Copyright (c) 2011-2013, ARM Limited. All rights reserved.
+// Copyright (c) 2015, Linaro Limited. 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.
+//
+//
+
+#include
+#include
+#include
+#include
+
+.text
+.align 3
+
+GCC_ASM_IMPORT(ArmPlatformIsPrimaryCore)
+GCC_ASM_IMPORT(ArmReadMpidr)
+GCC_ASM_IMPORT(ArmPlatformPeiBootAction)
+GCC_ASM_IMPORT(ArmPlatformStackSet)
+GCC_ASM_EXPORT(_ModuleEntryPoint)
+
+StartupAddr:.8byte ASM_PFX(CEntryPoint)
+
+ASM_PFX(_ModuleEntryPoint):
+ //
+ // We are built as a ET_DYN PIE executable, so we need to process all
+ // relative relocations regardless of whether or not we are executing from
+ // the same offset we were linked at. This is only possible if we are
+ // running from RAM.
+ //
+ adr x8, __reloc_base
+ adr x9, __reloc_start
+ adr x10, __reloc_end
+
+.Lreloc_loop:
+ cmp x9, x10
+ bhs .Lreloc_done
+
+ //
+ // AArch64 uses the ELF64 RELA format, which means each entry in the
+ // relocation table consists of
+ //
+ // UINT64 offset : the relative offset of the value that needs to
+ //be relocated
+ // UINT64 info: relocation type and symbol index (the latter is
+ //not used for R_AARCH64_RELATIVE relocations)
+ // UINT64 addend : value to be added to the value being relocated
+ //
+ ldp x11, x12, [x9], #24 // read offset into x11 and info into x12
+ cmp x12, #0x403 // check info == R_AARCH64_RELATIVE?
+ bne .Lreloc_loop // not a relative relocation? then skip
+
+ ldr x12, [x9, #-8]// read addend into x12
+ add x12, x12, x8
[Xen-devel] [PATCH v4 13/29] MdePkg/BaseSynchronizationLib: Added proper support for ARM architecture
This implements the following synchronization primitives for AArch64 (GCC) and ARM (GCC & RVCT): InternalSyncCompareExchange32 InternalSyncCompareExchange64 InternalSyncIncrement InternalSyncDecrement Note: these functions are implemented using the exclusive monitor, which implies that they can only be used after the caches (and hence the MMU) have been enabled. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin Signed-off-by: Ard Biesheuvel --- MdePkg/Library/BaseSynchronizationLib/AArch64/Synchronization.S | 159 + MdePkg/Library/BaseSynchronizationLib/AArch64/Synchronization.c | 115 - MdePkg/Library/BaseSynchronizationLib/Arm/Synchronization.S | 167 ++ MdePkg/Library/BaseSynchronizationLib/Arm/Synchronization.asm| 168 +++ MdePkg/Library/BaseSynchronizationLib/Arm/Synchronization.c | 115 - MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf | 5 ++-- 6 files changed, 497 insertions(+), 232 deletions(-) diff --git a/MdePkg/Library/BaseSynchronizationLib/AArch64/Synchronization.S b/MdePkg/Library/BaseSynchronizationLib/AArch64/Synchronization.S new file mode 100644 index ..601b00495f26 --- /dev/null +++ b/MdePkg/Library/BaseSynchronizationLib/AArch64/Synchronization.S @@ -0,0 +1,159 @@ +// Implementation of synchronization functions for ARM architecture (AArch64) +// +// Copyright (c) 2012-2015, ARM Limited. All rights reserved. +// Copyright (c) 2015, Linaro Limited. 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. +// +// + +.text +.align 3 + +GCC_ASM_EXPORT(InternalSyncCompareExchange32) +GCC_ASM_EXPORT(InternalSyncCompareExchange64) +GCC_ASM_EXPORT(InternalSyncIncrement) +GCC_ASM_EXPORT(InternalSyncDecrement) + +/** + Performs an atomic compare exchange operation on a 32-bit unsigned integer. + + Performs an atomic compare exchange operation on the 32-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. + + @param Value A pointer to the 32-bit value for the compare exchange +operation. + @param CompareValue 32-bit value used in compare operation. + @param ExchangeValue 32-bit value used in exchange operation. + + @return The original *Value before exchange. + +**/ +//UINT32 +//EFIAPI +//InternalSyncCompareExchange32 ( +// IN volatile UINT32 *Value, +// IN UINT32CompareValue, +// IN UINT32ExchangeValue +// ) +ASM_PFX(InternalSyncCompareExchange32): + dmb sy + +InternalSyncCompareExchange32Again: + ldxrw3, [x0] + cmp w3, w1 + bne InternalSyncCompareExchange32Fail + +InternalSyncCompareExchange32Exchange: + stxrw4, w2, [x0] + cbnzw4, InternalSyncCompareExchange32Again + +InternalSyncCompareExchange32Fail: + dmb sy + mov w0, w3 + ret + +/** + Performs an atomic compare exchange operation on a 64-bit unsigned integer. + + Performs an atomic compare exchange operation on the 64-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. + + @param Value A pointer to the 64-bit value for the compare exchange +operation. + @param CompareValue 64-bit value used in compare operation. + @param ExchangeValue 64-bit value used in exchange operation. + + @return The original *Value before exchange. + +**/ +//UINT64 +//EFIAPI +//InternalSyncCompareExchange64 ( +// IN volatile UINT64 *Value, +// IN UINT64CompareValue, +// IN UINT64ExchangeValue +// ) +ASM_PFX(InternalSyncCompareExchange64): + dmb sy + +InternalSyncCompareExchange64Again: +
[Xen-devel] [PATCH v4 10/29] ArmVirtualizationPkg: implement custom MemoryInitPeiLib
This implements a MemoryInitPeiLib instance that differs from the
stock ArmPlatformPkg version only in the fact that it does not remove
the memory used by the flash device (FD). The reason is that, when using
PrePi, the DXE core is started immediately and never returns so there is
no reason to preserve any of the memory that the flash device occupied
originally, and it is preferable to release is so that the OS loader
can reuse it. This is especially important for the relocatable PrePi
configuration, which is aimed at being launched from a boot loader that
itself adheres to the Linux arm64 boot protocol.
Contributed-under: TianoCore Contribution Agreement 1.0
Acked-by: Laszlo Ersek
Reviewed-By: Olivier Martin
Signed-off-by: Ard Biesheuvel
---
ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationMemoryInitPeiLib/ArmVirtualizationMemoryInitPeiLib.c
| 91 +++
.../ArmVirtualizationPkg/Library/ArmVirtualizationMemoryInitPeiLib/ArmVirtualizationMemoryInitPeiLib.inf
| 66 +++
2 files changed, 157 insertions(+)
diff --git
a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationMemoryInitPeiLib/ArmVirtualizationMemoryInitPeiLib.c
b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationMemoryInitPeiLib/ArmVirtualizationMemoryInitPeiLib.c
new file mode 100644
index ..5f6cd059c47f
--- /dev/null
+++
b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationMemoryInitPeiLib/ArmVirtualizationMemoryInitPeiLib.c
@@ -0,0 +1,91 @@
+/** @file
+*
+* Copyright (c) 2011-2014, ARM Limited. All rights reserved.
+* Copyright (c) 2014, Linaro Limited. 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.
+*
+**/
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+VOID
+BuildMemoryTypeInformationHob (
+ VOID
+ );
+
+VOID
+InitMmu (
+ VOID
+ )
+{
+ ARM_MEMORY_REGION_DESCRIPTOR *MemoryTable;
+ VOID *TranslationTableBase;
+ UINTN TranslationTableSize;
+ RETURN_STATUS Status;
+
+ // Get Virtual Memory Map from the Platform Library
+ ArmPlatformGetVirtualMemoryMap (&MemoryTable);
+
+ //Note: Because we called PeiServicesInstallPeiMemory() before to call
InitMmu() the MMU Page Table resides in
+ // DRAM (even at the top of DRAM as it is the first permanent memory
allocation)
+ Status = ArmConfigureMmu (MemoryTable, &TranslationTableBase,
&TranslationTableSize);
+ if (EFI_ERROR (Status)) {
+DEBUG ((EFI_D_ERROR, "Error: Failed to enable MMU\n"));
+ }
+}
+
+EFI_STATUS
+EFIAPI
+MemoryPeim (
+ IN EFI_PHYSICAL_ADDRESS UefiMemoryBase,
+ IN UINT64 UefiMemorySize
+ )
+{
+ EFI_RESOURCE_ATTRIBUTE_TYPE ResourceAttributes;
+
+ // Ensure PcdSystemMemorySize has been set
+ ASSERT (PcdGet64 (PcdSystemMemorySize) != 0);
+
+ //
+ // Now, the permanent memory has been installed, we can call AllocatePages()
+ //
+ ResourceAttributes = (
+ EFI_RESOURCE_ATTRIBUTE_PRESENT |
+ EFI_RESOURCE_ATTRIBUTE_INITIALIZED |
+ EFI_RESOURCE_ATTRIBUTE_UNCACHEABLE |
+ EFI_RESOURCE_ATTRIBUTE_WRITE_COMBINEABLE |
+ EFI_RESOURCE_ATTRIBUTE_WRITE_THROUGH_CACHEABLE |
+ EFI_RESOURCE_ATTRIBUTE_WRITE_BACK_CACHEABLE |
+ EFI_RESOURCE_ATTRIBUTE_TESTED
+ );
+
+ BuildResourceDescriptorHob (
+ EFI_RESOURCE_SYSTEM_MEMORY,
+ ResourceAttributes,
+ PcdGet64 (PcdSystemMemoryBase),
+ PcdGet64 (PcdSystemMemorySize)
+ );
+
+ // Build Memory Allocation Hob
+ InitMmu ();
+
+ if (FeaturePcdGet (PcdPrePiProduceMemoryTypeInformationHob)) {
+// Optional feature that helps prevent EFI memory map fragmentation.
+BuildMemoryTypeInformationHob ();
+ }
+
+ return EFI_SUCCESS;
+}
diff --git
a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationMemoryInitPeiLib/ArmVirtualizationMemoryInitPeiLib.inf
b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationMemoryInitPeiLib/ArmVirtualizationMemoryInitPeiLib.inf
new file mode 100644
index ..fcdae06de7c2
--- /dev/null
+++
b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationMemoryInitPeiLib/ArmVirtualizationMemoryInitPeiLib.inf
@@ -0,0 +1,66 @@
+#/** @file
+#
+# Copyright (c) 2011-2014, ARM Ltd. All rights reserved.
+# Copyright (c) 2014, Linaro Ltd. 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 distributio
[Xen-devel] [PATCH v4 15/29] Ovmf/Xen: move Xen interface version to
Tiancore has its private copy of the Xen headers, and all drivers that depend on it should use the same Xen interface version, so let's move the #define to xen.h itself. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Stefano Stabellini Acked-by: Laszlo Ersek Signed-off-by: Ard Biesheuvel --- OvmfPkg/Include/IndustryStandard/Xen/xen.h | 5 + OvmfPkg/XenBusDxe/XenBusDxe.h | 5 - OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h | 4 3 files changed, 5 insertions(+), 9 deletions(-) diff --git a/OvmfPkg/Include/IndustryStandard/Xen/xen.h b/OvmfPkg/Include/IndustryStandard/Xen/xen.h index 79697fcb6152..1cd7ab3ab136 100644 --- a/OvmfPkg/Include/IndustryStandard/Xen/xen.h +++ b/OvmfPkg/Include/IndustryStandard/Xen/xen.h @@ -27,6 +27,11 @@ #ifndef __XEN_PUBLIC_XEN_H__ #define __XEN_PUBLIC_XEN_H__ +// +// Xen interface version used by Tianocore +// +#define __XEN_INTERFACE_VERSION__ 0x00040400 + #include "xen-compat.h" #if defined(MDE_CPU_IA32) || defined(MDE_CPU_X64) diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.h b/OvmfPkg/XenBusDxe/XenBusDxe.h index 11640223ebf4..80253b7d1ca9 100644 --- a/OvmfPkg/XenBusDxe/XenBusDxe.h +++ b/OvmfPkg/XenBusDxe/XenBusDxe.h @@ -19,11 +19,6 @@ #include // -// Xen interface version used -// -#define __XEN_INTERFACE_VERSION__ 0x00040400 - -// // Libraries // #include diff --git a/OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h b/OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h index e5b1b5f4b90d..c0b62c4f38ca 100644 --- a/OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h +++ b/OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h @@ -18,10 +18,6 @@ #include -// -// Xen interface version used -// -#define __XEN_INTERFACE_VERSION__ 0x00040400 #define xen_mb() MemoryFence() #define xen_rmb() MemoryFence() #define xen_wmb() MemoryFence() -- 1.8.3.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 11/29] ArmVirtualizationPkg: allow patchable PCD for FV and DT base addresses
Allow the use of patchable PCDs for gArmTokenSpaceGuid.PcdFvBaseAddress and gArmVirtualizationTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress by moving them from the [FixedPcd] to the [Pcd] section in the INF file of PlatformPeiLib. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Laszlo Ersek Reviewed-by: Olivier Martin Signed-off-by: Ard Biesheuvel --- ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.inf | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.inf b/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.inf index 6675a1f91561..4fe0cbae3812 100644 --- a/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.inf +++ b/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.inf @@ -37,11 +37,13 @@ FdtLib [FixedPcd] - gArmTokenSpaceGuid.PcdFvBaseAddress gArmTokenSpaceGuid.PcdFvSize - gArmVirtualizationTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress gArmVirtualizationTokenSpaceGuid.PcdDeviceTreeAllocationPadding +[Pcd] + gArmTokenSpaceGuid.PcdFvBaseAddress + gArmVirtualizationTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress + [Guids] gEarlyPL011BaseAddressGuid gFdtHobGuid -- 1.8.3.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 16/29] Ovmf/Xen: fix pointer to int cast in XenBusDxe
On ARM, xen_pfn_t is 64 bits but the size of a pointer is only
32 bits, so casting between them needs to go via (UINTN). Also
move the xen_pfn_t cast outside the shift so that we can avoid
shifting 64-bit quantities on 32-bit architectures, which may
require runtime library support.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Stefano Stabellini
Reviewed-by: Laszlo Ersek
Signed-off-by: Ard Biesheuvel
---
OvmfPkg/XenBusDxe/GrantTable.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/OvmfPkg/XenBusDxe/GrantTable.c b/OvmfPkg/XenBusDxe/GrantTable.c
index 37d3bf786c64..8405edc51bc4 100644
--- a/OvmfPkg/XenBusDxe/GrantTable.c
+++ b/OvmfPkg/XenBusDxe/GrantTable.c
@@ -160,7 +160,7 @@ XenGrantTableInit (
Parameters.domid = DOMID_SELF;
Parameters.idx = Index;
Parameters.space = XENMAPSPACE_grant_table;
-Parameters.gpfn = (((xen_pfn_t) GrantTable) >> EFI_PAGE_SHIFT) + Index;
+Parameters.gpfn = (xen_pfn_t) ((UINTN) GrantTable >> EFI_PAGE_SHIFT) +
Index;
ReturnCode = XenHypercallMemoryOp (Dev, XENMEM_add_to_physmap,
&Parameters);
if (ReturnCode != 0) {
DEBUG ((EFI_D_ERROR, "Xen GrantTable, add_to_physmap hypercall error:
%d\n", ReturnCode));
@@ -182,7 +182,7 @@ XenGrantTableDeinit (
for (Index = NR_GRANT_FRAMES - 1; Index >= 0; Index--) {
Parameters.domid = DOMID_SELF;
-Parameters.gpfn = (((xen_pfn_t) GrantTable) >> EFI_PAGE_SHIFT) + Index;
+Parameters.gpfn = (xen_pfn_t) ((UINTN) GrantTable >> EFI_PAGE_SHIFT) +
Index;
DEBUG ((EFI_D_INFO, "Xen GrantTable, removing %X\n", Parameters.gpfn));
ReturnCode = XenHypercallMemoryOp (Dev, XENMEM_remove_from_physmap,
&Parameters);
if (ReturnCode != 0) {
--
1.8.3.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 25/29] ArmVirtualizationPkg: implement dummy RealTimeClockLib for Xen
This implements a dummy RealTimeClockLib for Xen, as there is no
guest interface to access the time kept by Xen that can be shared
between UEFI and the OS.
Contributed-under: TianoCore Contribution Agreement 1.0
Acked-by: Laszlo Ersek
Reviewed-By: Olivier Martin
Signed-off-by: Ard Biesheuvel
---
ArmPlatformPkg/ArmVirtualizationPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c
| 196
ArmPlatformPkg/ArmVirtualizationPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
| 38 +
2 files changed, 234 insertions(+)
diff --git
a/ArmPlatformPkg/ArmVirtualizationPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c
b/ArmPlatformPkg/ArmVirtualizationPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c
new file mode 100644
index ..70204ac22a92
--- /dev/null
+++
b/ArmPlatformPkg/ArmVirtualizationPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c
@@ -0,0 +1,196 @@
+/** @file
+ Implement EFI RealTimeClock runtime services via Xen shared info page
+
+ Copyright (c) 2015, Linaro Ltd. 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.
+
+**/
+
+#include
+#include
+#include
+#include
+
+/**
+ Converts Epoch seconds (elapsed since 1970 JANUARY 01, 00:00:00 UTC) to
EFI_TIME
+ **/
+STATIC
+VOID
+EpochToEfiTime (
+ IN UINTN EpochSeconds,
+ OUT EFI_TIME *Time
+ )
+{
+ UINTN a;
+ UINTN b;
+ UINTN c;
+ UINTN d;
+ UINTN g;
+ UINTN j;
+ UINTN m;
+ UINTN y;
+ UINTN da;
+ UINTN db;
+ UINTN dc;
+ UINTN dg;
+ UINTN hh;
+ UINTN mm;
+ UINTN ss;
+ UINTN J;
+
+ J = (EpochSeconds / 86400) + 2440588;
+ j = J + 32044;
+ g = j / 146097;
+ dg = j % 146097;
+ c = (((dg / 36524) + 1) * 3) / 4;
+ dc = dg - (c * 36524);
+ b = dc / 1461;
+ db = dc % 1461;
+ a = (((db / 365) + 1) * 3) / 4;
+ da = db - (a * 365);
+ y = (g * 400) + (c * 100) + (b * 4) + a;
+ m = (((da * 5) + 308) / 153) - 2;
+ d = da - (((m + 4) * 153) / 5) + 122;
+
+ Time->Year = y - 4800 + ((m + 2) / 12);
+ Time->Month = ((m + 2) % 12) + 1;
+ Time->Day = d + 1;
+
+ ss = EpochSeconds % 60;
+ a = (EpochSeconds - ss) / 60;
+ mm = a % 60;
+ b = (a - mm) / 60;
+ hh = b % 24;
+
+ Time->Hour= hh;
+ Time->Minute = mm;
+ Time->Second = ss;
+ Time->Nanosecond = 0;
+
+}
+
+/**
+ Returns the current time and date information, and the time-keeping
capabilities
+ of the hardware platform.
+
+ @param Time A pointer to storage to receive a snapshot of
the current time.
+ @param Capabilities An optional pointer to a buffer to receive the
real time clock
+device's capabilities.
+
+ @retval EFI_SUCCESS The operation completed successfully.
+ @retval EFI_INVALID_PARAMETER Time is NULL.
+ @retval EFI_DEVICE_ERROR The time could not be retrieved due to
hardware error.
+
+**/
+EFI_STATUS
+EFIAPI
+LibGetTime (
+ OUT EFI_TIME*Time,
+ OUT EFI_TIME_CAPABILITIES *Capabilities
+ )
+{
+ ASSERT (Time != NULL);
+
+ //
+ // For now, there is nothing that we can do besides returning a bogus time,
+ // as Xen's timekeeping uses a shared info page which cannot be shared
+ // between UEFI and the OS
+ //
+ EpochToEfiTime(1421770011, Time);
+
+ return EFI_SUCCESS;
+}
+
+/**
+ Sets the current local time and date information.
+
+ @param Time A pointer to the current time.
+
+ @retval EFI_SUCCESS The operation completed successfully.
+ @retval EFI_INVALID_PARAMETER A time field is out of range.
+ @retval EFI_DEVICE_ERROR The time could not be set due due to hardware
error.
+
+**/
+EFI_STATUS
+EFIAPI
+LibSetTime (
+ IN EFI_TIME*Time
+ )
+{
+ return EFI_DEVICE_ERROR;
+}
+
+
+/**
+ Returns the current wakeup alarm clock setting.
+
+ @param Enabled Indicates if the alarm is currently enabled or
disabled.
+ @param Pending Indicates if the alarm signal is pending and
requires acknowledgement.
+ @param Time The current alarm setting.
+
+ @retval EFI_SUCCESS The alarm settings were returned.
+ @retval EFI_INVALID_PARAMETER Any parameter is NULL.
+ @retval EFI_DEVICE_ERROR The wakeup time could not be retrieved due to
a hardware error.
+ @retval EFI_UNSUPPORTED A wakeup timer is not supported on this
platform.
+
+**/
+EFI_STATUS
+EFIAPI
+Lib
[Xen-devel] [PATCH v4 27/29] ArmVirtualizationPkg: add XenIoMmioLib
This adds a XenIoMmioLib declaration and implementation that can
be invoked to install the XENIO_PROTOCOL and a corresponding
grant table address on a EFI handle.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek
Signed-off-by: Ard Biesheuvel
---
OvmfPkg/Include/Library/XenIoMmioLib.h| 64
+
OvmfPkg/Library/XenIoMmioLib/XenIoMmioLib.c | 166
++
OvmfPkg/Library/XenIoMmioLib/XenIoMmioLib.inf | 39
++
OvmfPkg/OvmfPkg.dec | 4
4 files changed, 273 insertions(+)
diff --git a/OvmfPkg/Include/Library/XenIoMmioLib.h
b/OvmfPkg/Include/Library/XenIoMmioLib.h
new file mode 100644
index ..3986c72c574e
--- /dev/null
+++ b/OvmfPkg/Include/Library/XenIoMmioLib.h
@@ -0,0 +1,64 @@
+/** @file
+* Manage XenBus device path and I/O handles
+*
+* Copyright (c) 2015, Linaro Ltd. 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.
+*
+**/
+
+#ifndef _XENIO_MMIO_DEVICE_LIB_H_
+#define _XENIO_MMIO_DEVICE_LIB_H_
+
+/**
+
+ Install the XENBUS_ROOT_DEVICE_PATH and XENIO_PROTOCOL protocols on
+ the handle pointed to by @Handle, or on a new handle if it points to
+ NULL
+
+ @param HandlePointer to the handle to install the protocols
+on, may point to a NULL handle.
+
+ @param GrantTableAddress The address of the Xen grant table
+
+ @retval EFI_SUCCESS Protocols were installed successfully
+
+ @retval EFI_OUT_OF_RESOURCES The function failed to allocate memory required
+by the XenIo MMIO and device path protocols
+
+ @return Status code returned by the boot service
+InstallMultipleProtocolInterfaces ()
+
+**/
+EFI_STATUS
+XenIoMmioInstall (
+ IN OUT EFI_HANDLE *Handle,
+ IN EFI_PHYSICAL_ADDRESSGrantTableAddress
+ );
+
+
+/**
+
+ Uninstall the XENBUS_ROOT_DEVICE_PATH and XENIO_PROTOCOL protocols
+
+ @param Handle Handle onto which the protocols have been installed
+ earlier by XenIoMmioInstall ()
+
+ @retval EFI_SUCCESS Protocols were uninstalled successfully
+
+ @return Status code returned by the boot service
+ UninstallMultipleProtocolInterfaces ()
+
+**/
+EFI_STATUS
+XenIoMmioUninstall (
+ IN EFI_HANDLE Handle
+ );
+
+#endif
diff --git a/OvmfPkg/Library/XenIoMmioLib/XenIoMmioLib.c
b/OvmfPkg/Library/XenIoMmioLib/XenIoMmioLib.c
new file mode 100644
index ..c710e85865c3
--- /dev/null
+++ b/OvmfPkg/Library/XenIoMmioLib/XenIoMmioLib.c
@@ -0,0 +1,166 @@
+/** @file
+* Manage XenBus device path and I/O handles
+*
+* Copyright (c) 2015, Linaro Ltd. 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.
+*
+**/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#pragma pack (1)
+typedef struct {
+ VENDOR_DEVICE_PATH Vendor;
+ EFI_PHYSICAL_ADDRESSGrantTableAddress;
+ EFI_DEVICE_PATH_PROTOCOLEnd;
+} XENBUS_ROOT_DEVICE_PATH;
+#pragma pack ()
+
+STATIC CONST XENBUS_ROOT_DEVICE_PATH mXenBusRootDevicePathTemplate = {
+ {
+{
+ HARDWARE_DEVICE_PATH,
+ HW_VENDOR_DP,
+ { sizeof (VENDOR_DEVICE_PATH) + sizeof (EFI_PHYSICAL_ADDRESS), 0 }
+},
+XENBUS_ROOT_DEVICE_GUID,
+ },
+ 0,
+ {
+END_DEVICE_PATH_TYPE,
+END_ENTIRE_DEVICE_PATH_SUBTYPE,
+{ sizeof (EFI_DEVICE_PATH_PROTOCOL), 0 }
+ }
+};
+
+/**
+
+ Install the XENBUS_ROOT_DEVICE_PATH and XENIO_PROTOCOL protocols on
+ the handle pointed to by @Handle, or on a new handle if it points to
+ NULL
+
+ @param HandlePointer to the handle to install the protocols
+on, may point to a NULL handle.
+
+ @param GrantTableAddress The address of the Xen grant table
+
+ @retval EFI_SUCCESS Protocols were installed
[Xen-devel] [PATCH v4 26/29] Ovfm/Xen: add a Vendor Hardware device path GUID for the XenBus root
On non-PCI Xen guests (such as ARM), the XenBus root is not a PCI
device but an abstract 'platform' device. Add a dedicated Vendor
Hardware device path GUID to identify this node.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek
Signed-off-by: Ard Biesheuvel
---
OvmfPkg/Include/Guid/XenBusRootDevice.h | 24
OvmfPkg/OvmfPkg.dec | 1 +
2 files changed, 25 insertions(+)
diff --git a/OvmfPkg/Include/Guid/XenBusRootDevice.h
b/OvmfPkg/Include/Guid/XenBusRootDevice.h
new file mode 100644
index ..2b6e71018052
--- /dev/null
+++ b/OvmfPkg/Include/Guid/XenBusRootDevice.h
@@ -0,0 +1,24 @@
+/** @file
+ GUID to be used to identify the XenBus root node on non-PCI Xen guests
+
+ Copyright (C) 2015, Linaro Ltd.
+
+ This program and the accompanying materials are licensed and made available
+ under the terms and conditions of the BSD License that accompanies this
+ distribution. The full text of the license may be found at
+ http://opensource.org/licenses/bsd-license.php.
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
+ WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __XENBUS_ROOT_DEVICE_H__
+#define __XENBUS_ROOT_DEVICE_H__
+
+#define XENBUS_ROOT_DEVICE_GUID \
+{0xa732241f, 0x383d, 0x4d9c, {0x8a, 0xe1, 0x8e, 0x09, 0x83, 0x75, 0x89, 0xd7}}
+
+extern EFI_GUID gXenBusRootDeviceGuid;
+
+#endif
diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 3711fa922311..d61600225919 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -53,6 +53,7 @@
gEfiXenInfoGuid = {0xd3b46f3b, 0xd441, 0x1244, {0x9a, 0x12,
0x0, 0x12, 0x27, 0x3f, 0xc1, 0x4d}}
gOvmfPlatformConfigGuid = {0x7235c51c, 0x0c80, 0x4cab, {0x87, 0xac,
0x3b, 0x08, 0x4a, 0x63, 0x04, 0xb1}}
gVirtioMmioTransportGuid= {0x837dca9e, 0xe874, 0x4d82, {0xb2, 0x9a,
0x23, 0xfe, 0x0e, 0x23, 0xd1, 0xe2}}
+ gXenBusRootDeviceGuid = {0xa732241f, 0x383d, 0x4d9c, {0x8a, 0xe1,
0x8e, 0x09, 0x83, 0x75, 0x89, 0xd7}}
[Protocols]
gVirtioDeviceProtocolGuid = {0xfa920010, 0x6785, 0x4941, {0xb6, 0xec,
0x49, 0x8c, 0x57, 0x9f, 0x16, 0x0a}}
--
1.8.3.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 18/29] Ovmf/Xen: move XenBusDxe hypercall code to separate library
This moves all of the Xen hypercall code that was private to XenBusDxe
to a new library class XenHypercallLib. This will allow us to reimplement
it for ARM, and to export the Xen hypercall functionality to other parts
of the code, such as a Xen console SerialPortLib driver.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek
Signed-off-by: Ard Biesheuvel
---
OvmfPkg/{XenBusDxe/XenHypercall.h => Include/Library/XenHypercallLib.h} | 16
++--
OvmfPkg/{XenBusDxe => Library/XenHypercallLib}/Ia32/hypercall.nasm | 0
OvmfPkg/{XenBusDxe => Library/XenHypercallLib}/X64/hypercall.nasm | 0
OvmfPkg/{XenBusDxe => Library/XenHypercallLib}/XenHypercall.c | 48
++--
OvmfPkg/Library/XenHypercallLib/XenHypercallIntel.c | 77
+
OvmfPkg/Library/XenHypercallLib/XenHypercallLibIntel.inf| 52
OvmfPkg/OvmfPkg.dec | 4
OvmfPkg/OvmfPkgIa32.dsc | 1 +
OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
OvmfPkg/OvmfPkgX64.dsc | 1 +
OvmfPkg/XenBusDxe/EventChannel.c| 3
++-
OvmfPkg/XenBusDxe/GrantTable.c | 2 +-
OvmfPkg/XenBusDxe/XenBusDxe.c | 9
+
OvmfPkg/XenBusDxe/XenBusDxe.inf | 11
+--
OvmfPkg/XenBusDxe/XenStore.c| 2 +-
15 files changed, 146 insertions(+), 81 deletions(-)
diff --git a/OvmfPkg/XenBusDxe/XenHypercall.h
b/OvmfPkg/Include/Library/XenHypercallLib.h
similarity index 82%
rename from OvmfPkg/XenBusDxe/XenHypercall.h
rename to OvmfPkg/Include/Library/XenHypercallLib.h
index 9d49e33eb5af..7a170ff3b90e 100644
--- a/OvmfPkg/XenBusDxe/XenHypercall.h
+++ b/OvmfPkg/Include/Library/XenHypercallLib.h
@@ -13,8 +13,8 @@
**/
-#ifndef __XENBUS_DXE_HYPERCALL_H__
-#define __XENBUS_DXE_HYPERCALL_H__
+#ifndef __XEN_HYPERCALL_LIB_H__
+#define __XEN_HYPERCALL_LIB_H__
/**
This function will put the two arguments in the right place (registers) and
@@ -35,18 +35,6 @@ XenHypercall2 (
);
/**
- Get the page where all hypercall are from the XenInfo hob.
-
- @param DevA XENBUS_DEVICE instance.
-
- @retval EFI_NOT_FOUND hyperpage could not be found.
- @retval EFI_SUCCESS Successfully retrieve the hyperpage pointer.
-**/
-EFI_STATUS
-XenHyperpageInit (
- );
-
-/**
Return the value of the HVM parameter Index.
@param Index The parameter to get, e.g. HVM_PARAM_STORE_EVTCHN.
diff --git a/OvmfPkg/XenBusDxe/Ia32/hypercall.nasm
b/OvmfPkg/Library/XenHypercallLib/Ia32/hypercall.nasm
similarity index 100%
rename from OvmfPkg/XenBusDxe/Ia32/hypercall.nasm
rename to OvmfPkg/Library/XenHypercallLib/Ia32/hypercall.nasm
diff --git a/OvmfPkg/XenBusDxe/X64/hypercall.nasm
b/OvmfPkg/Library/XenHypercallLib/X64/hypercall.nasm
similarity index 100%
rename from OvmfPkg/XenBusDxe/X64/hypercall.nasm
rename to OvmfPkg/Library/XenHypercallLib/X64/hypercall.nasm
diff --git a/OvmfPkg/XenBusDxe/XenHypercall.c
b/OvmfPkg/Library/XenHypercallLib/XenHypercall.c
similarity index 60%
rename from OvmfPkg/XenBusDxe/XenHypercall.c
rename to OvmfPkg/Library/XenHypercallLib/XenHypercall.c
index 19c34bdd0cec..ecc757cf707c 100644
--- a/OvmfPkg/XenBusDxe/XenHypercall.c
+++ b/OvmfPkg/Library/XenHypercallLib/XenHypercall.c
@@ -14,43 +14,12 @@
**/
#include
-#include
-#include
-
-#include "XenBusDxe.h"
-#include "XenHypercall.h"
#include
#include
-STATIC VOID *HyperPage;
-
-//
-// Interface exposed by the ASM implementation of the core hypercall
-//
-INTN
-EFIAPI
-__XenHypercall2 (
- IN VOID *HypercallAddr,
- IN OUT INTN Arg1,
- IN OUT INTN Arg2
- );
-
-EFI_STATUS
-XenHyperpageInit (
- )
-{
- EFI_HOB_GUID_TYPE *GuidHob;
- EFI_XEN_INFO*XenInfo;
-
- GuidHob = GetFirstGuidHob (&gEfiXenInfoGuid);
- if (GuidHob == NULL) {
-return EFI_NOT_FOUND;
- }
- XenInfo = (EFI_XEN_INFO *) GET_GUID_HOB_DATA (GuidHob);
- HyperPage = XenInfo->HyperPages;
- return EFI_SUCCESS;
-}
+#include
+#include
UINT64
XenHypercallHvmGetParam (
@@ -92,16 +61,3 @@ XenHypercallEventChannelOp (
return XenHypercall2 (__HYPERVISOR_event_channel_op,
Operation, (INTN) Arguments);
}
-
-INTN
-EFIAPI
-XenHypercall2 (
- IN INTN HypercallID,
- IN OUT INTN Arg1,
- IN OUT INTN Arg2
- )
-{
- ASSERT (HyperPage != NULL);
-
- return __XenHypercall2 ((UINT8*)HyperPage + HypercallID * 32, Arg1, Arg2);
-}
diff --git a/OvmfPkg/Library/XenHypercallLib/XenHypercallIntel.c
b/OvmfPkg/Library/XenHypercallLib/XenHypercallIntel.c
[Xen-devel] [PATCH v4 23/29] Ovmf/Xen: port XenBusDxe to other architectures
This patch updates XenBusDxe to use the 16-bit compare and exchange function that was introduced for this purpose to the BaseSynchronizationLib. It also provides a new generic implementation of TestAndClearBit () using the same 16-bit compare and exchange, making this module fully architecture agnostic. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- OvmfPkg/XenBusDxe/GrantTable.c | 2 +- OvmfPkg/XenBusDxe/Ia32/InterlockedCompareExchange16.nasm | 42 -- OvmfPkg/XenBusDxe/Ia32/TestAndClearBit.nasm | 16 OvmfPkg/XenBusDxe/InterlockedCompareExchange16.c | 33 - OvmfPkg/XenBusDxe/InterlockedCompareExchange16.h | 38 -- OvmfPkg/XenBusDxe/TestAndClearBit.c | 46 ++ OvmfPkg/XenBusDxe/X64/InterlockedCompareExchange16.nasm | 41 - OvmfPkg/XenBusDxe/X64/TestAndClearBit.nasm | 15 --- OvmfPkg/XenBusDxe/XenBusDxe.h| 2 +- OvmfPkg/XenBusDxe/XenBusDxe.inf | 12 ++-- 10 files changed, 50 insertions(+), 197 deletions(-) diff --git a/OvmfPkg/XenBusDxe/GrantTable.c b/OvmfPkg/XenBusDxe/GrantTable.c index 19117fbe0373..6e47483f136f 100644 --- a/OvmfPkg/XenBusDxe/GrantTable.c +++ b/OvmfPkg/XenBusDxe/GrantTable.c @@ -35,9 +35,9 @@ #include #include +#include #include "GrantTable.h" -#include "InterlockedCompareExchange16.h" #define NR_RESERVED_ENTRIES 8 diff --git a/OvmfPkg/XenBusDxe/Ia32/InterlockedCompareExchange16.nasm b/OvmfPkg/XenBusDxe/Ia32/InterlockedCompareExchange16.nasm deleted file mode 100644 index d45582dd8109.. --- a/OvmfPkg/XenBusDxe/Ia32/InterlockedCompareExchange16.nasm +++ /dev/null @@ -1,42 +0,0 @@ -;-- -; -; 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: -; -;-- - -SECTION .text - -;-- -; UINT32 -; EFIAPI -; InternalSyncCompareExchange16 ( -; IN UINT16*Value, -; IN UINT16CompareValue, -; IN UINT16ExchangeValue -; ); -;-- -global ASM_PFX(InternalSyncCompareExchange16) -ASM_PFX(InternalSyncCompareExchange16): -mov ecx, [esp + 4] -mov eax, [esp + 8] -mov edx, [esp + 12] -lockcmpxchg [ecx], dx -ret - diff --git a/OvmfPkg/XenBusDxe/Ia32/TestAndClearBit.nasm b/OvmfPkg/XenBusDxe/Ia32/TestAndClearBit.nasm deleted file mode 100644 index d77f74ef249d.. --- a/OvmfPkg/XenBusDxe/Ia32/TestAndClearBit.nasm +++ /dev/null @@ -1,16 +0,0 @@ -SECTION .text - -; INT32 -; EFIAPI -; TestAndClearBit ( -; IN INT32 Bit, -; IN volatile VOID* Address -; ); -global ASM_PFX(TestAndClearBit) -ASM_PFX(TestAndClearBit): - mov ecx, [esp + 4] - mov edx, [esp + 8] - lock btr [edx], ecx - sbb eax, eax - ret - diff --git a/OvmfPkg/XenBusDxe/InterlockedCompareExchange16.c b/OvmfPkg/XenBusDxe/InterlockedCompareExchange16.c deleted file mode 100644 index 2b0fadd88dd1.. --- a/OvmfPkg/XenBusDxe/InterlockedCompareExchange16.c +++ /dev/null @@ -1,33 +0,0 @@ -#include -#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. - -**/ -UI
[Xen-devel] [PATCH v4 28/29] ArmVirtualizationPkg/VirtFdtDxe: wire up XenBusDxe to "xen, xen" DT node
This patchs adds support to VirtFdtDxe for the Xen DT node which
contains the base address of the Grant Table. This data is communicated
to XenBusDxe using a XENIO_PROTOCOL instance.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek
Reviewed-by: Olivier Martin
Signed-off-by: Ard Biesheuvel
---
ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualization.dsc.inc | 2 ++
ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c | 23
+++
ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf | 1 +
3 files changed, 26 insertions(+)
diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualization.dsc.inc
b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualization.dsc.inc
index f17cd2f5d876..e7a03cd13d3a 100644
--- a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualization.dsc.inc
+++ b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualization.dsc.inc
@@ -100,6 +100,8 @@
BdsLib|ArmPkg/Library/BdsLib/BdsLib.inf
FdtLib|EmbeddedPkg/Library/FdtLib/FdtLib.inf
+ XenIoMmioLib|OvmfPkg/Library/XenIoMmioLib/XenIoMmioLib.inf
+
[LibraryClasses.common.SEC]
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
ArmPlatformSecExtraActionLib|ArmPlatformPkg/Library/DebugSecExtraActionLib/DebugSecExtraActionLib.inf
diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
index 0b6414d59d46..2cc4610376b9 100644
--- a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
+++ b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -49,6 +50,7 @@ typedef enum {
PropertyTypePsci,
PropertyTypeFwCfg,
PropertyTypeGicV3,
+ PropertyTypeXen,
} PROPERTY_TYPE;
typedef struct {
@@ -66,6 +68,7 @@ STATIC CONST PROPERTY CompatibleProperties[] = {
{ PropertyTypePsci,"arm,psci-0.2"},
{ PropertyTypeFwCfg, "qemu,fw-cfg-mmio"},
{ PropertyTypeGicV3, "arm,gic-v3" },
+ { PropertyTypeXen, "xen,xen" },
{ PropertyTypeUnknown, ""}
};
@@ -345,6 +348,26 @@ InitializeVirtFdtDxe (
}
break;
+case PropertyTypeXen:
+ ASSERT (Len == 16);
+
+ //
+ // Retrieve the reg base from this node and wire it up to the
+ // MMIO flavor of the XenBus root device I/O protocol
+ //
+ RegBase = fdt64_to_cpu (((UINT64 *)RegProp)[0]);
+ Handle = NULL;
+ Status = XenIoMmioInstall (&Handle, RegBase);
+ if (EFI_ERROR (Status)) {
+DEBUG ((EFI_D_ERROR, "%a: XenIoMmioInstall () failed on a new handle "
+ "(Status == %r)\n", __FUNCTION__, Status));
+break;
+ }
+
+ DEBUG ((EFI_D_INFO, "Found Xen node with Grant table @ 0x%Lx\n",
RegBase));
+
+ break;
+
default:
break;
}
diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf
b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf
index 0774fadda21c..a7eef1b979cb 100644
--- a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf
+++ b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf
@@ -41,6 +41,7 @@
FdtLib
VirtioMmioDeviceLib
HobLib
+ XenIoMmioLib
[Guids]
gFdtTableGuid
--
1.8.3.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 22/29] Ovmf/Xen: implement XenHypercallLib for ARM
This patch adds an implementation of XenHypercallLib for both AArch64 and AArch32 execution modes on ARM systems. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Stefano Stabellini Signed-off-by: Ard Biesheuvel --- OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h| 436 + OvmfPkg/Include/IndustryStandard/Xen/xen.h | 2 +- OvmfPkg/Library/XenHypercallLib/Aarch64/Hypercall.S| 26 +++ OvmfPkg/Library/XenHypercallLib/Arm/Hypercall.S| 25 +++ OvmfPkg/Library/XenHypercallLib/XenHypercallLibArm.inf | 40 +++ 5 files changed, 528 insertions(+), 1 deletion(-) diff --git a/OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h b/OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h new file mode 100644 index ..655a221f6337 --- /dev/null +++ b/OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h @@ -0,0 +1,436 @@ +/** + * arch-arm.h + * + * Guest OS interface to ARM Xen. + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (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. + * + * Copyright 2011 (C) Citrix Systems + */ + +#ifndef __XEN_PUBLIC_ARCH_ARM_H__ +#define __XEN_PUBLIC_ARCH_ARM_H__ + +/* + * `incontents 50 arm_abi Hypercall Calling Convention + * + * A hypercall is issued using the ARM HVC instruction. + * + * A hypercall can take up to 5 arguments. These are passed in + * registers, the first argument in x0/r0 (for arm64/arm32 guests + * respectively irrespective of whether the underlying hypervisor is + * 32- or 64-bit), the second argument in x1/r1, the third in x2/r2, + * the forth in x3/r3 and the fifth in x4/r4. + * + * The hypercall number is passed in r12 (arm) or x16 (arm64). In both + * cases the relevant ARM procedure calling convention specifies this + * is an inter-procedure-call scratch register (e.g. for use in linker + * stubs). This use does not conflict with use during a hypercall. + * + * The HVC ISS must contain a Xen specific TAG: XEN_HYPERCALL_TAG. + * + * The return value is in x0/r0. + * + * The hypercall will clobber x16/r12 and the argument registers used + * by that hypercall (except r0 which is the return value) i.e. in + * addition to x16/r12 a 2 argument hypercall will clobber x1/r1 and a + * 4 argument hypercall will clobber x1/r1, x2/r2 and x3/r3. + * + * Parameter structs passed to hypercalls are laid out according to + * the Procedure Call Standard for the ARM Architecture (AAPCS, AKA + * EABI) and Procedure Call Standard for the ARM 64-bit Architecture + * (AAPCS64). Where there is a conflict the 64-bit standard should be + * used regardless of guest type. Structures which are passed as + * hypercall arguments are always little endian. + * + * All memory which is shared with other entities in the system + * (including the hypervisor and other guests) must reside in memory + * which is mapped as Normal Inner-cacheable. This applies to: + * - hypercall arguments passed via a pointer to guest memory. + * - memory shared via the grant table mechanism (including PV I/O + *rings etc). + * - memory shared with the hypervisor (struct shared_info, struct + *vcpu_info, the grant table, etc). + * + * Any Inner cache allocation strategy (Write-Back, Write-Through etc) + * is acceptable. There is no restriction on the Outer-cacheability. + */ + +/* + * `incontents 55 arm_hcall Supported Hypercalls + * + * Xen on ARM makes extensive use of hardware facilities and therefore + * only a subset of the potential hypercalls are required. + * + * Since ARM uses second stage paging any machine/physical addresses + * passed to hypercalls are Guest Physical Addresses (Intermediate + * Physical Addresses) unless otherwise noted. + * + * The following hypercalls (and sub operations) are supported on the + * ARM platform. Other hypercalls should be
[Xen-devel] [PATCH v4 19/29] Ovmf/Xen: introduce XENIO_PROTOCOL
This introduces the abstract XENIO_PROTOCOL that will be used to
communicate the Xen grant table address to drivers supporting this
protocol. Primary purpose is allowing us to change the XenBusDxe
implementation so that it can support non-PCI Xen implementations
such as Xen on ARM.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek
Signed-off-by: Ard Biesheuvel
---
OvmfPkg/Include/Protocol/XenIo.h | 48
OvmfPkg/OvmfPkg.dec | 1 +
2 files changed, 49 insertions(+)
diff --git a/OvmfPkg/Include/Protocol/XenIo.h b/OvmfPkg/Include/Protocol/XenIo.h
new file mode 100644
index ..510391f3b3e8
--- /dev/null
+++ b/OvmfPkg/Include/Protocol/XenIo.h
@@ -0,0 +1,48 @@
+/** @file
+ XenIo protocol to abstract arch specific details
+
+ The Xen implementations for the Intel and ARM archictures differ in the way
+ the base address of the grant table is communicated to the guest. The former
+ uses a virtual PCI device, while the latter uses a device tree node.
+ In order to allow the XenBusDxe UEFI driver to be reused for the non-PCI
+ Xen implementation, this abstract protocol can be installed on a handle
+ with the appropriate base address.
+
+ Copyright (C) 2014, Linaro Ltd.
+
+ This program and the accompanying materials
+ are licensed and made available under the terms and conditions of the BSD
License
+ which accompanies this distribution. The full text of the license may be
found at
+ http://opensource.org/licenses/bsd-license.php
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __PROTOCOL_XENIO_H__
+#define __PROTOCOL_XENIO_H__
+
+#include
+
+#define XENIO_PROTOCOL_GUID \
+ {0x6efac84f, 0x0ab0, 0x4747, {0x81, 0xbe, 0x85, 0x55, 0x62, 0x59, 0x04,
0x49}}
+
+///
+/// Forward declaration
+///
+typedef struct _XENIO_PROTOCOL XENIO_PROTOCOL;
+
+///
+/// Protocol structure
+///
+struct _XENIO_PROTOCOL {
+ //
+ // Protocol data fields
+ //
+ EFI_PHYSICAL_ADDRESS GrantTableAddress;
+};
+
+extern EFI_GUID gXenIoProtocolGuid;
+
+#endif
diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 30a9fb1e9b42..3711fa922311 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -58,6 +58,7 @@
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}}
+ gXenIoProtocolGuid = {0x6efac84f, 0x0ab0, 0x4747, {0x81, 0xbe,
0x85, 0x55, 0x62, 0x59, 0x04, 0x49}}
[PcdsFixedAtBuild]
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|0x0|UINT32|0
--
1.8.3.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 17/29] Ovmf/Xen: refactor XenBusDxe hypercall implementation
This refactors the Xen hypercall implementation that is part of the
XenBusDxe driver, in preparation of splitting it off entirely into
a XenHypercallLib library. This involves:
- removing the dependency on XENBUS_DEVICE* pointers in the XenHypercall()
prototypes
- moving the discovered hyperpage address to a global variable
- moving XenGetSharedInfoPage() to its only user XenBusDxe.c (the shared info
page is not strictly part of the Xen hypercall interface, and is not used
by other expected users of XenHypercallLib such as the Xen console version
of SerialPortLib
- reimplement XenHypercall2() in C and move the indexing of the hyperpage
there; the existing asm implementations are renamed to __XenHypercall2() and
invoked from the new C implementation.
Contributed-under: TianoCore Contribution Agreement 1.0
Acked-by: Laszlo Ersek
Signed-off-by: Ard Biesheuvel
---
OvmfPkg/XenBusDxe/EventChannel.c | 11 +++
OvmfPkg/XenBusDxe/GrantTable.c| 4 ++--
OvmfPkg/XenBusDxe/Ia32/hypercall.nasm | 6 +++---
OvmfPkg/XenBusDxe/X64/hypercall.nasm | 6 +++---
OvmfPkg/XenBusDxe/XenBusDxe.c | 44
+++-
OvmfPkg/XenBusDxe/XenBusDxe.h | 1 -
OvmfPkg/XenBusDxe/XenHypercall.c | 61
+
OvmfPkg/XenBusDxe/XenHypercall.h | 28 +++-
OvmfPkg/XenBusDxe/XenStore.c | 4 ++--
9 files changed, 84 insertions(+), 81 deletions(-)
diff --git a/OvmfPkg/XenBusDxe/EventChannel.c b/OvmfPkg/XenBusDxe/EventChannel.c
index 03efaf9cb904..a86323e6adfd 100644
--- a/OvmfPkg/XenBusDxe/EventChannel.c
+++ b/OvmfPkg/XenBusDxe/EventChannel.c
@@ -28,7 +28,7 @@ XenEventChannelNotify (
evtchn_send_t Send;
Send.port = Port;
- ReturnCode = XenHypercallEventChannelOp (Dev, EVTCHNOP_send, &Send);
+ ReturnCode = XenHypercallEventChannelOp (EVTCHNOP_send, &Send);
return (UINT32)ReturnCode;
}
@@ -40,15 +40,12 @@ XenBusEventChannelAllocate (
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 = (UINT32)XenHypercallEventChannelOp (Private->Dev,
+ ReturnCode = (UINT32)XenHypercallEventChannelOp (
EVTCHNOP_alloc_unbound,
&Parameter);
if (ReturnCode != 0) {
@@ -79,10 +76,8 @@ XenBusEventChannelClose (
IN evtchn_port_t Port
)
{
- XENBUS_PRIVATE_DATA *Private;
evtchn_close_t Close;
- Private = XENBUS_PRIVATE_DATA_FROM_THIS (This);
Close.port = Port;
- return (UINT32)XenHypercallEventChannelOp (Private->Dev, EVTCHNOP_close,
&Close);
+ return (UINT32)XenHypercallEventChannelOp (EVTCHNOP_close, &Close);
}
diff --git a/OvmfPkg/XenBusDxe/GrantTable.c b/OvmfPkg/XenBusDxe/GrantTable.c
index 8405edc51bc4..53cb99f0e004 100644
--- a/OvmfPkg/XenBusDxe/GrantTable.c
+++ b/OvmfPkg/XenBusDxe/GrantTable.c
@@ -161,7 +161,7 @@ XenGrantTableInit (
Parameters.idx = Index;
Parameters.space = XENMAPSPACE_grant_table;
Parameters.gpfn = (xen_pfn_t) ((UINTN) GrantTable >> EFI_PAGE_SHIFT) +
Index;
-ReturnCode = XenHypercallMemoryOp (Dev, XENMEM_add_to_physmap,
&Parameters);
+ReturnCode = XenHypercallMemoryOp (XENMEM_add_to_physmap, &Parameters);
if (ReturnCode != 0) {
DEBUG ((EFI_D_ERROR, "Xen GrantTable, add_to_physmap hypercall error:
%d\n", ReturnCode));
}
@@ -184,7 +184,7 @@ XenGrantTableDeinit (
Parameters.domid = DOMID_SELF;
Parameters.gpfn = (xen_pfn_t) ((UINTN) GrantTable >> EFI_PAGE_SHIFT) +
Index;
DEBUG ((EFI_D_INFO, "Xen GrantTable, removing %X\n", Parameters.gpfn));
-ReturnCode = XenHypercallMemoryOp (Dev, XENMEM_remove_from_physmap,
&Parameters);
+ReturnCode = XenHypercallMemoryOp (XENMEM_remove_from_physmap,
&Parameters);
if (ReturnCode != 0) {
DEBUG ((EFI_D_ERROR, "Xen GrantTable, remove_from_physmap hypercall
error: %d\n", ReturnCode));
}
diff --git a/OvmfPkg/XenBusDxe/Ia32/hypercall.nasm
b/OvmfPkg/XenBusDxe/Ia32/hypercall.nasm
index 8547c30b81ee..e0fa71bb5ba8 100644
--- a/OvmfPkg/XenBusDxe/Ia32/hypercall.nasm
+++ b/OvmfPkg/XenBusDxe/Ia32/hypercall.nasm
@@ -2,13 +2,13 @@ SECTION .text
; INTN
; EFIAPI
-; XenHypercall2 (
+; __XenHypercall2 (
; IN VOID *HypercallAddr,
; IN OUT INTN Arg1,
; IN OUT INTN Arg2
; );
-global ASM_PFX(XenHypercall2)
-ASM_PFX(XenHypercall2):
+global ASM_PFX(__XenHypercall2)
+ASM_PFX(__XenHypercall2):
; Save only ebx, ecx is supposed to be a scratch register and needs to be
; saved by the caller
push ebx
diff --git a/OvmfPkg/XenBusDxe/X64/hypercall.nasm
b/OvmfPkg/XenBusDxe/X64/hypercall.nasm
index 177f271ef094..5e6a0c05c5c4 100644
--- a/OvmfPkg/XenBusDxe/X64/hypercall.nasm
+++ b/OvmfPkg/XenBusDxe/X64/hypercall.nasm
@@ -3,13 +3,13 @@
[Xen-devel] [PATCH v4 14/29] MdePkg/BaseSynchronizationLib: implement 16-bit compare-exchange
This implements the function InterlockedCompareExchange16 () for all architectures, using architecture and toolchain specific intrinsics or primitive assembler instructions. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Olivier Martin Signed-off-by: Ard Biesheuvel --- MdePkg/Include/Library/SynchronizationLib.h | 26 ++ MdePkg/Library/BaseSynchronizationLib/AArch64/Synchronization.S | 44 MdePkg/Library/BaseSynchronizationLib/Arm/Synchronization.S | 44 MdePkg/Library/BaseSynchronizationLib/Arm/Synchronization.asm | 44 MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf| 5 + MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLibInternals.h | 26 ++ MdePkg/Library/BaseSynchronizationLib/Ebc/Synchronization.c | 31 +++ MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c | 42 ++ MdePkg/Library/BaseSynchronizationLib/Ia32/InterlockedCompareExchange16.asm | 46 ++ MdePkg/Library/BaseSynchronizationLib/Ia32/InterlockedCompareExchange16.c | 51 +++ MdePkg/Library/BaseSynchronizationLib/Ipf/InterlockedCompareExchange16.s| 30 ++ MdePkg/Library/BaseSynchronizationLib/Synchronization.c | 31 +++ MdePkg/Library/BaseSynchronizationLib/SynchronizationGcc.c | 31 +++ MdePkg/Library/BaseSynchronizationLib/SynchronizationMsc.c | 31 +++ MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c | 44 MdePkg/Library/BaseSynchronizationLib/X64/InterlockedCompareExchange16.asm | 42 ++ MdePkg/Library/BaseSynchronizationLib/X64/InterlockedCompareExchange16.c| 54 ++ 17 files changed, 622 insertions(+) diff --git a/MdePkg/Include/Library/SynchronizationLib.h b/MdePkg/Include/Library/SynchronizationLib.h index f97569739914..7b97683ca0af 100644 --- a/MdePkg/Include/Library/SynchronizationLib.h +++ b/MdePkg/Include/Library/SynchronizationLib.h @@ -184,6 +184,32 @@ InterlockedDecrement ( /** + 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 + ); + +/** Performs an atomic compare exchange operation on a 32-bit unsigned integer. Performs an atomic compare exchange operation on the 32-bit unsigned integer diff --git a/MdePkg/Library/BaseSynchronizationLib/AArch64/Synchronization.S b/MdePkg/Library/BaseSynchronizationLib/AArch64/Synchronization.S index 601b00495f26..ecb87fc12755 100644 --- a/MdePkg/Library/BaseSynchronizationLib/AArch64/Synchronization.S +++ b/MdePkg/Library/BaseSynchronizationLib/AArch64/Synchronization.S @@ -16,12 +16,56 @@ .text .align 3 +GCC_ASM_EXPORT(InternalSyncCompareExchange16) GCC_ASM_EXPORT(InternalSyncCompareExchange32) GCC_ASM_EXPORT(InternalSyncCompareExchange64) GCC_ASM_EXPORT(InternalSyncIncrement) GCC_ASM_EXPORT(InternalSyncDecrement) /** + 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. + + @param Value A pointer to the 16-bit value for the compare exchange +operation. + @param CompareValue 16-b
[Xen-devel] [PATCH v4 21/29] Ovmf/Xen: move XenBusDxe to abstract XENIO_PROTOCOL
While Xen on Intel uses a virtual PCI device to communicate the
base address of the grant table, the ARM implementation uses a DT
node, which is fundamentally incompatible with the way XenBusDxe is
implemented, i.e., as a UEFI Driver Model implementation for a PCI
device.
Contributed-under: TianoCore Contribution Agreement 1.0
Acked-by: Laszlo Ersek
Signed-off-by: Ard Biesheuvel
---
OvmfPkg/OvmfPkgIa32.dsc | 1 +
OvmfPkg/OvmfPkgIa32.fdf | 1 +
OvmfPkg/OvmfPkgIa32X64.dsc| 1 +
OvmfPkg/OvmfPkgIa32X64.fdf| 1 +
OvmfPkg/OvmfPkgX64.dsc| 1 +
OvmfPkg/OvmfPkgX64.fdf| 1 +
OvmfPkg/XenBusDxe/ComponentName.c | 2 +-
OvmfPkg/XenBusDxe/GrantTable.c| 5 ++---
OvmfPkg/XenBusDxe/GrantTable.h| 3 +--
OvmfPkg/XenBusDxe/XenBus.c| 6 +++---
OvmfPkg/XenBusDxe/XenBusDxe.c | 55
+--
OvmfPkg/XenBusDxe/XenBusDxe.h | 8 ++--
OvmfPkg/XenBusDxe/XenBusDxe.inf | 2 +-
13 files changed, 29 insertions(+), 58 deletions(-)
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 90540272745c..8c880613851d 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -444,6 +444,7 @@
OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
+ OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
OvmfPkg/XenBusDxe/XenBusDxe.inf
OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf {
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index f47e7ddc7834..ecef963d1e85 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.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/XenIoPciDxe/XenIoPciDxe.inf
INF OvmfPkg/XenBusDxe/XenBusDxe.inf
INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 0a331eda8be0..ff32ecefd07b 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -451,6 +451,7 @@
OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
+ OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
OvmfPkg/XenBusDxe/XenBusDxe.inf
OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf {
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index 4c034460d5d2..29414ff04082 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.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/XenIoPciDxe/XenIoPciDxe.inf
INF OvmfPkg/XenBusDxe/XenBusDxe.inf
INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index e2b37c271681..8bac6dc313f0 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -449,6 +449,7 @@
OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
+ OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
OvmfPkg/XenBusDxe/XenBusDxe.inf
OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf {
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 2323eb2edf33..f1feb698ba66 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/XenIoPciDxe/XenIoPciDxe.inf
INF OvmfPkg/XenBusDxe/XenBusDxe.inf
INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
diff --git a/OvmfPkg/XenBusDxe/ComponentName.c
b/OvmfPkg/XenBusDxe/ComponentName.c
index 4530509e65dc..3f2dd406c77d 100644
--- a/OvmfPkg/XenBusDxe/ComponentName.c
+++ b/OvmfPkg/XenBusDxe/ComponentName.c
@@ -155,7 +155,7 @@ XenBusDxeComponentNameGetControllerName (
Status = EfiTestManagedDevice (
ControllerHandle,
gXenBusDxeDriverBinding.DriverBindingHandle,
- &gEfiPciIoProtocolGuid
+ &gXenIoProtocolGuid
);
if (EFI_ERROR (Status)) {
return Status;
diff --git a/OvmfPkg/XenBusDxe/GrantTable.c b/OvmfPkg/XenBusDxe/GrantTable.c
index a80d5eff39cd..19117fbe0373 100644
--- a/OvmfPkg/XenBusDxe/GrantTable.c
+++ b/OvmfPkg/XenBusDxe/GrantTable.c
@@ -139,8 +139,7 @@ XenGrantTableEndAccess (
VOID
XenGrantTableInit (
- IN XENBUS_DEVICE *Dev,
-
[Xen-devel] [PATCH v4 20/29] Ovmf/Xen: add separate driver for Xen PCI device
Prepare for making XenBusDxe suitable for use with non-PCI devices
(such as the DT node exposed by Xen on ARM) by introducing a separate
DXE driver that binds to the Xen virtual PCI device and exposes the
abstract XENIO_PROTOCOL for XenBusDxe to bind against.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek
Signed-off-by: Ard Biesheuvel
---
OvmfPkg/XenIoPciDxe/XenIoPciDxe.c | 367
OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf | 45 +
2 files changed, 412 insertions(+)
diff --git a/OvmfPkg/XenIoPciDxe/XenIoPciDxe.c
b/OvmfPkg/XenIoPciDxe/XenIoPciDxe.c
new file mode 100644
index ..c205cf74db34
--- /dev/null
+++ b/OvmfPkg/XenIoPciDxe/XenIoPciDxe.c
@@ -0,0 +1,367 @@
+/** @file
+
+ Driver for the virtual Xen PCI device
+
+ Copyright (C) 2012, Red Hat, Inc.
+ Copyright (c) 2012, Intel Corporation. All rights reserved.
+ Copyright (C) 2013, ARM Ltd.
+ Copyright (C) 2015, Linaro Ltd.
+
+ 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.
+
+**/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#define PCI_VENDOR_ID_XEN0x5853
+#define PCI_DEVICE_ID_XEN_PLATFORM 0x0001
+
+/**
+
+ Device probe function for this driver.
+
+ The DXE core calls this function for any given device in order to see if the
+ driver can drive the device.
+
+ @param[in] ThisThe EFI_DRIVER_BINDING_PROTOCOL object
+ incorporating this driver (independently of
+ any device).
+
+ @param[in] DeviceHandle The device to probe.
+
+ @param[in] RemainingDevicePath Relevant only for bus drivers, ignored.
+
+
+ @retval EFI_SUCCESS The driver supports the device being probed.
+
+ @retval EFI_UNSUPPORTED The driver does not support the device being probed.
+
+ @return Error codes from the OpenProtocol() boot service or
+ the PciIo protocol.
+
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+XenIoPciDeviceBindingSupported (
+ IN EFI_DRIVER_BINDING_PROTOCOL *This,
+ IN EFI_HANDLE DeviceHandle,
+ IN EFI_DEVICE_PATH_PROTOCOL*RemainingDevicePath
+ )
+{
+ EFI_STATUS Status;
+ EFI_PCI_IO_PROTOCOL *PciIo;
+ PCI_TYPE00 Pci;
+
+ //
+ // Attempt to open the device with the PciIo set of interfaces. On success,
+ // the protocol is "instantiated" for the PCI device. Covers duplicate open
+ // attempts (EFI_ALREADY_STARTED).
+ //
+ Status = gBS->OpenProtocol (
+ DeviceHandle, // candidate device
+ &gEfiPciIoProtocolGuid, // for generic PCI access
+ (VOID **)&PciIo,// handle to instantiate
+ This->DriverBindingHandle, // requestor driver identity
+ DeviceHandle, // ControllerHandle, according to
+ // the UEFI Driver Model
+ EFI_OPEN_PROTOCOL_BY_DRIVER // get exclusive PciIo access to
+ // the device; to be released
+ );
+ if (EFI_ERROR (Status)) {
+return Status;
+ }
+
+ //
+ // Read entire PCI configuration header for more extensive check ahead.
+ //
+ Status = PciIo->Pci.Read (
+PciIo,// (protocol, device)
+ // handle
+EfiPciIoWidthUint32, // access width & copy
+ // mode
+0,// Offset
+sizeof Pci / sizeof (UINT32), // Count
+&Pci // target buffer
+);
+
+ if (Status == EFI_SUCCESS) {
+if ((Pci.Hdr.VendorId == PCI_VENDOR_ID_XEN) &&
+(Pci.Hdr.DeviceId == PCI_DEVICE_ID_XEN_PLATFORM)) {
+ Status = EFI_SUCCESS;
+} else {
+ Status = EFI_UNSUPPORTED;
+}
+ }
+
+ //
+ // We needed PCI IO access only transitorily, to see whether we support the
+ // device or not.
+ //
+ gBS->CloseProtocol (DeviceHandle, &gEfiPciIoProtocolGuid,
+ This->DriverBindingHandle, DeviceHandle);
+
+ return Status;
+}
+
+/**
+
+ After we've pronounced support for a specific device in
+ DriverBindingSupported(), we start managing said device (passed in
[Xen-devel] [PATCH v4 24/29] Ovmf/Xen: add Xen PV console SerialPortLib driver
This implements a SerialPortLib instance that wires up to the
PV console ring used by domU guests. Also imports the required
upstream Xen io/console.h header.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Stefano Stabellini
Acked-by: Laszlo Ersek
Signed-off-by: Ard Biesheuvel
---
OvmfPkg/Include/IndustryStandard/Xen/io/console.h | 51
++
OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.c | 156
OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.inf | 35
3 files changed, 242 insertions(+)
diff --git a/OvmfPkg/Include/IndustryStandard/Xen/io/console.h
b/OvmfPkg/Include/IndustryStandard/Xen/io/console.h
new file mode 100644
index ..f1caa9765bcf
--- /dev/null
+++ b/OvmfPkg/Include/IndustryStandard/Xen/io/console.h
@@ -0,0 +1,51 @@
+/**
+ * console.h
+ *
+ * Console I/O interface for Xen guest OSes.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (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.
+ *
+ * Copyright (c) 2005, Keir Fraser
+ */
+
+#ifndef __XEN_PUBLIC_IO_CONSOLE_H__
+#define __XEN_PUBLIC_IO_CONSOLE_H__
+
+typedef UINT32 XENCONS_RING_IDX;
+
+#define MASK_XENCONS_IDX(idx, ring) ((idx) & (sizeof(ring)-1))
+
+struct xencons_interface {
+char in[1024];
+char out[2048];
+XENCONS_RING_IDX in_cons, in_prod;
+XENCONS_RING_IDX out_cons, out_prod;
+};
+
+#endif /* __XEN_PUBLIC_IO_CONSOLE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.c
b/OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.c
new file mode 100644
index ..98022354cf31
--- /dev/null
+++ b/OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.c
@@ -0,0 +1,156 @@
+/** @file
+ Xen console SerialPortLib instance
+
+ Copyright (c) 2015, Linaro Ltd. 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.
+
+**/
+
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+//
+// The code below expects these global variables to be mutable, even in the
case
+// that we have been incorporated into SEC or PEIM phase modules (which is
+// allowed by our INF description). While this is a dangerous assumption to
make
+// in general, it is actually fine for the Xen domU (guest) environment that
+// this module is intended for, as UEFI always executes from DRAM in that case.
+//
+STATIC evtchn_send_t mXenConsoleEventChain;
+STATIC struct xencons_interface *mXenConsoleInterface;
+
+RETURN_STATUS
+EFIAPI
+SerialPortInitialize (
+ VOID
+ )
+{
+ if (!mXenConsoleInterface) {
+mXenConsoleEventChain.port = (UINT32)XenHypercallHvmGetParam
(HVM_PARAM_CONSOLE_EVTCHN);
+mXenConsoleInterface = (struct xencons_interface *)(UINTN)
+ (XenHypercallHvmGetParam (HVM_PARAM_CONSOLE_PFN) << EFI_PAGE_SHIFT);
+
+//
+// No point in ASSERT'ing here as we won't be seeing the output
+//
+ }
+ return RETURN_SUCCESS;
+}
+
+/**
+ Write data to serial device.
+
+ @param Buffer Point of data buffer which need to be written.
+ @param NumberOfBytesNumber of output bytes which are cached in Buffer.
+
+ @retval 0Write data failed.
+ @retval !0 Actual
[Xen-devel] [PATCH v4 29/29] ArmVirtualizationPkg: add platform description for Xen guests
This adds the .dsc and .fdf descriptions to build a UEFI image that is bootable by a Xen guest on 64-bit ARM (AArch64) Contributed-under: TianoCore Contribution Agreement 1.0 Acked-by: Laszlo Ersek Reviewed-by: Olivier Martin Signed-off-by: Ard Biesheuvel --- ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationXen.dsc | 218 ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationXen.fdf | 302 +++ 2 files changed, 520 insertions(+) diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationXen.dsc b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationXen.dsc new file mode 100644 index ..eb9167b6f816 --- /dev/null +++ b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationXen.dsc @@ -0,0 +1,218 @@ +# +# Copyright (c) 2011-2013, ARM Limited. All rights reserved. +# Copyright (c) 2014, Linaro Limited. 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. +# +# + + +# +# Defines Section - statements that will be processed to create a Makefile. +# + +[Defines] + PLATFORM_NAME = ArmVirtualizationXen + PLATFORM_GUID = d1c43be3-3373-4a06-86fb-d1cb3083a207 + PLATFORM_VERSION = 0.1 + DSC_SPECIFICATION = 0x00010005 + OUTPUT_DIRECTORY = Build/ArmVirtualizationXen-$(ARCH) + SUPPORTED_ARCHITECTURES= AARCH64 + BUILD_TARGETS = DEBUG|RELEASE + SKUID_IDENTIFIER = DEFAULT + FLASH_DEFINITION = ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationXen.fdf + +!include ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualization.dsc.inc + +[LibraryClasses] + SerialPortLib|OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.inf + RealTimeClockLib|ArmPlatformPkg/ArmVirtualizationPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf + XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLibArm.inf + +[LibraryClasses.AARCH64] + ArmLib|ArmPkg/Library/ArmLib/AArch64/AArch64Lib.inf + ArmCpuLib|ArmPkg/Drivers/ArmCpuLib/ArmCortexAEMv8Lib/ArmCortexAEMv8Lib.inf + +[LibraryClasses.ARM] + ArmLib|ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.inf + ArmCpuLib|ArmPkg/Drivers/ArmCpuLib/ArmCortexA15Lib/ArmCortexA15Lib.inf + +[LibraryClasses.common] + # Virtio Support + VirtioLib|OvmfPkg/Library/VirtioLib/VirtioLib.inf + VirtioMmioDeviceLib|OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf + + ArmPlatformLib|ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmXenRelocatablePlatformLib/ArmXenRelocatablePlatformLib.inf + ArmPlatformSysConfigLib|ArmPlatformPkg/Library/ArmPlatformSysConfigLibNull/ArmPlatformSysConfigLibNull.inf + + TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf + + CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf + GenericBdsLib|IntelFrameworkModulePkg/Library/GenericBdsLib/GenericBdsLib.inf + PlatformBdsLib|ArmPlatformPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf + CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf + +[LibraryClasses.common.UEFI_DRIVER] + UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf + +[LibraryClasses.AARCH64.SEC] + ArmLib|ArmPkg/Library/ArmLib/AArch64/AArch64LibSec.inf + +[LibraryClasses.ARM.SEC] + ArmLib|ArmPkg/Library/ArmLib/ArmV7/ArmV7LibSec.inf + +[BuildOptions] + RVCT:*_*_ARM_PLATFORM_FLAGS == --cpu Cortex-A15 -I$(WORKSPACE)/ArmPlatformPkg/ArmVirtualizationPkg/Include + GCC:*_*_ARM_PLATFORM_FLAGS == -mcpu=cortex-a15 -I$(WORKSPACE)/ArmPlatformPkg/ArmVirtualizationPkg/Include + GCC:*_*_AARCH64_PLATFORM_FLAGS == -I$(WORKSPACE)/ArmPlatformPkg/ArmVirtualizationPkg/Include + + +# +# Pcd Section - list of all EDK II PCD Entries defined by this Platform +# + + +[PcdsFixedAtBuild.common] + gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x804F + + gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"XEN-UEFI" + gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"$(FIRMWARE_VER)" + + gArmPlatformTokenSpaceGuid.PcdCoreCount|1 +!if $(ARCH) == AARCH64 + gArmTokenSpaceGuid.PcdVFPEnabled|1 +!endif + + gArmPlatformTokenSpace
Re: [Xen-devel] [PATCH 0/2] arm/arm64: Detect Xen support earlier
On 12 February 2015 at 14:34, Julien Grall wrote: > Hello, > > This small patch series move the detection of running on Xen earlier. This is > required in order to support earlyprintk via Xen and selecting the preferred > console. > > Ard, the patch to move the call earlier (see #2) differed from the one I sent > you privately mostly because it's not possible to translate an IRQ before the > GIC has been initialized. > > Let me know if it works for you. > I have tested these patches with my preferred console patch on top, and it results in console output without having to pass 'console=hvc0' on the command line. I didn't check anything else, nor do I have enough of a clue about Xen to notice anything else out of the ordinary So FWIW, Tested-by: Ard Biesheuvel > Sincerely yours, > > Julien Grall (1): > arm/xen: Correctly check if the event channel interrupt is present > > Stefano Stabellini (1): > arm,arm64/xen: move Xen initialization earlier > > arch/arm/include/asm/xen/hypervisor.h | 8 + > arch/arm/kernel/setup.c | 2 ++ > arch/arm/xen/enlighten.c | 58 > +-- > arch/arm64/kernel/setup.c | 2 ++ > 4 files changed, 47 insertions(+), 23 deletions(-) > > -- > 2.1.0 > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] 3.19 + xen-devel: kernel BUG at fs/ext4/page-io.c:85!
Hello, El 12/02/15 a les 9.54, Sander Eikelenboom ha escrit: > Hi, > > With a 3.19 kernel + xen-devel tree pulled on top i run into this splat below. > It's on a Xen PV-guest running a postgres database and doing a pg_dump at that > moment in time, after running for a while (within 2 days or so). > > -- > Sander > > [139595.736073] [ cut here ] > [139595.736073] kernel BUG at fs/ext4/page-io.c:85! > [139595.736073] invalid opcode: [#1] SMP > [139595.736073] Modules linked in: > [139595.736073] CPU: 0 PID: 25632 Comm: pg_dump Not tainted > 3.19.0-20150209-doflr-xendevel-edid+ #1 > [139595.736073] task: 8800f8fd10c0 ti: 88006bc7 task.ti: > 88006bc7 > [139595.736073] RIP: e030:[] [] > ext4_finish_bio+0x24f/0x260 > [139595.736073] RSP: e02b:8800fac03bc8 EFLAGS: 00010046 > [139595.736073] RAX: 0042002c RBX: 880060fa6170 RCX: > 0034 > [139595.736073] RDX: RSI: ea00014a77c0 RDI: > 8800f9357300 > [139595.736073] RBP: 8800fac03c58 R08: 0009 R09: > 00016830 > [139595.736073] R10: 8800ff820680 R11: R12: > > [139595.736073] R13: 88006bf111a0 R14: R15: > eacd1800 > [139595.736073] FS: 7f623b3f7720() GS:8800fac0() > knlGS: > [139595.736073] CS: e033 DS: ES: CR0: 8005003b > [139595.736073] CR2: ff600400 CR3: 91907000 CR4: > 0660 > [139595.736073] Stack: > [139595.736073] 8800fac03be8 81bc11c2 83140070 > 8800fac03cc6 > [139595.736073] 8800f9357300 1000244d0001 0040002c > 0017 > [139595.736073] 0002 8800fac03c98 > 8110582d > [139595.736073] Call Trace: > [139595.736073] > [139595.736073] [] ? _raw_spin_unlock_irqrestore+0x52/0x90 > [139595.736073] [] ? lock_acquire+0xed/0x110 > [139595.736073] [] ext4_end_bio+0x58/0x110 > [139595.736073] [] bio_endio+0x53/0x90 > [139595.736073] [] blk_update_request+0x80/0x300 > [139595.736073] [] blk_update_bidi_request+0x22/0x90 > [139595.736073] [] __blk_end_bidi_request+0x1b/0x40 > [139595.736073] [] __blk_end_request_all+0x1a/0x30 > [139595.736073] [] blkif_interrupt+0x731/0x8c0 AFAICT the crash is due to the ext4 code not finding it's private data embedded in the page. xen-blkfront doesn't use page->private at all, so I'm not sure who is touching this. The only Xen specific code that touches page->private is the p2m code. Was the domain saved/restored/migrated? Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] xen/arm: allow console=hvc0 to be omitted for guests
This patch registers hvc0 as the preferred console if no console
has been specified explicitly on the kernel command line.
The purpose is to allow platform agnostic kernels and boot images
(such as distro installers) to boot in a Xen/ARM domU without the
need to modify the command line by hand.
Signed-off-by: Ard Biesheuvel
---
arch/arm/xen/enlighten.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 0abeefa7dbf8..927be1d1bad7 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
@@ -255,6 +256,9 @@ void __init xen_early_init(void)
xen_start_info->flags |= SIF_INITDOMAIN|SIF_PRIVILEGED;
else
xen_start_info->flags &= ~(SIF_INITDOMAIN|SIF_PRIVILEGED);
+
+ if (!console_set_on_cmdline && !xen_initial_domain())
+ add_preferred_console("hvc", 0, NULL);
}
static int __init xen_guest_init(void)
--
1.8.3.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH V3] x86 spinlock: Fix memory corruption on completing completions
Paravirt spinlock clears slowpath flag after doing unlock.
As explained by Linus currently it does:
prev = *lock;
add_smp(&lock->tickets.head, TICKET_LOCK_INC);
/* add_smp() is a full mb() */
if (unlikely(lock->tickets.tail & TICKET_SLOWPATH_FLAG))
__ticket_unlock_slowpath(lock, prev);
which is *exactly* the kind of things you cannot do with spinlocks,
because after you've done the "add_smp()" and released the spinlock
for the fast-path, you can't access the spinlock any more. Exactly
because a fast-path lock might come in, and release the whole data
structure.
Linus suggested that we should not do any writes to lock after unlock(),
and we can move slowpath clearing to fastpath lock.
So this patch implements the fix with:
1. Moving slowpath flag to head (Oleg).
2. use xadd to avoid read/write after unlock that checks the need for
unlock_kick (Linus).
Result:
setup: 16core (32 cpu +ht sandy bridge 8GB 16vcpu guest)
benchmark overcommit %improve
kernbench 1x -0.13
kernbench 2x0.02
dbench 1x -1.77
dbench 2x -0.63
[Jeremy: hinted missing TICKET_LOCK_INC for kick]
[Oleg: Moving slowpath flag to head, ticket_equals idea]
Reported-by: Sasha Levin
Suggested-by: Linus Torvalds
Signed-off-by: Raghavendra K T
---
arch/x86/include/asm/spinlock.h | 87 -
arch/x86/kernel/kvm.c | 4 +-
2 files changed, 45 insertions(+), 46 deletions(-)
potential TODO:
* The whole patch be splitted into, 1. move slowpath flag
2. fix memory corruption in completion problem ??
* May be we could directly pass inc for __ticket_check_and_clear_slowpath
but I hope current code is more readable.
Changes since V2:
- Move the slowpath flag to head, this enables xadd usage in unlock code
and inturn we can get rid of read/write after unlock (Oleg)
- usage of ticket_equals (Oleg)
Changes since V1:
- Add missing TICKET_LOCK_INC before unlock kick (fixes hang in overcommit:
Jeremy).
- Remove SLOWPATH_FLAG clearing in fast lock. (Jeremy)
- clear SLOWPATH_FLAG in arch_spin_value_unlocked during comparison.
Note: The current implementation is still based on avoid writing after unlock.
we could still have potential invalid memory read. (Sasha)
Result:
setup: 16core (32 cpu +ht sandy bridge 8GB 16vcpu guest)
base = 3_19_rc7
3_19_rc7_spinfix_v3
+---+---+---++---+
kernbench (Time taken in sec lower is better)
+---+---+---++---+
base %stdevpatched %stdev %improve
+---+---+---++---+
1x 54.2300 3.0652 54.3008 4.0366-0.13056
2x 90.1883 5.5509 90.1650 6.4336 0.02583
+---+---+---++---+
+---+---+---++---+
dbench (Throughput higher is better)
+---+---+---++---+
base %stdevpatched %stdev %improve
+---+---+---++---+
1x 7029.9188 2.5952 6905.0712 4.4737-1.77595
2x 3254.207514.8291 3233.713726.8784-0.62976
+---+---+---++---+
(here is the result I got from the patches, I believe there may
be some small overhead from xadd etc, but overall looks fine but
a thorough test may be needed)
diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h
index 625660f..9697b45 100644
--- a/arch/x86/include/asm/spinlock.h
+++ b/arch/x86/include/asm/spinlock.h
@@ -46,7 +46,7 @@ static __always_inline bool static_key_false(struct
static_key *key);
static inline void __ticket_enter_slowpath(arch_spinlock_t *lock)
{
- set_bit(0, (volatile unsigned long *)&lock->tickets.tail);
+ set_bit(0, (volatile unsigned long *)&lock->tickets.head);
}
#else /* !CONFIG_PARAVIRT_SPINLOCKS */
@@ -60,10 +60,30 @@ static inline void __ticket_unlock_kick(arch_spinlock_t
*lock,
}
#endif /* CONFIG_PARAVIRT_SPINLOCKS */
+static inline int __tickets_equal(__ticket_t one, __ticket_t two)
+{
+ return !((one ^ two) & ~TICKET_SLOWPATH_FLAG);
+}
+
+static inline void __ticket_check_and_clear_slowpath(arch_spinlock_t *lock,
+ __ticket_t head)
+{
+ if (head & TICKET_SLOWPATH_FLAG) {
+ arch_spinlock_t old, new;
+
+ old.tickets.head = head;
+ new.tickets.head = head & ~TICKET_SLOWPATH_FLAG;
+ old.tickets.tail = new.tickets.head + TICKET_LOCK_INC;
+ new.tickets.tail = old.tickets.tail;
+
+ /* try to clear slowpath flag when there are no contenders */
+ cmpxchg(&lock->head_tail, old.head_tail, new.hea
Re: [Xen-devel] 3.19 + xen-devel: kernel BUG at fs/ext4/page-io.c:85!
Thursday, February 12, 2015, 12:28:35 PM, you wrote: > Hello, > El 12/02/15 a les 9.54, Sander Eikelenboom ha escrit: >> Hi, >> >> With a 3.19 kernel + xen-devel tree pulled on top i run into this splat >> below. >> It's on a Xen PV-guest running a postgres database and doing a pg_dump at >> that >> moment in time, after running for a while (within 2 days or so). >> >> -- >> Sander >> >> [139595.736073] [ cut here ] >> [139595.736073] kernel BUG at fs/ext4/page-io.c:85! >> [139595.736073] invalid opcode: [#1] SMP >> [139595.736073] Modules linked in: >> [139595.736073] CPU: 0 PID: 25632 Comm: pg_dump Not tainted >> 3.19.0-20150209-doflr-xendevel-edid+ #1 >> [139595.736073] task: 8800f8fd10c0 ti: 88006bc7 task.ti: >> 88006bc7 >> [139595.736073] RIP: e030:[] [] >> ext4_finish_bio+0x24f/0x260 >> [139595.736073] RSP: e02b:8800fac03bc8 EFLAGS: 00010046 >> [139595.736073] RAX: 0042002c RBX: 880060fa6170 RCX: >> 0034 >> [139595.736073] RDX: RSI: ea00014a77c0 RDI: >> 8800f9357300 >> [139595.736073] RBP: 8800fac03c58 R08: 0009 R09: >> 00016830 >> [139595.736073] R10: 8800ff820680 R11: R12: >> >> [139595.736073] R13: 88006bf111a0 R14: R15: >> eacd1800 >> [139595.736073] FS: 7f623b3f7720() GS:8800fac0() >> knlGS: >> [139595.736073] CS: e033 DS: ES: CR0: 8005003b >> [139595.736073] CR2: ff600400 CR3: 91907000 CR4: >> 0660 >> [139595.736073] Stack: >> [139595.736073] 8800fac03be8 81bc11c2 83140070 >> 8800fac03cc6 >> [139595.736073] 8800f9357300 1000244d0001 0040002c >> 0017 >> [139595.736073] 0002 8800fac03c98 >> 8110582d >> [139595.736073] Call Trace: >> [139595.736073] >> [139595.736073] [] ? _raw_spin_unlock_irqrestore+0x52/0x90 >> [139595.736073] [] ? lock_acquire+0xed/0x110 >> [139595.736073] [] ext4_end_bio+0x58/0x110 >> [139595.736073] [] bio_endio+0x53/0x90 >> [139595.736073] [] blk_update_request+0x80/0x300 >> [139595.736073] [] blk_update_bidi_request+0x22/0x90 >> [139595.736073] [] __blk_end_bidi_request+0x1b/0x40 >> [139595.736073] [] __blk_end_request_all+0x1a/0x30 >> [139595.736073] [] blkif_interrupt+0x731/0x8c0 > AFAICT the crash is due to the ext4 code not finding it's private data > embedded in the page. xen-blkfront doesn't use page->private at all, so > I'm not sure who is touching this. The only Xen specific code that touches page->>private is the p2m code. Was the domain > saved/restored/migrated? > Roger. Hi Roger, Nope, no saving/restoring or migration. What *could* be happening in the mean time would be LVM making and operating on a snapshot in dom0 of the same logical LVM partition. But AFIAK that shouldn't matter. -- Sander ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] OvmfPkg: AcpiPlatformDxe: PCI enumeration may be disabled
SVN r16411 delayed ACPI table installation until PCI enumeration was
complete, because on QEMU the ACPI-related fw_cfg files should only be
downloaded after PCI enumeration.
However, InitializeXen() in "OvmfPkg/PlatformPei/Xen.c" sets
PcdPciDisableBusEnumeration to TRUE. This causes
PciBusDriverBindingStart() in "MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c" to
set gFullEnumeration to FALSE, which in turn makes PciEnumerator() in
"MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c" branch to
PciEnumeratorLight(). The installation of
EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL at the end of PciEnumerator() is not
reached.
Which means that starting with SVN r16411, AcpiPlatformDxe is never
dispatched on Xen.
This patch replaces the EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL depex with a
matching protocol registration callback for the PCI enumeration enabled
(ie. QEMU) case. When PCI enumeration is disabled (ie. when running on
Xen), AcpiPlatformDxe doesn't wait for
EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek
---
OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf | 4 +-
OvmfPkg/AcpiPlatformDxe/AcpiPlatform.c | 84 +++--
2 files changed, 72 insertions(+), 16 deletions(-)
diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
index 53292bf..6b2c9d2 100644
--- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
+++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
@@ -56,16 +56,18 @@
[Protocols]
gEfiAcpiTableProtocolGuid # PROTOCOL ALWAYS_CONSUMED
+ gEfiPciEnumerationCompleteProtocolGuid# PROTOCOL SOMETIMES_CONSUMED
[Guids]
gEfiXenInfoGuid
[Pcd]
gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiTableStorageFile
+ gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration
gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFdBaseAddress
[Depex]
- gEfiAcpiTableProtocolGuid AND gEfiPciEnumerationCompleteProtocolGuid
+ gEfiAcpiTableProtocolGuid
diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.c
b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.c
index 11f0ca8..9823eba 100644
--- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.c
+++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.c
@@ -12,6 +12,7 @@
**/
+#include
#include "AcpiPlatform.h"
EFI_STATUS
@@ -221,6 +222,47 @@ FindAcpiTablesInFv (
return EFI_SUCCESS;
}
+STATIC
+EFI_STATUS
+EFIAPI
+InstallTables (
+ VOID
+ )
+{
+ EFI_STATUS Status;
+ EFI_ACPI_TABLE_PROTOCOL *AcpiTable;
+
+ Status = gBS->LocateProtocol (&gEfiAcpiTableProtocolGuid,
+ NULL /* Registration */, (VOID **)&AcpiTable);
+ if (EFI_ERROR (Status)) {
+return EFI_ABORTED;
+ }
+
+ if (XenDetected ()) {
+Status = InstallXenTables (AcpiTable);
+ } else {
+Status = InstallAllQemuLinkedTables (AcpiTable);
+ }
+
+ if (EFI_ERROR (Status)) {
+Status = FindAcpiTablesInFv (AcpiTable);
+ }
+
+ return Status;
+}
+
+STATIC
+VOID
+EFIAPI
+OnPciEnumerated (
+ IN EFI_EVENT Event,
+ IN VOID *Context
+ )
+{
+ InstallTables ();
+ gBS->CloseEvent (Event);
+}
+
/**
Entrypoint of Acpi Platform driver.
@@ -239,31 +281,43 @@ AcpiPlatformEntryPoint (
IN EFI_SYSTEM_TABLE *SystemTable
)
{
- EFI_STATUS Status;
- EFI_ACPI_TABLE_PROTOCOL*AcpiTable;
+ EFI_STATUS Status;
+ VOID *Interface;
+ EFI_EVENT PciEnumerated;
+ VOID *Registration;
//
- // Find the AcpiTable protocol
+ // If PCI enumeration has been disabled, or it has already completed, install
+ // the tables at once, and let the entry point's return code reflect the full
+ // functionality.
//
- Status = gBS->LocateProtocol (
- &gEfiAcpiTableProtocolGuid,
- NULL,
- (VOID**)&AcpiTable
- );
- if (EFI_ERROR (Status)) {
-return EFI_ABORTED;
+ if (PcdGetBool (PcdPciDisableBusEnumeration)) {
+return InstallTables ();
}
- if (XenDetected ()) {
-Status = InstallXenTables (AcpiTable);
- } else {
-Status = InstallAllQemuLinkedTables (AcpiTable);
+ Status = gBS->LocateProtocol (&gEfiPciEnumerationCompleteProtocolGuid,
+ NULL /* Registration */, &Interface);
+ if (!EFI_ERROR (Status)) {
+return InstallTables ();
}
+ ASSERT (Status == EFI_NOT_FOUND);
+ //
+ // Otherwise, delay the installation until PCI enumeration is complete. The
+ // entry point's return status will only reflect the callback setup.
+ //
+ Status = gBS->CreateEvent (EVT_NOTIFY_SIGNAL, TPL_CALLBACK, OnPciEnumerated,
+ NULL /* Context */, &PciEnumerated);
if (EFI_ERROR (Status)) {
-Status = FindAcpiTablesInFv (AcpiTable);
+return Status;
}
+ Status = gBS->RegisterProtocolNotify (
+ &gEfiPciEnumerationCompleteProtocolGuid, PciEnumerated,
+
Re: [Xen-devel] [PATCH] OvmfPkg: AcpiPlatformDxe: PCI enumeration may be disabled
On Thu, Feb 12, 2015 at 01:16:07PM +0100, Laszlo Ersek wrote: > SVN r16411 delayed ACPI table installation until PCI enumeration was > complete, because on QEMU the ACPI-related fw_cfg files should only be > downloaded after PCI enumeration. > > However, InitializeXen() in "OvmfPkg/PlatformPei/Xen.c" sets > PcdPciDisableBusEnumeration to TRUE. This causes > PciBusDriverBindingStart() in "MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c" to > set gFullEnumeration to FALSE, which in turn makes PciEnumerator() in > "MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c" branch to > PciEnumeratorLight(). The installation of > EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL at the end of PciEnumerator() is not > reached. > > Which means that starting with SVN r16411, AcpiPlatformDxe is never > dispatched on Xen. > > This patch replaces the EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL depex with a > matching protocol registration callback for the PCI enumeration enabled > (ie. QEMU) case. When PCI enumeration is disabled (ie. when running on > Xen), AcpiPlatformDxe doesn't wait for > EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Laszlo Ersek This patch fixes the bug I have. Thanks! Tested-by: Wei Liu Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] OvmfPkg: AcpiPlatformDxe: PCI enumeration may be disabled
On 02/12/15 13:29, Wei Liu wrote: > On Thu, Feb 12, 2015 at 01:16:07PM +0100, Laszlo Ersek wrote: >> SVN r16411 delayed ACPI table installation until PCI enumeration was >> complete, because on QEMU the ACPI-related fw_cfg files should only be >> downloaded after PCI enumeration. >> >> However, InitializeXen() in "OvmfPkg/PlatformPei/Xen.c" sets >> PcdPciDisableBusEnumeration to TRUE. This causes >> PciBusDriverBindingStart() in "MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c" to >> set gFullEnumeration to FALSE, which in turn makes PciEnumerator() in >> "MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c" branch to >> PciEnumeratorLight(). The installation of >> EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL at the end of PciEnumerator() is not >> reached. >> >> Which means that starting with SVN r16411, AcpiPlatformDxe is never >> dispatched on Xen. >> >> This patch replaces the EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL depex with a >> matching protocol registration callback for the PCI enumeration enabled >> (ie. QEMU) case. When PCI enumeration is disabled (ie. when running on >> Xen), AcpiPlatformDxe doesn't wait for >> EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL. >> >> Contributed-under: TianoCore Contribution Agreement 1.0 >> Signed-off-by: Laszlo Ersek > > This patch fixes the bug I have. Thanks! > > Tested-by: Wei Liu Thanks. If Jordan is okay with the patch too, I'll push it. Sorry about the regression, too. Cheers Laszlo ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] PML (Page Modification Logging) design for Xen
Hi, Thanks for posting this design! At 16:28 +0800 on 11 Feb (1423668493), Kai Huang wrote: > Design > == > > - PML feature is used globally > > A new Xen boot parameter, say 'opt_enable_pml', will be introduced to control > PML feature detection, and PML feature will only be detected if > opt_enable_pml = 1. Once PML feature is detected, it will be used for dirty > logging for all domains globally. Currently we don't support to use PML on > basis of per-domain as it will require additional control from XL tool. Sounds good. I agree that there's no point in making this a per-VM feature. > - PML enable/disable for particular Domain > > PML needs to be enabled (allocate PML buffer, initialize PML index, PML base > address, turn PML on VMCS, etc) for all vcpus of the domain, as PML buffer > and PML index are per-vcpu, but EPT table may be shared by vcpus. Enabling > PML on partial vcpus of the domain won't work. Also PML will only be enabled > for the domain when it is switched to dirty logging mode, and it will be > disabled when domain is switched back to normal mode. As looks vcpu number > won't be changed dynamically during guest is running (correct me if I am > wrong here), so we don't have to consider enabling PML for new created vcpu > when guest is in dirty logging mode. > No - you really ought to handle enabling this for new VCPUs. There have been cases in the past where VMs are put into log-dirty mode before their VCPUs are assigned, and there might be again. It ought to be easy to handle, though - just one more check and function call on the vcpu setup path. > After PML is enabled for the domain, we only need to clear EPT entry's D-bit > for guest memory in dirty logging mode. We achieve this by checking if PML is > enabled for the domain when p2m_ram_rx changed to p2m_ram_logdirty, and > updating EPT entry accordingly. However, for super pages, we still write > protect them in case of PML as we still need to split super page to 4K page > in dirty logging mode. > IIUC, you are suggesting leaving superpages handled as they are now, with read-only EPTEs, and only using PML for single-page mappings. That seems good. :) > - PML buffer flush > > There are two places we need to flush PML buffer. The first place is PML > buffer full VMEXIT handler (apparently), and the second place is in > paging_log_dirty_op (either peek or clean), as vcpus are running > asynchronously along with paging_log_dirty_op is called from userspace via > hypercall, and it's possible there are dirty GPAs logged in vcpus' PML > buffers but not full. Therefore we'd better to flush all vcpus' PML buffers > before reporting dirty GPAs to userspace. > > We handle above two cases by flushing PML buffer at the beginning of all > VMEXITs. This solves the first case above, and it also solves the second > case, as prior to paging_log_dirty_op, domain_pause is called, which kicks > vcpus (that are in guest mode) out of guest mode via sending IPI, which cause > VMEXIT, to them. > I would prefer to flush only on buffer-full VMEXITs and handle the peek/clear path by explicitly reading all VCPUs' buffers. That avoids putting more code on the fast paths for other VMEXIT types. > This also makes log-dirty radix tree more updated as PML buffer is flushed on > basis of all VMEXITs but not only PML buffer full VMEXIT. > > - Video RAM tracking (and partial dirty logging for guest memory range) > > Video RAM is in dirty logging mode unconditionally during guest's run-time, > and it is partial memory range of the guest. However, PML operates on the > whole guest memory (the whole valid EPT table, more precisely), so we need to > choose whether to use PML if only partial guest memory ranges are in dirty > logging mode. > > Currently, PML will be used as long as there's guest memory in dirty logging > mode, no matter globally or partially. And in case of partial dirty logging, > we need to check if the logged GPA in PML buffer is in dirty logging range. > I think, as other people have said, that you can just use PML for this case without any other restrictions. After all, mappings for non-VRAM areas ought not to have their D-bits clear anyway. Cheers, Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] PML (Page Modification Logging) design for Xen
At 07:08 + on 12 Feb (1423721283), Tian, Kevin wrote: > for general log dirty, ept_invalidate_emt is required because there is > access permission change (dirtied page becomes rw after 1st fault, > so need to change them back to ro again for the new dirty tracking > round). But for PML, there's no permission change at all (always rw), > so such behavior should be noted by general logdirty layer for better > optimization. AIUI the reason for calling ept_invalidate_emt() is to avoid having to update a large number of EPTEs at once. If you still need to update a large number of EPTEs (to clear the Dirty bits), that has to me preemptable, or else use ept_invalidate_emt(). Or have I misunderstood? Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] OvmfPkg: AcpiPlatformDxe: PCI enumeration may be disabled
On Thu, Feb 12, 2015 at 01:33:50PM +0100, Laszlo Ersek wrote: > On 02/12/15 13:29, Wei Liu wrote: > > On Thu, Feb 12, 2015 at 01:16:07PM +0100, Laszlo Ersek wrote: > >> SVN r16411 delayed ACPI table installation until PCI enumeration was > >> complete, because on QEMU the ACPI-related fw_cfg files should only be > >> downloaded after PCI enumeration. > >> > >> However, InitializeXen() in "OvmfPkg/PlatformPei/Xen.c" sets > >> PcdPciDisableBusEnumeration to TRUE. This causes > >> PciBusDriverBindingStart() in "MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c" to > >> set gFullEnumeration to FALSE, which in turn makes PciEnumerator() in > >> "MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c" branch to > >> PciEnumeratorLight(). The installation of > >> EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL at the end of PciEnumerator() is not > >> reached. > >> > >> Which means that starting with SVN r16411, AcpiPlatformDxe is never > >> dispatched on Xen. > >> > >> This patch replaces the EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL depex with a > >> matching protocol registration callback for the PCI enumeration enabled > >> (ie. QEMU) case. When PCI enumeration is disabled (ie. when running on > >> Xen), AcpiPlatformDxe doesn't wait for > >> EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL. > >> > >> Contributed-under: TianoCore Contribution Agreement 1.0 > >> Signed-off-by: Laszlo Ersek > > > > This patch fixes the bug I have. Thanks! > > > > Tested-by: Wei Liu > > Thanks. If Jordan is okay with the patch too, I'll push it. > > Sorry about the regression, too. > Thanks for the fix. No need to be sorry. It happens. :-) I wish I had setup a regression test side on our side earlier. Now things are getting into shape (our bisector is working on bisecting OVMF but I figured it would be faster if I just did the work myself) and hopefully we can catch regressions earlier in the future with our test system. Wei. > Cheers > Laszlo ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V3] x86 spinlock: Fix memory corruption on completing completions
On 02/12, Raghavendra K T wrote:
>
> @@ -772,7 +773,8 @@ __visible void kvm_lock_spinning(struct arch_spinlock
> *lock, __ticket_t want)
>* check again make sure it didn't become free while
>* we weren't looking.
>*/
> - if (ACCESS_ONCE(lock->tickets.head) == want) {
> + head = ACCESS_ONCE(lock->tickets.head);
> + if (__tickets_equal(head, want)) {
> add_stats(TAKEN_SLOW_PICKUP, 1);
While at it, perhaps it makes sense to s/ACCESS_ONCE/READ_ONCE/ but this
is cosmetic.
We also need to change another user of enter_slow_path, xen_lock_spinning()
in arch/x86/xen/spinlock.c.
Other than that looks correct at first glance... but this is up to
maintainers.
Oleg.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V3] x86 spinlock: Fix memory corruption on completing completions
On 02/12, Raghavendra K T wrote: > > @@ -191,8 +189,7 @@ static inline void arch_spin_unlock_wait(arch_spinlock_t > *lock) >* We need to check "unlocked" in a loop, tmp.head == head >* can be false positive because of overflow. >*/ > - if (tmp.head == (tmp.tail & ~TICKET_SLOWPATH_FLAG) || > - tmp.head != head) > + if (__tickets_equal(tmp.head, tmp.tail) || tmp.head != head) > break; Ah, it seems that "tmp.head != head" should be turned into !__tickets_equal(), no? Suppose that TICKET_SLOWPATH_FLAG is set after the first ACCESS_ONCE(head), then tmp.head != head will be true before the first unlock we are waiting for. And perhaps you can turn these ACCESS_ONCE into READ_ONCE as well. Oleg. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V3] x86 spinlock: Fix memory corruption on completing completions
Damn, sorry for noise, forgot to mention...
On 02/12, Raghavendra K T wrote:
>
> +static inline void __ticket_check_and_clear_slowpath(arch_spinlock_t *lock,
> + __ticket_t head)
> +{
> + if (head & TICKET_SLOWPATH_FLAG) {
> + arch_spinlock_t old, new;
> +
> + old.tickets.head = head;
> + new.tickets.head = head & ~TICKET_SLOWPATH_FLAG;
> + old.tickets.tail = new.tickets.head + TICKET_LOCK_INC;
> + new.tickets.tail = old.tickets.tail;
> +
> + /* try to clear slowpath flag when there are no contenders */
> + cmpxchg(&lock->head_tail, old.head_tail, new.head_tail);
> + }
> +}
...
> +clear_slowpath:
> + if (TICKET_SLOWPATH_FLAG)
> + __ticket_check_and_clear_slowpath(lock, inc.head);
I think you can remove this "if (TICKET_SLOWPATH_FLAG)" check. If it is
defined as zero, gcc should optimize out the code under "if (head & 0)".
But this is purely cosmetic and subjective, feel free to ignore.
Oleg.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] PML (Page Modification Logging) design for Xen
On 12/02/15 06:54, Tian, Kevin wrote: > >>> which presumably >>> means that the PML buffer flush needs to be aware of which gfns are >>> mapped by superpages to be able to correctly set a block of bits in the >>> logdirty bitmap. >>> >> Unfortunately PML itself can't tell us if the logged GPA comes from >> superpage or not, but even in PML we still need to split superpages to >> 4K page, just like traditional write protection approach does. I think >> this is because live migration should be based on 4K page granularity. >> Marking all 512 bits of a 2M page to be dirty by a single write doesn't >> make sense in both write protection and PML cases. >> > agree. extending one write to superpage enlarges dirty set unnecessary. > since spec doesn't say superpage logging is not supported, I'd think a > 4k-aligned entry being logged if within superpage. The spec states that an gfn is appended to the log strictly on the transition of the D bit from 0 to 1. In the case of a 2M superpage, there is a single D bit for the entire 2M range. The plausible (working) scenarios I can see are: 1) superpages are not supported (not indicated by the whitepaper). 2) a single entry will be written which must be taken to cover the entire 2M range. 3) an individual entry is written for every access. Have I missed anything? ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V3] x86 spinlock: Fix memory corruption on completing completions
On 02/12/2015 07:07 PM, Oleg Nesterov wrote:
On 02/12, Raghavendra K T wrote:
@@ -772,7 +773,8 @@ __visible void kvm_lock_spinning(struct arch_spinlock
*lock, __ticket_t want)
* check again make sure it didn't become free while
* we weren't looking.
*/
- if (ACCESS_ONCE(lock->tickets.head) == want) {
+ head = ACCESS_ONCE(lock->tickets.head);
+ if (__tickets_equal(head, want)) {
add_stats(TAKEN_SLOW_PICKUP, 1);
While at it, perhaps it makes sense to s/ACCESS_ONCE/READ_ONCE/ but this
is cosmetic.
yes.. will do.
We also need to change another user of enter_slow_path, xen_lock_spinning()
in arch/x86/xen/spinlock.c.
Had in mind but forgot before sending. will update resend.
Other than that looks correct at first glance... but this is up to
maintainers.
Thanks
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V3] x86 spinlock: Fix memory corruption on completing completions
On 02/12/2015 07:20 PM, Oleg Nesterov wrote: On 02/12, Raghavendra K T wrote: @@ -191,8 +189,7 @@ static inline void arch_spin_unlock_wait(arch_spinlock_t *lock) * We need to check "unlocked" in a loop, tmp.head == head * can be false positive because of overflow. */ - if (tmp.head == (tmp.tail & ~TICKET_SLOWPATH_FLAG) || - tmp.head != head) + if (__tickets_equal(tmp.head, tmp.tail) || tmp.head != head) break; Ah, it seems that "tmp.head != head" should be turned into !__tickets_equal(), no? Suppose that TICKET_SLOWPATH_FLAG is set after the first ACCESS_ONCE(head), then tmp.head != head will be true before the first unlock we are waiting for. Good catch. othewise we would wrongly break out even when somebody does halt wait. And perhaps you can turn these ACCESS_ONCE into READ_ONCE as well. Yes again :) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V3] x86 spinlock: Fix memory corruption on completing completions
On 02/12/2015 07:32 PM, Oleg Nesterov wrote:
Damn, sorry for noise, forgot to mention...
On 02/12, Raghavendra K T wrote:
+static inline void __ticket_check_and_clear_slowpath(arch_spinlock_t *lock,
+ __ticket_t head)
+{
+ if (head & TICKET_SLOWPATH_FLAG) {
+ arch_spinlock_t old, new;
+
+ old.tickets.head = head;
+ new.tickets.head = head & ~TICKET_SLOWPATH_FLAG;
+ old.tickets.tail = new.tickets.head + TICKET_LOCK_INC;
+ new.tickets.tail = old.tickets.tail;
+
+ /* try to clear slowpath flag when there are no contenders */
+ cmpxchg(&lock->head_tail, old.head_tail, new.head_tail);
+ }
+}
...
+clear_slowpath:
+ if (TICKET_SLOWPATH_FLAG)
+ __ticket_check_and_clear_slowpath(lock, inc.head);
I think you can remove this "if (TICKET_SLOWPATH_FLAG)" check. If it is
defined as zero, gcc should optimize out the code under "if (head & 0)".
right, the above if ( ) is unnecesary, though we would have same code
at the end, getting rid of that makes code more clean.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V3] x86 spinlock: Fix memory corruption on completing completions
On Thu, Feb 12, 2015 at 05:17:27PM +0530, Raghavendra K T wrote: > Paravirt spinlock clears slowpath flag after doing unlock. > As explained by Linus currently it does: > prev = *lock; > add_smp(&lock->tickets.head, TICKET_LOCK_INC); > > /* add_smp() is a full mb() */ > > if (unlikely(lock->tickets.tail & TICKET_SLOWPATH_FLAG)) > __ticket_unlock_slowpath(lock, prev); > > > which is *exactly* the kind of things you cannot do with spinlocks, > because after you've done the "add_smp()" and released the spinlock > for the fast-path, you can't access the spinlock any more. Exactly > because a fast-path lock might come in, and release the whole data > structure. > > Linus suggested that we should not do any writes to lock after unlock(), > and we can move slowpath clearing to fastpath lock. > > So this patch implements the fix with: > 1. Moving slowpath flag to head (Oleg). > 2. use xadd to avoid read/write after unlock that checks the need for > unlock_kick (Linus). Maybe spend a few more words explaining these things; something like: Unlocked locks don't care about the slowpath flag; therefore we can keep it set after the last unlock, as long as we clear it again on the first (try)lock -- this removes the write after unlock. By moving the slowpath flag from the tail to the head ticket we avoid the need to access both the head and tail tickets on unlock. We can further avoid the need for a read-after-release by using xadd; the prev head value will include the slowpath flag and indicate if we need to do PV kicking of suspended spinners -- on modern chips xadd isn't (much) more expensive than an add + load. Its 'obvious' now, but maybe not so much after we've all not looked at this for a few months. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] vsprintf: Make sure argument to %pX specifier is valid
On 02/12/2015 06:04 AM, Andrew Cooper wrote:
On 11/02/15 20:58, Boris Ostrovsky wrote:
If invalid pointer (i.e. something smaller than HYPERVISOR_VIRT_START)
is passed for %*ph/%pv/%ps/%pS format specifiers then print "(NULL)"
Signed-off-by: Boris Ostrovsky
---
xen/common/vsprintf.c | 23 ---
1 files changed, 16 insertions(+), 7 deletions(-)
v2:
* Print "(NULL)" instead of specifier-specific string
* Consider all addresses under HYPERVISOR_VIRT_START as invalid. (I think
this is true for both x86 and ARM but I don't have ARM platform to test).
diff --git a/xen/common/vsprintf.c b/xen/common/vsprintf.c
index 065cc42..b9542b5 100644
--- a/xen/common/vsprintf.c
+++ b/xen/common/vsprintf.c
@@ -270,6 +270,22 @@ static char *pointer(char *str, char *end, const char
**fmt_ptr,
const char *fmt = *fmt_ptr, *s;
/* Custom %p suffixes. See XEN_ROOT/docs/misc/printk-formats.txt */
+
+switch ( fmt[1] )
+{
+case 'h':
+case 's':
+case 'S':
+case 'v':
+++*fmt_ptr;
+}
+
+if ( (unsigned long)arg < HYPERVISOR_VIRT_START )
+{
+char *s = "(NULL)";
+return string(str, end, s, -1, -1, 0);
+}
+
switch ( fmt[1] )
This wont function, as you have inverted the increment of *fmt_ptr and
check of fmt[1].
fmt value doesn't change, it is stashed at the top of the routine.
(What *is* wrong in the above code is the fact that the arg test is done
outside the switch. It should be part of the four case statements,
otherwise we will print plain %p arguments as "NULL").
"(NULL)" is inappropriate for non-null pointers less than VIRT_START.
Yes, I thought about it after I sent it. "(invalid)"?
Given the VIRT check, I would just put the entire switch statement
inside an "if ( (unsigned long)arg < HYPERVISOR_VIRT_START )" block and
let it fall through to the plain number case for a bogus pointer.
Not sure I understand what you are suggesting here, sorry.
-boris
~Andrew
{
case 'h': /* Raw buffer as hex string. */
@@ -277,9 +293,6 @@ static char *pointer(char *str, char *end, const char
**fmt_ptr,
const uint8_t *hex_buffer = arg;
unsigned int i;
-/* Consumed 'h' from the format string. */
-++*fmt_ptr;
-
/* Bound user count from %* to between 0 and 64 bytes. */
if ( field_width <= 0 )
return str;
@@ -306,9 +319,6 @@ static char *pointer(char *str, char *end, const char
**fmt_ptr,
unsigned long sym_size, sym_offset;
char namebuf[KSYM_NAME_LEN+1];
-/* Advance parents fmt string, as we have consumed 's' or 'S' */
-++*fmt_ptr;
-
s = symbols_lookup((unsigned long)arg, &sym_size, &sym_offset,
namebuf);
/* If the symbol is not found, fall back to printing the address */
@@ -335,7 +345,6 @@ static char *pointer(char *str, char *end, const char
**fmt_ptr,
{
const struct vcpu *v = arg;
-++*fmt_ptr;
if ( str < end )
*str = 'd';
str = number(str + 1, end, v->domain->domain_id, 10, -1, -1, 0);
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] vsprintf: Make sure argument to %pX specifier is valid
On 12/02/15 15:01, Boris Ostrovsky wrote:
> On 02/12/2015 06:04 AM, Andrew Cooper wrote:
>> On 11/02/15 20:58, Boris Ostrovsky wrote:
>>> If invalid pointer (i.e. something smaller than HYPERVISOR_VIRT_START)
>>> is passed for %*ph/%pv/%ps/%pS format specifiers then print "(NULL)"
>>>
>>> Signed-off-by: Boris Ostrovsky
>>> ---
>>> xen/common/vsprintf.c | 23 ---
>>> 1 files changed, 16 insertions(+), 7 deletions(-)
>>>
>>> v2:
>>> * Print "(NULL)" instead of specifier-specific string
>>> * Consider all addresses under HYPERVISOR_VIRT_START as invalid.
>>> (I think
>>> this is true for both x86 and ARM but I don't have ARM platform
>>> to test).
>>>
>>>
>>> diff --git a/xen/common/vsprintf.c b/xen/common/vsprintf.c
>>> index 065cc42..b9542b5 100644
>>> --- a/xen/common/vsprintf.c
>>> +++ b/xen/common/vsprintf.c
>>> @@ -270,6 +270,22 @@ static char *pointer(char *str, char *end,
>>> const char **fmt_ptr,
>>> const char *fmt = *fmt_ptr, *s;
>>> /* Custom %p suffixes. See
>>> XEN_ROOT/docs/misc/printk-formats.txt */
>>> +
>>> +switch ( fmt[1] )
>>> +{
>>> +case 'h':
>>> +case 's':
>>> +case 'S':
>>> +case 'v':
>>> +++*fmt_ptr;
>>> +}
>>> +
>>> +if ( (unsigned long)arg < HYPERVISOR_VIRT_START )
>>> +{
>>> +char *s = "(NULL)";
>>> +return string(str, end, s, -1, -1, 0);
>>> +}
>>> +
>>> switch ( fmt[1] )
>> This wont function, as you have inverted the increment of *fmt_ptr and
>> check of fmt[1].
>
> fmt value doesn't change, it is stashed at the top of the routine.
You are correct. My apologies. I however dislike the splitting of the
switch into two.
>
> (What *is* wrong in the above code is the fact that the arg test is
> done outside the switch. It should be part of the four case
> statements, otherwise we will print plain %p arguments as "NULL").
>
>
>>
>> "(NULL)" is inappropriate for non-null pointers less than VIRT_START.
>
> Yes, I thought about it after I sent it. "(invalid)"?
Better, but overriding the number with a string does hide information.
In the case that the pointer is invalid, it would be useful to see its
contents.
>
>>
>> Given the VIRT check, I would just put the entire switch statement
>> inside an "if ( (unsigned long)arg < HYPERVISOR_VIRT_START )" block and
>> let it fall through to the plain number case for a bogus pointer.
>
> Not sure I understand what you are suggesting here, sorry.
>
> -boris
if ( (unsigned long)arg < HYPERVISOR_VIRT_START )
{
switch ( fmt[1] )
{
}
}
This makes the patch a whole 3 line addition and indenting the whole
switch block by 4 spaces.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V3] x86 spinlock: Fix memory corruption on completing completions
On 02/12/2015 08:30 PM, Peter Zijlstra wrote: On Thu, Feb 12, 2015 at 05:17:27PM +0530, Raghavendra K T wrote: [...] Linus suggested that we should not do any writes to lock after unlock(), and we can move slowpath clearing to fastpath lock. So this patch implements the fix with: 1. Moving slowpath flag to head (Oleg). 2. use xadd to avoid read/write after unlock that checks the need for unlock_kick (Linus). Maybe spend a few more words explaining these things; something like: Unlocked locks don't care about the slowpath flag; therefore we can keep it set after the last unlock, as long as we clear it again on the first (try)lock -- this removes the write after unlock. Nit: I 'll reword a bit here since slowpath flag would result in unnecessary kick but otherwise harmless IMO. something like: Unlocked locks don't care about the slowpath flag; therefore we can keep it set after the last unlock, and clear it again on the first (try)lock. -- this removes the write after unlock. note that keeping slowpath flag would result in unnecessary kicks. By moving the slowpath flag from the tail to the head ticket we avoid the need to access both the head and tail tickets on unlock. We can further avoid the need for a read-after-release by using xadd; the prev head value will include the slowpath flag and indicate if we need to do PV kicking of suspended spinners -- on modern chips xadd isn't (much) more expensive than an add + load. Its 'obvious' now, but maybe not so much after we've all not looked at this for a few months. Absolutely correct. Thanks Peter for the detailed and very helpful writeup. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] vsprintf: Make sure argument to %pX specifier is valid
On 02/12/2015 10:21 AM, Andrew Cooper wrote:
On 12/02/15 15:01, Boris Ostrovsky wrote:
On 02/12/2015 06:04 AM, Andrew Cooper wrote:
On 11/02/15 20:58, Boris Ostrovsky wrote:
If invalid pointer (i.e. something smaller than HYPERVISOR_VIRT_START)
is passed for %*ph/%pv/%ps/%pS format specifiers then print "(NULL)"
Signed-off-by: Boris Ostrovsky
---
xen/common/vsprintf.c | 23 ---
1 files changed, 16 insertions(+), 7 deletions(-)
v2:
* Print "(NULL)" instead of specifier-specific string
* Consider all addresses under HYPERVISOR_VIRT_START as invalid.
(I think
this is true for both x86 and ARM but I don't have ARM platform
to test).
diff --git a/xen/common/vsprintf.c b/xen/common/vsprintf.c
index 065cc42..b9542b5 100644
--- a/xen/common/vsprintf.c
+++ b/xen/common/vsprintf.c
@@ -270,6 +270,22 @@ static char *pointer(char *str, char *end,
const char **fmt_ptr,
const char *fmt = *fmt_ptr, *s;
/* Custom %p suffixes. See
XEN_ROOT/docs/misc/printk-formats.txt */
+
+switch ( fmt[1] )
+{
+case 'h':
+case 's':
+case 'S':
+case 'v':
+++*fmt_ptr;
+}
+
+if ( (unsigned long)arg < HYPERVISOR_VIRT_START )
+{
+char *s = "(NULL)";
+return string(str, end, s, -1, -1, 0);
+}
+
switch ( fmt[1] )
This wont function, as you have inverted the increment of *fmt_ptr and
check of fmt[1].
fmt value doesn't change, it is stashed at the top of the routine.
You are correct. My apologies. I however dislike the splitting of the
switch into two.
(What *is* wrong in the above code is the fact that the arg test is
done outside the switch. It should be part of the four case
statements, otherwise we will print plain %p arguments as "NULL").
"(NULL)" is inappropriate for non-null pointers less than VIRT_START.
Yes, I thought about it after I sent it. "(invalid)"?
Better, but overriding the number with a string does hide information.
In the case that the pointer is invalid, it would be useful to see its
contents.
How about "<0xXX>" (i.e. effectively replace "%pv" with "<%p>", with
angle brackets indicating invalid pointer)?
Given the VIRT check, I would just put the entire switch statement
inside an "if ( (unsigned long)arg < HYPERVISOR_VIRT_START )" block and
let it fall through to the plain number case for a bogus pointer.
Not sure I understand what you are suggesting here, sorry.
-boris
if ( (unsigned long)arg < HYPERVISOR_VIRT_START )
{
switch ( fmt[1] )
{
}
}
This makes the patch a whole 3 line addition and indenting the whole
switch block by 4 spaces.
Still don't understand. This will never print anything unless it's a bad
pointer, won't it?
(And if you meant '>=' then we will simply print the invalid pointer in
plain %p format. Which, btw, may be the solution but we will still need
to bump fmt_ptr, so we again will need another switch or something to
test for sub-specifier)
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [linux-next test] 34461: regressions - FAIL
flight 34461 linux-next real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34461/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-amd64 5 xen-boot fail REGR. vs. 34299 test-amd64-i386-qemut-rhel6hvm-intel 5 xen-boot fail REGR. vs. 34299 test-amd64-i386-xl-qemuu-win7-amd64 5 xen-boot fail REGR. vs. 34299 test-amd64-i386-xl-qemut-debianhvm-amd64 5 xen-boot fail REGR. vs. 34299 test-armhf-armhf-xl 12 guest-start.2 fail REGR. vs. 34299 test-amd64-i386-qemuu-rhel6hvm-intel 5 xen-boot fail REGR. vs. 34299 test-amd64-i386-xl-qemut-winxpsp3 5 xen-boot fail REGR. vs. 34299 test-amd64-i386-xl-qemut-win7-amd64 5 xen-boot fail REGR. vs. 34299 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 5 xen-boot fail REGR. vs. 34299 test-amd64-amd64-xl 5 xen-boot fail REGR. vs. 34299 test-amd64-amd64-xl-qemuu-ovmf-amd64 5 xen-boot fail REGR. vs. 34299 test-amd64-amd64-pair 8 xen-boot/dst_host fail REGR. vs. 34299 test-amd64-amd64-pair 7 xen-boot/src_host fail REGR. vs. 34299 test-amd64-i386-xl-qemuu-debianhvm-amd64 5 xen-boot fail REGR. vs. 34299 test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 34299 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail REGR. vs. 34299 test-amd64-i386-libvirt 9 guest-start fail like 34299 test-amd64-amd64-xl-sedf-pin 5 xen-boot fail REGR. vs. 34299 test-amd64-i386-freebsd10-i386 7 freebsd-install fail like 34299 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 34299 test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail like 34299 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-armhf-armhf-xl 10 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 10 migrate-support-checkfail never pass test-armhf-armhf-libvirt 10 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-armhf-armhf-xl-sedf-pin 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-libvirt 10 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 10 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 10 migrate-support-checkfail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass version targeted for testing: linuxf61b8d6d777dfb241ebe87478c5c82126ac8d687 baseline version: linux26cdd1f76a889a21faa851bcb260782db2c7f0a9 jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl fail test-armhf-armhf-xl fail test-amd64-i386-xl pass test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemu
Re: [Xen-devel] [PATCH v2] vsprintf: Make sure argument to %pX specifier is valid
On 12/02/15 15:38, Boris Ostrovsky wrote:
> On 02/12/2015 10:21 AM, Andrew Cooper wrote:
>> On 12/02/15 15:01, Boris Ostrovsky wrote:
>>> On 02/12/2015 06:04 AM, Andrew Cooper wrote:
On 11/02/15 20:58, Boris Ostrovsky wrote:
> If invalid pointer (i.e. something smaller than
> HYPERVISOR_VIRT_START)
> is passed for %*ph/%pv/%ps/%pS format specifiers then print "(NULL)"
>
> Signed-off-by: Boris Ostrovsky
> ---
>xen/common/vsprintf.c | 23 ---
>1 files changed, 16 insertions(+), 7 deletions(-)
>
> v2:
>* Print "(NULL)" instead of specifier-specific string
>* Consider all addresses under HYPERVISOR_VIRT_START as invalid.
> (I think
> this is true for both x86 and ARM but I don't have ARM platform
> to test).
>
>
> diff --git a/xen/common/vsprintf.c b/xen/common/vsprintf.c
> index 065cc42..b9542b5 100644
> --- a/xen/common/vsprintf.c
> +++ b/xen/common/vsprintf.c
> @@ -270,6 +270,22 @@ static char *pointer(char *str, char *end,
> const char **fmt_ptr,
>const char *fmt = *fmt_ptr, *s;
> /* Custom %p suffixes. See
> XEN_ROOT/docs/misc/printk-formats.txt */
> +
> +switch ( fmt[1] )
> +{
> +case 'h':
> +case 's':
> +case 'S':
> +case 'v':
> +++*fmt_ptr;
> +}
> +
> +if ( (unsigned long)arg < HYPERVISOR_VIRT_START )
> +{
> +char *s = "(NULL)";
> +return string(str, end, s, -1, -1, 0);
> +}
> +
>switch ( fmt[1] )
This wont function, as you have inverted the increment of *fmt_ptr and
check of fmt[1].
>>>
>>> fmt value doesn't change, it is stashed at the top of the routine.
>>
>> You are correct. My apologies. I however dislike the splitting of the
>> switch into two.
>>
>>>
>>> (What *is* wrong in the above code is the fact that the arg test is
>>> done outside the switch. It should be part of the four case
>>> statements, otherwise we will print plain %p arguments as "NULL").
>>>
>>>
"(NULL)" is inappropriate for non-null pointers less than VIRT_START.
>>>
>>> Yes, I thought about it after I sent it. "(invalid)"?
>>
>> Better, but overriding the number with a string does hide information.
>> In the case that the pointer is invalid, it would be useful to see its
>> contents.
>
>
> How about "<0xXX>" (i.e. effectively replace "%pv" with "<%p>",
> with angle brackets indicating invalid pointer)?
>
It feels like change for change sake, especially as there is a perfectly
good hex decode for plain %p.
>
>>
>>>
Given the VIRT check, I would just put the entire switch statement
inside an "if ( (unsigned long)arg < HYPERVISOR_VIRT_START )" block
and
let it fall through to the plain number case for a bogus pointer.
>>>
>>> Not sure I understand what you are suggesting here, sorry.
>>>
>>> -boris
>>
>> if ( (unsigned long)arg < HYPERVISOR_VIRT_START )
>> {
>> switch ( fmt[1] )
>> {
>>
>> }
>> }
>>
>>
>> This makes the patch a whole 3 line addition and indenting the whole
>> switch block by 4 spaces.
>
> Still don't understand. This will never print anything unless it's a
> bad pointer, won't it?
>
> (And if you meant '>=' then we will simply print the invalid pointer
> in plain %p format. Which, btw, may be the solution but we will still
> need to bump fmt_ptr, so we again will need another switch or
> something to test for sub-specifier)
Oops - I did mean >=. I.e. only do the custom %pX decoding in the case
that arg is a plausible pointer.
There is no need I can see to alter the fmt_ptr handling. The code
currently works, other than the issue at hand of falling over a bad pointer.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] vsprintf: Make sure argument to %pX specifier is valid
On 02/12/2015 10:48 AM, Andrew Cooper wrote:
On 12/02/15 15:38, Boris Ostrovsky wrote:
On 02/12/2015 10:21 AM, Andrew Cooper wrote:
On 12/02/15 15:01, Boris Ostrovsky wrote:
On 02/12/2015 06:04 AM, Andrew Cooper wrote:
On 11/02/15 20:58, Boris Ostrovsky wrote:
If invalid pointer (i.e. something smaller than
HYPERVISOR_VIRT_START)
is passed for %*ph/%pv/%ps/%pS format specifiers then print "(NULL)"
Signed-off-by: Boris Ostrovsky
---
xen/common/vsprintf.c | 23 ---
1 files changed, 16 insertions(+), 7 deletions(-)
v2:
* Print "(NULL)" instead of specifier-specific string
* Consider all addresses under HYPERVISOR_VIRT_START as invalid.
(I think
this is true for both x86 and ARM but I don't have ARM platform
to test).
diff --git a/xen/common/vsprintf.c b/xen/common/vsprintf.c
index 065cc42..b9542b5 100644
--- a/xen/common/vsprintf.c
+++ b/xen/common/vsprintf.c
@@ -270,6 +270,22 @@ static char *pointer(char *str, char *end,
const char **fmt_ptr,
const char *fmt = *fmt_ptr, *s;
/* Custom %p suffixes. See
XEN_ROOT/docs/misc/printk-formats.txt */
+
+switch ( fmt[1] )
+{
+case 'h':
+case 's':
+case 'S':
+case 'v':
+++*fmt_ptr;
+}
+
+if ( (unsigned long)arg < HYPERVISOR_VIRT_START )
+{
+char *s = "(NULL)";
+return string(str, end, s, -1, -1, 0);
+}
+
switch ( fmt[1] )
This wont function, as you have inverted the increment of *fmt_ptr and
check of fmt[1].
fmt value doesn't change, it is stashed at the top of the routine.
You are correct. My apologies. I however dislike the splitting of the
switch into two.
(What *is* wrong in the above code is the fact that the arg test is
done outside the switch. It should be part of the four case
statements, otherwise we will print plain %p arguments as "NULL").
"(NULL)" is inappropriate for non-null pointers less than VIRT_START.
Yes, I thought about it after I sent it. "(invalid)"?
Better, but overriding the number with a string does hide information.
In the case that the pointer is invalid, it would be useful to see its
contents.
How about "<0xXX>" (i.e. effectively replace "%pv" with "<%p>",
with angle brackets indicating invalid pointer)?
It feels like change for change sake, especially as there is a perfectly
good hex decode for plain %p.
Given the VIRT check, I would just put the entire switch statement
inside an "if ( (unsigned long)arg < HYPERVISOR_VIRT_START )" block
and
let it fall through to the plain number case for a bogus pointer.
Not sure I understand what you are suggesting here, sorry.
-boris
if ( (unsigned long)arg < HYPERVISOR_VIRT_START )
{
switch ( fmt[1] )
{
}
}
This makes the patch a whole 3 line addition and indenting the whole
switch block by 4 spaces.
Still don't understand. This will never print anything unless it's a
bad pointer, won't it?
(And if you meant '>=' then we will simply print the invalid pointer
in plain %p format. Which, btw, may be the solution but we will still
need to bump fmt_ptr, so we again will need another switch or
something to test for sub-specifier)
Oops - I did mean >=. I.e. only do the custom %pX decoding in the case
that arg is a plausible pointer.
There is no need I can see to alter the fmt_ptr handling. The code
currently works, other than the issue at hand of falling over a bad pointer.
We do, otherwise we will be printing the sub-specifier. Here is example
of what happens if we don't bump it:
struct vcpu *badvcpu = NULL;
printk("badvcpu: %pv current: %pv\n", badvcpu, current);
console:
badvcpu: v current: d0v0
Also, for %*ph format, if we just go with falling through to plain
format and not marking somehow that we are printing a bad pointer:
unsigned badval = 0xab;
unsigned *badptr = &badval;
printk("badptr = %*ph\n", 1, badptr);
console:
badptr = ab
We don't know here whether badptr was pointing to 0xab or it itself was
0xab.
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [linux-3.14 test] 34468: regressions - FAIL
flight 34468 linux-3.14 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34468/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemut-rhel6hvm-intel 11 leak-check/check fail REGR. vs. 34268 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-sedf 9 guest-start fail REGR. vs. 34268 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 34268 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-sedf-pin 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-armhf-armhf-xl 10 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 10 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-amd64-amd64-libvirt 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-libvirt 10 migrate-support-checkfail never pass test-armhf-armhf-libvirt 10 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 10 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass version targeted for testing: linuxa74f1d1204a5c892466b52ac68ee6443c1e459d7 baseline version: linux4ccf212fb84d79b75fc66a2e26ac6bdbab0aedbf People who touched revisions under test: Aaro Koskinen Andrew Morton Andy Lutomirski Bjorn Helgaas Bo Shen Catalin Marinas Charlotte Richardson David Daney David S. Miller Dmitry Monakhov Eric Dumazet Eric Nelson Felix Fietkau Greg Kroah-Hartman Hemmo Nieminen hujianyang Jaroslav Kysela Jeff Layton Johan Hovold karl beldan Karl Beldan Lai Jiangshan Linus Torvalds Linus Walleij Mark Brown Mark Rutland Mathias Krause Michal Marek Naoya Horiguchi Paolo Bonzini Pavel Hofman Peter Kümmel Ralf Baechle Raymond Ngun Russell King Ryusuke Konishi Sachin Prabhu Shiraz Hashim Shirish Pargaonkar Steve French Takashi Iwai Theodore Ts'o Thomas Gleixner Wang Kai Will Deacon jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64
Re: [Xen-devel] [PATCH v2] vsprintf: Make sure argument to %pX specifier is valid
On 02/12/2015 11:33 AM, Boris Ostrovsky wrote:
Also, for %*ph format, if we just go with falling through to plain
format and not marking somehow that we are printing a bad pointer:
unsigned badval = 0xab;
unsigned *badptr = &badval;
printk("badptr = %*ph\n", 1, badptr);
console:
badptr = ab
We don't know here whether badptr was pointing to 0xab or it itself
was 0xab.
Ugh, bad example. Here is what I meant:
unsigned badval = 0xab;
unsigned *badptr = &badval;
unsigned *badvalptr = (void *)0xab;
printk("badvalptr = %*ph badptr = %*ph\n", 1, badvalptr, 1, badptr);
console:
badvalptr = ab badptr = ab
Sorry.
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] pvSCSI test
On Monday, February 9, 2015 07:02, Juergen Gross wrote: > To: Kristian Hagsted Rasmussen; Olaf Hering; xen-de...@lists.xensource.com > Subject: Re: [Xen-devel] pvSCSI test snip > > No, that's okay. The connection between p-dev and the drive is done > via the target infrastructure. > > Something seems to be wrong with your link in configfs: the target > seems not to be active. Could you please check the link to be correct? > Please check whether the pscsi (or iblock) entry is active. This can > be done via the "ls" command in targetcli for example. > In targetcli, ls returns: o- / . [...] o- backstores .. [...] | o- fileio ... [0 Storage Object] | o- iblock ... [0 Storage Object] | o- pscsi [1 Storage Object] | | o- 3:0:0:0 .. [/dev/sdb activated] | o- rd_dr [0 Storage Object] | o- rd_mcp ... [0 Storage Object] o- ib_srpt ... [0 Targets] o- iscsi . [0 Targets] o- loopback .. [0 Targets] o- qla2xxx ... [0 Targets] o- tcm_fc [0 Targets] And my script for starting xen-pvscsi is this: modprobe xen-scsiback mkdir /sys/kernel/config/target/xen-pvscsi mkdir -p /sys/kernel/config/target/xen-pvscsi/naa.600140512a981c66/tpgt_0 echo naa.6001405708ab297e > /sys/kernel/config/target/xen-pvscsi/naa.600140512a981c66/tpgt_0/nexus pvscsi Target Ports mkdir -p /sys/kernel/config/target/xen-pvscsi/naa.600140512a981c66/tpgt_0/lun/lun_0 ln -s /sys/kernel/config/target/core/pscsi_0/3:0:0:0 /sys/kernel/config/target/xen-pvscsi/naa.600140512a981c66/tpgt_0/lun/lun_0/xen-pvscsi_port Attributes for pvscsi Target Portal Group Parameters for pvscsi Target Portal Group echo "3:0:0:0" > /sys/kernel/config/target/xen-pvscsi/naa.600140512a981c66/tpgt_0/param/alias I hope you can spot my error, as I am a little lost right now. > When I tested the pscsi entry in configfs switched to "active" when I > linked the xen-pvscsi entry to it. > >> Do I have to manually add the device to xenstore? > > I never did it. :-) > > > Juergen > >> >> If you do not feel for answering more of my questions please feel free to >> say so, I am just interested in this work and really look forward to its >> inclusion in xen. >> >> /Kristian >> >>> You are not using pscsi, but iblock. Is that on purpose? I have tested >>> pscsi and fileio only. >>> >>> What does lsscsi tell you after adding the device via targetcli? I >>> suppose you see a new scsi target you should use instead of 3:0:0:0 >>> (that's what I did in the fileio case). >>> I do not see more devices with lsscsi when I add and iBlock devices, however I also tested with a fileIO device, this does also not show up in lsscsi. However I can get it to show up by making a loopback entry in targetcli, this however does not change the outcome of my domain creation. Best regards Kristian ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] vsprintf: Make sure argument to %pX specifier is valid
On 12/02/15 16:33, Boris Ostrovsky wrote:
> On 02/12/2015 10:48 AM, Andrew Cooper wrote:
>> On 12/02/15 15:38, Boris Ostrovsky wrote:
>>> On 02/12/2015 10:21 AM, Andrew Cooper wrote:
On 12/02/15 15:01, Boris Ostrovsky wrote:
> On 02/12/2015 06:04 AM, Andrew Cooper wrote:
>> On 11/02/15 20:58, Boris Ostrovsky wrote:
>>> If invalid pointer (i.e. something smaller than
>>> HYPERVISOR_VIRT_START)
>>> is passed for %*ph/%pv/%ps/%pS format specifiers then print
>>> "(NULL)"
>>>
>>> Signed-off-by: Boris Ostrovsky
>>> ---
>>> xen/common/vsprintf.c | 23 ---
>>> 1 files changed, 16 insertions(+), 7 deletions(-)
>>>
>>> v2:
>>> * Print "(NULL)" instead of specifier-specific string
>>> * Consider all addresses under HYPERVISOR_VIRT_START as
>>> invalid.
>>> (I think
>>> this is true for both x86 and ARM but I don't have ARM
>>> platform
>>> to test).
>>>
>>>
>>> diff --git a/xen/common/vsprintf.c b/xen/common/vsprintf.c
>>> index 065cc42..b9542b5 100644
>>> --- a/xen/common/vsprintf.c
>>> +++ b/xen/common/vsprintf.c
>>> @@ -270,6 +270,22 @@ static char *pointer(char *str, char *end,
>>> const char **fmt_ptr,
>>> const char *fmt = *fmt_ptr, *s;
>>> /* Custom %p suffixes. See
>>> XEN_ROOT/docs/misc/printk-formats.txt */
>>> +
>>> +switch ( fmt[1] )
>>> +{
>>> +case 'h':
>>> +case 's':
>>> +case 'S':
>>> +case 'v':
>>> +++*fmt_ptr;
>>> +}
>>> +
>>> +if ( (unsigned long)arg < HYPERVISOR_VIRT_START )
>>> +{
>>> +char *s = "(NULL)";
>>> +return string(str, end, s, -1, -1, 0);
>>> +}
>>> +
>>> switch ( fmt[1] )
>> This wont function, as you have inverted the increment of
>> *fmt_ptr and
>> check of fmt[1].
> fmt value doesn't change, it is stashed at the top of the routine.
You are correct. My apologies. I however dislike the splitting of
the
switch into two.
> (What *is* wrong in the above code is the fact that the arg test is
> done outside the switch. It should be part of the four case
> statements, otherwise we will print plain %p arguments as "NULL").
>
>
>> "(NULL)" is inappropriate for non-null pointers less than
>> VIRT_START.
> Yes, I thought about it after I sent it. "(invalid)"?
Better, but overriding the number with a string does hide information.
In the case that the pointer is invalid, it would be useful to see its
contents.
>>>
>>> How about "<0xXX>" (i.e. effectively replace "%pv" with "<%p>",
>>> with angle brackets indicating invalid pointer)?
>>>
>> It feels like change for change sake, especially as there is a perfectly
>> good hex decode for plain %p.
>>
>> Given the VIRT check, I would just put the entire switch statement
>> inside an "if ( (unsigned long)arg < HYPERVISOR_VIRT_START )" block
>> and
>> let it fall through to the plain number case for a bogus pointer.
> Not sure I understand what you are suggesting here, sorry.
>
> -boris
if ( (unsigned long)arg < HYPERVISOR_VIRT_START )
{
switch ( fmt[1] )
{
}
}
This makes the patch a whole 3 line addition and indenting the whole
switch block by 4 spaces.
>>> Still don't understand. This will never print anything unless it's a
>>> bad pointer, won't it?
>>>
>>> (And if you meant '>=' then we will simply print the invalid pointer
>>> in plain %p format. Which, btw, may be the solution but we will still
>>> need to bump fmt_ptr, so we again will need another switch or
>>> something to test for sub-specifier)
>> Oops - I did mean >=. I.e. only do the custom %pX decoding in the case
>> that arg is a plausible pointer.
>>
>> There is no need I can see to alter the fmt_ptr handling. The code
>> currently works, other than the issue at hand of falling over a bad
>> pointer.
>
> We do, otherwise we will be printing the sub-specifier. Here is
> example of what happens if we don't bump it:
>
> struct vcpu *badvcpu = NULL;
> printk("badvcpu: %pv current: %pv\n", badvcpu, current);
>
> console:
> badvcpu: v current: d0v0
>
Ah - I see what you mean now.
>
> Also, for %*ph format, if we just go with falling through to plain
> format and not marking somehow that we are printing a bad pointer:
>
> unsigned badval = 0xab;
> unsigned *badptr = &badval;
> printk("badptr = %*ph\n", 1, badptr);
>
> console:
> badptr = ab
>
> We don't know here whether badptr was pointing to 0xab or it itself
> was 0xab.
Ok. As this is only for making debug code less fragile, it probably is
better to explicitly call out a bad pointer differently.
~Andrew
Re: [Xen-devel] [PATCH] x86 spinlock: Fix memory corruption on completing completions
On 02/11, Jeremy Fitzhardinge wrote: > > On 02/11/2015 09:24 AM, Oleg Nesterov wrote: > > I agree, and I have to admit I am not sure I fully understand why > > unlock uses the locked add. Except we need a barrier to avoid the race > > with the enter_slowpath() users, of course. Perhaps this is the only > > reason? > > Right now it needs to be a locked operation to prevent read-reordering. > x86 memory ordering rules state that all writes are seen in a globally > consistent order, and are globally ordered wrt reads *on the same > addresses*, but reads to different addresses can be reordered wrt to writes. > > So, if the unlocking add were not a locked operation: > > __add(&lock->tickets.head, TICKET_LOCK_INC); /* not locked */ > > if (unlikely(lock->tickets.tail & TICKET_SLOWPATH_FLAG)) > __ticket_unlock_slowpath(lock, prev); > > Then the read of lock->tickets.tail can be reordered before the unlock, > which introduces a race: Yes, yes, thanks, but this is what I meant. We need a barrier. Even if "Every store is a release" as Linus mentioned. > This *might* be OK, but I think it's on dubious ground: > > __add(&lock->tickets.head, TICKET_LOCK_INC); /* not locked */ > > /* read overlaps write, and so is ordered */ > if (unlikely(lock->head_tail & (TICKET_SLOWPATH_FLAG << TICKET_SHIFT)) > __ticket_unlock_slowpath(lock, prev); > > because I think Intel and AMD differed in interpretation about how > overlapping but different-sized reads & writes are ordered (or it simply > isn't architecturally defined). can't comment, I simply so not know how the hardware works. > If the slowpath flag is moved to head, then it would always have to be > locked anyway, because it needs to be atomic against other CPU's RMW > operations setting the flag. Yes, this is true. But again, if we want to avoid the read-after-unlock, we need to update this lock and read SLOWPATH atomically, it seems that we can't avoid the locked insn. Oleg. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] stubdom vtpm build failure in staging
Sorry for that. Read the other thread of email, it looks that some maintainers
are working for this issue.
And I am working for 'Xen stubdom vTPM for HVM virtual machine' v4 patches.
There are a lot of modifications.
I will be out of office from Feb. 16th to Feb. 26th for Chinese New Year. I
plan to summit v4 patches
Before Feb. 16, and fix this issue after Feb. 26th.
--Quan
> -Original Message-
> From: Olaf Hering [mailto:o...@aepfle.de]
> Sent: Wednesday, February 11, 2015 11:21 PM
> To: Xu, Quan
> Cc: xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] stubdom vtpm build failure in staging
>
> On Wed, Jan 28, Xu, Quan wrote:
>
> > Thanks, I will check and fix it tomorrow. It is 23:12 PM Pacific time now.
>
> Any progress?
> These typedefs are duplicated in stubdom/vtpmmgr/tcg.h and supported
> compilers do not cope with current staging:
>
> # for i in `grep -w typedef stubdom/vtpmmgr/tcg.h | sed -n '/;/{s@^.*
> @@;s@;@@p}'` # do
> # if test -n "`git grep -wn $i|grep -w typedef|grep -v
> stubdom/vtpmmgr/tcg.h`"
> # then
> # echo $i
> # fi
> # done
>
> BYTE
> BOOL
> UINT16
> UINT32
> UINT64
> TPM_HANDLE
> TPM_ALGORITHM_ID
>
> TPMI_RH_HIERARCHY_AUTH and TPM_ALG_ID are defined twice in the same
> file.
>
> This change works for me:
>
> ---
> stubdom/vtpmmgr/odd_types.h | 11 +++
> stubdom/vtpmmgr/tcg.h| 9 +
> stubdom/vtpmmgr/tpm2_types.h | 11 +--
> 3 files changed, 13 insertions(+), 18 deletions(-) create mode 100644
> stubdom/vtpmmgr/odd_types.h
>
> diff --git a/stubdom/vtpmmgr/odd_types.h b/stubdom/vtpmmgr/odd_types.h
> new file mode 100644 index 000..d72da9b
> --- /dev/null
> +++ b/stubdom/vtpmmgr/odd_types.h
> @@ -0,0 +1,11 @@
> +#ifndef VTPM_ODD_TYPES
> +#define VTPM_ODD_TYPES 1
> +typedef unsigned char BYTE;
> +typedef unsigned char BOOL;
> +typedef uint16_t UINT16;
> +typedef uint32_t UINT32;
> +typedef uint64_t UINT64;
> +typedef UINT32 TPM_HANDLE;
> +typedef UINT32 TPM_ALGORITHM_ID;
> +#endif
> +
> diff --git a/stubdom/vtpmmgr/tcg.h b/stubdom/vtpmmgr/tcg.h index
> 7321ec6..cac1bbc 100644
> --- a/stubdom/vtpmmgr/tcg.h
> +++ b/stubdom/vtpmmgr/tcg.h
> @@ -401,16 +401,10 @@
>
>
> // *** TYPEDEFS
> * -typedef unsigned char BYTE;
> -typedef unsigned char BOOL; -typedef uint16_t UINT16; -typedef uint32_t
> UINT32; -typedef uint64_t UINT64;
> -
> +#include "odd_types.h"
> typedef UINT32 TPM_RESULT;
> typedef UINT32 TPM_PCRINDEX;
> typedef UINT32 TPM_DIRINDEX;
> -typedef UINT32 TPM_HANDLE;
> typedef TPM_HANDLE TPM_AUTHHANDLE;
> typedef TPM_HANDLE TCPA_HASHHANDLE;
> typedef TPM_HANDLE TCPA_HMACHANDLE;
> @@ -422,7 +416,6 @@ typedef UINT32 TPM_COMMAND_CODE; typedef
> UINT16 TPM_PROTOCOL_ID; typedef BYTE TPM_AUTH_DATA_USAGE;
> typedef UINT16 TPM_ENTITY_TYPE; -typedef UINT32 TPM_ALGORITHM_ID;
> typedef UINT16 TPM_KEY_USAGE; typedef UINT16 TPM_STARTUP_TYPE;
> typedef UINT32 TPM_CAPABILITY_AREA; diff --git
> a/stubdom/vtpmmgr/tpm2_types.h b/stubdom/vtpmmgr/tpm2_types.h index
> ac2830d..63564cd 100644
> --- a/stubdom/vtpmmgr/tpm2_types.h
> +++ b/stubdom/vtpmmgr/tpm2_types.h
> @@ -83,12 +83,8 @@
> #defineMAX_ECC_KEY_BYTES((MAX_ECC_KEY_BITS + 7) / 8)
>
>
> -typedef unsigned char BYTE;
> -typedef unsigned char BOOL;
> +#include "odd_types.h"
> typedef uint8_t UINT8;
> -typedef uint16_t UINT16;
> -typedef uint32_t UINT32;
> -typedef uint64_t UINT64;
>
> // TPM2 command code
>
> @@ -216,7 +212,6 @@ typedef UINT16 TPM_ST;
>
>
> // TPM Handle types
> -typedef UINT32 TPM_HANDLE;
> typedef UINT8 TPM_HT;
>
>
> @@ -233,7 +228,6 @@ typedef UINT32 TPM_RH;
> #defineTPM_RH_LAST (TPM_RH)(0x400C)
>
> // Table 4 -- DocumentationClarity Types
> -typedef UINT32TPM_ALGORITHM_ID;
> typedef UINT32TPM_MODIFIER_INDICATOR;
> typedef UINT32TPM_SESSION_OFFSET;
> typedef UINT16TPM_KEY_SIZE;
> @@ -261,8 +255,6 @@ typedef BYTE TPMA_LOCALITY; // Table 37 --
> TPMI_YES_NO Type typedef BYTE TPMI_YES_NO;
>
> -typedef TPM_HANDLE TPMI_RH_HIERARCHY_AUTH;
> -
> // Table 38 -- TPMI_DH_OBJECT Type typedef TPM_HANDLE
> TPMI_DH_OBJECT;
>
> @@ -304,7 +296,6 @@ typedef TPM_HANDLE TPMI_RH_LOCKOUT;
>
> // Table 7 -- TPM_ALG_ID
> typedef UINT16 TPM_ALG_ID;
> -typedef UINT16 TPM_ALG_ID;
>
> #defineTPM2_ALG_ERROR (TPM_ALG_ID)(0x) // a: ; D:
> #defineTPM2_ALG_FIRST (TPM_ALG_ID)(0x0001) // a: ; D:
>
> Olaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 02/20] x86/shadow: Rename hash_foreach() to hash_vcpu_foreach()
A later change requires the introduction of a domain variant.
Signed-off-by: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/mm/shadow/common.c | 31 +++
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 502e0d8..2e4954f 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -1999,12 +1999,11 @@ void shadow_hash_delete(struct vcpu *v, unsigned long
n, unsigned int t,
sh_hash_audit_bucket(d, key);
}
-typedef int (*hash_callback_t)(struct vcpu *v, mfn_t smfn, mfn_t other_mfn);
+typedef int (*hash_vcpu_callback_t)(struct vcpu *v, mfn_t smfn, mfn_t
other_mfn);
-static void hash_foreach(struct vcpu *v,
- unsigned int callback_mask,
- const hash_callback_t callbacks[],
- mfn_t callback_mfn)
+static void hash_vcpu_foreach(struct vcpu *v, unsigned int callback_mask,
+ const hash_vcpu_callback_t callbacks[],
+ mfn_t callback_mfn)
/* Walk the hash table looking at the types of the entries and
* calling the appropriate callback function for each entry.
* The mask determines which shadow types we call back for, and the array
@@ -2140,7 +2139,7 @@ int sh_remove_write_access(struct vcpu *v, mfn_t gmfn,
unsigned long fault_addr)
{
/* Dispatch table for getting per-type functions */
-static const hash_callback_t callbacks[SH_type_unused] = {
+static const hash_vcpu_callback_t callbacks[SH_type_unused] = {
NULL, /* none*/
SHADOW_INTERNAL_NAME(sh_rm_write_access_from_l1, 2), /* l1_32 */
SHADOW_INTERNAL_NAME(sh_rm_write_access_from_l1, 2), /* fl1_32 */
@@ -2334,7 +2333,7 @@ int sh_remove_write_access(struct vcpu *v, mfn_t gmfn,
perfc_incr(shadow_writeable_bf_1);
else
perfc_incr(shadow_writeable_bf);
-hash_foreach(v, callback_mask, callbacks, gmfn);
+hash_vcpu_foreach(v, callback_mask, callbacks, gmfn);
/* If that didn't catch the mapping, then there's some non-pagetable
* mapping -- ioreq page, grant mapping, &c. */
@@ -2390,7 +2389,7 @@ static int sh_remove_all_mappings(struct vcpu *v, mfn_t
gmfn)
struct page_info *page = mfn_to_page(gmfn);
/* Dispatch table for getting per-type functions */
-static const hash_callback_t callbacks[SH_type_unused] = {
+static const hash_vcpu_callback_t callbacks[SH_type_unused] = {
NULL, /* none*/
SHADOW_INTERNAL_NAME(sh_rm_mappings_from_l1, 2), /* l1_32 */
SHADOW_INTERNAL_NAME(sh_rm_mappings_from_l1, 2), /* fl1_32 */
@@ -2432,7 +2431,7 @@ static int sh_remove_all_mappings(struct vcpu *v, mfn_t
gmfn)
/* Brute-force search of all the shadows, by walking the hash */
perfc_incr(shadow_mappings_bf);
-hash_foreach(v, callback_mask, callbacks, gmfn);
+hash_vcpu_foreach(v, callback_mask, callbacks, gmfn);
/* If that didn't catch the mapping, something is very wrong */
if ( !sh_check_page_has_no_refs(page) )
@@ -2533,7 +2532,7 @@ void sh_remove_shadows(struct vcpu *v, mfn_t gmfn, int
fast, int all)
/* Dispatch table for getting per-type functions: each level must
* be called with the function to remove a lower-level shadow. */
-static const hash_callback_t callbacks[SH_type_unused] = {
+static const hash_vcpu_callback_t callbacks[SH_type_unused] = {
NULL, /* none*/
NULL, /* l1_32 */
NULL, /* fl1_32 */
@@ -2594,7 +2593,7 @@ void sh_remove_shadows(struct vcpu *v, mfn_t gmfn, int
fast, int all)
perfc_incr(shadow_unshadow);
/* Lower-level shadows need to be excised from upper-level shadows.
- * This call to hash_foreach() looks dangerous but is in fact OK: each
+ * This call to hash_vcpu_foreach() looks dangerous but is in fact OK: each
* call will remove at most one shadow, and terminate immediately when
* it does remove it, so we never walk the hash after doing a deletion. */
#define DO_UNSHADOW(_type) do { \
@@ -2617,7 +2616,7 @@ void sh_remove_shadows(struct vcpu *v, mfn_t gmfn, int
fast, int all)
if( !fast \
&& (pg->count_info & PGC_page_table)\
&& (pg->shadow_flags & (1 << t)) ) \
-hash_foreach(v, masks[t], callbacks, smfn); \
+hash_vcpu_foreach(v, masks[t], callbacks, smfn);\
} while (0)
DO_UNSHADOW(SH_type_l2_32_shadow);
@@ -2678,7 +2677,7 @@ static int sh_clear_up_pointer(struct vcpu *v, mfn_t
smfn, mfn_t unused)
void sh_reset_l3_up_pointers(struct vcpu *v)
{
-static const hash_callback_t callbacks[SH_type_unused] = {
+static const hash_vcpu_callb
[Xen-devel] [PATCH 04/20] x86/shadow: Only apply shadow heuristics when in guest context
It is incorrect to be applying these heuristics because of toolstack actions.
As the vcpu parameters are to be replaced with domain parameters, guest
context is identified by using current->domain.
Note that the majority of the heuristics in sh_remove_write_access() were
already restricted to guest context, but they are updated to use 'curr' for
clarity.
Signed-off-by: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/mm/shadow/common.c | 21 +
xen/arch/x86/mm/shadow/multi.c | 13 +
2 files changed, 22 insertions(+), 12 deletions(-)
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 3b5ef19..26dab30 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -2170,6 +2170,9 @@ int sh_remove_write_access(struct vcpu *v, mfn_t gmfn,
;
struct domain *d = v->domain;
struct page_info *pg = mfn_to_page(gmfn);
+#if SHADOW_OPTIMIZATIONS & SHOPT_WRITABLE_HEURISTIC
+struct vcpu *curr = current;
+#endif
ASSERT(paging_locked_by_me(d));
@@ -2205,7 +2208,7 @@ int sh_remove_write_access(struct vcpu *v, mfn_t gmfn,
}
#if SHADOW_OPTIMIZATIONS & SHOPT_WRITABLE_HEURISTIC
-if ( v == current )
+if ( curr->domain == d )
{
unsigned long gfn;
/* Heuristic: there is likely to be only one writeable mapping,
@@ -2213,7 +2216,8 @@ int sh_remove_write_access(struct vcpu *v, mfn_t gmfn,
* in the guest's linear map (on non-HIGHPTE linux and windows)*/
#define GUESS(_a, _h) do { \
-if ( v->arch.paging.mode->shadow.guess_wrmap(v, (_a), gmfn) ) \
+if ( curr->arch.paging.mode->shadow.guess_wrmap(\
+ curr, (_a), gmfn) )\
perfc_incr(shadow_writeable_h_ ## _h); \
if ( (pg->u.inuse.type_info & PGT_count_mask) == 0 )\
{ \
@@ -,7 +2226,7 @@ int sh_remove_write_access(struct vcpu *v, mfn_t gmfn,
} \
} while (0)
-if ( v->arch.paging.mode->guest_levels == 2 )
+if ( curr->arch.paging.mode->guest_levels == 2 )
{
if ( level == 1 )
/* 32bit non-PAE w2k3: linear map at 0xC000 */
@@ -2237,7 +2241,7 @@ int sh_remove_write_access(struct vcpu *v, mfn_t gmfn,
GUESS(0xBFC0UL
+ ((fault_addr & VADDR_MASK) >> 10), 6);
}
-else if ( v->arch.paging.mode->guest_levels == 3 )
+else if ( curr->arch.paging.mode->guest_levels == 3 )
{
/* 32bit PAE w2k3: linear map at 0xC000 */
switch ( level )
@@ -2259,7 +2263,7 @@ int sh_remove_write_access(struct vcpu *v, mfn_t gmfn,
+ ((fault_addr & VADDR_MASK) >> 18), 6); break;
}
}
-else if ( v->arch.paging.mode->guest_levels == 4 )
+else if ( curr->arch.paging.mode->guest_levels == 4 )
{
/* 64bit w2k3: linear map at 0xf680 */
switch ( level )
@@ -2312,14 +2316,15 @@ int sh_remove_write_access(struct vcpu *v, mfn_t gmfn,
* the writeable mapping by looking at the same MFN where the last
* brute-force search succeeded. */
-if ( v->arch.paging.shadow.last_writeable_pte_smfn != 0 )
+if ( (curr->domain == d) &&
+ (curr->arch.paging.shadow.last_writeable_pte_smfn != 0) )
{
unsigned long old_count = (pg->u.inuse.type_info & PGT_count_mask);
-mfn_t last_smfn = _mfn(v->arch.paging.shadow.last_writeable_pte_smfn);
+mfn_t last_smfn =
_mfn(curr->arch.paging.shadow.last_writeable_pte_smfn);
int shtype = mfn_to_page(last_smfn)->u.sh.type;
if ( callbacks[shtype] )
-callbacks[shtype](v, last_smfn, gmfn);
+callbacks[shtype](curr, last_smfn, gmfn);
if ( (pg->u.inuse.type_info & PGT_count_mask) != old_count )
perfc_incr(shadow_writeable_h_5);
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index b538997..f532bff 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -4185,6 +4185,8 @@ sh_update_cr3(struct vcpu *v, int do_locking)
int sh_rm_write_access_from_sl1p(struct vcpu *v, mfn_t gmfn,
mfn_t smfn, unsigned long off)
{
+struct domain *d = v->domain;
+struct vcpu *curr = current;
int r;
shadow_l1e_t *sl1p, sl1e;
struct page_info *sp;
@@ -4193,9 +4195,9 @@ int sh_rm_write_access_from_sl1p(struct vcpu *v, mfn_t
gmfn,
ASSERT(mfn_valid(smfn));
/* Remember if we've been told that this process is being torn down */
-v->arch.paging.shadow.pagetable_dying
-= !!(mfn_to_page(gmfn)->sh
[Xen-devel] [PATCH 07/20] x86/shadow: Alter sh_type_{is_pinnable, has_up_pointer}() to take a domain
Signed-off-by: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/mm/shadow/common.c |7 ---
xen/arch/x86/mm/shadow/multi.c | 10 +-
xen/arch/x86/mm/shadow/private.h | 18 ++
3 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 80174df..bdb19fb 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -2472,6 +2472,7 @@ static int sh_remove_shadow_via_pointer(struct vcpu *v,
mfn_t smfn)
/* Follow this shadow's up-pointer, if it has one, and remove the reference
* found there. Returns 1 if that was the only reference to this shadow */
{
+struct domain *d = v->domain;
struct page_info *sp = mfn_to_page(smfn);
mfn_t pmfn;
void *vaddr;
@@ -2479,7 +2480,7 @@ static int sh_remove_shadow_via_pointer(struct vcpu *v,
mfn_t smfn)
ASSERT(sp->u.sh.type > 0);
ASSERT(sp->u.sh.type < SH_type_max_shadow);
-ASSERT(sh_type_has_up_pointer(v, sp->u.sh.type));
+ASSERT(sh_type_has_up_pointer(d, sp->u.sh.type));
if (sp->up == 0) return 0;
pmfn = _mfn(sp->up >> PAGE_SHIFT);
@@ -2616,9 +2617,9 @@ void sh_remove_shadows(struct vcpu *v, mfn_t gmfn, int
fast, int all)
mfn_x(gmfn), (uint32_t)pg->shadow_flags, t); \
break; \
} \
-if ( sh_type_is_pinnable(v, t) )\
+if ( sh_type_is_pinnable(d, t) )\
sh_unpin(v, smfn); \
-else if ( sh_type_has_up_pointer(v, t) )\
+else if ( sh_type_has_up_pointer(d, t) )\
sh_remove_shadow_via_pointer(v, smfn); \
if( !fast \
&& (pg->count_info & PGC_page_table)\
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 154274f..ea3b520 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -903,7 +903,7 @@ static int shadow_set_l4e(struct vcpu *v,
mfn_t sl3mfn = shadow_l4e_get_mfn(new_sl4e);
ok = sh_get_ref(v, sl3mfn, paddr);
/* Are we pinning l3 shadows to handle wierd linux behaviour? */
-if ( sh_type_is_pinnable(v, SH_type_l3_64_shadow) )
+if ( sh_type_is_pinnable(d, SH_type_l3_64_shadow) )
ok |= sh_pin(v, sl3mfn);
if ( !ok )
{
@@ -1501,7 +1501,7 @@ sh_make_shadow(struct vcpu *v, mfn_t gmfn, u32
shadow_type)
SHADOW_DEBUG(MAKE_SHADOW, "(%05lx, %u)=>%05lx\n",
mfn_x(gmfn), shadow_type, mfn_x(smfn));
-if ( sh_type_has_up_pointer(v, shadow_type) )
+if ( sh_type_has_up_pointer(d, shadow_type) )
/* Lower-level shadow, not yet linked form a higher level */
mfn_to_page(smfn)->up = 0;
@@ -2367,7 +2367,7 @@ int sh_safe_not_to_sync(struct vcpu *v, mfn_t gl1mfn)
struct page_info *sp;
mfn_t smfn;
-if ( !sh_type_has_up_pointer(v, SH_type_l1_shadow) )
+if ( !sh_type_has_up_pointer(d, SH_type_l1_shadow) )
return 0;
smfn = get_shadow_status(d, gl1mfn, SH_type_l1_shadow);
@@ -2383,7 +2383,7 @@ int sh_safe_not_to_sync(struct vcpu *v, mfn_t gl1mfn)
#if (SHADOW_PAGING_LEVELS == 4)
/* up to l3 */
sp = mfn_to_page(smfn);
-ASSERT(sh_type_has_up_pointer(v, SH_type_l2_shadow));
+ASSERT(sh_type_has_up_pointer(d, SH_type_l2_shadow));
if ( sp->u.sh.count != 1 || !sp->up )
return 0;
smfn = _mfn(sp->up >> PAGE_SHIFT);
@@ -2392,7 +2392,7 @@ int sh_safe_not_to_sync(struct vcpu *v, mfn_t gl1mfn)
/* up to l4 */
sp = mfn_to_page(smfn);
if ( sp->u.sh.count != 1
- || !sh_type_has_up_pointer(v, SH_type_l3_64_shadow) || !sp->up )
+ || !sh_type_has_up_pointer(d, SH_type_l3_64_shadow) || !sp->up )
return 0;
smfn = _mfn(sp->up >> PAGE_SHIFT);
ASSERT(mfn_valid(smfn));
diff --git a/xen/arch/x86/mm/shadow/private.h b/xen/arch/x86/mm/shadow/private.h
index df1dd8c..8c06775 100644
--- a/xen/arch/x86/mm/shadow/private.h
+++ b/xen/arch/x86/mm/shadow/private.h
@@ -195,7 +195,7 @@ extern void shadow_audit_tables(struct vcpu *v);
* What counts as a pinnable shadow?
*/
-static inline int sh_type_is_pinnable(struct vcpu *v, unsigned int t)
+static inline int sh_type_is_pinnable(struct domain *d, unsigned int t)
{
/* Top-level shadow types in each mode can be pinned, so that they
* persist even when not currently in use in a guest CR3 */
@@ -211,7 +211,7 @@ static inline int sh_type_is_pinnable(struct vcpu *v,
unsigned int t)
* page. When we're shadowing those kernels, we have to pin l3
* shadows so they don't just eva
[Xen-devel] [PATCH 09/20] x86/shadow: Alter shadow_{pro, de}mote() to take a domain
Signed-off-by: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/mm/shadow/common.c |6 ++
xen/arch/x86/mm/shadow/multi.c | 10 +-
xen/arch/x86/mm/shadow/private.h |4 ++--
3 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 6945dfe..c6b8e6f 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -990,9 +990,8 @@ int sh_unsync(struct vcpu *v, mfn_t gmfn)
* involves making sure there are no writable mappings available to the guest
* for this page.
*/
-void shadow_promote(struct vcpu *v, mfn_t gmfn, unsigned int type)
+void shadow_promote(struct domain *d, mfn_t gmfn, unsigned int type)
{
-struct domain *d = v->domain;
struct page_info *page = mfn_to_page(gmfn);
ASSERT(mfn_valid(gmfn));
@@ -1017,9 +1016,8 @@ void shadow_promote(struct vcpu *v, mfn_t gmfn, unsigned
int type)
TRACE_SHADOW_PATH_FLAG(TRCE_SFLAG_PROMOTE);
}
-void shadow_demote(struct vcpu *v, mfn_t gmfn, u32 type)
+void shadow_demote(struct domain *d, mfn_t gmfn, u32 type)
{
-struct domain *d = v->domain;
struct page_info *page = mfn_to_page(gmfn);
ASSERT(test_bit(_PGC_page_table, &page->count_info));
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 82759a6..f2dea16 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -1563,7 +1563,7 @@ sh_make_shadow(struct vcpu *v, mfn_t gmfn, u32
shadow_type)
}
}
-shadow_promote(v, gmfn, shadow_type);
+shadow_promote(d, gmfn, shadow_type);
set_shadow_status(d, gmfn, shadow_type, smfn);
return smfn;
@@ -1898,7 +1898,7 @@ void sh_destroy_l4_shadow(struct vcpu *v, mfn_t smfn)
/* Record that the guest page isn't shadowed any more (in this type) */
gmfn = backpointer(sp);
delete_shadow_status(d, gmfn, t, smfn);
-shadow_demote(v, gmfn, t);
+shadow_demote(d, gmfn, t);
/* Decrement refcounts of all the old entries */
sl4mfn = smfn;
SHADOW_FOREACH_L4E(sl4mfn, sl4e, 0, 0, d, {
@@ -1930,7 +1930,7 @@ void sh_destroy_l3_shadow(struct vcpu *v, mfn_t smfn)
/* Record that the guest page isn't shadowed any more (in this type) */
gmfn = backpointer(sp);
delete_shadow_status(d, gmfn, t, smfn);
-shadow_demote(v, gmfn, t);
+shadow_demote(d, gmfn, t);
/* Decrement refcounts of all the old entries */
sl3mfn = smfn;
@@ -1968,7 +1968,7 @@ void sh_destroy_l2_shadow(struct vcpu *v, mfn_t smfn)
/* Record that the guest page isn't shadowed any more (in this type) */
gmfn = backpointer(sp);
delete_shadow_status(d, gmfn, t, smfn);
-shadow_demote(v, gmfn, t);
+shadow_demote(d, gmfn, t);
/* Decrement refcounts of all the old entries */
sl2mfn = smfn;
@@ -2005,7 +2005,7 @@ void sh_destroy_l1_shadow(struct vcpu *v, mfn_t smfn)
{
mfn_t gmfn = backpointer(sp);
delete_shadow_status(d, gmfn, t, smfn);
-shadow_demote(v, gmfn, t);
+shadow_demote(d, gmfn, t);
}
if ( shadow_mode_refcounts(d) )
diff --git a/xen/arch/x86/mm/shadow/private.h b/xen/arch/x86/mm/shadow/private.h
index 7abb0e0..3820d9e 100644
--- a/xen/arch/x86/mm/shadow/private.h
+++ b/xen/arch/x86/mm/shadow/private.h
@@ -350,8 +350,8 @@ void shadow_hash_delete(struct domain *d,
unsigned long n, unsigned int t, mfn_t smfn);
/* shadow promotion */
-void shadow_promote(struct vcpu *v, mfn_t gmfn, u32 type);
-void shadow_demote(struct vcpu *v, mfn_t gmfn, u32 type);
+void shadow_promote(struct domain *d, mfn_t gmfn, u32 type);
+void shadow_demote(struct domain *d, mfn_t gmfn, u32 type);
/* Shadow page allocation functions */
void shadow_prealloc(struct domain *d, u32 shadow_type, unsigned int count);
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 03/20] x86/shadow: Introduce 'd' pointers and clean up use of 'v->domain'
All of the introduced domain pointers will eventually be removed, but doing
this mechanical cleanup here allows the subsequent patches which change
function prototypes to be smaller and more clear.
In addition, swap some use of is_pv_32on64_vcpu(v) for is_pv_32on64_domain(d).
No functional change.
Signed-off-by: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/mm/shadow/common.c | 49 +++--
xen/arch/x86/mm/shadow/multi.c | 146 ++
xen/arch/x86/mm/shadow/private.h |6 +-
3 files changed, 116 insertions(+), 85 deletions(-)
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 2e4954f..3b5ef19 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -665,6 +665,7 @@ void oos_fixup_add(struct vcpu *v, mfn_t gmfn,
static int oos_remove_write_access(struct vcpu *v, mfn_t gmfn,
struct oos_fixup *fixup)
{
+struct domain *d = v->domain;
int ftlb = 0;
ftlb |= oos_fixup_flush_gmfn(v, gmfn, fixup);
@@ -690,7 +691,7 @@ static int oos_remove_write_access(struct vcpu *v, mfn_t
gmfn,
}
if ( ftlb )
-flush_tlb_mask(v->domain->domain_dirty_cpumask);
+flush_tlb_mask(d->domain_dirty_cpumask);
return 0;
}
@@ -991,6 +992,7 @@ int sh_unsync(struct vcpu *v, mfn_t gmfn)
*/
void shadow_promote(struct vcpu *v, mfn_t gmfn, unsigned int type)
{
+struct domain *d = v->domain;
struct page_info *page = mfn_to_page(gmfn);
ASSERT(mfn_valid(gmfn));
@@ -1004,7 +1006,7 @@ void shadow_promote(struct vcpu *v, mfn_t gmfn, unsigned
int type)
/* We should never try to promote a gmfn that has writeable mappings */
ASSERT((page->u.inuse.type_info & PGT_type_mask) != PGT_writable_page
|| (page->u.inuse.type_info & PGT_count_mask) == 0
- || v->domain->is_shutting_down);
+ || d->is_shutting_down);
/* Is the page already shadowed? */
if ( !test_and_set_bit(_PGC_page_table, &page->count_info) )
@@ -2056,6 +2058,7 @@ static void hash_vcpu_foreach(struct vcpu *v, unsigned
int callback_mask,
void sh_destroy_shadow(struct vcpu *v, mfn_t smfn)
{
+struct domain *d = v->domain;
struct page_info *sp = mfn_to_page(smfn);
unsigned int t = sp->u.sh.type;
@@ -2068,9 +2071,8 @@ void sh_destroy_shadow(struct vcpu *v, mfn_t smfn)
t == SH_type_fl1_pae_shadow ||
t == SH_type_fl1_64_shadow ||
t == SH_type_monitor_table ||
- (is_pv_32on64_vcpu(v) && t == SH_type_l4_64_shadow) ||
- (page_get_owner(mfn_to_page(backpointer(sp)))
-== v->domain));
+ (is_pv_32on64_domain(d) && t == SH_type_l4_64_shadow) ||
+ (page_get_owner(mfn_to_page(backpointer(sp))) == d));
/* The down-shifts here are so that the switch statement is on nice
* small numbers that the compiler will enjoy */
@@ -2098,7 +2100,7 @@ void sh_destroy_shadow(struct vcpu *v, mfn_t smfn)
SHADOW_INTERNAL_NAME(sh_destroy_l1_shadow, 4)(v, smfn);
break;
case SH_type_l2h_64_shadow:
-ASSERT(is_pv_32on64_vcpu(v));
+ASSERT(is_pv_32on64_domain(d));
/* Fall through... */
case SH_type_l2_64_shadow:
SHADOW_INTERNAL_NAME(sh_destroy_l2_shadow, 4)(v, smfn);
@@ -2166,15 +2168,16 @@ int sh_remove_write_access(struct vcpu *v, mfn_t gmfn,
| SHF_L1_64
| SHF_FL1_64
;
+struct domain *d = v->domain;
struct page_info *pg = mfn_to_page(gmfn);
-ASSERT(paging_locked_by_me(v->domain));
+ASSERT(paging_locked_by_me(d));
/* Only remove writable mappings if we are doing shadow refcounts.
* In guest refcounting, we trust Xen to already be restricting
* all the writes to the guest page tables, so we do not need to
* do more. */
-if ( !shadow_mode_refcounts(v->domain) )
+if ( !shadow_mode_refcounts(d) )
return 0;
/* Early exit if it's already a pagetable, or otherwise not writeable */
@@ -2198,7 +2201,7 @@ int sh_remove_write_access(struct vcpu *v, mfn_t gmfn,
SHADOW_ERROR("can't remove write access to mfn %lx, type_info is %"
PRtype_info "\n",
mfn_x(gmfn), mfn_to_page(gmfn)->u.inuse.type_info);
-domain_crash(v->domain);
+domain_crash(d);
}
#if SHADOW_OPTIMIZATIONS & SHOPT_WRITABLE_HEURISTIC
@@ -2226,7 +2229,7 @@ int sh_remove_write_access(struct vcpu *v, mfn_t gmfn,
GUESS(0xC000UL + (fault_addr >> 10), 1);
/* Linux lowmem: first 896MB is mapped 1-to-1 above 0xC000 */
-if ((gfn = mfn_to_gfn(v->domain, gmfn)) < 0x38000 )
+if ((gfn = mfn_to_gfn(d, gmfn)) < 0x38000 )
GUESS(0xC000UL + (gfn << PAGE_SHIFT), 4);
/* FreeBSD: Linear map at 0xBFC0 */
@@ -2244,7 +2247,7 @@ int sh_remove_write_access(struct vcpu *v,
[Xen-devel] [PATCH 06/20] x86/shadow: Alter *_shadow_status() and make_fl1_shadow() to take a domain
Signed-off-by: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/mm/shadow/multi.c | 99 +++-
1 file changed, 48 insertions(+), 51 deletions(-)
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 1e6bc33..154274f 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -91,20 +91,18 @@ static char *fetch_type_names[] = {
*/
static inline mfn_t
-get_fl1_shadow_status(struct vcpu *v, gfn_t gfn)
+get_fl1_shadow_status(struct domain *d, gfn_t gfn)
/* Look for FL1 shadows in the hash table */
{
-struct domain *d = v->domain;
mfn_t smfn = shadow_hash_lookup(d, gfn_x(gfn), SH_type_fl1_shadow);
ASSERT(!mfn_valid(smfn) || mfn_to_page(smfn)->u.sh.head);
return smfn;
}
static inline mfn_t
-get_shadow_status(struct vcpu *v, mfn_t gmfn, u32 shadow_type)
+get_shadow_status(struct domain *d, mfn_t gmfn, u32 shadow_type)
/* Look for shadows in the hash table */
{
-struct domain *d = v->domain;
mfn_t smfn = shadow_hash_lookup(d, mfn_x(gmfn), shadow_type);
ASSERT(!mfn_valid(smfn) || mfn_to_page(smfn)->u.sh.head);
perfc_incr(shadow_get_shadow_status);
@@ -112,10 +110,9 @@ get_shadow_status(struct vcpu *v, mfn_t gmfn, u32
shadow_type)
}
static inline void
-set_fl1_shadow_status(struct vcpu *v, gfn_t gfn, mfn_t smfn)
+set_fl1_shadow_status(struct domain *d, gfn_t gfn, mfn_t smfn)
/* Put an FL1 shadow into the hash table */
{
-struct domain *d = v->domain;
SHADOW_PRINTK("gfn=%"SH_PRI_gfn", type=%08x, smfn=%05lx\n",
gfn_x(gfn), SH_type_fl1_shadow, mfn_x(smfn));
@@ -124,15 +121,13 @@ set_fl1_shadow_status(struct vcpu *v, gfn_t gfn, mfn_t
smfn)
}
static inline void
-set_shadow_status(struct vcpu *v, mfn_t gmfn, u32 shadow_type, mfn_t smfn)
+set_shadow_status(struct domain *d, mfn_t gmfn, u32 shadow_type, mfn_t smfn)
/* Put a shadow into the hash table */
{
-struct domain *d = v->domain;
int res;
-SHADOW_PRINTK("d=%d, v=%d, gmfn=%05lx, type=%08x, smfn=%05lx\n",
- d->domain_id, v->vcpu_id, mfn_x(gmfn),
- shadow_type, mfn_x(smfn));
+SHADOW_PRINTK("d=%d: gmfn=%lx, type=%08x, smfn=%lx\n",
+ d->domain_id, mfn_x(gmfn), shadow_type, mfn_x(smfn));
ASSERT(mfn_to_page(smfn)->u.sh.head);
@@ -147,10 +142,9 @@ set_shadow_status(struct vcpu *v, mfn_t gmfn, u32
shadow_type, mfn_t smfn)
}
static inline void
-delete_fl1_shadow_status(struct vcpu *v, gfn_t gfn, mfn_t smfn)
+delete_fl1_shadow_status(struct domain *d, gfn_t gfn, mfn_t smfn)
/* Remove a shadow from the hash table */
{
-struct domain *d = v->domain;
SHADOW_PRINTK("gfn=%"SH_PRI_gfn", type=%08x, smfn=%05lx\n",
gfn_x(gfn), SH_type_fl1_shadow, mfn_x(smfn));
ASSERT(mfn_to_page(smfn)->u.sh.head);
@@ -158,13 +152,11 @@ delete_fl1_shadow_status(struct vcpu *v, gfn_t gfn, mfn_t
smfn)
}
static inline void
-delete_shadow_status(struct vcpu *v, mfn_t gmfn, u32 shadow_type, mfn_t smfn)
+delete_shadow_status(struct domain *d, mfn_t gmfn, u32 shadow_type, mfn_t smfn)
/* Remove a shadow from the hash table */
{
-struct domain *d = v->domain;
-SHADOW_PRINTK("d=%d, v=%d, gmfn=%05lx, type=%08x, smfn=%05lx\n",
- d->domain_id, v->vcpu_id,
- mfn_x(gmfn), shadow_type, mfn_x(smfn));
+SHADOW_PRINTK("d=%d: gmfn=%lx, type=%08x, smfn=%lx\n",
+ d->domain_id, mfn_x(gmfn), shadow_type, mfn_x(smfn));
ASSERT(mfn_to_page(smfn)->u.sh.head);
shadow_hash_delete(d, mfn_x(gmfn), shadow_type, smfn);
/* 32-on-64 PV guests don't own their l4 pages; see set_shadow_status */
@@ -330,6 +322,7 @@ gw_remove_write_accesses(struct vcpu *v, unsigned long va,
walk_t *gw)
* through the audit mechanisms */
static void sh_audit_gw(struct vcpu *v, walk_t *gw)
{
+struct domain *d = v->domain;
mfn_t smfn;
if ( !(SHADOW_AUDIT_ENABLE) )
@@ -337,33 +330,33 @@ static void sh_audit_gw(struct vcpu *v, walk_t *gw)
#if GUEST_PAGING_LEVELS >= 4 /* 64-bit only... */
if ( mfn_valid(gw->l4mfn)
- && mfn_valid((smfn = get_shadow_status(v, gw->l4mfn,
+ && mfn_valid((smfn = get_shadow_status(d, gw->l4mfn,
SH_type_l4_shadow))) )
(void) sh_audit_l4_table(v, smfn, _mfn(INVALID_MFN));
if ( mfn_valid(gw->l3mfn)
- && mfn_valid((smfn = get_shadow_status(v, gw->l3mfn,
+ && mfn_valid((smfn = get_shadow_status(d, gw->l3mfn,
SH_type_l3_shadow))) )
(void) sh_audit_l3_table(v, smfn, _mfn(INVALID_MFN));
#endif /* PAE or 64... */
if ( mfn_valid(gw->l2mfn) )
{
-if ( mfn_valid((smfn = get_shadow_status(v, gw->l2mfn,
+if ( mfn_valid((smfn = get_shadow_status(d, gw->l2mfn,
SH_type_l2_shadow))) )
(voi
[Xen-devel] [PATCH 08/20] x86/shadow: Alter OOS functions to take a domain
Signed-off-by: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/mm/shadow/common.c | 23 ---
xen/arch/x86/mm/shadow/multi.c | 19 ---
xen/arch/x86/mm/shadow/private.h |6 +++---
3 files changed, 27 insertions(+), 21 deletions(-)
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index bdb19fb..6945dfe 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -603,13 +603,13 @@ static inline int oos_fixup_flush_gmfn(struct vcpu *v,
mfn_t gmfn,
return 1;
}
-void oos_fixup_add(struct vcpu *v, mfn_t gmfn,
+void oos_fixup_add(struct domain *d, mfn_t gmfn,
mfn_t smfn, unsigned long off)
{
int idx, next;
mfn_t *oos;
struct oos_fixup *oos_fixup;
-struct domain *d = v->domain;
+struct vcpu *v;
perfc_incr(shadow_oos_fixup_add);
@@ -788,13 +788,13 @@ static void oos_hash_add(struct vcpu *v, mfn_t gmfn)
}
/* Remove an MFN from the list of out-of-sync guest pagetables */
-static void oos_hash_remove(struct vcpu *v, mfn_t gmfn)
+static void oos_hash_remove(struct domain *d, mfn_t gmfn)
{
int idx;
mfn_t *oos;
-struct domain *d = v->domain;
+struct vcpu *v;
-SHADOW_PRINTK("%pv gmfn %lx\n", v, mfn_x(gmfn));
+SHADOW_PRINTK("d%d gmfn %lx\n", d->domain_id, mfn_x(gmfn));
for_each_vcpu(d, v)
{
@@ -813,12 +813,12 @@ static void oos_hash_remove(struct vcpu *v, mfn_t gmfn)
BUG();
}
-mfn_t oos_snapshot_lookup(struct vcpu *v, mfn_t gmfn)
+mfn_t oos_snapshot_lookup(struct domain *d, mfn_t gmfn)
{
int idx;
mfn_t *oos;
mfn_t *oos_snapshot;
-struct domain *d = v->domain;
+struct vcpu *v;
for_each_vcpu(d, v)
{
@@ -839,13 +839,13 @@ mfn_t oos_snapshot_lookup(struct vcpu *v, mfn_t gmfn)
}
/* Pull a single guest page back into sync */
-void sh_resync(struct vcpu *v, mfn_t gmfn)
+void sh_resync(struct domain *d, mfn_t gmfn)
{
int idx;
mfn_t *oos;
mfn_t *oos_snapshot;
struct oos_fixup *oos_fixup;
-struct domain *d = v->domain;
+struct vcpu *v;
for_each_vcpu(d, v)
{
@@ -1000,7 +1000,7 @@ void shadow_promote(struct vcpu *v, mfn_t gmfn, unsigned
int type)
#if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
/* Is the page already shadowed and out of sync? */
if ( page_is_out_of_sync(page) )
-sh_resync(v, gmfn);
+sh_resync(d, gmfn);
#endif
/* We should never try to promote a gmfn that has writeable mappings */
@@ -1019,6 +1019,7 @@ void shadow_promote(struct vcpu *v, mfn_t gmfn, unsigned
int type)
void shadow_demote(struct vcpu *v, mfn_t gmfn, u32 type)
{
+struct domain *d = v->domain;
struct page_info *page = mfn_to_page(gmfn);
ASSERT(test_bit(_PGC_page_table, &page->count_info));
@@ -1032,7 +1033,7 @@ void shadow_demote(struct vcpu *v, mfn_t gmfn, u32 type)
/* Was the page out of sync? */
if ( page_is_out_of_sync(page) )
{
-oos_hash_remove(v, gmfn);
+oos_hash_remove(d, gmfn);
}
#endif
clear_bit(_PGC_page_table, &page->count_info);
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index ea3b520..82759a6 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -278,6 +278,11 @@ shadow_check_gl1e(struct vcpu *v, walk_t *gw)
static inline uint32_t
gw_remove_write_accesses(struct vcpu *v, unsigned long va, walk_t *gw)
{
+#if GUEST_PAGING_LEVELS >= 3 /* PAE or 64... */
+#if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
+struct domain *d = v->domain;
+#endif
+#endif
uint32_t rc = 0;
#if GUEST_PAGING_LEVELS >= 3 /* PAE or 64... */
@@ -285,7 +290,7 @@ gw_remove_write_accesses(struct vcpu *v, unsigned long va,
walk_t *gw)
#if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
if ( mfn_is_out_of_sync(gw->l3mfn) )
{
-sh_resync(v, gw->l3mfn);
+sh_resync(d, gw->l3mfn);
rc = GW_RMWR_REWALK;
}
else
@@ -297,7 +302,7 @@ gw_remove_write_accesses(struct vcpu *v, unsigned long va,
walk_t *gw)
#if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
if ( mfn_is_out_of_sync(gw->l2mfn) )
{
-sh_resync(v, gw->l2mfn);
+sh_resync(d, gw->l2mfn);
rc |= GW_RMWR_REWALK;
}
else
@@ -1030,7 +1035,7 @@ static int shadow_set_l2e(struct vcpu *v,
OOS. */
if ( (sp->u.sh.type != SH_type_fl1_shadow) && mfn_valid(gl1mfn)
&& mfn_is_out_of_sync(gl1mfn) )
-sh_resync(v, gl1mfn);
+sh_resync(d, gl1mfn);
}
#endif
#if GUEST_PAGING_LEVELS == 2
@@ -1178,7 +1183,7 @@ static int shadow_set_l1e(struct vcpu *v,
if ( mfn_valid(new_gmfn) && mfn_oos_may_write(new_gmfn)
&& ((shadow_l1e_get_flags(new_sl1e) & (_PAGE_RW|_PAGE_PRESENT))
== (_PAGE_RW|_PAGE_PRESENT)) )
-oos_fixup_add(v, new_gmfn, sl1mfn, pgentry_ptr
[Xen-devel] [PATCH 05/20] x86/shadow: Alter shadow_hash_{lookup, insert, delete}() to take a domain
Signed-off-by: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/mm/shadow/common.c | 11 ---
xen/arch/x86/mm/shadow/multi.c | 22 +-
xen/arch/x86/mm/shadow/private.h |6 +++---
3 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 26dab30..80174df 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -1878,11 +1878,10 @@ static void shadow_hash_teardown(struct domain *d)
}
-mfn_t shadow_hash_lookup(struct vcpu *v, unsigned long n, unsigned int t)
+mfn_t shadow_hash_lookup(struct domain *d, unsigned long n, unsigned int t)
/* Find an entry in the hash table. Returns the MFN of the shadow,
* or INVALID_MFN if it doesn't exist */
{
-struct domain *d = v->domain;
struct page_info *sp, *prev;
key_t key;
@@ -1932,11 +1931,10 @@ mfn_t shadow_hash_lookup(struct vcpu *v, unsigned long
n, unsigned int t)
return _mfn(INVALID_MFN);
}
-void shadow_hash_insert(struct vcpu *v, unsigned long n, unsigned int t,
+void shadow_hash_insert(struct domain *d, unsigned long n, unsigned int t,
mfn_t smfn)
/* Put a mapping (n,t)->smfn into the hash table */
{
-struct domain *d = v->domain;
struct page_info *sp;
key_t key;
@@ -1958,11 +1956,10 @@ void shadow_hash_insert(struct vcpu *v, unsigned long
n, unsigned int t,
sh_hash_audit_bucket(d, key);
}
-void shadow_hash_delete(struct vcpu *v, unsigned long n, unsigned int t,
+void shadow_hash_delete(struct domain *d, unsigned long n, unsigned int t,
mfn_t smfn)
/* Excise the mapping (n,t)->smfn from the hash table */
{
-struct domain *d = v->domain;
struct page_info *sp, *x;
key_t key;
@@ -2611,7 +2608,7 @@ void sh_remove_shadows(struct vcpu *v, mfn_t gmfn, int
fast, int all)
if( !(pg->count_info & PGC_page_table) \
|| !(pg->shadow_flags & (1 << t)) ) \
break; \
-smfn = shadow_hash_lookup(v, mfn_x(gmfn), t); \
+smfn = shadow_hash_lookup(d, mfn_x(gmfn), t); \
if ( unlikely(!mfn_valid(smfn)) ) \
{ \
SHADOW_ERROR(": gmfn %#lx has flags %#"PRIx32 \
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index f532bff..1e6bc33 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -94,7 +94,8 @@ static inline mfn_t
get_fl1_shadow_status(struct vcpu *v, gfn_t gfn)
/* Look for FL1 shadows in the hash table */
{
-mfn_t smfn = shadow_hash_lookup(v, gfn_x(gfn), SH_type_fl1_shadow);
+struct domain *d = v->domain;
+mfn_t smfn = shadow_hash_lookup(d, gfn_x(gfn), SH_type_fl1_shadow);
ASSERT(!mfn_valid(smfn) || mfn_to_page(smfn)->u.sh.head);
return smfn;
}
@@ -103,7 +104,8 @@ static inline mfn_t
get_shadow_status(struct vcpu *v, mfn_t gmfn, u32 shadow_type)
/* Look for shadows in the hash table */
{
-mfn_t smfn = shadow_hash_lookup(v, mfn_x(gmfn), shadow_type);
+struct domain *d = v->domain;
+mfn_t smfn = shadow_hash_lookup(d, mfn_x(gmfn), shadow_type);
ASSERT(!mfn_valid(smfn) || mfn_to_page(smfn)->u.sh.head);
perfc_incr(shadow_get_shadow_status);
return smfn;
@@ -113,11 +115,12 @@ static inline void
set_fl1_shadow_status(struct vcpu *v, gfn_t gfn, mfn_t smfn)
/* Put an FL1 shadow into the hash table */
{
+struct domain *d = v->domain;
SHADOW_PRINTK("gfn=%"SH_PRI_gfn", type=%08x, smfn=%05lx\n",
gfn_x(gfn), SH_type_fl1_shadow, mfn_x(smfn));
ASSERT(mfn_to_page(smfn)->u.sh.head);
-shadow_hash_insert(v, gfn_x(gfn), SH_type_fl1_shadow, smfn);
+shadow_hash_insert(d, gfn_x(gfn), SH_type_fl1_shadow, smfn);
}
static inline void
@@ -140,17 +143,18 @@ set_shadow_status(struct vcpu *v, mfn_t gmfn, u32
shadow_type, mfn_t smfn)
ASSERT(res == 1);
}
-shadow_hash_insert(v, mfn_x(gmfn), shadow_type, smfn);
+shadow_hash_insert(d, mfn_x(gmfn), shadow_type, smfn);
}
static inline void
delete_fl1_shadow_status(struct vcpu *v, gfn_t gfn, mfn_t smfn)
/* Remove a shadow from the hash table */
{
+struct domain *d = v->domain;
SHADOW_PRINTK("gfn=%"SH_PRI_gfn", type=%08x, smfn=%05lx\n",
gfn_x(gfn), SH_type_fl1_shadow, mfn_x(smfn));
ASSERT(mfn_to_page(smfn)->u.sh.head);
-shadow_hash_delete(v, gfn_x(gfn), SH_type_fl1_shadow, smfn);
+shadow_hash_delete(d, gfn_x(gfn), SH_type_fl1_shadow, smfn);
}
static inline void
@@ -162,7 +166,7 @@ delete_shadow_status(struct vcpu *v, mfn_t gmfn, u32
shadow_type, mfn_t smfn)
d->domain_id, v->vcpu_id,
mfn_x(gm
[Xen-devel] [PATCH RFC 00/20] Change parts of the shadow interface to be domain based
The purpose of this series is to prevent toolstack entry points into the
shadow code from passing d->vcpu[0] for actions which are inherenly domain
wide. It also fixes the fact that shadow heuristics were being applied to
vcpu 0 for toolstack-initiated actions.
This series is composed mostly of mechanical changes. The only patches which
have a practical difference on shadow execution are patches 4 and 20
The entire series has been compile tested at each changeset, for both
shadow-paging=y and n. It has also been tested internally in XenServer, but
appears to have gotten caught up in some collateral damage from an unrelated
merge. I am rerunning the tests.
This series can be found as in the shadow-dom-v1 branch on
git://xenbits.xen.org/people/andrewcoop/xen.git
Andrew Cooper (20):
x86/shadow: Whitespace cleanup
x86/shadow: Rename hash_foreach() to hash_vcpu_foreach()
x86/shadow: Introduce 'd' pointers and clean up use of 'v->domain'
x86/shadow: Only apply shadow heuristics when in guest context
x86/shadow: Alter shadow_hash_{lookup,insert,delete}() to take a domain
x86/shadow: Alter *_shadow_status() and make_fl1_shadow() to take a domain
x86/shadow: Alter sh_type_{is_pinnable,has_up_pointer}() to take a domain
x86/shadow: Alter OOS functions to take a domain
x86/shadow: Alter shadow_{pro,de}mote() to take a domain
x86/shadow: Alter sh_put_ref() and shadow destroy functions to take a domain
x86/shadow: Alter sh_get_ref() and sh_{,un}pin() to take a domain
x86/shadow: Alter shadow_set_l?e() to take a domain
x86/shadow: Alter sh_{clear_shadow_entry,remove_shadow_via_pointer}() to take
a domain
x86/shadow: Alter sh_remove_l?_shadow() to take a domain
x86/shadow: Alter shadow_unhook{_???}_mappings() to take a domain
x86/shadow: Alter sh_rm_write_access_from_???() to take a domain
x86/shadow: Alter sh_remove_{all_}shadows{,_and_parents}() to take a domain
x86/shadow: Alter sh_{remove_all_mappings,rm_mappings_from_l1}() to take a
domain
x86/shadow: Alter sh_remove_write_access to take a domain
x86/shadow: Cleanup of vcpu handling
xen/arch/x86/hvm/hvm.c |2 +-
xen/arch/x86/mm.c|4 +-
xen/arch/x86/mm/shadow/common.c | 769 +
xen/arch/x86/mm/shadow/multi.c | 1180 +++---
xen/arch/x86/mm/shadow/multi.h | 64 +--
xen/arch/x86/mm/shadow/private.h | 154 ++---
xen/arch/x86/mm/shadow/types.h | 42 +-
xen/include/asm-x86/shadow.h |8 +-
8 files changed, 1140 insertions(+), 1083 deletions(-)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] stubdom vtpm build failure in staging
> -Original Message-
> From: xen-devel-boun...@lists.xen.org
> [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Xu, Quan
> Sent: Friday, February 13, 2015 12:57 AM
> To: Olaf Hering
> Cc: xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] stubdom vtpm build failure in staging
>
> Sorry for that. Read the other thread of email, it looks that some
> maintainers are
> working for this issue.
> And I am working for 'Xen stubdom vTPM for HVM virtual machine' v4 patches.
> There are a lot of modifications.
>
> I will be out of office from Feb. 16th to Feb. 26th for Chinese New Year. I
> plan to
> summit v4 patches Before Feb. 16, and fix this issue after Feb. 26th.
>
> --Quan
>
>
> > -Original Message-
> > From: Olaf Hering [mailto:o...@aepfle.de]
> > Sent: Wednesday, February 11, 2015 11:21 PM
> > To: Xu, Quan
> > Cc: xen-devel@lists.xen.org
> > Subject: Re: [Xen-devel] stubdom vtpm build failure in staging
> >
> > On Wed, Jan 28, Xu, Quan wrote:
> >
> > > Thanks, I will check and fix it tomorrow. It is 23:12 PM Pacific time now.
> >
> > Any progress?
> > These typedefs are duplicated in stubdom/vtpmmgr/tcg.h and supported
> > compilers do not cope with current staging:
> >
> > # for i in `grep -w typedef stubdom/vtpmmgr/tcg.h | sed -n '/;/{s@^.*
> > @@;s@;@@p}'` # do
> > # if test -n "`git grep -wn $i|grep -w typedef|grep -v
> > stubdom/vtpmmgr/tcg.h`"
> > # then
> > # echo $i
> > # fi
> > # done
> >
> > BYTE
> > BOOL
> > UINT16
> > UINT32
> > UINT64
> > TPM_HANDLE
> > TPM_ALGORITHM_ID
> >
> > TPMI_RH_HIERARCHY_AUTH and TPM_ALG_ID are defined twice in the same
> > file.
> >
> > This change works for me:
> >
> > ---
> > stubdom/vtpmmgr/odd_types.h | 11 +++
> > stubdom/vtpmmgr/tcg.h| 9 +
> > stubdom/vtpmmgr/tpm2_types.h | 11 +--
> > 3 files changed, 13 insertions(+), 18 deletions(-) create mode
> > 100644 stubdom/vtpmmgr/odd_types.h
> >
> > diff --git a/stubdom/vtpmmgr/odd_types.h b/stubdom/vtpmmgr/odd_types.h
> > new file mode 100644 index 000..d72da9b
> > --- /dev/null
> > +++ b/stubdom/vtpmmgr/odd_types.h
> > @@ -0,0 +1,11 @@
> > +#ifndef VTPM_ODD_TYPES
> > +#define VTPM_ODD_TYPES 1
> > +typedef unsigned char BYTE;
> > +typedef unsigned char BOOL;
> > +typedef uint16_t UINT16;
> > +typedef uint32_t UINT32;
> > +typedef uint64_t UINT64;
> > +typedef UINT32 TPM_HANDLE;
> > +typedef UINT32 TPM_ALGORITHM_ID;
> > +#endif
> > +
> > diff --git a/stubdom/vtpmmgr/tcg.h b/stubdom/vtpmmgr/tcg.h index
> > 7321ec6..cac1bbc 100644
> > --- a/stubdom/vtpmmgr/tcg.h
> > +++ b/stubdom/vtpmmgr/tcg.h
> > @@ -401,16 +401,10 @@
> >
> >
> > // *** TYPEDEFS
> > * -typedef unsigned char BYTE;
> > -typedef unsigned char BOOL; -typedef uint16_t UINT16; -typedef
> > uint32_t UINT32; -typedef uint64_t UINT64;
> > -
> > +#include "odd_types.h"
I think it is just for gcc backward compatibility. IMHO, That does seem pretty
strange.
cc Daniel who is the maintainer of vTPM / XSM.
-Quan
> > typedef UINT32 TPM_RESULT;
> > typedef UINT32 TPM_PCRINDEX;
> > typedef UINT32 TPM_DIRINDEX;
> > -typedef UINT32 TPM_HANDLE;
> > typedef TPM_HANDLE TPM_AUTHHANDLE;
> > typedef TPM_HANDLE TCPA_HASHHANDLE;
> > typedef TPM_HANDLE TCPA_HMACHANDLE;
> > @@ -422,7 +416,6 @@ typedef UINT32 TPM_COMMAND_CODE; typedef
> > UINT16 TPM_PROTOCOL_ID; typedef BYTE TPM_AUTH_DATA_USAGE;
> typedef
> > UINT16 TPM_ENTITY_TYPE; -typedef UINT32 TPM_ALGORITHM_ID; typedef
> > UINT16 TPM_KEY_USAGE; typedef UINT16 TPM_STARTUP_TYPE; typedef
> UINT32
> > TPM_CAPABILITY_AREA; diff --git a/stubdom/vtpmmgr/tpm2_types.h
> > b/stubdom/vtpmmgr/tpm2_types.h index ac2830d..63564cd 100644
> > --- a/stubdom/vtpmmgr/tpm2_types.h
> > +++ b/stubdom/vtpmmgr/tpm2_types.h
> > @@ -83,12 +83,8 @@
> > #defineMAX_ECC_KEY_BYTES((MAX_ECC_KEY_BITS + 7) / 8)
> >
> >
> > -typedef unsigned char BYTE;
> > -typedef unsigned char BOOL;
> > +#include "odd_types.h"
> > typedef uint8_t UINT8;
> > -typedef uint16_t UINT16;
> > -typedef uint32_t UINT32;
> > -typedef uint64_t UINT64;
> >
> > // TPM2 command code
> >
> > @@ -216,7 +212,6 @@ typedef UINT16 TPM_ST;
> >
> >
> > // TPM Handle types
> > -typedef UINT32 TPM_HANDLE;
> > typedef UINT8 TPM_HT;
> >
> >
> > @@ -233,7 +228,6 @@ typedef UINT32 TPM_RH;
> > #defineTPM_RH_LAST (TPM_RH)(0x400C)
> >
> > // Table 4 -- DocumentationClarity Types
> > -typedef UINT32TPM_ALGORITHM_ID;
> > typedef UINT32TPM_MODIFIER_INDICATOR;
> > typedef UINT32TPM_SESSION_OFFSET;
> > typedef UINT16TPM_KEY_SIZE;
> > @@ -261,8 +255,6 @@ typedef BYTE TPMA_LOCALITY; // Table 37 --
> > TPMI_YES_NO Type typedef BYTE TPMI_YES_NO;
> >
> > -typedef TPM_HANDLE TPMI_RH_HIERARCHY_AUTH;
> > -
> > // Table 38 -- TPMI_DH_OBJECT Type typedef TPM_HANDLE
> > TPMI_DH_OBJECT;
> >
> > @@ -304,7 +296,6 @@ typedef TPM_HANDLE TPMI_RH_LOC
[Xen-devel] [PATCH 12/20] x86/shadow: Alter shadow_set_l?e() to take a domain
Signed-off-by: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/mm/shadow/multi.c | 69
1 file changed, 35 insertions(+), 34 deletions(-)
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index ccb08d3..1db8161 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -885,12 +885,11 @@ shadow_put_page_from_l1e(shadow_l1e_t sl1e, struct domain
*d)
}
#if GUEST_PAGING_LEVELS >= 4
-static int shadow_set_l4e(struct vcpu *v,
+static int shadow_set_l4e(struct domain *d,
shadow_l4e_t *sl4e,
shadow_l4e_t new_sl4e,
mfn_t sl4mfn)
{
-struct domain *d = v->domain;
int flags = 0, ok;
shadow_l4e_t old_sl4e;
paddr_t paddr;
@@ -936,12 +935,11 @@ static int shadow_set_l4e(struct vcpu *v,
return flags;
}
-static int shadow_set_l3e(struct vcpu *v,
+static int shadow_set_l3e(struct domain *d,
shadow_l3e_t *sl3e,
shadow_l3e_t new_sl3e,
mfn_t sl3mfn)
{
-struct domain *d = v->domain;
int flags = 0;
shadow_l3e_t old_sl3e;
paddr_t paddr;
@@ -983,12 +981,11 @@ static int shadow_set_l3e(struct vcpu *v,
}
#endif /* GUEST_PAGING_LEVELS >= 4 */
-static int shadow_set_l2e(struct vcpu *v,
+static int shadow_set_l2e(struct domain *d,
shadow_l2e_t *sl2e,
shadow_l2e_t new_sl2e,
mfn_t sl2mfn)
{
-struct domain *d = v->domain;
int flags = 0;
shadow_l2e_t old_sl2e;
paddr_t paddr;
@@ -1165,14 +1162,13 @@ static inline void shadow_vram_put_l1e(shadow_l1e_t
old_sl1e,
}
}
-static int shadow_set_l1e(struct vcpu *v,
+static int shadow_set_l1e(struct domain *d,
shadow_l1e_t *sl1e,
shadow_l1e_t new_sl1e,
p2m_type_t new_type,
mfn_t sl1mfn)
{
int flags = 0;
-struct domain *d = v->domain;
shadow_l1e_t old_sl1e;
#if SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC
mfn_t new_gmfn = shadow_l1e_get_mfn(new_sl1e);
@@ -1699,7 +1695,7 @@ static shadow_l3e_t * shadow_get_and_create_l3e(struct
vcpu *v,
}
/* Install the new sl3 table in the sl4e */
l4e_propagate_from_guest(v, gw->l4e, *sl3mfn, &new_sl4e, ft);
-r = shadow_set_l4e(v, sl4e, new_sl4e, sl4mfn);
+r = shadow_set_l4e(d, sl4e, new_sl4e, sl4mfn);
ASSERT((r & SHADOW_SET_FLUSH) == 0);
if ( r & SHADOW_SET_ERROR )
return NULL;
@@ -1755,7 +1751,7 @@ static shadow_l2e_t * shadow_get_and_create_l2e(struct
vcpu *v,
}
/* Install the new sl2 table in the sl3e */
l3e_propagate_from_guest(v, gw->l3e, *sl2mfn, &new_sl3e, ft);
-r = shadow_set_l3e(v, sl3e, new_sl3e, sl3mfn);
+r = shadow_set_l3e(d, sl3e, new_sl3e, sl3mfn);
ASSERT((r & SHADOW_SET_FLUSH) == 0);
if ( r & SHADOW_SET_ERROR )
return NULL;
@@ -1845,7 +1841,7 @@ static shadow_l1e_t * shadow_get_and_create_l1e(struct
vcpu *v,
}
/* Install the new sl1 table in the sl2e */
l2e_propagate_from_guest(v, gw->l2e, *sl1mfn, &new_sl2e, ft);
-r = shadow_set_l2e(v, sl2e, new_sl2e, sl2mfn);
+r = shadow_set_l2e(d, sl2e, new_sl2e, sl2mfn);
ASSERT((r & SHADOW_SET_FLUSH) == 0);
if ( r & SHADOW_SET_ERROR )
return NULL;
@@ -2084,7 +2080,7 @@ void sh_unhook_32b_mappings(struct vcpu *v, mfn_t sl2mfn,
int user_only)
shadow_l2e_t *sl2e;
SHADOW_FOREACH_L2E(sl2mfn, sl2e, 0, 0, d, {
if ( !user_only || (sl2e->l2 & _PAGE_USER) )
-(void) shadow_set_l2e(v, sl2e, shadow_l2e_empty(), sl2mfn);
+(void) shadow_set_l2e(d, sl2e, shadow_l2e_empty(), sl2mfn);
});
}
@@ -2097,7 +2093,7 @@ void sh_unhook_pae_mappings(struct vcpu *v, mfn_t sl2mfn,
int user_only)
shadow_l2e_t *sl2e;
SHADOW_FOREACH_L2E(sl2mfn, sl2e, 0, 0, d, {
if ( !user_only || (sl2e->l2 & _PAGE_USER) )
-(void) shadow_set_l2e(v, sl2e, shadow_l2e_empty(), sl2mfn);
+(void) shadow_set_l2e(d, sl2e, shadow_l2e_empty(), sl2mfn);
});
}
@@ -2109,7 +2105,7 @@ void sh_unhook_64b_mappings(struct vcpu *v, mfn_t sl4mfn,
int user_only)
shadow_l4e_t *sl4e;
SHADOW_FOREACH_L4E(sl4mfn, sl4e, 0, 0, d, {
if ( !user_only || (sl4e->l4 & _PAGE_USER) )
-(void) shadow_set_l4e(v, sl4e, shadow_l4e_empty(), sl4mfn);
+(void) shadow_set_l4e(d, sl4e, shadow_l4e_empty(), sl4mfn);
});
}
@@ -2180,7 +2176,7 @@ static int validate_gl4e(struct vcpu *v, void *new_ge,
mfn_t sl4mfn, void *se)
}
}
-result |= shadow_set_l4e(v, sl4p, new_sl4e, sl4mfn);
+result |= shadow_set_l4e(d, sl4p, new_sl4e, sl4mfn);
return result;
}
@@
[Xen-devel] [PATCH 20/20] x86/shadow: Cleanup of vcpu handling
There existed some codepaths which had a domain in their hand, but needed a
vcpu to drive the shadow interface.
Now that these interfaces have changed to be domain based, the hoop-jumping
can be removed.
Signed-off-by: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/mm/shadow/common.c | 30 ++
1 file changed, 10 insertions(+), 20 deletions(-)
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 4e6397a..01bc750 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -1280,23 +1280,17 @@ static inline void trace_shadow_prealloc_unpin(struct
domain *d, mfn_t smfn)
/* Make sure there are at least count order-sized pages
* available in the shadow page pool. */
-static void _shadow_prealloc(
-struct domain *d,
-unsigned int pages)
+static void _shadow_prealloc(struct domain *d, unsigned int pages)
{
-/* Need a vpcu for calling unpins; for now, since we don't have
- * per-vcpu shadows, any will do */
-struct vcpu *v, *v2;
+struct vcpu *v;
struct page_info *sp, *t;
mfn_t smfn;
int i;
if ( d->arch.paging.shadow.free_pages >= pages ) return;
-v = current;
-if ( v->domain != d )
-v = d->vcpu[0];
-ASSERT(v != NULL); /* Shouldn't have enabled shadows if we've no vcpus */
+/* Shouldn't have enabled shadows if we've no vcpus. */
+ASSERT(d->vcpu && d->vcpu[0]);
/* Stage one: walk the list of pinned pages, unpinning them */
perfc_incr(shadow_prealloc_1);
@@ -1317,14 +1311,14 @@ static void _shadow_prealloc(
* mappings. */
perfc_incr(shadow_prealloc_2);
-for_each_vcpu(d, v2)
+for_each_vcpu(d, v)
for ( i = 0 ; i < 4 ; i++ )
{
-if ( !pagetable_is_null(v2->arch.shadow_table[i]) )
+if ( !pagetable_is_null(v->arch.shadow_table[i]) )
{
TRACE_SHADOW_PATH_FLAG(TRCE_SFLAG_PREALLOC_UNHOOK);
shadow_unhook_mappings(d,
- pagetable_get_mfn(v2->arch.shadow_table[i]), 0);
+ pagetable_get_mfn(v->arch.shadow_table[i]), 0);
/* See if that freed up enough space */
if ( d->arch.paging.shadow.free_pages >= pages )
@@ -1361,11 +1355,12 @@ void shadow_prealloc(struct domain *d, u32 type,
unsigned int count)
static void shadow_blow_tables(struct domain *d)
{
struct page_info *sp, *t;
-struct vcpu *v = d->vcpu[0];
+struct vcpu *v;
mfn_t smfn;
int i;
-ASSERT(v != NULL);
+/* Shouldn't have enabled shadows if we've no vcpus. */
+ASSERT(d->vcpu && d->vcpu[0]);
/* Pass one: unpin all pinned pages */
foreach_pinned_shadow(d, sp, t)
@@ -3363,11 +3358,6 @@ static void sh_unshadow_for_p2m_change(struct domain *d,
unsigned long gfn,
l1_pgentry_t *p, l1_pgentry_t new,
unsigned int level)
{
-struct vcpu *v = current;
-
-if ( v->domain != d )
-v = d->vcpu ? d->vcpu[0] : NULL;
-
/* The following assertion is to make sure we don't step on 1GB host
* page support of HVM guest. */
ASSERT(!(level > 2 && (l1e_get_flags(*p) & _PAGE_PRESENT) &&
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 18/20] x86/shadow: Alter sh_{remove_all_mappings, rm_mappings_from_l1}() to take a domain
This allows the removal an improper use of d->vcpu[0] from toolstack context
Signed-off-by: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/mm/shadow/common.c | 13 ++---
xen/arch/x86/mm/shadow/multi.c |3 +--
xen/arch/x86/mm/shadow/multi.h |2 +-
3 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 30580ee..d24859e 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -2436,13 +2436,12 @@ int sh_remove_write_access_from_sl1p(struct domain *d,
mfn_t gmfn,
/* Remove all mappings of a guest frame from the shadow tables.
* Returns non-zero if we need to flush TLBs. */
-static int sh_remove_all_mappings(struct vcpu *v, mfn_t gmfn)
+static int sh_remove_all_mappings(struct domain *d, mfn_t gmfn)
{
-struct domain *d = v->domain;
struct page_info *page = mfn_to_page(gmfn);
/* Dispatch table for getting per-type functions */
-static const hash_vcpu_callback_t callbacks[SH_type_unused] = {
+static const hash_domain_callback_t callbacks[SH_type_unused] = {
NULL, /* none*/
SHADOW_INTERNAL_NAME(sh_rm_mappings_from_l1, 2), /* l1_32 */
SHADOW_INTERNAL_NAME(sh_rm_mappings_from_l1, 2), /* fl1_32 */
@@ -2484,7 +2483,7 @@ static int sh_remove_all_mappings(struct vcpu *v, mfn_t
gmfn)
/* Brute-force search of all the shadows, by walking the hash */
perfc_incr(shadow_mappings_bf);
-hash_vcpu_foreach(v, callback_mask, callbacks, gmfn);
+hash_domain_foreach(d, callback_mask, callbacks, gmfn);
/* If that didn't catch the mapping, something is very wrong */
if ( !sh_check_page_has_no_refs(page) )
@@ -3383,7 +3382,7 @@ static void sh_unshadow_for_p2m_change(struct domain *d,
unsigned long gfn,
if ( (p2m_is_valid(p2mt) || p2m_is_grant(p2mt)) && mfn_valid(mfn) )
{
sh_remove_all_shadows_and_parents(d, mfn);
-if ( sh_remove_all_mappings(v, mfn) )
+if ( sh_remove_all_mappings(d, mfn) )
flush_tlb_mask(d->domain_dirty_cpumask);
}
}
@@ -3418,7 +3417,7 @@ static void sh_unshadow_for_p2m_change(struct domain *d,
unsigned long gfn,
{
/* This GFN->MFN mapping has gone away */
sh_remove_all_shadows_and_parents(d, omfn);
-if ( sh_remove_all_mappings(v, omfn) )
+if ( sh_remove_all_mappings(d, omfn) )
cpumask_or(&flushmask, &flushmask,
d->domain_dirty_cpumask);
}
@@ -3634,7 +3633,7 @@ int shadow_track_dirty_vram(struct domain *d,
dirty = 1;
/* TODO: Heuristics for finding the single mapping of
* this gmfn */
-flush_tlb |= sh_remove_all_mappings(d->vcpu[0], mfn);
+flush_tlb |= sh_remove_all_mappings(d, mfn);
}
else
{
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 7705674..288c7d5 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -4315,10 +4315,9 @@ int sh_rm_write_access_from_l1(struct domain *d, mfn_t
sl1mfn,
}
-int sh_rm_mappings_from_l1(struct vcpu *v, mfn_t sl1mfn, mfn_t target_mfn)
+int sh_rm_mappings_from_l1(struct domain *d, mfn_t sl1mfn, mfn_t target_mfn)
/* Excises all mappings to guest frame from this shadow l1 table */
{
-struct domain *d = v->domain;
shadow_l1e_t *sl1e;
int done = 0;
int flags;
diff --git a/xen/arch/x86/mm/shadow/multi.h b/xen/arch/x86/mm/shadow/multi.h
index 1af9225..935e12d 100644
--- a/xen/arch/x86/mm/shadow/multi.h
+++ b/xen/arch/x86/mm/shadow/multi.h
@@ -65,7 +65,7 @@ SHADOW_INTERNAL_NAME(sh_rm_write_access_from_l1, GUEST_LEVELS)
(struct domain *d, mfn_t sl1mfn, mfn_t readonly_mfn);
extern int
SHADOW_INTERNAL_NAME(sh_rm_mappings_from_l1, GUEST_LEVELS)
-(struct vcpu *v, mfn_t sl1mfn, mfn_t target_mfn);
+(struct domain *d, mfn_t sl1mfn, mfn_t target_mfn);
extern void
SHADOW_INTERNAL_NAME(sh_clear_shadow_entry, GUEST_LEVELS)
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 15/20] x86/shadow: Alter shadow_unhook{_???}_mappings() to take a domain
Signed-off-by: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/mm/shadow/common.c | 12 ++--
xen/arch/x86/mm/shadow/multi.c | 13 +
xen/arch/x86/mm/shadow/multi.h |6 +++---
xen/arch/x86/mm/shadow/private.h |2 +-
4 files changed, 15 insertions(+), 18 deletions(-)
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 3810b75..4a9b94b 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -1244,20 +1244,20 @@ static unsigned int shadow_min_acceptable_pages(struct
domain *d)
/* Dispatcher function: call the per-mode function that will unhook the
* non-Xen mappings in this top-level shadow mfn. With user_only == 1,
* unhooks only the user-mode mappings. */
-void shadow_unhook_mappings(struct vcpu *v, mfn_t smfn, int user_only)
+void shadow_unhook_mappings(struct domain *d, mfn_t smfn, int user_only)
{
struct page_info *sp = mfn_to_page(smfn);
switch ( sp->u.sh.type )
{
case SH_type_l2_32_shadow:
-SHADOW_INTERNAL_NAME(sh_unhook_32b_mappings, 2)(v, smfn, user_only);
+SHADOW_INTERNAL_NAME(sh_unhook_32b_mappings, 2)(d, smfn, user_only);
break;
case SH_type_l2_pae_shadow:
case SH_type_l2h_pae_shadow:
-SHADOW_INTERNAL_NAME(sh_unhook_pae_mappings, 3)(v, smfn, user_only);
+SHADOW_INTERNAL_NAME(sh_unhook_pae_mappings, 3)(d, smfn, user_only);
break;
case SH_type_l4_64_shadow:
-SHADOW_INTERNAL_NAME(sh_unhook_64b_mappings, 4)(v, smfn, user_only);
+SHADOW_INTERNAL_NAME(sh_unhook_64b_mappings, 4)(d, smfn, user_only);
break;
default:
SHADOW_ERROR("top-level shadow has bad type %08x\n", sp->u.sh.type);
@@ -1322,7 +1322,7 @@ static void _shadow_prealloc(
if ( !pagetable_is_null(v2->arch.shadow_table[i]) )
{
TRACE_SHADOW_PATH_FLAG(TRCE_SFLAG_PREALLOC_UNHOOK);
-shadow_unhook_mappings(v,
+shadow_unhook_mappings(d,
pagetable_get_mfn(v2->arch.shadow_table[i]), 0);
/* See if that freed up enough space */
@@ -1377,7 +1377,7 @@ static void shadow_blow_tables(struct domain *d)
for_each_vcpu(d, v)
for ( i = 0 ; i < 4 ; i++ )
if ( !pagetable_is_null(v->arch.shadow_table[i]) )
-shadow_unhook_mappings(v,
+shadow_unhook_mappings(d,
pagetable_get_mfn(v->arch.shadow_table[i]), 0);
/* Make sure everyone sees the unshadowings */
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index ab6ebe2..79d 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -2074,9 +2074,8 @@ void sh_destroy_monitor_table(struct vcpu *v, mfn_t mmfn)
#if GUEST_PAGING_LEVELS == 2
-void sh_unhook_32b_mappings(struct vcpu *v, mfn_t sl2mfn, int user_only)
+void sh_unhook_32b_mappings(struct domain *d, mfn_t sl2mfn, int user_only)
{
-struct domain *d = v->domain;
shadow_l2e_t *sl2e;
SHADOW_FOREACH_L2E(sl2mfn, sl2e, 0, 0, d, {
if ( !user_only || (sl2e->l2 & _PAGE_USER) )
@@ -2086,10 +2085,9 @@ void sh_unhook_32b_mappings(struct vcpu *v, mfn_t
sl2mfn, int user_only)
#elif GUEST_PAGING_LEVELS == 3
-void sh_unhook_pae_mappings(struct vcpu *v, mfn_t sl2mfn, int user_only)
+void sh_unhook_pae_mappings(struct domain *d, mfn_t sl2mfn, int user_only)
/* Walk a PAE l2 shadow, unhooking entries from all the subshadows */
{
-struct domain *d = v->domain;
shadow_l2e_t *sl2e;
SHADOW_FOREACH_L2E(sl2mfn, sl2e, 0, 0, d, {
if ( !user_only || (sl2e->l2 & _PAGE_USER) )
@@ -2099,9 +2097,8 @@ void sh_unhook_pae_mappings(struct vcpu *v, mfn_t sl2mfn,
int user_only)
#elif GUEST_PAGING_LEVELS == 4
-void sh_unhook_64b_mappings(struct vcpu *v, mfn_t sl4mfn, int user_only)
+void sh_unhook_64b_mappings(struct domain *d, mfn_t sl4mfn, int user_only)
{
-struct domain *d = v->domain;
shadow_l4e_t *sl4e;
SHADOW_FOREACH_L4E(sl4mfn, sl4e, 0, 0, d, {
if ( !user_only || (sl4e->l4 & _PAGE_USER) )
@@ -4506,7 +4503,7 @@ static void sh_pagetable_dying(struct vcpu *v, paddr_t
gpa)
{
gmfn = _mfn(mfn_to_page(smfn)->v.sh.back);
mfn_to_page(gmfn)->shadow_flags |= SHF_pagetable_dying;
-shadow_unhook_mappings(v, smfn, 1/* user pages only */);
+shadow_unhook_mappings(d, smfn, 1/* user pages only */);
flush = 1;
}
}
@@ -4545,7 +4542,7 @@ static void sh_pagetable_dying(struct vcpu *v, paddr_t
gpa)
if ( mfn_valid(smfn) )
{
mfn_to_page(gmfn)->shadow_flags |= SHF_pagetable_dying;
-shadow_unhook_mappings(v, smfn, 1/* user pages only */);
+shadow_unhook_mappings(d, smfn, 1/* user pages only */);
/* Now flush the TLB: we removed toplevel mappings. */
flush_tlb_mask(d->domain_dir
[Xen-devel] [PATCH 16/20] x86/shadow: Alter sh_rm_write_access_from_???() to take a domain
Signed-off-by: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/mm/shadow/common.c | 19 ++-
xen/arch/x86/mm/shadow/multi.c |6 ++
xen/arch/x86/mm/shadow/multi.h |4 ++--
xen/arch/x86/mm/shadow/private.h |2 +-
4 files changed, 15 insertions(+), 16 deletions(-)
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 4a9b94b..e10b578 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -587,12 +587,13 @@ static inline void _sh_resync_l1(struct vcpu *v, mfn_t
gmfn, mfn_t snpmfn)
static inline int oos_fixup_flush_gmfn(struct vcpu *v, mfn_t gmfn,
struct oos_fixup *fixup)
{
+struct domain *d = v->domain;
int i;
for ( i = 0; i < SHADOW_OOS_FIXUPS; i++ )
{
if ( mfn_x(fixup->smfn[i]) != INVALID_MFN )
{
-sh_remove_write_access_from_sl1p(v, gmfn,
+sh_remove_write_access_from_sl1p(d, gmfn,
fixup->smfn[i],
fixup->off[i]);
fixup->smfn[i] = _mfn(INVALID_MFN);
@@ -638,7 +639,7 @@ void oos_fixup_add(struct domain *d, mfn_t gmfn,
TRACE_SHADOW_PATH_FLAG(TRCE_SFLAG_OOS_FIXUP_EVICT);
/* Reuse this slot and remove current writable mapping. */
-sh_remove_write_access_from_sl1p(v, gmfn,
+sh_remove_write_access_from_sl1p(d, gmfn,
oos_fixup[idx].smfn[next],
oos_fixup[idx].off[next]);
perfc_incr(shadow_oos_fixup_evict);
@@ -2184,7 +2185,7 @@ int sh_remove_write_access(struct vcpu *v, mfn_t gmfn,
unsigned long fault_addr)
{
/* Dispatch table for getting per-type functions */
-static const hash_vcpu_callback_t callbacks[SH_type_unused] = {
+static const hash_domain_callback_t callbacks[SH_type_unused] = {
NULL, /* none*/
SHADOW_INTERNAL_NAME(sh_rm_write_access_from_l1, 2), /* l1_32 */
SHADOW_INTERNAL_NAME(sh_rm_write_access_from_l1, 2), /* fl1_32 */
@@ -2367,7 +2368,7 @@ int sh_remove_write_access(struct vcpu *v, mfn_t gmfn,
int shtype = mfn_to_page(last_smfn)->u.sh.type;
if ( callbacks[shtype] )
-callbacks[shtype](curr, last_smfn, gmfn);
+callbacks[shtype](d, last_smfn, gmfn);
if ( (pg->u.inuse.type_info & PGT_count_mask) != old_count )
perfc_incr(shadow_writeable_h_5);
@@ -2384,7 +2385,7 @@ int sh_remove_write_access(struct vcpu *v, mfn_t gmfn,
perfc_incr(shadow_writeable_bf_1);
else
perfc_incr(shadow_writeable_bf);
-hash_vcpu_foreach(v, callback_mask, callbacks, gmfn);
+hash_domain_foreach(d, callback_mask, callbacks, gmfn);
/* If that didn't catch the mapping, then there's some non-pagetable
* mapping -- ioreq page, grant mapping, &c. */
@@ -2404,7 +2405,7 @@ int sh_remove_write_access(struct vcpu *v, mfn_t gmfn,
}
#if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
-int sh_remove_write_access_from_sl1p(struct vcpu *v, mfn_t gmfn,
+int sh_remove_write_access_from_sl1p(struct domain *d, mfn_t gmfn,
mfn_t smfn, unsigned long off)
{
struct page_info *sp = mfn_to_page(smfn);
@@ -2416,16 +2417,16 @@ int sh_remove_write_access_from_sl1p(struct vcpu *v,
mfn_t gmfn,
|| sp->u.sh.type == SH_type_fl1_32_shadow )
{
return SHADOW_INTERNAL_NAME(sh_rm_write_access_from_sl1p,2)
-(v, gmfn, smfn, off);
+(d, gmfn, smfn, off);
}
else if ( sp->u.sh.type == SH_type_l1_pae_shadow
|| sp->u.sh.type == SH_type_fl1_pae_shadow )
return SHADOW_INTERNAL_NAME(sh_rm_write_access_from_sl1p,3)
-(v, gmfn, smfn, off);
+(d, gmfn, smfn, off);
else if ( sp->u.sh.type == SH_type_l1_64_shadow
|| sp->u.sh.type == SH_type_fl1_64_shadow )
return SHADOW_INTERNAL_NAME(sh_rm_write_access_from_sl1p,4)
-(v, gmfn, smfn, off);
+(d, gmfn, smfn, off);
return 0;
}
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 79d..0d1021b 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -4177,10 +4177,9 @@ sh_update_cr3(struct vcpu *v, int do_locking)
/* Functions to revoke guest rights */
#if SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC
-int sh_rm_write_access_from_sl1p(struct vcpu *v, mfn_t gmfn,
+int sh_rm_write_access_from_sl1p(struct domain *d, mfn_t gmfn,
mfn_t smfn, unsigned long off)
{
-struct domain *d = v->domain;
struct vcpu *curr = current;
int r;
shadow_l1e_t *sl1p, sl1e;
@@ -4280,11 +4279,10 @@ static int sh_guess_wrmap(struct vcpu *v, unsigned long
vaddr, mfn_t
[Xen-devel] [PATCH 19/20] x86/shadow: Alter sh_remove_write_access to take a domain
This allows the removal an improper use of d->vcpu[0] from toolstack context
Signed-off-by: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/mm/shadow/common.c |7 +++
xen/arch/x86/mm/shadow/multi.c | 16 ++--
xen/arch/x86/mm/shadow/private.h |2 +-
3 files changed, 10 insertions(+), 15 deletions(-)
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index d24859e..4e6397a 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -671,7 +671,7 @@ static int oos_remove_write_access(struct vcpu *v, mfn_t
gmfn,
ftlb |= oos_fixup_flush_gmfn(v, gmfn, fixup);
-switch ( sh_remove_write_access(v, gmfn, 0, 0) )
+switch ( sh_remove_write_access(d, gmfn, 0, 0) )
{
default:
case 0:
@@ -2180,7 +2180,7 @@ static inline void trace_shadow_wrmap_bf(mfn_t gmfn)
* level==0 means we have some other reason for revoking write access.
* If level==0 we are allowed to fail, returning -1. */
-int sh_remove_write_access(struct vcpu *v, mfn_t gmfn,
+int sh_remove_write_access(struct domain *d, mfn_t gmfn,
unsigned int level,
unsigned long fault_addr)
{
@@ -2212,7 +2212,6 @@ int sh_remove_write_access(struct vcpu *v, mfn_t gmfn,
| SHF_L1_64
| SHF_FL1_64
;
-struct domain *d = v->domain;
struct page_info *pg = mfn_to_page(gmfn);
#if SHADOW_OPTIMIZATIONS & SHOPT_WRITABLE_HEURISTIC
struct vcpu *curr = current;
@@ -3689,7 +3688,7 @@ int shadow_track_dirty_vram(struct domain *d,
for ( i = begin_pfn; i < end_pfn; i++ ) {
mfn_t mfn = get_gfn_query_unlocked(d, i, &t);
if (mfn_x(mfn) != INVALID_MFN)
-flush_tlb |= sh_remove_write_access(d->vcpu[0], mfn,
1, 0);
+flush_tlb |= sh_remove_write_access(d, mfn, 1, 0);
}
dirty_vram->last_dirty = -1;
}
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 288c7d5..16cd60d 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -278,11 +278,7 @@ shadow_check_gl1e(struct vcpu *v, walk_t *gw)
static inline uint32_t
gw_remove_write_accesses(struct vcpu *v, unsigned long va, walk_t *gw)
{
-#if GUEST_PAGING_LEVELS >= 3 /* PAE or 64... */
-#if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
struct domain *d = v->domain;
-#endif
-#endif
uint32_t rc = 0;
#if GUEST_PAGING_LEVELS >= 3 /* PAE or 64... */
@@ -295,7 +291,7 @@ gw_remove_write_accesses(struct vcpu *v, unsigned long va,
walk_t *gw)
}
else
#endif /* OOS */
- if ( sh_remove_write_access(v, gw->l3mfn, 3, va) )
+ if ( sh_remove_write_access(d, gw->l3mfn, 3, va) )
rc = GW_RMWR_FLUSHTLB;
#endif /* GUEST_PAGING_LEVELS >= 4 */
@@ -307,7 +303,7 @@ gw_remove_write_accesses(struct vcpu *v, unsigned long va,
walk_t *gw)
}
else
#endif /* OOS */
-if ( sh_remove_write_access(v, gw->l2mfn, 2, va) )
+if ( sh_remove_write_access(d, gw->l2mfn, 2, va) )
rc |= GW_RMWR_FLUSHTLB;
#endif /* GUEST_PAGING_LEVELS >= 3 */
@@ -316,7 +312,7 @@ gw_remove_write_accesses(struct vcpu *v, unsigned long va,
walk_t *gw)
#if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
&& !mfn_is_out_of_sync(gw->l1mfn)
#endif /* OOS */
- && sh_remove_write_access(v, gw->l1mfn, 1, va) )
+ && sh_remove_write_access(d, gw->l1mfn, 1, va) )
rc |= GW_RMWR_FLUSHTLB;
return rc;
@@ -4028,7 +4024,7 @@ sh_update_cr3(struct vcpu *v, int do_locking)
* replace the old shadow pagetable(s), so that we can safely use the
* (old) shadow linear maps in the writeable mapping heuristics. */
#if GUEST_PAGING_LEVELS == 2
-if ( sh_remove_write_access(v, gmfn, 2, 0) != 0 )
+if ( sh_remove_write_access(d, gmfn, 2, 0) != 0 )
flush_tlb_mask(d->domain_dirty_cpumask);
sh_set_toplevel_shadow(v, 0, gmfn, SH_type_l2_shadow);
#elif GUEST_PAGING_LEVELS == 3
@@ -4048,7 +4044,7 @@ sh_update_cr3(struct vcpu *v, int do_locking)
gl2gfn = guest_l3e_get_gfn(gl3e[i]);
gl2mfn = get_gfn_query_unlocked(d, gfn_x(gl2gfn), &p2mt);
if ( p2m_is_ram(p2mt) )
-flush |= sh_remove_write_access(v, gl2mfn, 2, 0);
+flush |= sh_remove_write_access(d, gl2mfn, 2, 0);
}
}
if ( flush )
@@ -4072,7 +4068,7 @@ sh_update_cr3(struct vcpu *v, int do_locking)
}
}
#elif GUEST_PAGING_LEVELS == 4
-if ( sh_remove_write_access(v, gmfn, 4, 0) != 0 )
+if ( sh_remove_write_access(d, gmfn, 4, 0) != 0 )
flush_tlb_mask(d->domain_dirty_cpumask);
sh_set_toplevel_shadow(v, 0, gmfn, SH_type_l4_shadow);
#else
diff --git a/xen/arch/x86/mm/shadow/private.h b/xen/arch/x86/mm/shadow/private.h
index 96b53b9..1bf1deb 100644
--- a/xen/arch/x86/mm/
[Xen-devel] [PATCH 13/20] x86/shadow: Alter sh_{clear_shadow_entry, remove_shadow_via_pointer}() to take a domain
Signed-off-by: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/mm/shadow/common.c | 11 +--
xen/arch/x86/mm/shadow/multi.c |4 +---
xen/arch/x86/mm/shadow/multi.h |2 +-
3 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 046201a..e522b60 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -2466,11 +2466,10 @@ static int sh_remove_all_mappings(struct vcpu *v, mfn_t
gmfn)
/**/
/* Remove all shadows of a guest frame from the shadow tables */
-static int sh_remove_shadow_via_pointer(struct vcpu *v, mfn_t smfn)
+static int sh_remove_shadow_via_pointer(struct domain *d, mfn_t smfn)
/* Follow this shadow's up-pointer, if it has one, and remove the reference
* found there. Returns 1 if that was the only reference to this shadow */
{
-struct domain *d = v->domain;
struct page_info *sp = mfn_to_page(smfn);
mfn_t pmfn;
void *vaddr;
@@ -2496,19 +2495,19 @@ static int sh_remove_shadow_via_pointer(struct vcpu *v,
mfn_t smfn)
{
case SH_type_l1_32_shadow:
case SH_type_l2_32_shadow:
-SHADOW_INTERNAL_NAME(sh_clear_shadow_entry, 2)(v, vaddr, pmfn);
+SHADOW_INTERNAL_NAME(sh_clear_shadow_entry, 2)(d, vaddr, pmfn);
break;
case SH_type_l1_pae_shadow:
case SH_type_l2_pae_shadow:
case SH_type_l2h_pae_shadow:
-SHADOW_INTERNAL_NAME(sh_clear_shadow_entry, 3)(v, vaddr, pmfn);
+SHADOW_INTERNAL_NAME(sh_clear_shadow_entry, 3)(d, vaddr, pmfn);
break;
case SH_type_l1_64_shadow:
case SH_type_l2_64_shadow:
case SH_type_l2h_64_shadow:
case SH_type_l3_64_shadow:
case SH_type_l4_64_shadow:
-SHADOW_INTERNAL_NAME(sh_clear_shadow_entry, 4)(v, vaddr, pmfn);
+SHADOW_INTERNAL_NAME(sh_clear_shadow_entry, 4)(d, vaddr, pmfn);
break;
default: BUG(); /* Some wierd unknown shadow type */
}
@@ -2618,7 +2617,7 @@ void sh_remove_shadows(struct vcpu *v, mfn_t gmfn, int
fast, int all)
if ( sh_type_is_pinnable(d, t) )\
sh_unpin(d, smfn); \
else if ( sh_type_has_up_pointer(d, t) )\
-sh_remove_shadow_via_pointer(v, smfn); \
+sh_remove_shadow_via_pointer(d, smfn); \
if( !fast \
&& (pg->count_info & PGC_page_table)\
&& (pg->shadow_flags & (1 << t)) ) \
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 1db8161..469ad25 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -4347,11 +4347,9 @@ int sh_rm_mappings_from_l1(struct vcpu *v, mfn_t sl1mfn,
mfn_t target_mfn)
/**/
/* Functions to excise all pointers to shadows from higher-level shadows. */
-void sh_clear_shadow_entry(struct vcpu *v, void *ep, mfn_t smfn)
+void sh_clear_shadow_entry(struct domain *d, void *ep, mfn_t smfn)
/* Blank out a single shadow entry */
{
-struct domain *d = v->domain;
-
switch ( mfn_to_page(smfn)->u.sh.type )
{
case SH_type_l1_shadow:
diff --git a/xen/arch/x86/mm/shadow/multi.h b/xen/arch/x86/mm/shadow/multi.h
index 614103d..e33948c 100644
--- a/xen/arch/x86/mm/shadow/multi.h
+++ b/xen/arch/x86/mm/shadow/multi.h
@@ -69,7 +69,7 @@ SHADOW_INTERNAL_NAME(sh_rm_mappings_from_l1, GUEST_LEVELS)
extern void
SHADOW_INTERNAL_NAME(sh_clear_shadow_entry, GUEST_LEVELS)
-(struct vcpu *v, void *ep, mfn_t smfn);
+(struct domain *d, void *ep, mfn_t smfn);
extern int
SHADOW_INTERNAL_NAME(sh_remove_l1_shadow, GUEST_LEVELS)
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
