Re: [Xen-devel] [PATCH] xen/grant-table: remove unnecessary BUG_ON on gnttab_interface

2019-12-15 Thread Jürgen Groß 

On 15.12.19 21:13, Aditya Pakki wrote:

grow_gnttab_list() checks for NULL on gnttab_interface immediately
after gnttab_expand() check. The patch removes the redundant assertion
and replaces the BUG_ON call with recovery code.

Signed-off-by: Aditya Pakki 
---
  drivers/xen/grant-table.c | 9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 49b381e104ef..f59694c352be 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -664,7 +664,6 @@ static int grow_gnttab_list(unsigned int more_frames)
unsigned int nr_glist_frames, new_nr_glist_frames;
unsigned int grefs_per_frame;
  
-	BUG_ON(gnttab_interface == NULL);

grefs_per_frame = gnttab_interface->grefs_per_grant_frame;
  
  	new_nr_grant_frames = nr_grant_frames + more_frames;

@@ -1388,7 +1387,9 @@ static int gnttab_expand(unsigned int req_entries)
int rc;
unsigned int cur, extra;
  
-	BUG_ON(gnttab_interface == NULL);

+   if (!gnttab_interface)
+   return -EINVAL;
+
cur = nr_grant_frames;
extra = ((req_entries + gnttab_interface->grefs_per_grant_frame - 1) /
 gnttab_interface->grefs_per_grant_frame);
@@ -1423,7 +1424,9 @@ int gnttab_init(void)
/* Determine the maximum number of frames required for the
 * grant reference free list on the current hypervisor.
 */
-   BUG_ON(gnttab_interface == NULL);
+   if (!gnttab_interface)
+   return -EINVAL;
+


I'd just remove the BUG_ON().

gnttab_request_version() called some lines up always sets
gnttab_interface.

The BUG_ON() in nr_status_frames() can be removed, too. It is either
called by v2 specific functions (for those to be reached
gnttab_interface must be set) or by gnttab_init() (reasoning see
above).


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [ovmf test] 144855: regressions - FAIL

2019-12-15 Thread osstest service owner 
flight 144855 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144855/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm6 xen-buildfail REGR. vs. 144637
 build-amd64   6 xen-buildfail REGR. vs. 144637
 build-amd64-xsm   6 xen-buildfail REGR. vs. 144637
 build-i3866 xen-buildfail REGR. vs. 144637

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a

version targeted for testing:
 ovmf bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
baseline version:
 ovmf 804666c86e7b6f04fe5c5cfdb13199c19e0e99b0

Last test of basis   144637  2019-12-09 09:09:49 Z6 days
Failing since144646  2019-12-10 01:39:53 Z6 days   48 attempts
Testing same since   144770  2019-12-12 18:41:26 Z3 days   37 attempts


People who touched revisions under test:
  Antoine Coeur 
  Ard Biesheuvel 
  Bob Feng 
  Jiewen Yao 
  Michael Kubacki 
  Pete Batard 
  Philippe Mathieu-Daude 
  Steven Shi 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
Author: Pete Batard 
Date:   Tue Dec 10 18:23:04 2019 +

MdePkg/Include: Add DCC and BCM2835 SPCR UART types

As per the Microsoft Debug Port Table 2 (DBG2) documentation, that
can be found online, we are missing 2 serial interface types for
Arm DCC and Bcm2835 (the latter being used with the Raspberry Pi).

These same types are present in DebugPort2Table.h so add them to
SerialPortConsoleRedirectionTable.h too.

Note that we followed the same idiosyncrasies as DebugPort2Table
for naming these new macros.

Signed-off-by: Pete Batard 
Acked-by: Ard Biesheuvel 
Reviewed-by: Liming Gao 

commit 2fe25a74d6fee3c2ac0b930f7f3596cb432e766e
Author: Ard Biesheuvel 
Date:   Tue Mar 5 14:32:48 2019 +0100

ArmPkg/MmCommunicationDxe: relay architected PI events to MM context

PI defines a few architected events that have significance in the MM
context as well as in the non-secure DXE context. So register notify
handlers for these events, and relay them into the standalone MM world.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Jiewen Yao 
Reviewed-by: Achin Gupta 

commit d3add11e87dace180387562d6f1951f2bffbd3d9
Author: Michael Kubacki 
Date:   Wed Nov 20 17:31:24 2019 -0800

MdeModulePkg PeiCore: Improve comment semantics

This patch clarifies wording in several PeiCore comments to improve
reading comprehension.

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Jian J Wang 

commit d39d1260c615b716675f67f5c4e1f4f52df01dad
Author: Michael Kubacki 
Date:   Wed Nov 20 17:10:48 2019 -0800

MdeModulePkg PeiCore: Fix typos

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Philippe Mathieu-Daude 
Reviewed-by: Jian J Wang 

commit 97eedf5dfbaffde33210fd88066247cf0b7d3325
Author: Antoine Coeur 
Date:   Wed Dec 4 12:14:53

Re: [Xen-devel] [PATCH v2] IOMMU: make DMA containment of quarantined devices optional

2019-12-15 Thread Jürgen Groß 

On 16.12.19 06:58, Tian, Kevin wrote:

From: Jürgen Groß 
Sent: Friday, December 13, 2019 11:36 PM

On 13.12.19 15:45, Jan Beulich wrote:

On 13.12.2019 15:24, Jürgen Groß wrote:

On 13.12.19 15:11, Jan Beulich wrote:

On 13.12.2019 14:46, Jürgen Groß wrote:

On 13.12.19 14:38, Jan Beulich wrote:

On 13.12.2019 14:31, Jürgen Groß wrote:

Maybe I have misunderstood the current state, but I thought that it
would just silently hide quirky devices without imposing a security
risk. We would not learn which devices are quirky, but OTOH I doubt
we'd get many reports about those in case your patch goes in.


We don't want or need such reports, that's not the point. The
security risk comes from the quirkiness of the devices - admins
may wrongly think all is well and expose quirky devices to not
sufficiently trusted guests. (I say this fully realizing that
exposing devices to untrusted guests is almost always a certain
level of risk.)


Do we _know_ those devices are problematic from security standpoint?
Normally the IOMMU should do the isolation just fine. If it doesn't
then its not the quirky device which is problematic, but the IOMMU.

I thought the problem was that the quirky devices would not stop all
(read) DMA even when being unassigned from the guest resulting in
fatal IOMMU faults. The dummy page should stop those faults to

happen

resulting in a more stable system.


IOMMU faults by themselves are not impacting stability (they will
add processing overhead, yes). The problem, according to Paul's
description, is that the occurrence of at least some forms of IOMMU
faults (not present ones as it seems, as opposed to permission
violation ones) is fatal to certain systems. Irrespective of the
sink page used after de-assignment a guest can arrange for IOMMU
faults to occur even while it still has the device assigned. Hence
it is important for the admin to know that their system (not the
the particular device) behaves in this undesirable way.


So how does the admin learn this? Its not as if your patch would result
in a system crash or hang all the time, right? This would be the case
only if there either is a malicious (on purpose or due to a bug) guest
which gets the device assigned, or if there happens to be a pending DMA
operation when the device gets unassigned.


I didn't claim the change would cover all cases. All I am claiming
is that it increases the chances of admins becoming aware of reasons
not to pass through devices to certain guests.


So combined with your answer this means to me:

With your patch (or the original one reverted) a DoS will occur either
due to a malicious guest or in case a DMA is still pending. As a result
the admin will no longer pass this device to any untrusted guest.

With the current 4.13-staging a DoS will occur only due to a malicious
guest. The admin will then no longer pass this device to any untrusted
guest.

So right now without any untrusted guest no DoS, while possibly DoS with
your patch. How is that better?



I'd suggest separating run-time DoS from original quarantine purpose
of this patch.

For quarantine, I'm with Jan that giving admin the chance of knowing
whether quarantine is required is important. Say an admin just gets
a sample device from a new vendor and needs to decide whether his
employer should put such device in their production system. It's
essential to have a default configuration which can warn on any
possible violation of the expectations on a good assignable device.
Then the admin can look at Xen user guide to find out what the warning
information means and then does whatever required (usually means
more scrutinization than the warning itself) to figure out whether
identified problems are safe (e.g. by enabling quarantine) or are
real indicators of bogus implementation (then should not use it).
Having quarantine default on means that every admin should remember
that Xen already enables some band-aids on benign warnings so he
should explicitly turn off those options to do evaluation which, to me
is not realistic.


This implies the admin is aware of the necessity to do that testing.
And for the tests to be conclusive he probably needs to do more than
just a basic "does it work" test, as the pending DMA might occur in
some cases only. And that is basically my problem with Jan's default:
an admin not doing enough testing (or non at all) will end up with a
DoS situation in production, while an admin knowing that he needs to
test properly is probably more aware of the needed command line option
for evaluation of the device's security relevance.

Its a complex problem and I think the decision for the default should
not be rushed. So I think it is best to discuss it on xen-devel and
leave the patch out of the initial 4.13 release (this patch is the last
pending one for 4.13 now). After a decision is made the patch can easily
by backported to 4.13 in case it is regarded to be important.


Juergen

___
Xen-devel

Re: [Xen-devel] [PATCH] Xen missing prompt log when exec-sp=off

2019-12-15 Thread Jin Nan Wang 

On 16/12/2019 2:17 pm, Tian, Kevin wrote:
>> From: Jin Nan Wang 
>> Sent: Monday, December 16, 2019 1:48 PM
>>
>> Fix a issue when user disable ETP exec-sp, xen missed a prompt
>> log in dmesg.
>>
>> Signed-off-by: James Wang 
>> ---
>>   xen/arch/x86/hvm/vmx/vmx.c | 4 +++-
>>   1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
>> index 7970ba93e1..9c1f0f645d 100644
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -2499,7 +2499,9 @@ const struct hvm_function_table * __init
>> start_vmx(void)
>>   {
>>   /* Default to non-executable superpages on vulnerable 
>> hardware. */
>>   opt_ept_exec_sp = !cpu_has_bug_pschange_mc;
>> -
>> +}
> no parenthesis then. Just move the comment before the earlier condition
> check
Got it.
>> +if (opt_ept_exec_sp == false)
>> +{
>>   if ( cpu_has_bug_pschange_mc )
>>   printk("VMX: Disabling executable EPT superpages due to 
>> CVE-
>> 2018-12207\n");
>>   }
> Can we do it another way? Always throw out a warning if the hardware
> is vulnerable, plus its enabling status?
OK. Let me try.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2] IOMMU: make DMA containment of quarantined devices optional

2019-12-15 Thread Tian, Kevin 
> From: Tian, Kevin
> Sent: Monday, December 16, 2019 1:58 PM
> 
> > From: Jürgen Groß 
> > Sent: Friday, December 13, 2019 11:36 PM
> >
> > On 13.12.19 15:45, Jan Beulich wrote:
> > > On 13.12.2019 15:24, Jürgen Groß wrote:
> > >> On 13.12.19 15:11, Jan Beulich wrote:
> > >>> On 13.12.2019 14:46, Jürgen Groß wrote:
> >  On 13.12.19 14:38, Jan Beulich wrote:
> > > On 13.12.2019 14:31, Jürgen Groß wrote:
> > >> Maybe I have misunderstood the current state, but I thought that it
> > >> would just silently hide quirky devices without imposing a security
> > >> risk. We would not learn which devices are quirky, but OTOH I
> doubt
> > >> we'd get many reports about those in case your patch goes in.
> > >
> > > We don't want or need such reports, that's not the point. The
> > > security risk comes from the quirkiness of the devices - admins
> > > may wrongly think all is well and expose quirky devices to not
> > > sufficiently trusted guests. (I say this fully realizing that
> > > exposing devices to untrusted guests is almost always a certain
> > > level of risk.)
> > 
> >  Do we _know_ those devices are problematic from security
> standpoint?
> >  Normally the IOMMU should do the isolation just fine. If it doesn't
> >  then its not the quirky device which is problematic, but the IOMMU.
> > 
> >  I thought the problem was that the quirky devices would not stop all
> >  (read) DMA even when being unassigned from the guest resulting in
> >  fatal IOMMU faults. The dummy page should stop those faults to
> > happen
> >  resulting in a more stable system.
> > >>>
> > >>> IOMMU faults by themselves are not impacting stability (they will
> > >>> add processing overhead, yes). The problem, according to Paul's
> > >>> description, is that the occurrence of at least some forms of IOMMU
> > >>> faults (not present ones as it seems, as opposed to permission
> > >>> violation ones) is fatal to certain systems. Irrespective of the
> > >>> sink page used after de-assignment a guest can arrange for IOMMU
> > >>> faults to occur even while it still has the device assigned. Hence
> > >>> it is important for the admin to know that their system (not the
> > >>> the particular device) behaves in this undesirable way.
> > >>
> > >> So how does the admin learn this? Its not as if your patch would result
> > >> in a system crash or hang all the time, right? This would be the case
> > >> only if there either is a malicious (on purpose or due to a bug) guest
> > >> which gets the device assigned, or if there happens to be a pending DMA
> > >> operation when the device gets unassigned.
> > >
> > > I didn't claim the change would cover all cases. All I am claiming
> > > is that it increases the chances of admins becoming aware of reasons
> > > not to pass through devices to certain guests.
> >
> > So combined with your answer this means to me:
> >
> > With your patch (or the original one reverted) a DoS will occur either
> > due to a malicious guest or in case a DMA is still pending. As a result
> > the admin will no longer pass this device to any untrusted guest.
> >
> > With the current 4.13-staging a DoS will occur only due to a malicious
> > guest. The admin will then no longer pass this device to any untrusted
> > guest.
> >
> > So right now without any untrusted guest no DoS, while possibly DoS with
> > your patch. How is that better?
> >
> 
> I'd suggest separating run-time DoS from original quarantine purpose
> of this patch.
> 
> For quarantine, I'm with Jan that giving admin the chance of knowing
> whether quarantine is required is important. Say an admin just gets
> a sample device from a new vendor and needs to decide whether his
> employer should put such device in their production system. It's
> essential to have a default configuration which can warn on any
> possible violation of the expectations on a good assignable device.
> Then the admin can look at Xen user guide to find out what the warning
> information means and then does whatever required (usually means
> more scrutinization than the warning itself) to figure out whether
> identified problems are safe (e.g. by enabling quarantine) or are
> real indicators of bogus implementation (then should not use it).
> Having quarantine default on means that every admin should remember
> that Xen already enables some band-aids on benign warnings so he
> should explicitly turn off those options to do evaluation which, to me
> is not realistic.
> 
> On the other hand, although a sink page can help mitigate run-time DoS,
> how to handle it should be an admin policy. If DoS is caused by
> malicious guest, it makes more sense to warn the admin and then switch
> to sink page after meeting a DoS detection condition (e.g. number of
> faults within a timing window exceeds a threshold). Lots of such warnings
> from multiple VMs may imply a massive attack then the admin may adopt
> more comprehensive

[Xen-devel] [ovmf test] 144854: regressions - FAIL

2019-12-15 Thread osstest service owner 
flight 144854 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144854/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm6 xen-buildfail REGR. vs. 144637
 build-amd64   6 xen-buildfail REGR. vs. 144637
 build-amd64-xsm   6 xen-buildfail REGR. vs. 144637
 build-i3866 xen-buildfail REGR. vs. 144637

Tests which did not succeed, but are not blocking:
 build-i386-libvirt1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
baseline version:
 ovmf 804666c86e7b6f04fe5c5cfdb13199c19e0e99b0

Last test of basis   144637  2019-12-09 09:09:49 Z6 days
Failing since144646  2019-12-10 01:39:53 Z6 days   47 attempts
Testing same since   144770  2019-12-12 18:41:26 Z3 days   36 attempts


People who touched revisions under test:
  Antoine Coeur 
  Ard Biesheuvel 
  Bob Feng 
  Jiewen Yao 
  Michael Kubacki 
  Pete Batard 
  Philippe Mathieu-Daude 
  Steven Shi 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
Author: Pete Batard 
Date:   Tue Dec 10 18:23:04 2019 +

MdePkg/Include: Add DCC and BCM2835 SPCR UART types

As per the Microsoft Debug Port Table 2 (DBG2) documentation, that
can be found online, we are missing 2 serial interface types for
Arm DCC and Bcm2835 (the latter being used with the Raspberry Pi).

These same types are present in DebugPort2Table.h so add them to
SerialPortConsoleRedirectionTable.h too.

Note that we followed the same idiosyncrasies as DebugPort2Table
for naming these new macros.

Signed-off-by: Pete Batard 
Acked-by: Ard Biesheuvel 
Reviewed-by: Liming Gao 

commit 2fe25a74d6fee3c2ac0b930f7f3596cb432e766e
Author: Ard Biesheuvel 
Date:   Tue Mar 5 14:32:48 2019 +0100

ArmPkg/MmCommunicationDxe: relay architected PI events to MM context

PI defines a few architected events that have significance in the MM
context as well as in the non-secure DXE context. So register notify
handlers for these events, and relay them into the standalone MM world.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Jiewen Yao 
Reviewed-by: Achin Gupta 

commit d3add11e87dace180387562d6f1951f2bffbd3d9
Author: Michael Kubacki 
Date:   Wed Nov 20 17:31:24 2019 -0800

MdeModulePkg PeiCore: Improve comment semantics

This patch clarifies wording in several PeiCore comments to improve
reading comprehension.

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Jian J Wang 

commit d39d1260c615b716675f67f5c4e1f4f52df01dad
Author: Michael Kubacki 
Date:   Wed Nov 20 17:10:48 2019 -0800

MdeModulePkg PeiCore: Fix typos

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Philippe Mathieu-Daude 
Reviewed-by: Jian J Wang 

commit 97eedf5dfbaffde33210fd88066247cf0b7d3325
Author: Antoine Coeur 
Date:   Wed Dec 4 12:14:53

Re: [Xen-devel] [PATCH] Xen missing prompt log when exec-sp=off

2019-12-15 Thread Tian, Kevin 
> From: Jin Nan Wang 
> Sent: Monday, December 16, 2019 1:48 PM
> 
> Fix a issue when user disable ETP exec-sp, xen missed a prompt
> log in dmesg.
> 
> Signed-off-by: James Wang 
> ---
>  xen/arch/x86/hvm/vmx/vmx.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 7970ba93e1..9c1f0f645d 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2499,7 +2499,9 @@ const struct hvm_function_table * __init
> start_vmx(void)
>  {
>  /* Default to non-executable superpages on vulnerable hardware. 
> */
>  opt_ept_exec_sp = !cpu_has_bug_pschange_mc;
> -
> +}

no parenthesis then. Just move the comment before the earlier condition
check

> +if (opt_ept_exec_sp == false)
> +{
>  if ( cpu_has_bug_pschange_mc )
>  printk("VMX: Disabling executable EPT superpages due to CVE-
> 2018-12207\n");
>  }

Can we do it another way? Always throw out a warning if the hardware
is vulnerable, plus its enabling status?

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2] IOMMU: make DMA containment of quarantined devices optional

2019-12-15 Thread Tian, Kevin 
> From: Roger Pau Monné 
> Sent: Friday, December 13, 2019 10:13 PM
> 
> On Fri, Dec 13, 2019 at 01:53:29PM +0100, Jan Beulich wrote:
> > Containing still in flight DMA was introduced to work around certain
> > devices / systems hanging hard upon hitting an IOMMU fault. Passing
> > through (such) devices (on such systems) is inherently insecure (as
> > guests could easily arrange for IOMMU faults to occur). Defaulting to
> > a mode where admins may not even become aware of issues with devices
> can
> > be considered undesirable. Therefore convert this mode of operation to
> > an optional one, not one enabled by default.
> >
> > This involves resurrecting code commit ea38867831da ("x86 / iommu: set
> > up a scratch page in the quarantine domain") did remove, in a slightly
> > extended and abstracted fashion. Here, instead of reintroducing a pretty
> > pointless use of "goto" in domain_context_unmap(), and instead of making
> > the function (at least temporarily) inconsistent, take the opportunity
> > and replace the other similarly pointless "goto" as well.
> >
> > In order to key the re-instated bypasses off of there (not) being a root
> > page table this further requires moving the allocate_domain_resources()
> > invocation from reassign_device() to amd_iommu_setup_domain_device()
> (or
> > else reassign_device() would allocate a root page table anyway); this is
> > benign to the second caller of the latter function.
> >
> > Signed-off-by: Jan Beulich 
> 
> Reviewed-by: Roger Pau Monné 
> 
> I'm however not sure if the default quarantine mode should be the
> basic or the full one.
> 
> At the end of day the full one does prevent hard hangs on specific
> systems, but a guest with a device behind such bogus IOMMU can
> trivially trigger those anyway.

It's a bogus device behind a good IOMMU. If IOMMU is bogus, we
should not pass through devices behind it. 

> 
> > ---
> > As far as 4.13 is concerned, I guess if we can't come to an agreement
> > here, the only other option is to revert ea38867831da from the branch,
> > for having been committed prematurely (I'm not so much worried about
> the
> > master branch, where we have ample time until 4.14). What I surely want
> > to see us avoid is a back and forth in behavior of released versions.
> > (Note that 4.12.2 is similarly blocked on a decision either way here.)
> >
> > I'm happy to take better suggestions to replace "full".
> 
> I was going to comment on v1, but I really have no better alternative.
> 
> > --- a/xen/drivers/passthrough/iommu.c
> > +++ b/xen/drivers/passthrough/iommu.c
> > @@ -30,13 +30,17 @@ bool_t __initdata iommu_enable = 1;
> >  bool_t __read_mostly iommu_enabled;
> >  bool_t __read_mostly force_iommu;
> >  bool_t __read_mostly iommu_verbose;
> > -bool __read_mostly iommu_quarantine = true;
> >  bool_t __read_mostly iommu_igfx = 1;
> >  bool_t __read_mostly iommu_snoop = 1;
> >  bool_t __read_mostly iommu_qinval = 1;
> >  bool_t __read_mostly iommu_intremap = 1;
> >  bool_t __read_mostly iommu_crash_disable;
> >
> > +#define IOMMU_quarantine_none  0
> > +#define IOMMU_quarantine_basic 1
> > +#define IOMMU_quarantine_full  2
> > +uint8_t __read_mostly iommu_quarantine = IOMMU_quarantine_basic;
> 
> I wonder whether the default should be to use the sink page. Not using
> it can lead to a hard hang on certain hardware according to the
> description. OTOH if such devices are actually passed through, the
> guest itself can trigger such page faults and hence freeze the system.
> 
> Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2] IOMMU: make DMA containment of quarantined devices optional

2019-12-15 Thread Tian, Kevin 
> From: Jürgen Groß 
> Sent: Friday, December 13, 2019 11:36 PM
> 
> On 13.12.19 15:45, Jan Beulich wrote:
> > On 13.12.2019 15:24, Jürgen Groß wrote:
> >> On 13.12.19 15:11, Jan Beulich wrote:
> >>> On 13.12.2019 14:46, Jürgen Groß wrote:
>  On 13.12.19 14:38, Jan Beulich wrote:
> > On 13.12.2019 14:31, Jürgen Groß wrote:
> >> Maybe I have misunderstood the current state, but I thought that it
> >> would just silently hide quirky devices without imposing a security
> >> risk. We would not learn which devices are quirky, but OTOH I doubt
> >> we'd get many reports about those in case your patch goes in.
> >
> > We don't want or need such reports, that's not the point. The
> > security risk comes from the quirkiness of the devices - admins
> > may wrongly think all is well and expose quirky devices to not
> > sufficiently trusted guests. (I say this fully realizing that
> > exposing devices to untrusted guests is almost always a certain
> > level of risk.)
> 
>  Do we _know_ those devices are problematic from security standpoint?
>  Normally the IOMMU should do the isolation just fine. If it doesn't
>  then its not the quirky device which is problematic, but the IOMMU.
> 
>  I thought the problem was that the quirky devices would not stop all
>  (read) DMA even when being unassigned from the guest resulting in
>  fatal IOMMU faults. The dummy page should stop those faults to
> happen
>  resulting in a more stable system.
> >>>
> >>> IOMMU faults by themselves are not impacting stability (they will
> >>> add processing overhead, yes). The problem, according to Paul's
> >>> description, is that the occurrence of at least some forms of IOMMU
> >>> faults (not present ones as it seems, as opposed to permission
> >>> violation ones) is fatal to certain systems. Irrespective of the
> >>> sink page used after de-assignment a guest can arrange for IOMMU
> >>> faults to occur even while it still has the device assigned. Hence
> >>> it is important for the admin to know that their system (not the
> >>> the particular device) behaves in this undesirable way.
> >>
> >> So how does the admin learn this? Its not as if your patch would result
> >> in a system crash or hang all the time, right? This would be the case
> >> only if there either is a malicious (on purpose or due to a bug) guest
> >> which gets the device assigned, or if there happens to be a pending DMA
> >> operation when the device gets unassigned.
> >
> > I didn't claim the change would cover all cases. All I am claiming
> > is that it increases the chances of admins becoming aware of reasons
> > not to pass through devices to certain guests.
> 
> So combined with your answer this means to me:
> 
> With your patch (or the original one reverted) a DoS will occur either
> due to a malicious guest or in case a DMA is still pending. As a result
> the admin will no longer pass this device to any untrusted guest.
> 
> With the current 4.13-staging a DoS will occur only due to a malicious
> guest. The admin will then no longer pass this device to any untrusted
> guest.
> 
> So right now without any untrusted guest no DoS, while possibly DoS with
> your patch. How is that better?
> 

I'd suggest separating run-time DoS from original quarantine purpose
of this patch.

For quarantine, I'm with Jan that giving admin the chance of knowing
whether quarantine is required is important. Say an admin just gets
a sample device from a new vendor and needs to decide whether his
employer should put such device in their production system. It's
essential to have a default configuration which can warn on any 
possible violation of the expectations on a good assignable device. 
Then the admin can look at Xen user guide to find out what the warning
information means and then does whatever required (usually means
more scrutinization than the warning itself) to figure out whether 
identified problems are safe (e.g. by enabling quarantine) or are
real indicators of bogus implementation (then should not use it).
Having quarantine default on means that every admin should remember
that Xen already enables some band-aids on benign warnings so he
should explicitly turn off those options to do evaluation which, to me
is not realistic.

On the other hand, although a sink page can help mitigate run-time DoS,
how to handle it should be an admin policy. If DoS is caused by 
malicious guest, it makes more sense to warn the admin and then switch
to sink page after meeting a DoS detection condition (e.g. number of
faults within a timing window exceeds a threshold). Lots of such warnings
from multiple VMs may imply a massive attack then the admin may adopt
more comprehensive analysis or defensive means. Then it's also possible
that DoS is caused by a vulnerability within the guest. In such case, the
guest may want to contain the DoS attack itself through a virtual IOMMU.
Then Xen needs to know the fault and

[Xen-devel] [PATCH] Xen missing prompt log when exec-sp=off

2019-12-15 Thread Jin Nan Wang 
Fix a issue when user disable ETP exec-sp, xen missed a prompt
log in dmesg.

Signed-off-by: James Wang 
---
 xen/arch/x86/hvm/vmx/vmx.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 7970ba93e1..9c1f0f645d 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2499,7 +2499,9 @@ const struct hvm_function_table * __init start_vmx(void)
 {
 /* Default to non-executable superpages on vulnerable hardware. */
 opt_ept_exec_sp = !cpu_has_bug_pschange_mc;
-
+}
+if (opt_ept_exec_sp == false)
+{
 if ( cpu_has_bug_pschange_mc )
 printk("VMX: Disabling executable EPT superpages due to 
CVE-2018-12207\n");
 }
-- 
2.24.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH] xen/grant-table: remove unnecessary BUG_ON on gnttab_interface

2019-12-15 Thread Aditya Pakki 
grow_gnttab_list() checks for NULL on gnttab_interface immediately
after gnttab_expand() check. The patch removes the redundant assertion
and replaces the BUG_ON call with recovery code.

Signed-off-by: Aditya Pakki 
---
 drivers/xen/grant-table.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 49b381e104ef..f59694c352be 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -664,7 +664,6 @@ static int grow_gnttab_list(unsigned int more_frames)
unsigned int nr_glist_frames, new_nr_glist_frames;
unsigned int grefs_per_frame;
 
-   BUG_ON(gnttab_interface == NULL);
grefs_per_frame = gnttab_interface->grefs_per_grant_frame;
 
new_nr_grant_frames = nr_grant_frames + more_frames;
@@ -1388,7 +1387,9 @@ static int gnttab_expand(unsigned int req_entries)
int rc;
unsigned int cur, extra;
 
-   BUG_ON(gnttab_interface == NULL);
+   if (!gnttab_interface)
+   return -EINVAL;
+
cur = nr_grant_frames;
extra = ((req_entries + gnttab_interface->grefs_per_grant_frame - 1) /
 gnttab_interface->grefs_per_grant_frame);
@@ -1423,7 +1424,9 @@ int gnttab_init(void)
/* Determine the maximum number of frames required for the
 * grant reference free list on the current hypervisor.
 */
-   BUG_ON(gnttab_interface == NULL);
+   if (!gnttab_interface)
+   return -EINVAL;
+
max_nr_glist_frames = (max_nr_grant_frames *
   gnttab_interface->grefs_per_grant_frame / RPP);
 
-- 
2.20.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [ovmf test] 144852: regressions - FAIL

2019-12-15 Thread osstest service owner 
flight 144852 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144852/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm6 xen-buildfail REGR. vs. 144637
 build-amd64   6 xen-buildfail REGR. vs. 144637
 build-amd64-xsm   6 xen-buildfail REGR. vs. 144637
 build-i3866 xen-buildfail REGR. vs. 144637

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
baseline version:
 ovmf 804666c86e7b6f04fe5c5cfdb13199c19e0e99b0

Last test of basis   144637  2019-12-09 09:09:49 Z6 days
Failing since144646  2019-12-10 01:39:53 Z6 days   46 attempts
Testing same since   144770  2019-12-12 18:41:26 Z3 days   35 attempts


People who touched revisions under test:
  Antoine Coeur 
  Ard Biesheuvel 
  Bob Feng 
  Jiewen Yao 
  Michael Kubacki 
  Pete Batard 
  Philippe Mathieu-Daude 
  Steven Shi 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
Author: Pete Batard 
Date:   Tue Dec 10 18:23:04 2019 +

MdePkg/Include: Add DCC and BCM2835 SPCR UART types

As per the Microsoft Debug Port Table 2 (DBG2) documentation, that
can be found online, we are missing 2 serial interface types for
Arm DCC and Bcm2835 (the latter being used with the Raspberry Pi).

These same types are present in DebugPort2Table.h so add them to
SerialPortConsoleRedirectionTable.h too.

Note that we followed the same idiosyncrasies as DebugPort2Table
for naming these new macros.

Signed-off-by: Pete Batard 
Acked-by: Ard Biesheuvel 
Reviewed-by: Liming Gao 

commit 2fe25a74d6fee3c2ac0b930f7f3596cb432e766e
Author: Ard Biesheuvel 
Date:   Tue Mar 5 14:32:48 2019 +0100

ArmPkg/MmCommunicationDxe: relay architected PI events to MM context

PI defines a few architected events that have significance in the MM
context as well as in the non-secure DXE context. So register notify
handlers for these events, and relay them into the standalone MM world.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Jiewen Yao 
Reviewed-by: Achin Gupta 

commit d3add11e87dace180387562d6f1951f2bffbd3d9
Author: Michael Kubacki 
Date:   Wed Nov 20 17:31:24 2019 -0800

MdeModulePkg PeiCore: Improve comment semantics

This patch clarifies wording in several PeiCore comments to improve
reading comprehension.

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Jian J Wang 

commit d39d1260c615b716675f67f5c4e1f4f52df01dad
Author: Michael Kubacki 
Date:   Wed Nov 20 17:10:48 2019 -0800

MdeModulePkg PeiCore: Fix typos

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Philippe Mathieu-Daude 
Reviewed-by: Jian J Wang 

commit 97eedf5dfbaffde33210fd88066247cf0b7d3325
Author: Antoine Coeur 
Date:   Wed Dec 4 12:14:53

[Xen-devel] [ovmf test] 144851: regressions - FAIL

2019-12-15 Thread osstest service owner 
flight 144851 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144851/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm6 xen-buildfail REGR. vs. 144637
 build-amd64   6 xen-buildfail REGR. vs. 144637
 build-amd64-xsm   6 xen-buildfail REGR. vs. 144637
 build-i3866 xen-buildfail REGR. vs. 144637

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
baseline version:
 ovmf 804666c86e7b6f04fe5c5cfdb13199c19e0e99b0

Last test of basis   144637  2019-12-09 09:09:49 Z6 days
Failing since144646  2019-12-10 01:39:53 Z6 days   45 attempts
Testing same since   144770  2019-12-12 18:41:26 Z3 days   34 attempts


People who touched revisions under test:
  Antoine Coeur 
  Ard Biesheuvel 
  Bob Feng 
  Jiewen Yao 
  Michael Kubacki 
  Pete Batard 
  Philippe Mathieu-Daude 
  Steven Shi 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
Author: Pete Batard 
Date:   Tue Dec 10 18:23:04 2019 +

MdePkg/Include: Add DCC and BCM2835 SPCR UART types

As per the Microsoft Debug Port Table 2 (DBG2) documentation, that
can be found online, we are missing 2 serial interface types for
Arm DCC and Bcm2835 (the latter being used with the Raspberry Pi).

These same types are present in DebugPort2Table.h so add them to
SerialPortConsoleRedirectionTable.h too.

Note that we followed the same idiosyncrasies as DebugPort2Table
for naming these new macros.

Signed-off-by: Pete Batard 
Acked-by: Ard Biesheuvel 
Reviewed-by: Liming Gao 

commit 2fe25a74d6fee3c2ac0b930f7f3596cb432e766e
Author: Ard Biesheuvel 
Date:   Tue Mar 5 14:32:48 2019 +0100

ArmPkg/MmCommunicationDxe: relay architected PI events to MM context

PI defines a few architected events that have significance in the MM
context as well as in the non-secure DXE context. So register notify
handlers for these events, and relay them into the standalone MM world.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Jiewen Yao 
Reviewed-by: Achin Gupta 

commit d3add11e87dace180387562d6f1951f2bffbd3d9
Author: Michael Kubacki 
Date:   Wed Nov 20 17:31:24 2019 -0800

MdeModulePkg PeiCore: Improve comment semantics

This patch clarifies wording in several PeiCore comments to improve
reading comprehension.

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Jian J Wang 

commit d39d1260c615b716675f67f5c4e1f4f52df01dad
Author: Michael Kubacki 
Date:   Wed Nov 20 17:10:48 2019 -0800

MdeModulePkg PeiCore: Fix typos

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Philippe Mathieu-Daude 
Reviewed-by: Jian J Wang 

commit 97eedf5dfbaffde33210fd88066247cf0b7d3325
Author: Antoine Coeur 
Date:   Wed Dec 4 12:14:53

[Xen-devel] [ovmf test] 144849: regressions - FAIL

2019-12-15 Thread osstest service owner 
flight 144849 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144849/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 144637
 build-i386-xsm6 xen-buildfail REGR. vs. 144637
 build-amd64-xsm   6 xen-buildfail REGR. vs. 144637
 build-i3866 xen-buildfail REGR. vs. 144637

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a

version targeted for testing:
 ovmf bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
baseline version:
 ovmf 804666c86e7b6f04fe5c5cfdb13199c19e0e99b0

Last test of basis   144637  2019-12-09 09:09:49 Z6 days
Failing since144646  2019-12-10 01:39:53 Z6 days   44 attempts
Testing same since   144770  2019-12-12 18:41:26 Z3 days   33 attempts


People who touched revisions under test:
  Antoine Coeur 
  Ard Biesheuvel 
  Bob Feng 
  Jiewen Yao 
  Michael Kubacki 
  Pete Batard 
  Philippe Mathieu-Daude 
  Steven Shi 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
Author: Pete Batard 
Date:   Tue Dec 10 18:23:04 2019 +

MdePkg/Include: Add DCC and BCM2835 SPCR UART types

As per the Microsoft Debug Port Table 2 (DBG2) documentation, that
can be found online, we are missing 2 serial interface types for
Arm DCC and Bcm2835 (the latter being used with the Raspberry Pi).

These same types are present in DebugPort2Table.h so add them to
SerialPortConsoleRedirectionTable.h too.

Note that we followed the same idiosyncrasies as DebugPort2Table
for naming these new macros.

Signed-off-by: Pete Batard 
Acked-by: Ard Biesheuvel 
Reviewed-by: Liming Gao 

commit 2fe25a74d6fee3c2ac0b930f7f3596cb432e766e
Author: Ard Biesheuvel 
Date:   Tue Mar 5 14:32:48 2019 +0100

ArmPkg/MmCommunicationDxe: relay architected PI events to MM context

PI defines a few architected events that have significance in the MM
context as well as in the non-secure DXE context. So register notify
handlers for these events, and relay them into the standalone MM world.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Jiewen Yao 
Reviewed-by: Achin Gupta 

commit d3add11e87dace180387562d6f1951f2bffbd3d9
Author: Michael Kubacki 
Date:   Wed Nov 20 17:31:24 2019 -0800

MdeModulePkg PeiCore: Improve comment semantics

This patch clarifies wording in several PeiCore comments to improve
reading comprehension.

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Jian J Wang 

commit d39d1260c615b716675f67f5c4e1f4f52df01dad
Author: Michael Kubacki 
Date:   Wed Nov 20 17:10:48 2019 -0800

MdeModulePkg PeiCore: Fix typos

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Philippe Mathieu-Daude 
Reviewed-by: Jian J Wang 

commit 97eedf5dfbaffde33210fd88066247cf0b7d3325
Author: Antoine Coeur 
Date:   Wed Dec 4 12:14:53

[Xen-devel] [ovmf test] 144848: regressions - FAIL

2019-12-15 Thread osstest service owner 
flight 144848 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144848/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 144637
 build-i386-xsm6 xen-buildfail REGR. vs. 144637
 build-amd64-xsm   6 xen-buildfail REGR. vs. 144637
 build-i3866 xen-buildfail REGR. vs. 144637

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a

version targeted for testing:
 ovmf bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
baseline version:
 ovmf 804666c86e7b6f04fe5c5cfdb13199c19e0e99b0

Last test of basis   144637  2019-12-09 09:09:49 Z6 days
Failing since144646  2019-12-10 01:39:53 Z5 days   43 attempts
Testing same since   144770  2019-12-12 18:41:26 Z3 days   32 attempts


People who touched revisions under test:
  Antoine Coeur 
  Ard Biesheuvel 
  Bob Feng 
  Jiewen Yao 
  Michael Kubacki 
  Pete Batard 
  Philippe Mathieu-Daude 
  Steven Shi 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
Author: Pete Batard 
Date:   Tue Dec 10 18:23:04 2019 +

MdePkg/Include: Add DCC and BCM2835 SPCR UART types

As per the Microsoft Debug Port Table 2 (DBG2) documentation, that
can be found online, we are missing 2 serial interface types for
Arm DCC and Bcm2835 (the latter being used with the Raspberry Pi).

These same types are present in DebugPort2Table.h so add them to
SerialPortConsoleRedirectionTable.h too.

Note that we followed the same idiosyncrasies as DebugPort2Table
for naming these new macros.

Signed-off-by: Pete Batard 
Acked-by: Ard Biesheuvel 
Reviewed-by: Liming Gao 

commit 2fe25a74d6fee3c2ac0b930f7f3596cb432e766e
Author: Ard Biesheuvel 
Date:   Tue Mar 5 14:32:48 2019 +0100

ArmPkg/MmCommunicationDxe: relay architected PI events to MM context

PI defines a few architected events that have significance in the MM
context as well as in the non-secure DXE context. So register notify
handlers for these events, and relay them into the standalone MM world.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Jiewen Yao 
Reviewed-by: Achin Gupta 

commit d3add11e87dace180387562d6f1951f2bffbd3d9
Author: Michael Kubacki 
Date:   Wed Nov 20 17:31:24 2019 -0800

MdeModulePkg PeiCore: Improve comment semantics

This patch clarifies wording in several PeiCore comments to improve
reading comprehension.

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Jian J Wang 

commit d39d1260c615b716675f67f5c4e1f4f52df01dad
Author: Michael Kubacki 
Date:   Wed Nov 20 17:10:48 2019 -0800

MdeModulePkg PeiCore: Fix typos

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Philippe Mathieu-Daude 
Reviewed-by: Jian J Wang 

commit 97eedf5dfbaffde33210fd88066247cf0b7d3325
Author: Antoine Coeur 
Date:   Wed Dec 4 12:14:53

[Xen-devel] [ovmf test] 144847: regressions - FAIL

2019-12-15 Thread osstest service owner 
flight 144847 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144847/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 144637
 build-i386-xsm6 xen-buildfail REGR. vs. 144637
 build-amd64-xsm   6 xen-buildfail REGR. vs. 144637
 build-i3866 xen-buildfail REGR. vs. 144637

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
baseline version:
 ovmf 804666c86e7b6f04fe5c5cfdb13199c19e0e99b0

Last test of basis   144637  2019-12-09 09:09:49 Z6 days
Failing since144646  2019-12-10 01:39:53 Z5 days   42 attempts
Testing same since   144770  2019-12-12 18:41:26 Z3 days   31 attempts


People who touched revisions under test:
  Antoine Coeur 
  Ard Biesheuvel 
  Bob Feng 
  Jiewen Yao 
  Michael Kubacki 
  Pete Batard 
  Philippe Mathieu-Daude 
  Steven Shi 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
Author: Pete Batard 
Date:   Tue Dec 10 18:23:04 2019 +

MdePkg/Include: Add DCC and BCM2835 SPCR UART types

As per the Microsoft Debug Port Table 2 (DBG2) documentation, that
can be found online, we are missing 2 serial interface types for
Arm DCC and Bcm2835 (the latter being used with the Raspberry Pi).

These same types are present in DebugPort2Table.h so add them to
SerialPortConsoleRedirectionTable.h too.

Note that we followed the same idiosyncrasies as DebugPort2Table
for naming these new macros.

Signed-off-by: Pete Batard 
Acked-by: Ard Biesheuvel 
Reviewed-by: Liming Gao 

commit 2fe25a74d6fee3c2ac0b930f7f3596cb432e766e
Author: Ard Biesheuvel 
Date:   Tue Mar 5 14:32:48 2019 +0100

ArmPkg/MmCommunicationDxe: relay architected PI events to MM context

PI defines a few architected events that have significance in the MM
context as well as in the non-secure DXE context. So register notify
handlers for these events, and relay them into the standalone MM world.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Jiewen Yao 
Reviewed-by: Achin Gupta 

commit d3add11e87dace180387562d6f1951f2bffbd3d9
Author: Michael Kubacki 
Date:   Wed Nov 20 17:31:24 2019 -0800

MdeModulePkg PeiCore: Improve comment semantics

This patch clarifies wording in several PeiCore comments to improve
reading comprehension.

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Jian J Wang 

commit d39d1260c615b716675f67f5c4e1f4f52df01dad
Author: Michael Kubacki 
Date:   Wed Nov 20 17:10:48 2019 -0800

MdeModulePkg PeiCore: Fix typos

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Philippe Mathieu-Daude 
Reviewed-by: Jian J Wang 

commit 97eedf5dfbaffde33210fd88066247cf0b7d3325
Author: Antoine Coeur 
Date:   Wed Dec 4 12:14:53

[Xen-devel] [RFC 5/6] arm64: hyperv: Enable userspace to read cntvct

2019-12-15 Thread Boqun Feng 
Since reading hyperv-timer clocksource requires reading cntvct,
userspace should be allowed to read it, otherwise reading cntvct will
result in traps, which makes vsyscall's cost similar compared to
syscall's.

So enable it on every cpu when a Hyper-V guest booting up.

Signed-off-by: Boqun Feng (Microsoft) 
---
 arch/arm64/hyperv/hv_init.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/hyperv/hv_init.c b/arch/arm64/hyperv/hv_init.c
index 86e4621d5885..1ea97ecfb143 100644
--- a/arch/arm64/hyperv/hv_init.c
+++ b/arch/arm64/hyperv/hv_init.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -45,6 +46,7 @@ EXPORT_SYMBOL_GPL(hv_max_vp_index);
 static int hv_cpu_init(unsigned int cpu)
 {
u64 msr_vp_index;
+   u32 cntkctl;
 
hv_get_vp_index(msr_vp_index);
 
@@ -53,6 +55,11 @@ static int hv_cpu_init(unsigned int cpu)
if (msr_vp_index > hv_max_vp_index)
hv_max_vp_index = msr_vp_index;
 
+   /* Enable EL0 to access cntvct */
+   cntkctl = arch_timer_get_cntkctl();
+   cntkctl |= ARCH_TIMER_USR_VCT_ACCESS_EN;
+   arch_timer_set_cntkctl(cntkctl);
+
return 0;
 }
 
-- 
2.24.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [RFC 0/6] vDSO support for Hyper-V guest on ARM64

2019-12-15 Thread Boqun Feng 
Hi,

This is the RFC patchset for vDSO support in ARM64 Hyper-V guest. To
test it, Michael's ARM64 support patchset:


https://lore.kernel.org/linux-arm-kernel/1570129355-16005-1-git-send-email-mikel...@microsoft.com/

is needed.

Similar as x86, Hyper-V on ARM64 use a TSC page for guests to read
the virtualized hardware timer, this TSC page is read-only for the
guests, so could be used for vDSO data page. And the vDSO (userspace)
code could use the same code for timer reading as kernel, since
they read the same TSC page.

This patchset therefore extends ARM64's __vsdo_init() to allow multiple
data pages and introduces the vclock_mode concept similar to x86 to
allow different platforms (bare-metal, Hyper-V, etc.) to switch to
different __arch_get_hw_counter() implementations. The rest of this
patchset does the necessary setup for Hyper-V guests: mapping tsc page,
enabling userspace to read cntvct, etc. to enable vDSO.

This patchset consists of 6 patches:

patch #1 allows hv_get_raw_timer() definition to be overridden for
userspace and kernel to share the same hv_read_tsc_page() definition.

patch #2 extends ARM64 to support multiple vDSO data pages.

patch #3 introduces vclock_mode similiar to x86 to allow different
__arch_get_hw_counter() implementations for different clocksources.

patch #4 maps Hyper-V TSC page into vDSO data page.

patch #5 allows userspace to read cntvct, so that userspace can
efficiently read the clocksource.

patch #6 enables the vDSO for ARM64 Hyper-V guest.

The whole patchset is based on v5.5-rc1 plus Michael's ARM64 support
patchset, and I've done a few tests with:

https://github.com/nlynch-mentor/vdsotest

Comments and suggestions are welcome!

Regards,
Boqun

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [RFC 6/6] arm64: hyperv: Enable vDSO

2019-12-15 Thread Boqun Feng 
Similar to x86, add a new vclock_mode VCLOCK_HVCLOCK, and reuse the
hv_read_tsc_page() for userspace to read tsc page clocksource.

Signed-off-by: Boqun Feng (Microsoft) 
---
 arch/arm64/include/asm/clocksource.h   |  3 ++-
 arch/arm64/include/asm/mshyperv.h  |  2 +-
 arch/arm64/include/asm/vdso/gettimeofday.h | 19 +++
 3 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/clocksource.h 
b/arch/arm64/include/asm/clocksource.h
index fbe80057468c..c6acd45fe748 100644
--- a/arch/arm64/include/asm/clocksource.h
+++ b/arch/arm64/include/asm/clocksource.h
@@ -4,7 +4,8 @@
 
 #define VCLOCK_NONE0   /* No vDSO clock available. */
 #define VCLOCK_CNTVCT  1   /* vDSO should use cntvcnt  */
-#define VCLOCK_MAX 1
+#define VCLOCK_HVCLOCK 2   /* vDSO should use vread_hvclock()  */
+#define VCLOCK_MAX 2
 
 struct arch_clocksource_data {
int vclock_mode;
diff --git a/arch/arm64/include/asm/mshyperv.h 
b/arch/arm64/include/asm/mshyperv.h
index 0afb00e3501d..7c85dd816dca 100644
--- a/arch/arm64/include/asm/mshyperv.h
+++ b/arch/arm64/include/asm/mshyperv.h
@@ -90,7 +90,7 @@ extern void hv_get_vpreg_128(u32 reg, struct 
hv_get_vp_register_output *result);
 #define hv_set_reference_tsc(val) \
hv_set_vpreg(HV_REGISTER_REFERENCE_TSC, val)
 #define hv_set_clocksource_vdso(val) \
-   ((val).archdata.vclock_mode = VCLOCK_NONE)
+   ((val).archdata.vclock_mode = VCLOCK_HVCLOCK)
 
 #if IS_ENABLED(CONFIG_HYPERV)
 #define hv_enable_stimer0_percpu_irq(irq)  enable_percpu_irq(irq, 0)
diff --git a/arch/arm64/include/asm/vdso/gettimeofday.h 
b/arch/arm64/include/asm/vdso/gettimeofday.h
index e6e3fe0488c7..7e689b903f4d 100644
--- a/arch/arm64/include/asm/vdso/gettimeofday.h
+++ b/arch/arm64/include/asm/vdso/gettimeofday.h
@@ -67,6 +67,20 @@ int clock_getres_fallback(clockid_t _clkid, struct 
__kernel_timespec *_ts)
return ret;
 }
 
+#ifdef CONFIG_HYPERV_TIMER
+/* This will override the default hv_get_raw_timer() */
+#define hv_get_raw_timer() __arch_counter_get_cntvct()
+#include 
+
+extern struct ms_hyperv_tsc_page
+_hvclock_page __attribute__((visibility("hidden")));
+
+static u64 vread_hvclock(void)
+{
+   return hv_read_tsc_page(&_hvclock_page);
+}
+#endif
+
 static __always_inline u64 __arch_get_hw_counter(s32 clock_mode)
 {
u64 res;
@@ -78,6 +92,11 @@ static __always_inline u64 __arch_get_hw_counter(s32 
clock_mode)
if (clock_mode == VCLOCK_NONE)
return __VDSO_USE_SYSCALL;
 
+#ifdef CONFIG_HYPERV_TIMER
+   if (likely(clock_mode == VCLOCK_HVCLOCK))
+   return vread_hvclock();
+#endif
+
/*
 * This isb() is required to prevent that the counter value
 * is speculated.
-- 
2.24.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [RFC 4/6] arm64: vdso: hyperv: Map tsc page into vDSO if enabled

2019-12-15 Thread Boqun Feng 
On Hyper-V, a tsc page has the data for adjusting cntvct numbers to
clocksource cycles, and that's how Hyper-V guest kernel reads the
clocksource. In order to allow userspace to read the same clocksource
directly, the tsc page has to been mapped into userspace via vDSO.

Use the framework for vDSO set-up in __vdso_init() to do this.

Note: if HYPERV_TIMER=y but the kernel is using other clocksource or
doesn't have the hyperv timer clocksource, tsc page will still be mapped
into userspace.

Signed-off-by: Boqun Feng (Microsoft) 
---
 arch/arm64/kernel/vdso.c  | 12 
 arch/arm64/kernel/vdso/vdso.lds.S | 12 +++-
 2 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index b9b5ec7a3084..18a634987bdc 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -9,6 +9,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -105,14 +106,22 @@ static int __vdso_init(enum arch_vdso_type arch_index)
struct page **vdso_code_pagelist;
unsigned long nr_vdso_pages;
unsigned long pfn;
+   struct ms_hyperv_tsc_page *tsc_page;
+   int tsc_page_idx;
 
if (memcmp(vdso_lookup[arch_index].vdso_code_start, "\177ELF", 4)) {
pr_err("vDSO is not a valid ELF object!\n");
return -EINVAL;
}
 
+   /* One vDSO data page */
vdso_lookup[arch_index].nr_vdso_data_pages = 1;
 
+   /* Grab the Hyper-V tsc page, if enabled, add one more page */
+   tsc_page = hv_get_tsc_page();
+   if (tsc_page)
+   tsc_page_idx = vdso_lookup[arch_index].nr_vdso_data_pages++;
+
vdso_lookup[arch_index].nr_vdso_code_pages = (
vdso_lookup[arch_index].vdso_code_end -
vdso_lookup[arch_index].vdso_code_start) >>
@@ -130,6 +139,9 @@ static int __vdso_init(enum arch_vdso_type arch_index)
/* Grab the vDSO data page. */
vdso_pagelist[0] = phys_to_page(__pa_symbol(vdso_data));
 
+   if (tsc_page)
+   vdso_pagelist[tsc_page_idx] = phys_to_page(__pa(tsc_page));
+
/* Grab the vDSO code pages. */
pfn = sym_to_pfn(vdso_lookup[arch_index].vdso_code_start);
 
diff --git a/arch/arm64/kernel/vdso/vdso.lds.S 
b/arch/arm64/kernel/vdso/vdso.lds.S
index 7ad2d3a0cd48..e40a1f5a6d30 100644
--- a/arch/arm64/kernel/vdso/vdso.lds.S
+++ b/arch/arm64/kernel/vdso/vdso.lds.S
@@ -17,7 +17,17 @@ OUTPUT_ARCH(aarch64)
 
 SECTIONS
 {
-   PROVIDE(_vdso_data = . - PAGE_SIZE);
+   /*
+* vdso data pages:
+*   vdso data (1 page)
+*   hv tsc page (1 page if enabled)
+*/
+   PROVIDE(_vdso_data = _hvclock_page - PAGE_SIZE);
+#ifdef CONFIG_HYPERV_TIMER
+   PROVIDE(_hvclock_page = . - PAGE_SIZE);
+#else
+   PROVIDE(_hvclock_page = .);
+#endif
. = VDSO_LBASE + SIZEOF_HEADERS;
 
.hash   : { *(.hash) }  :text
-- 
2.24.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [RFC 2/6] arm64: vdso: Add support for multiple vDSO data pages

2019-12-15 Thread Boqun Feng 
Split __vdso_abi::vdso_pages into nr_vdso_{data,code}_pages, so that
__setup_additional_pages() could work with multiple vDSO data pages with
the setup from __vdso_init().

Multiple vDSO data pages are required when running in a virtualized
environment, where the cycles read from cntvct at userspace need to
be adjusted with some data from a page maintained by the hypervisor. For
example, the TSC page in Hyper-V.

This is a prerequisite for vDSO support in ARM64 on Hyper-V.

Signed-off-by: Boqun Feng (Microsoft) 
---
 arch/arm64/kernel/vdso.c | 43 
 1 file changed, 26 insertions(+), 17 deletions(-)

diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index 354b11e27c07..b9b5ec7a3084 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -50,7 +50,8 @@ struct __vdso_abi {
const char *name;
const char *vdso_code_start;
const char *vdso_code_end;
-   unsigned long vdso_pages;
+   unsigned long nr_vdso_data_pages;
+   unsigned long nr_vdso_code_pages;
/* Data Mapping */
struct vm_special_mapping *dm;
/* Code Mapping */
@@ -101,6 +102,8 @@ static int __vdso_init(enum arch_vdso_type arch_index)
 {
int i;
struct page **vdso_pagelist;
+   struct page **vdso_code_pagelist;
+   unsigned long nr_vdso_pages;
unsigned long pfn;
 
if (memcmp(vdso_lookup[arch_index].vdso_code_start, "\177ELF", 4)) {
@@ -108,14 +111,18 @@ static int __vdso_init(enum arch_vdso_type arch_index)
return -EINVAL;
}
 
-   vdso_lookup[arch_index].vdso_pages = (
+   vdso_lookup[arch_index].nr_vdso_data_pages = 1;
+
+   vdso_lookup[arch_index].nr_vdso_code_pages = (
vdso_lookup[arch_index].vdso_code_end -
vdso_lookup[arch_index].vdso_code_start) >>
PAGE_SHIFT;
 
-   /* Allocate the vDSO pagelist, plus a page for the data. */
-   vdso_pagelist = kcalloc(vdso_lookup[arch_index].vdso_pages + 1,
-   sizeof(struct page *),
+   nr_vdso_pages = vdso_lookup[arch_index].nr_vdso_data_pages +
+   vdso_lookup[arch_index].nr_vdso_code_pages;
+
+   /* Allocate the vDSO pagelist. */
+   vdso_pagelist = kcalloc(nr_vdso_pages, sizeof(struct page *),
GFP_KERNEL);
if (vdso_pagelist == NULL)
return -ENOMEM;
@@ -123,15 +130,17 @@ static int __vdso_init(enum arch_vdso_type arch_index)
/* Grab the vDSO data page. */
vdso_pagelist[0] = phys_to_page(__pa_symbol(vdso_data));
 
-
/* Grab the vDSO code pages. */
pfn = sym_to_pfn(vdso_lookup[arch_index].vdso_code_start);
 
-   for (i = 0; i < vdso_lookup[arch_index].vdso_pages; i++)
-   vdso_pagelist[i + 1] = pfn_to_page(pfn + i);
+   vdso_code_pagelist = vdso_pagelist +
+vdso_lookup[arch_index].nr_vdso_data_pages;
+
+   for (i = 0; i < vdso_lookup[arch_index].nr_vdso_code_pages; i++)
+   vdso_code_pagelist[i] = pfn_to_page(pfn + i);
 
-   vdso_lookup[arch_index].dm->pages = _pagelist[0];
-   vdso_lookup[arch_index].cm->pages = _pagelist[1];
+   vdso_lookup[arch_index].dm->pages = vdso_pagelist;
+   vdso_lookup[arch_index].cm->pages = vdso_code_pagelist;
 
return 0;
 }
@@ -141,26 +150,26 @@ static int __setup_additional_pages(enum arch_vdso_type 
arch_index,
struct linux_binprm *bprm,
int uses_interp)
 {
-   unsigned long vdso_base, vdso_text_len, vdso_mapping_len;
+   unsigned long vdso_base, vdso_text_len, vdso_data_len;
void *ret;
 
-   vdso_text_len = vdso_lookup[arch_index].vdso_pages << PAGE_SHIFT;
-   /* Be sure to map the data page */
-   vdso_mapping_len = vdso_text_len + PAGE_SIZE;
+   vdso_data_len = vdso_lookup[arch_index].nr_vdso_data_pages << 
PAGE_SHIFT;
+   vdso_text_len = vdso_lookup[arch_index].nr_vdso_code_pages << 
PAGE_SHIFT;
 
-   vdso_base = get_unmapped_area(NULL, 0, vdso_mapping_len, 0, 0);
+   vdso_base = get_unmapped_area(NULL, 0,
+ vdso_data_len + vdso_text_len, 0, 0);
if (IS_ERR_VALUE(vdso_base)) {
ret = ERR_PTR(vdso_base);
goto up_fail;
}
 
-   ret = _install_special_mapping(mm, vdso_base, PAGE_SIZE,
+   ret = _install_special_mapping(mm, vdso_base, vdso_data_len,
   VM_READ|VM_MAYREAD,
   vdso_lookup[arch_index].dm);
if (IS_ERR(ret))
goto up_fail;
 
-   vdso_base += PAGE_SIZE;
+   vdso_base += vdso_data_len;
mm->context.vdso = (void *)vdso_base;
ret = _install_special_mapping(mm, vdso_base, vdso_text_len,
   VM_READ|VM_EXEC|

[Xen-devel] [RFC 3/6] arm/arm64: clocksource: Introduce vclock_mode

2019-12-15 Thread Boqun Feng 
Similar to x86, use a vclock_mode in arch_clocksource_data to differ
clocksoures use different read function in vDSO.

No functional changes, only preparation for support vDSO in ARM64 on
Hyper-V.

Note: the changes for arm are only because arm and arm64 share the same
code in the arch timer driver and require arch_clocksource_data having
the same field.

Signed-off-by: Boqun Feng (Microsoft) 
---
 arch/arm/include/asm/clocksource.h| 6 +-
 arch/arm/kernel/vdso.c| 1 -
 arch/arm64/include/asm/clocksource.h  | 6 +-
 arch/arm64/include/asm/mshyperv.h | 2 +-
 arch/arm64/include/asm/vdso/compat_gettimeofday.h | 5 +++--
 arch/arm64/include/asm/vdso/gettimeofday.h| 5 +++--
 arch/arm64/include/asm/vdso/vsyscall.h| 4 +---
 drivers/clocksource/arm_arch_timer.c  | 8 
 8 files changed, 22 insertions(+), 15 deletions(-)

diff --git a/arch/arm/include/asm/clocksource.h 
b/arch/arm/include/asm/clocksource.h
index 0b350a7e26f3..017c5ab6e587 100644
--- a/arch/arm/include/asm/clocksource.h
+++ b/arch/arm/include/asm/clocksource.h
@@ -1,8 +1,12 @@
 #ifndef _ASM_CLOCKSOURCE_H
 #define _ASM_CLOCKSOURCE_H
 
+#define VCLOCK_NONE0   /* No vDSO clock available. */
+#define VCLOCK_CNTVCT  1   /* vDSO should use cntvcnt  */
+#define VCLOCK_MAX 1
+
 struct arch_clocksource_data {
-   bool vdso_direct;   /* Usable for direct VDSO access? */
+   int vclock_mode;
 };
 
 #endif
diff --git a/arch/arm/kernel/vdso.c b/arch/arm/kernel/vdso.c
index c89ac1b9d28b..09e46ec420fe 100644
--- a/arch/arm/kernel/vdso.c
+++ b/arch/arm/kernel/vdso.c
@@ -263,4 +263,3 @@ void arm_install_vdso(struct mm_struct *mm, unsigned long 
addr)
if (!IS_ERR(vma))
mm->context.vdso = addr;
 }
-
diff --git a/arch/arm64/include/asm/clocksource.h 
b/arch/arm64/include/asm/clocksource.h
index 0ece64a26c8c..fbe80057468c 100644
--- a/arch/arm64/include/asm/clocksource.h
+++ b/arch/arm64/include/asm/clocksource.h
@@ -2,8 +2,12 @@
 #ifndef _ASM_CLOCKSOURCE_H
 #define _ASM_CLOCKSOURCE_H
 
+#define VCLOCK_NONE0   /* No vDSO clock available. */
+#define VCLOCK_CNTVCT  1   /* vDSO should use cntvcnt  */
+#define VCLOCK_MAX 1
+
 struct arch_clocksource_data {
-   bool vdso_direct;   /* Usable for direct VDSO access? */
+   int vclock_mode;
 };
 
 #endif
diff --git a/arch/arm64/include/asm/mshyperv.h 
b/arch/arm64/include/asm/mshyperv.h
index 9cc4aeddf2d0..0afb00e3501d 100644
--- a/arch/arm64/include/asm/mshyperv.h
+++ b/arch/arm64/include/asm/mshyperv.h
@@ -90,7 +90,7 @@ extern void hv_get_vpreg_128(u32 reg, struct 
hv_get_vp_register_output *result);
 #define hv_set_reference_tsc(val) \
hv_set_vpreg(HV_REGISTER_REFERENCE_TSC, val)
 #define hv_set_clocksource_vdso(val) \
-   ((val).archdata.vdso_direct = false)
+   ((val).archdata.vclock_mode = VCLOCK_NONE)
 
 #if IS_ENABLED(CONFIG_HYPERV)
 #define hv_enable_stimer0_percpu_irq(irq)  enable_percpu_irq(irq, 0)
diff --git a/arch/arm64/include/asm/vdso/compat_gettimeofday.h 
b/arch/arm64/include/asm/vdso/compat_gettimeofday.h
index c50ee1b7d5cd..630d04c3c92e 100644
--- a/arch/arm64/include/asm/vdso/compat_gettimeofday.h
+++ b/arch/arm64/include/asm/vdso/compat_gettimeofday.h
@@ -8,6 +8,7 @@
 #ifndef __ASSEMBLY__
 
 #include 
+#include 
 #include 
 
 #include 
@@ -117,10 +118,10 @@ static __always_inline u64 __arch_get_hw_counter(s32 
clock_mode)
u64 res;
 
/*
-* clock_mode == 0 implies that vDSO are enabled otherwise
+* clock_mode == VCLOCK_NONE implies that vDSO are disabled so
 * fallback on syscall.
 */
-   if (clock_mode)
+   if (clock_mode == VCLOCK_NONE)
return __VDSO_USE_SYSCALL;
 
/*
diff --git a/arch/arm64/include/asm/vdso/gettimeofday.h 
b/arch/arm64/include/asm/vdso/gettimeofday.h
index b08f476b72b4..e6e3fe0488c7 100644
--- a/arch/arm64/include/asm/vdso/gettimeofday.h
+++ b/arch/arm64/include/asm/vdso/gettimeofday.h
@@ -8,6 +8,7 @@
 #ifndef __ASSEMBLY__
 
 #include 
+#include 
 #include 
 
 #define __VDSO_USE_SYSCALL ULLONG_MAX
@@ -71,10 +72,10 @@ static __always_inline u64 __arch_get_hw_counter(s32 
clock_mode)
u64 res;
 
/*
-* clock_mode == 0 implies that vDSO are enabled otherwise
+* clock_mode == VCLOCK_NONE implies that vDSO are disabled so
 * fallback on syscall.
 */
-   if (clock_mode)
+   if (clock_mode == VCLOCK_NONE)
return __VDSO_USE_SYSCALL;
 
/*
diff --git a/arch/arm64/include/asm/vdso/vsyscall.h 
b/arch/arm64/include/asm/vdso/vsyscall.h
index 0c20a7c1bee5..07f78b0da498 100644
--- a/arch/arm64/include/asm/vdso/vsyscall.h
+++ b/arch/arm64/include/asm/vdso/vsyscall.h
@@ -24,9 +24,7 @@ struct vdso_data *__arm64_get_k_vdso_data(void)
 static __always_inline

[Xen-devel] [RFC 1/6] arm64: hyperv: Allow hv_get_raw_timer() definition to be overridden

2019-12-15 Thread Boqun Feng 
In order to support vDSO, hv_read_tsc_page() should be able to be called
from userspace if tsc page mapped. As a result, hv_get_raw_timer(),
called by hv_read_tsc_page() requires to be called by both kernel and
vDSO. Currently, it's defined as arch_timer_read_counter(), which is a
function pointer initialized (using a kernel address) by the arch timer
driver, therefore not usable in vDSO.

Fix this by allowing a previous definition to override the default one,
so that in vDSO code, we can define it as a function callable in
userspace.

Signed-off-by: Boqun Feng (Microsoft) 
---
 arch/arm64/include/asm/mshyperv.h | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/mshyperv.h 
b/arch/arm64/include/asm/mshyperv.h
index a8468a611912..9cc4aeddf2d0 100644
--- a/arch/arm64/include/asm/mshyperv.h
+++ b/arch/arm64/include/asm/mshyperv.h
@@ -97,8 +97,15 @@ extern void hv_get_vpreg_128(u32 reg, struct 
hv_get_vp_register_output *result);
 #define hv_disable_stimer0_percpu_irq(irq) disable_percpu_irq(irq)
 #endif
 
-/* ARM64 specific code to read the hardware clock */
+/*
+ * ARM64 specific code to read the hardware clock.
+ *
+ * This could be used in both kernel space and userspace (vDSO), so make it
+ * possible for a previous definition to override the default one.
+ */
+#ifndef hv_get_raw_timer
 #define hv_get_raw_timer() arch_timer_read_counter()
+#endif
 
 #include 
 
-- 
2.24.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [ovmf test] 144846: regressions - FAIL

2019-12-15 Thread osstest service owner 
flight 144846 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144846/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 144637
 build-i386-xsm6 xen-buildfail REGR. vs. 144637
 build-amd64-xsm   6 xen-buildfail REGR. vs. 144637
 build-i3866 xen-buildfail REGR. vs. 144637

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
baseline version:
 ovmf 804666c86e7b6f04fe5c5cfdb13199c19e0e99b0

Last test of basis   144637  2019-12-09 09:09:49 Z6 days
Failing since144646  2019-12-10 01:39:53 Z5 days   41 attempts
Testing same since   144770  2019-12-12 18:41:26 Z3 days   30 attempts


People who touched revisions under test:
  Antoine Coeur 
  Ard Biesheuvel 
  Bob Feng 
  Jiewen Yao 
  Michael Kubacki 
  Pete Batard 
  Philippe Mathieu-Daude 
  Steven Shi 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
Author: Pete Batard 
Date:   Tue Dec 10 18:23:04 2019 +

MdePkg/Include: Add DCC and BCM2835 SPCR UART types

As per the Microsoft Debug Port Table 2 (DBG2) documentation, that
can be found online, we are missing 2 serial interface types for
Arm DCC and Bcm2835 (the latter being used with the Raspberry Pi).

These same types are present in DebugPort2Table.h so add them to
SerialPortConsoleRedirectionTable.h too.

Note that we followed the same idiosyncrasies as DebugPort2Table
for naming these new macros.

Signed-off-by: Pete Batard 
Acked-by: Ard Biesheuvel 
Reviewed-by: Liming Gao 

commit 2fe25a74d6fee3c2ac0b930f7f3596cb432e766e
Author: Ard Biesheuvel 
Date:   Tue Mar 5 14:32:48 2019 +0100

ArmPkg/MmCommunicationDxe: relay architected PI events to MM context

PI defines a few architected events that have significance in the MM
context as well as in the non-secure DXE context. So register notify
handlers for these events, and relay them into the standalone MM world.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Jiewen Yao 
Reviewed-by: Achin Gupta 

commit d3add11e87dace180387562d6f1951f2bffbd3d9
Author: Michael Kubacki 
Date:   Wed Nov 20 17:31:24 2019 -0800

MdeModulePkg PeiCore: Improve comment semantics

This patch clarifies wording in several PeiCore comments to improve
reading comprehension.

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Jian J Wang 

commit d39d1260c615b716675f67f5c4e1f4f52df01dad
Author: Michael Kubacki 
Date:   Wed Nov 20 17:10:48 2019 -0800

MdeModulePkg PeiCore: Fix typos

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Philippe Mathieu-Daude 
Reviewed-by: Jian J Wang 

commit 97eedf5dfbaffde33210fd88066247cf0b7d3325
Author: Antoine Coeur 
Date:   Wed Dec 4 12:14:53

[Xen-devel] [ovmf test] 144845: regressions - FAIL

2019-12-15 Thread osstest service owner 
flight 144845 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144845/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 144637
 build-i386-xsm6 xen-buildfail REGR. vs. 144637
 build-amd64-xsm   6 xen-buildfail REGR. vs. 144637
 build-i3866 xen-buildfail REGR. vs. 144637

Tests which did not succeed, but are not blocking:
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
baseline version:
 ovmf 804666c86e7b6f04fe5c5cfdb13199c19e0e99b0

Last test of basis   144637  2019-12-09 09:09:49 Z6 days
Failing since144646  2019-12-10 01:39:53 Z5 days   40 attempts
Testing same since   144770  2019-12-12 18:41:26 Z3 days   29 attempts


People who touched revisions under test:
  Antoine Coeur 
  Ard Biesheuvel 
  Bob Feng 
  Jiewen Yao 
  Michael Kubacki 
  Pete Batard 
  Philippe Mathieu-Daude 
  Steven Shi 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
Author: Pete Batard 
Date:   Tue Dec 10 18:23:04 2019 +

MdePkg/Include: Add DCC and BCM2835 SPCR UART types

As per the Microsoft Debug Port Table 2 (DBG2) documentation, that
can be found online, we are missing 2 serial interface types for
Arm DCC and Bcm2835 (the latter being used with the Raspberry Pi).

These same types are present in DebugPort2Table.h so add them to
SerialPortConsoleRedirectionTable.h too.

Note that we followed the same idiosyncrasies as DebugPort2Table
for naming these new macros.

Signed-off-by: Pete Batard 
Acked-by: Ard Biesheuvel 
Reviewed-by: Liming Gao 

commit 2fe25a74d6fee3c2ac0b930f7f3596cb432e766e
Author: Ard Biesheuvel 
Date:   Tue Mar 5 14:32:48 2019 +0100

ArmPkg/MmCommunicationDxe: relay architected PI events to MM context

PI defines a few architected events that have significance in the MM
context as well as in the non-secure DXE context. So register notify
handlers for these events, and relay them into the standalone MM world.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Jiewen Yao 
Reviewed-by: Achin Gupta 

commit d3add11e87dace180387562d6f1951f2bffbd3d9
Author: Michael Kubacki 
Date:   Wed Nov 20 17:31:24 2019 -0800

MdeModulePkg PeiCore: Improve comment semantics

This patch clarifies wording in several PeiCore comments to improve
reading comprehension.

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Jian J Wang 

commit d39d1260c615b716675f67f5c4e1f4f52df01dad
Author: Michael Kubacki 
Date:   Wed Nov 20 17:10:48 2019 -0800

MdeModulePkg PeiCore: Fix typos

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Philippe Mathieu-Daude 
Reviewed-by: Jian J Wang 

commit 97eedf5dfbaffde33210fd88066247cf0b7d3325
Author: Antoine Coeur 
Date:   Wed Dec 4 12:14:53

Re: [Xen-devel] [GIT PULL] xen: branch for v5.5-rc2

2019-12-15 Thread pr-tracker-bot 
The pull request you sent on Sun, 15 Dec 2019 07:06:21 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git 
> for-linus-5.5b-rc2-tag

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b01d7cb41ff51b7779977de601a984406e2a5ba9

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [ovmf test] 144844: regressions - FAIL

2019-12-15 Thread osstest service owner 
flight 144844 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144844/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 144637
 build-i386-xsm6 xen-buildfail REGR. vs. 144637
 build-amd64-xsm   6 xen-buildfail REGR. vs. 144637
 build-i3866 xen-buildfail REGR. vs. 144637

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 ovmf bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
baseline version:
 ovmf 804666c86e7b6f04fe5c5cfdb13199c19e0e99b0

Last test of basis   144637  2019-12-09 09:09:49 Z6 days
Failing since144646  2019-12-10 01:39:53 Z5 days   39 attempts
Testing same since   144770  2019-12-12 18:41:26 Z3 days   28 attempts


People who touched revisions under test:
  Antoine Coeur 
  Ard Biesheuvel 
  Bob Feng 
  Jiewen Yao 
  Michael Kubacki 
  Pete Batard 
  Philippe Mathieu-Daude 
  Steven Shi 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
Author: Pete Batard 
Date:   Tue Dec 10 18:23:04 2019 +

MdePkg/Include: Add DCC and BCM2835 SPCR UART types

As per the Microsoft Debug Port Table 2 (DBG2) documentation, that
can be found online, we are missing 2 serial interface types for
Arm DCC and Bcm2835 (the latter being used with the Raspberry Pi).

These same types are present in DebugPort2Table.h so add them to
SerialPortConsoleRedirectionTable.h too.

Note that we followed the same idiosyncrasies as DebugPort2Table
for naming these new macros.

Signed-off-by: Pete Batard 
Acked-by: Ard Biesheuvel 
Reviewed-by: Liming Gao 

commit 2fe25a74d6fee3c2ac0b930f7f3596cb432e766e
Author: Ard Biesheuvel 
Date:   Tue Mar 5 14:32:48 2019 +0100

ArmPkg/MmCommunicationDxe: relay architected PI events to MM context

PI defines a few architected events that have significance in the MM
context as well as in the non-secure DXE context. So register notify
handlers for these events, and relay them into the standalone MM world.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Jiewen Yao 
Reviewed-by: Achin Gupta 

commit d3add11e87dace180387562d6f1951f2bffbd3d9
Author: Michael Kubacki 
Date:   Wed Nov 20 17:31:24 2019 -0800

MdeModulePkg PeiCore: Improve comment semantics

This patch clarifies wording in several PeiCore comments to improve
reading comprehension.

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Jian J Wang 

commit d39d1260c615b716675f67f5c4e1f4f52df01dad
Author: Michael Kubacki 
Date:   Wed Nov 20 17:10:48 2019 -0800

MdeModulePkg PeiCore: Fix typos

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Philippe Mathieu-Daude 
Reviewed-by: Jian J Wang 

commit 97eedf5dfbaffde33210fd88066247cf0b7d3325
Author: Antoine Coeur 
Date:   Wed Dec 4 12:14:53

[Xen-devel] [ovmf test] 144843: regressions - FAIL

2019-12-15 Thread osstest service owner 
flight 144843 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144843/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 144637
 build-i386-xsm6 xen-buildfail REGR. vs. 144637
 build-amd64-xsm   6 xen-buildfail REGR. vs. 144637
 build-i3866 xen-buildfail REGR. vs. 144637

Tests which did not succeed, but are not blocking:
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a

version targeted for testing:
 ovmf bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
baseline version:
 ovmf 804666c86e7b6f04fe5c5cfdb13199c19e0e99b0

Last test of basis   144637  2019-12-09 09:09:49 Z6 days
Failing since144646  2019-12-10 01:39:53 Z5 days   38 attempts
Testing same since   144770  2019-12-12 18:41:26 Z3 days   27 attempts


People who touched revisions under test:
  Antoine Coeur 
  Ard Biesheuvel 
  Bob Feng 
  Jiewen Yao 
  Michael Kubacki 
  Pete Batard 
  Philippe Mathieu-Daude 
  Steven Shi 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
Author: Pete Batard 
Date:   Tue Dec 10 18:23:04 2019 +

MdePkg/Include: Add DCC and BCM2835 SPCR UART types

As per the Microsoft Debug Port Table 2 (DBG2) documentation, that
can be found online, we are missing 2 serial interface types for
Arm DCC and Bcm2835 (the latter being used with the Raspberry Pi).

These same types are present in DebugPort2Table.h so add them to
SerialPortConsoleRedirectionTable.h too.

Note that we followed the same idiosyncrasies as DebugPort2Table
for naming these new macros.

Signed-off-by: Pete Batard 
Acked-by: Ard Biesheuvel 
Reviewed-by: Liming Gao 

commit 2fe25a74d6fee3c2ac0b930f7f3596cb432e766e
Author: Ard Biesheuvel 
Date:   Tue Mar 5 14:32:48 2019 +0100

ArmPkg/MmCommunicationDxe: relay architected PI events to MM context

PI defines a few architected events that have significance in the MM
context as well as in the non-secure DXE context. So register notify
handlers for these events, and relay them into the standalone MM world.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Jiewen Yao 
Reviewed-by: Achin Gupta 

commit d3add11e87dace180387562d6f1951f2bffbd3d9
Author: Michael Kubacki 
Date:   Wed Nov 20 17:31:24 2019 -0800

MdeModulePkg PeiCore: Improve comment semantics

This patch clarifies wording in several PeiCore comments to improve
reading comprehension.

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Jian J Wang 

commit d39d1260c615b716675f67f5c4e1f4f52df01dad
Author: Michael Kubacki 
Date:   Wed Nov 20 17:10:48 2019 -0800

MdeModulePkg PeiCore: Fix typos

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Philippe Mathieu-Daude 
Reviewed-by: Jian J Wang 

commit 97eedf5dfbaffde33210fd88066247cf0b7d3325
Author: Antoine Coeur 
Date:   Wed Dec 4 12:14:53

Re: [Xen-devel] [PATCH net v2] xen-netback: avoid race that can lead to NULL pointer dereference

2019-12-15 Thread Jakub Kicinski 
On Fri, 13 Dec 2019 13:20:40 +, Paul Durrant wrote:
> In function xenvif_disconnect_queue(), the value of queue->rx_irq is
> zeroed *before* queue->task is stopped. Unfortunately that task may call
> notify_remote_via_irq(queue->rx_irq) and calling that function with a
> zero value results in a NULL pointer dereference in evtchn_from_irq().
> 
> This patch simply re-orders things, stopping all tasks before zero-ing the
> irq values, thereby avoiding the possibility of the race.
> 
> Fixes: 2ac061ce97f4 ("xen/netback: cleanup init and deinit code")
> Signed-off-by: Paul Durrant 

> v2:
>  - Add 'Fixes' tag and re-work commit comment

I've added Wei's Ack from v1, if the code doesn't change substantially
please keep people's Acks.

Applied, thanks.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [ovmf test] 144842: regressions - FAIL

2019-12-15 Thread osstest service owner 
flight 144842 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144842/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 144637
 build-i386-xsm6 xen-buildfail REGR. vs. 144637
 build-amd64-xsm   6 xen-buildfail REGR. vs. 144637
 build-i3866 xen-buildfail REGR. vs. 144637

Tests which did not succeed, but are not blocking:
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a

version targeted for testing:
 ovmf bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
baseline version:
 ovmf 804666c86e7b6f04fe5c5cfdb13199c19e0e99b0

Last test of basis   144637  2019-12-09 09:09:49 Z6 days
Failing since144646  2019-12-10 01:39:53 Z5 days   37 attempts
Testing same since   144770  2019-12-12 18:41:26 Z2 days   26 attempts


People who touched revisions under test:
  Antoine Coeur 
  Ard Biesheuvel 
  Bob Feng 
  Jiewen Yao 
  Michael Kubacki 
  Pete Batard 
  Philippe Mathieu-Daude 
  Steven Shi 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
Author: Pete Batard 
Date:   Tue Dec 10 18:23:04 2019 +

MdePkg/Include: Add DCC and BCM2835 SPCR UART types

As per the Microsoft Debug Port Table 2 (DBG2) documentation, that
can be found online, we are missing 2 serial interface types for
Arm DCC and Bcm2835 (the latter being used with the Raspberry Pi).

These same types are present in DebugPort2Table.h so add them to
SerialPortConsoleRedirectionTable.h too.

Note that we followed the same idiosyncrasies as DebugPort2Table
for naming these new macros.

Signed-off-by: Pete Batard 
Acked-by: Ard Biesheuvel 
Reviewed-by: Liming Gao 

commit 2fe25a74d6fee3c2ac0b930f7f3596cb432e766e
Author: Ard Biesheuvel 
Date:   Tue Mar 5 14:32:48 2019 +0100

ArmPkg/MmCommunicationDxe: relay architected PI events to MM context

PI defines a few architected events that have significance in the MM
context as well as in the non-secure DXE context. So register notify
handlers for these events, and relay them into the standalone MM world.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Jiewen Yao 
Reviewed-by: Achin Gupta 

commit d3add11e87dace180387562d6f1951f2bffbd3d9
Author: Michael Kubacki 
Date:   Wed Nov 20 17:31:24 2019 -0800

MdeModulePkg PeiCore: Improve comment semantics

This patch clarifies wording in several PeiCore comments to improve
reading comprehension.

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Jian J Wang 

commit d39d1260c615b716675f67f5c4e1f4f52df01dad
Author: Michael Kubacki 
Date:   Wed Nov 20 17:10:48 2019 -0800

MdeModulePkg PeiCore: Fix typos

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Philippe Mathieu-Daude 
Reviewed-by: Jian J Wang 

commit 97eedf5dfbaffde33210fd88066247cf0b7d3325
Author: Antoine Coeur 
Date:   Wed Dec 4 12:14:53

[Xen-devel] [ovmf test] 144841: regressions - FAIL

2019-12-15 Thread osstest service owner 
flight 144841 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144841/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 144637
 build-i386-xsm6 xen-buildfail REGR. vs. 144637
 build-amd64-xsm   6 xen-buildfail REGR. vs. 144637
 build-i3866 xen-buildfail REGR. vs. 144637

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 ovmf bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
baseline version:
 ovmf 804666c86e7b6f04fe5c5cfdb13199c19e0e99b0

Last test of basis   144637  2019-12-09 09:09:49 Z6 days
Failing since144646  2019-12-10 01:39:53 Z5 days   36 attempts
Testing same since   144770  2019-12-12 18:41:26 Z2 days   25 attempts


People who touched revisions under test:
  Antoine Coeur 
  Ard Biesheuvel 
  Bob Feng 
  Jiewen Yao 
  Michael Kubacki 
  Pete Batard 
  Philippe Mathieu-Daude 
  Steven Shi 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
Author: Pete Batard 
Date:   Tue Dec 10 18:23:04 2019 +

MdePkg/Include: Add DCC and BCM2835 SPCR UART types

As per the Microsoft Debug Port Table 2 (DBG2) documentation, that
can be found online, we are missing 2 serial interface types for
Arm DCC and Bcm2835 (the latter being used with the Raspberry Pi).

These same types are present in DebugPort2Table.h so add them to
SerialPortConsoleRedirectionTable.h too.

Note that we followed the same idiosyncrasies as DebugPort2Table
for naming these new macros.

Signed-off-by: Pete Batard 
Acked-by: Ard Biesheuvel 
Reviewed-by: Liming Gao 

commit 2fe25a74d6fee3c2ac0b930f7f3596cb432e766e
Author: Ard Biesheuvel 
Date:   Tue Mar 5 14:32:48 2019 +0100

ArmPkg/MmCommunicationDxe: relay architected PI events to MM context

PI defines a few architected events that have significance in the MM
context as well as in the non-secure DXE context. So register notify
handlers for these events, and relay them into the standalone MM world.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Jiewen Yao 
Reviewed-by: Achin Gupta 

commit d3add11e87dace180387562d6f1951f2bffbd3d9
Author: Michael Kubacki 
Date:   Wed Nov 20 17:31:24 2019 -0800

MdeModulePkg PeiCore: Improve comment semantics

This patch clarifies wording in several PeiCore comments to improve
reading comprehension.

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Jian J Wang 

commit d39d1260c615b716675f67f5c4e1f4f52df01dad
Author: Michael Kubacki 
Date:   Wed Nov 20 17:10:48 2019 -0800

MdeModulePkg PeiCore: Fix typos

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Philippe Mathieu-Daude 
Reviewed-by: Jian J Wang 

commit 97eedf5dfbaffde33210fd88066247cf0b7d3325
Author: Antoine Coeur 
Date:   Wed Dec 4 12:14:53

[Xen-devel] [ovmf test] 144840: regressions - FAIL

2019-12-15 Thread osstest service owner 
flight 144840 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144840/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 144637
 build-i386-xsm6 xen-buildfail REGR. vs. 144637
 build-amd64-xsm   6 xen-buildfail REGR. vs. 144637
 build-i3866 xen-buildfail REGR. vs. 144637

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
baseline version:
 ovmf 804666c86e7b6f04fe5c5cfdb13199c19e0e99b0

Last test of basis   144637  2019-12-09 09:09:49 Z6 days
Failing since144646  2019-12-10 01:39:53 Z5 days   35 attempts
Testing same since   144770  2019-12-12 18:41:26 Z2 days   24 attempts


People who touched revisions under test:
  Antoine Coeur 
  Ard Biesheuvel 
  Bob Feng 
  Jiewen Yao 
  Michael Kubacki 
  Pete Batard 
  Philippe Mathieu-Daude 
  Steven Shi 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
Author: Pete Batard 
Date:   Tue Dec 10 18:23:04 2019 +

MdePkg/Include: Add DCC and BCM2835 SPCR UART types

As per the Microsoft Debug Port Table 2 (DBG2) documentation, that
can be found online, we are missing 2 serial interface types for
Arm DCC and Bcm2835 (the latter being used with the Raspberry Pi).

These same types are present in DebugPort2Table.h so add them to
SerialPortConsoleRedirectionTable.h too.

Note that we followed the same idiosyncrasies as DebugPort2Table
for naming these new macros.

Signed-off-by: Pete Batard 
Acked-by: Ard Biesheuvel 
Reviewed-by: Liming Gao 

commit 2fe25a74d6fee3c2ac0b930f7f3596cb432e766e
Author: Ard Biesheuvel 
Date:   Tue Mar 5 14:32:48 2019 +0100

ArmPkg/MmCommunicationDxe: relay architected PI events to MM context

PI defines a few architected events that have significance in the MM
context as well as in the non-secure DXE context. So register notify
handlers for these events, and relay them into the standalone MM world.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Jiewen Yao 
Reviewed-by: Achin Gupta 

commit d3add11e87dace180387562d6f1951f2bffbd3d9
Author: Michael Kubacki 
Date:   Wed Nov 20 17:31:24 2019 -0800

MdeModulePkg PeiCore: Improve comment semantics

This patch clarifies wording in several PeiCore comments to improve
reading comprehension.

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Jian J Wang 

commit d39d1260c615b716675f67f5c4e1f4f52df01dad
Author: Michael Kubacki 
Date:   Wed Nov 20 17:10:48 2019 -0800

MdeModulePkg PeiCore: Fix typos

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Philippe Mathieu-Daude 
Reviewed-by: Jian J Wang 

commit 97eedf5dfbaffde33210fd88066247cf0b7d3325
Author: Antoine Coeur 
Date:   Wed Dec 4 12:14:53

Re: [Xen-devel] [PATCH] x86/microcode: Support builtin CPU microcode

2019-12-15 Thread Tamas K Lengyel 
> > For DRTM I don't think it makes much
> > difference, I believe the active microcode info is already part of the
> > measurement, so having it measured as part of the Xen blob doesn't add
> > anything.
>
> I couldn't possibly comment on timelines, but if I could, the answer
> might be "not for a little while yet".
>
> For now, microcode is very definitely software's problem to include in
> measurements.

Ah right, I was mixing it up with the ACM blob that gets measured there.

Tamas

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [ovmf test] 144839: regressions - FAIL

2019-12-15 Thread osstest service owner 
flight 144839 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144839/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 144637
 build-i386-xsm6 xen-buildfail REGR. vs. 144637
 build-amd64-xsm   6 xen-buildfail REGR. vs. 144637
 build-i3866 xen-buildfail REGR. vs. 144637

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 ovmf bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
baseline version:
 ovmf 804666c86e7b6f04fe5c5cfdb13199c19e0e99b0

Last test of basis   144637  2019-12-09 09:09:49 Z6 days
Failing since144646  2019-12-10 01:39:53 Z5 days   34 attempts
Testing same since   144770  2019-12-12 18:41:26 Z2 days   23 attempts


People who touched revisions under test:
  Antoine Coeur 
  Ard Biesheuvel 
  Bob Feng 
  Jiewen Yao 
  Michael Kubacki 
  Pete Batard 
  Philippe Mathieu-Daude 
  Steven Shi 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
Author: Pete Batard 
Date:   Tue Dec 10 18:23:04 2019 +

MdePkg/Include: Add DCC and BCM2835 SPCR UART types

As per the Microsoft Debug Port Table 2 (DBG2) documentation, that
can be found online, we are missing 2 serial interface types for
Arm DCC and Bcm2835 (the latter being used with the Raspberry Pi).

These same types are present in DebugPort2Table.h so add them to
SerialPortConsoleRedirectionTable.h too.

Note that we followed the same idiosyncrasies as DebugPort2Table
for naming these new macros.

Signed-off-by: Pete Batard 
Acked-by: Ard Biesheuvel 
Reviewed-by: Liming Gao 

commit 2fe25a74d6fee3c2ac0b930f7f3596cb432e766e
Author: Ard Biesheuvel 
Date:   Tue Mar 5 14:32:48 2019 +0100

ArmPkg/MmCommunicationDxe: relay architected PI events to MM context

PI defines a few architected events that have significance in the MM
context as well as in the non-secure DXE context. So register notify
handlers for these events, and relay them into the standalone MM world.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Jiewen Yao 
Reviewed-by: Achin Gupta 

commit d3add11e87dace180387562d6f1951f2bffbd3d9
Author: Michael Kubacki 
Date:   Wed Nov 20 17:31:24 2019 -0800

MdeModulePkg PeiCore: Improve comment semantics

This patch clarifies wording in several PeiCore comments to improve
reading comprehension.

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Jian J Wang 

commit d39d1260c615b716675f67f5c4e1f4f52df01dad
Author: Michael Kubacki 
Date:   Wed Nov 20 17:10:48 2019 -0800

MdeModulePkg PeiCore: Fix typos

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Philippe Mathieu-Daude 
Reviewed-by: Jian J Wang 

commit 97eedf5dfbaffde33210fd88066247cf0b7d3325
Author: Antoine Coeur 
Date:   Wed Dec 4 12:14:53

[Xen-devel] [ovmf test] 144838: regressions - FAIL

2019-12-15 Thread osstest service owner 
flight 144838 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144838/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 144637
 build-i386-xsm6 xen-buildfail REGR. vs. 144637
 build-amd64-xsm   6 xen-buildfail REGR. vs. 144637
 build-i3866 xen-buildfail REGR. vs. 144637

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a

version targeted for testing:
 ovmf bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
baseline version:
 ovmf 804666c86e7b6f04fe5c5cfdb13199c19e0e99b0

Last test of basis   144637  2019-12-09 09:09:49 Z6 days
Failing since144646  2019-12-10 01:39:53 Z5 days   33 attempts
Testing same since   144770  2019-12-12 18:41:26 Z2 days   22 attempts


People who touched revisions under test:
  Antoine Coeur 
  Ard Biesheuvel 
  Bob Feng 
  Jiewen Yao 
  Michael Kubacki 
  Pete Batard 
  Philippe Mathieu-Daude 
  Steven Shi 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
Author: Pete Batard 
Date:   Tue Dec 10 18:23:04 2019 +

MdePkg/Include: Add DCC and BCM2835 SPCR UART types

As per the Microsoft Debug Port Table 2 (DBG2) documentation, that
can be found online, we are missing 2 serial interface types for
Arm DCC and Bcm2835 (the latter being used with the Raspberry Pi).

These same types are present in DebugPort2Table.h so add them to
SerialPortConsoleRedirectionTable.h too.

Note that we followed the same idiosyncrasies as DebugPort2Table
for naming these new macros.

Signed-off-by: Pete Batard 
Acked-by: Ard Biesheuvel 
Reviewed-by: Liming Gao 

commit 2fe25a74d6fee3c2ac0b930f7f3596cb432e766e
Author: Ard Biesheuvel 
Date:   Tue Mar 5 14:32:48 2019 +0100

ArmPkg/MmCommunicationDxe: relay architected PI events to MM context

PI defines a few architected events that have significance in the MM
context as well as in the non-secure DXE context. So register notify
handlers for these events, and relay them into the standalone MM world.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Jiewen Yao 
Reviewed-by: Achin Gupta 

commit d3add11e87dace180387562d6f1951f2bffbd3d9
Author: Michael Kubacki 
Date:   Wed Nov 20 17:31:24 2019 -0800

MdeModulePkg PeiCore: Improve comment semantics

This patch clarifies wording in several PeiCore comments to improve
reading comprehension.

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Jian J Wang 

commit d39d1260c615b716675f67f5c4e1f4f52df01dad
Author: Michael Kubacki 
Date:   Wed Nov 20 17:10:48 2019 -0800

MdeModulePkg PeiCore: Fix typos

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Philippe Mathieu-Daude 
Reviewed-by: Jian J Wang 

commit 97eedf5dfbaffde33210fd88066247cf0b7d3325
Author: Antoine Coeur 
Date:   Wed Dec 4 12:14:53

[Xen-devel] [ovmf test] 144837: regressions - FAIL

2019-12-15 Thread osstest service owner 
flight 144837 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144837/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 144637
 build-i386-xsm6 xen-buildfail REGR. vs. 144637
 build-amd64-xsm   6 xen-buildfail REGR. vs. 144637
 build-i3866 xen-buildfail REGR. vs. 144637

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a

version targeted for testing:
 ovmf bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
baseline version:
 ovmf 804666c86e7b6f04fe5c5cfdb13199c19e0e99b0

Last test of basis   144637  2019-12-09 09:09:49 Z6 days
Failing since144646  2019-12-10 01:39:53 Z5 days   32 attempts
Testing same since   144770  2019-12-12 18:41:26 Z2 days   21 attempts


People who touched revisions under test:
  Antoine Coeur 
  Ard Biesheuvel 
  Bob Feng 
  Jiewen Yao 
  Michael Kubacki 
  Pete Batard 
  Philippe Mathieu-Daude 
  Steven Shi 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
Author: Pete Batard 
Date:   Tue Dec 10 18:23:04 2019 +

MdePkg/Include: Add DCC and BCM2835 SPCR UART types

As per the Microsoft Debug Port Table 2 (DBG2) documentation, that
can be found online, we are missing 2 serial interface types for
Arm DCC and Bcm2835 (the latter being used with the Raspberry Pi).

These same types are present in DebugPort2Table.h so add them to
SerialPortConsoleRedirectionTable.h too.

Note that we followed the same idiosyncrasies as DebugPort2Table
for naming these new macros.

Signed-off-by: Pete Batard 
Acked-by: Ard Biesheuvel 
Reviewed-by: Liming Gao 

commit 2fe25a74d6fee3c2ac0b930f7f3596cb432e766e
Author: Ard Biesheuvel 
Date:   Tue Mar 5 14:32:48 2019 +0100

ArmPkg/MmCommunicationDxe: relay architected PI events to MM context

PI defines a few architected events that have significance in the MM
context as well as in the non-secure DXE context. So register notify
handlers for these events, and relay them into the standalone MM world.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Jiewen Yao 
Reviewed-by: Achin Gupta 

commit d3add11e87dace180387562d6f1951f2bffbd3d9
Author: Michael Kubacki 
Date:   Wed Nov 20 17:31:24 2019 -0800

MdeModulePkg PeiCore: Improve comment semantics

This patch clarifies wording in several PeiCore comments to improve
reading comprehension.

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Jian J Wang 

commit d39d1260c615b716675f67f5c4e1f4f52df01dad
Author: Michael Kubacki 
Date:   Wed Nov 20 17:10:48 2019 -0800

MdeModulePkg PeiCore: Fix typos

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Philippe Mathieu-Daude 
Reviewed-by: Jian J Wang 

commit 97eedf5dfbaffde33210fd88066247cf0b7d3325
Author: Antoine Coeur 
Date:   Wed Dec 4 12:14:53

[Xen-devel] [ovmf test] 144836: regressions - FAIL

2019-12-15 Thread osstest service owner 
flight 144836 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144836/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 144637
 build-i386-xsm6 xen-buildfail REGR. vs. 144637
 build-amd64-xsm   6 xen-buildfail REGR. vs. 144637
 build-i3866 xen-buildfail REGR. vs. 144637

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a

version targeted for testing:
 ovmf bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
baseline version:
 ovmf 804666c86e7b6f04fe5c5cfdb13199c19e0e99b0

Last test of basis   144637  2019-12-09 09:09:49 Z6 days
Failing since144646  2019-12-10 01:39:53 Z5 days   31 attempts
Testing same since   144770  2019-12-12 18:41:26 Z2 days   20 attempts


People who touched revisions under test:
  Antoine Coeur 
  Ard Biesheuvel 
  Bob Feng 
  Jiewen Yao 
  Michael Kubacki 
  Pete Batard 
  Philippe Mathieu-Daude 
  Steven Shi 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
Author: Pete Batard 
Date:   Tue Dec 10 18:23:04 2019 +

MdePkg/Include: Add DCC and BCM2835 SPCR UART types

As per the Microsoft Debug Port Table 2 (DBG2) documentation, that
can be found online, we are missing 2 serial interface types for
Arm DCC and Bcm2835 (the latter being used with the Raspberry Pi).

These same types are present in DebugPort2Table.h so add them to
SerialPortConsoleRedirectionTable.h too.

Note that we followed the same idiosyncrasies as DebugPort2Table
for naming these new macros.

Signed-off-by: Pete Batard 
Acked-by: Ard Biesheuvel 
Reviewed-by: Liming Gao 

commit 2fe25a74d6fee3c2ac0b930f7f3596cb432e766e
Author: Ard Biesheuvel 
Date:   Tue Mar 5 14:32:48 2019 +0100

ArmPkg/MmCommunicationDxe: relay architected PI events to MM context

PI defines a few architected events that have significance in the MM
context as well as in the non-secure DXE context. So register notify
handlers for these events, and relay them into the standalone MM world.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Jiewen Yao 
Reviewed-by: Achin Gupta 

commit d3add11e87dace180387562d6f1951f2bffbd3d9
Author: Michael Kubacki 
Date:   Wed Nov 20 17:31:24 2019 -0800

MdeModulePkg PeiCore: Improve comment semantics

This patch clarifies wording in several PeiCore comments to improve
reading comprehension.

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Jian J Wang 

commit d39d1260c615b716675f67f5c4e1f4f52df01dad
Author: Michael Kubacki 
Date:   Wed Nov 20 17:10:48 2019 -0800

MdeModulePkg PeiCore: Fix typos

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Philippe Mathieu-Daude 
Reviewed-by: Jian J Wang 

commit 97eedf5dfbaffde33210fd88066247cf0b7d3325
Author: Antoine Coeur 
Date:   Wed Dec 4 12:14:53

[Xen-devel] [xen-unstable test] 144827: tolerable FAIL

2019-12-15 Thread osstest service owner 
flight 144827 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144827/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-rtds 16 guest-localmigrate fail pass in 144813
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 16 
guest-start/debianhvm.repeat fail pass in 144813

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds  18 guest-localmigrate/x10 fail in 144813 like 144804
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 144813
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 144813
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 144813
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 144813
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 144813
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 144813
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 144813
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 144813
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 144813
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 144813
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass

version targeted for testing:
 xen  c9115affa6f83aebe29ae9cbf503aa163911a5bb
baseline version:
 xen  c9115affa6f83aebe29ae9cbf503aa163911a5bb

Last test of basis   144827  2019-12-15 04:10:19 Z0 days
Testing same since  (not found) 0

[Xen-devel] [libvirt test] 144828: regressions - FAIL

2019-12-15 Thread osstest service owner 
flight 144828 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144828/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt16 guest-start/debian.repeat fail REGR. vs. 144517

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 144517
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 144517
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  98feb0c4123047953c19f4a4557701eab507
baseline version:
 libvirt  d0d728c7c00fd3a62731e50c7bc646df323c0622

Last test of basis   144517  2019-12-04 04:18:55 Z   11 days
Failing since144526  2019-12-05 04:19:27 Z   10 days   11 attempts
Testing same since   144802  2019-12-14 04:19:31 Z1 days2 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Cole Robinson 
  Daniel Berrange 
  Daniel P. Berrangé 
  Eric Blake 
  Fabiano Fidêncio 
  Han Han 
  Huaqiang 
  Jidong Xia 
  Jiri Denemark 
  Jonathon Jongsma 
  Ján Tomko 
  Marc Hartmayer 
  Marc-André Lureau 
  Michal Privoznik 
  Pavel Hrdina 
  Pavel Mores 
  Peter Krempa 
  Yingle Hou 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-arm64-arm64-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt pass
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   pass
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master

[Xen-devel] [ovmf test] 144835: regressions - FAIL

2019-12-15 Thread osstest service owner 
flight 144835 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144835/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 144637
 build-i386-xsm6 xen-buildfail REGR. vs. 144637
 build-amd64-xsm   6 xen-buildfail REGR. vs. 144637
 build-i3866 xen-buildfail REGR. vs. 144637

Tests which did not succeed, but are not blocking:
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
baseline version:
 ovmf 804666c86e7b6f04fe5c5cfdb13199c19e0e99b0

Last test of basis   144637  2019-12-09 09:09:49 Z6 days
Failing since144646  2019-12-10 01:39:53 Z5 days   30 attempts
Testing same since   144770  2019-12-12 18:41:26 Z2 days   19 attempts


People who touched revisions under test:
  Antoine Coeur 
  Ard Biesheuvel 
  Bob Feng 
  Jiewen Yao 
  Michael Kubacki 
  Pete Batard 
  Philippe Mathieu-Daude 
  Steven Shi 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
Author: Pete Batard 
Date:   Tue Dec 10 18:23:04 2019 +

MdePkg/Include: Add DCC and BCM2835 SPCR UART types

As per the Microsoft Debug Port Table 2 (DBG2) documentation, that
can be found online, we are missing 2 serial interface types for
Arm DCC and Bcm2835 (the latter being used with the Raspberry Pi).

These same types are present in DebugPort2Table.h so add them to
SerialPortConsoleRedirectionTable.h too.

Note that we followed the same idiosyncrasies as DebugPort2Table
for naming these new macros.

Signed-off-by: Pete Batard 
Acked-by: Ard Biesheuvel 
Reviewed-by: Liming Gao 

commit 2fe25a74d6fee3c2ac0b930f7f3596cb432e766e
Author: Ard Biesheuvel 
Date:   Tue Mar 5 14:32:48 2019 +0100

ArmPkg/MmCommunicationDxe: relay architected PI events to MM context

PI defines a few architected events that have significance in the MM
context as well as in the non-secure DXE context. So register notify
handlers for these events, and relay them into the standalone MM world.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Jiewen Yao 
Reviewed-by: Achin Gupta 

commit d3add11e87dace180387562d6f1951f2bffbd3d9
Author: Michael Kubacki 
Date:   Wed Nov 20 17:31:24 2019 -0800

MdeModulePkg PeiCore: Improve comment semantics

This patch clarifies wording in several PeiCore comments to improve
reading comprehension.

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Jian J Wang 

commit d39d1260c615b716675f67f5c4e1f4f52df01dad
Author: Michael Kubacki 
Date:   Wed Nov 20 17:10:48 2019 -0800

MdeModulePkg PeiCore: Fix typos

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Philippe Mathieu-Daude 
Reviewed-by: Jian J Wang 

commit 97eedf5dfbaffde33210fd88066247cf0b7d3325
Author: Antoine Coeur 
Date:   Wed Dec 4 12:14:53

[Xen-devel] [xen-unstable-coverity test] 144833: all pass - PUSHED

2019-12-15 Thread osstest service owner 
flight 144833 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144833/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen  c9115affa6f83aebe29ae9cbf503aa163911a5bb
baseline version:
 xen  272c18435e93cbf749c096a9552ab5ef0d79a4ca

Last test of basis   144699  2019-12-11 09:18:24 Z4 days
Testing same since   144833  2019-12-15 09:18:19 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  George Dunlap 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Paul Durrant 
  Wei Liu 
  Wei Liu 

jobs:
 coverity-amd64   pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   272c18435e..c9115affa6  c9115affa6f83aebe29ae9cbf503aa163911a5bb -> 
coverity-tested/smoke

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [ovmf test] 144834: regressions - FAIL

2019-12-15 Thread osstest service owner 
flight 144834 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144834/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 144637
 build-i386-xsm6 xen-buildfail REGR. vs. 144637
 build-amd64-xsm   6 xen-buildfail REGR. vs. 144637
 build-i3866 xen-buildfail REGR. vs. 144637

Tests which did not succeed, but are not blocking:
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a

version targeted for testing:
 ovmf bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
baseline version:
 ovmf 804666c86e7b6f04fe5c5cfdb13199c19e0e99b0

Last test of basis   144637  2019-12-09 09:09:49 Z6 days
Failing since144646  2019-12-10 01:39:53 Z5 days   29 attempts
Testing same since   144770  2019-12-12 18:41:26 Z2 days   18 attempts


People who touched revisions under test:
  Antoine Coeur 
  Ard Biesheuvel 
  Bob Feng 
  Jiewen Yao 
  Michael Kubacki 
  Pete Batard 
  Philippe Mathieu-Daude 
  Steven Shi 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
Author: Pete Batard 
Date:   Tue Dec 10 18:23:04 2019 +

MdePkg/Include: Add DCC and BCM2835 SPCR UART types

As per the Microsoft Debug Port Table 2 (DBG2) documentation, that
can be found online, we are missing 2 serial interface types for
Arm DCC and Bcm2835 (the latter being used with the Raspberry Pi).

These same types are present in DebugPort2Table.h so add them to
SerialPortConsoleRedirectionTable.h too.

Note that we followed the same idiosyncrasies as DebugPort2Table
for naming these new macros.

Signed-off-by: Pete Batard 
Acked-by: Ard Biesheuvel 
Reviewed-by: Liming Gao 

commit 2fe25a74d6fee3c2ac0b930f7f3596cb432e766e
Author: Ard Biesheuvel 
Date:   Tue Mar 5 14:32:48 2019 +0100

ArmPkg/MmCommunicationDxe: relay architected PI events to MM context

PI defines a few architected events that have significance in the MM
context as well as in the non-secure DXE context. So register notify
handlers for these events, and relay them into the standalone MM world.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Jiewen Yao 
Reviewed-by: Achin Gupta 

commit d3add11e87dace180387562d6f1951f2bffbd3d9
Author: Michael Kubacki 
Date:   Wed Nov 20 17:31:24 2019 -0800

MdeModulePkg PeiCore: Improve comment semantics

This patch clarifies wording in several PeiCore comments to improve
reading comprehension.

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Jian J Wang 

commit d39d1260c615b716675f67f5c4e1f4f52df01dad
Author: Michael Kubacki 
Date:   Wed Nov 20 17:10:48 2019 -0800

MdeModulePkg PeiCore: Fix typos

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Philippe Mathieu-Daude 
Reviewed-by: Jian J Wang 

commit 97eedf5dfbaffde33210fd88066247cf0b7d3325
Author: Antoine Coeur 
Date:   Wed Dec 4 12:14:53

Re: [Xen-devel] [PATCH 12/12] hw/i386/pc: Move PC-machine specific declarations to 'pc_internal.h'

2019-12-15 Thread Michael S. Tsirkin 
On Fri, Dec 13, 2019 at 05:47:28PM +0100, Philippe Mathieu-Daudé wrote:
> On 12/13/19 5:17 PM, Philippe Mathieu-Daudé wrote:
> > Historically, QEMU started with only one X86 machine: the PC.
> > The 'hw/i386/pc.h' header was used to store all X86 and PC
> > declarations. Since we have now multiple machines based on the
> > X86 architecture, move the PC-specific declarations in a new
> > header.
> > We use 'internal' in the name to explicit this header is restricted
> > to the X86 architecture. Other architecture can not access it.
> > 
> > Signed-off-by: Philippe Mathieu-Daudé 
> > ---
> > Maybe name it 'pc_machine.h'?
> 
> I forgot to describe here (and in the cover), what's follow after this
> patch.
> 
> Patch #13 moves PCMachineClass to
> 
> If you ignore PCMachineState, "hw/i386/pc.h" now only contains 76 lines, and
> it is easier to see what is PC machine specific, what is X86 specific, and
> what is device generic (not X86 related at all):
> 
> - GSI is common to X86 (Paolo sent [3], [6])
> - IOAPIC is common to X86
> - i8259 is multiarch (Paolo [2])
> - PCI_HOST definitions and pc_pci_hole64_start() are X86
> - pc_machine_is_smm_enabled() is X86 (Paolo sent [5])
> - hpet
> - tsc (Paolo sent [3])
> - 3 more functions
> 
> So we can move half of this file to "pc_internal.h" and the other to
> 
> One problem is the Q35 MCH north bridge which directly sets the PCI
> PCMachineState->bus in q35_host_realize(). This seems a QOM violation and is
> probably easily fixable.
> 
> Maybe I can apply Paolo's patches instead of this #12, move X86-generic
> declarations to "hw/i386/x86.h", and directly git-move what's left of
> "hw/i386/pc.h" to "pc_internal.h".

Yea that sounds a bit better.

> [3] https://www.mail-archive.com/qemu-devel@nongnu.org/msg664627.html
> [2] https://www.mail-archive.com/qemu-devel@nongnu.org/msg664765.html
> [5] https://www.mail-archive.com/qemu-devel@nongnu.org/msg664754.html
> [6] https://www.mail-archive.com/qemu-devel@nongnu.org/msg664766.html
> 
> > ---
> >   hw/i386/pc_internal.h | 144 ++
> >   include/hw/i386/pc.h  | 128 -
> >   hw/i386/acpi-build.c  |   1 +
> >   hw/i386/pc.c  |   1 +
> >   hw/i386/pc_piix.c |   1 +
> >   hw/i386/pc_q35.c  |   1 +
> >   hw/i386/pc_sysfw.c|   1 +
> >   hw/i386/xen/xen-hvm.c |   1 +
> >   8 files changed, 150 insertions(+), 128 deletions(-)
> >   create mode 100644 hw/i386/pc_internal.h


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [ovmf test] 144832: regressions - FAIL

2019-12-15 Thread osstest service owner 
flight 144832 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144832/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 144637
 build-i386-xsm6 xen-buildfail REGR. vs. 144637
 build-amd64-xsm   6 xen-buildfail REGR. vs. 144637
 build-i3866 xen-buildfail REGR. vs. 144637

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a

version targeted for testing:
 ovmf bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
baseline version:
 ovmf 804666c86e7b6f04fe5c5cfdb13199c19e0e99b0

Last test of basis   144637  2019-12-09 09:09:49 Z6 days
Failing since144646  2019-12-10 01:39:53 Z5 days   28 attempts
Testing same since   144770  2019-12-12 18:41:26 Z2 days   17 attempts


People who touched revisions under test:
  Antoine Coeur 
  Ard Biesheuvel 
  Bob Feng 
  Jiewen Yao 
  Michael Kubacki 
  Pete Batard 
  Philippe Mathieu-Daude 
  Steven Shi 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
Author: Pete Batard 
Date:   Tue Dec 10 18:23:04 2019 +

MdePkg/Include: Add DCC and BCM2835 SPCR UART types

As per the Microsoft Debug Port Table 2 (DBG2) documentation, that
can be found online, we are missing 2 serial interface types for
Arm DCC and Bcm2835 (the latter being used with the Raspberry Pi).

These same types are present in DebugPort2Table.h so add them to
SerialPortConsoleRedirectionTable.h too.

Note that we followed the same idiosyncrasies as DebugPort2Table
for naming these new macros.

Signed-off-by: Pete Batard 
Acked-by: Ard Biesheuvel 
Reviewed-by: Liming Gao 

commit 2fe25a74d6fee3c2ac0b930f7f3596cb432e766e
Author: Ard Biesheuvel 
Date:   Tue Mar 5 14:32:48 2019 +0100

ArmPkg/MmCommunicationDxe: relay architected PI events to MM context

PI defines a few architected events that have significance in the MM
context as well as in the non-secure DXE context. So register notify
handlers for these events, and relay them into the standalone MM world.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Jiewen Yao 
Reviewed-by: Achin Gupta 

commit d3add11e87dace180387562d6f1951f2bffbd3d9
Author: Michael Kubacki 
Date:   Wed Nov 20 17:31:24 2019 -0800

MdeModulePkg PeiCore: Improve comment semantics

This patch clarifies wording in several PeiCore comments to improve
reading comprehension.

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Jian J Wang 

commit d39d1260c615b716675f67f5c4e1f4f52df01dad
Author: Michael Kubacki 
Date:   Wed Nov 20 17:10:48 2019 -0800

MdeModulePkg PeiCore: Fix typos

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Michael Kubacki 
Reviewed-by: Liming Gao 
Reviewed-by: Philippe Mathieu-Daude 
Reviewed-by: Jian J Wang 

commit 97eedf5dfbaffde33210fd88066247cf0b7d3325
Author: Antoine Coeur 
Date:   Wed Dec 4 12:14:53