Re: [Xen-devel] [PATCH] x86/cpuid: fix dom0 crash on skylake machine

[Han, Huaitong]

On Wed, 2016-06-01 at 12:58 +0800, Luwei Kang wrote:
> CPUID.0XD.0X0.EAX is from machine value for dom0, and dom0 kernel will xsetbv
> with xfeatures_mask that is from CPUID.0XD.0X0.EAX, but handle_xsetbv has
> ingored XSTATE_PKRU with hardware protection fault emulation, so dom0 kernel
> will crash on skylake machine with PKRU support.
> 
> Signed-off-by: Luwei Kang 
Signed-off-by: Huaitong Han 
> ---
>  xen/arch/x86/traps.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
> index 1ef8401..5e72e44 100644
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -1100,6 +1100,9 @@ void pv_cpuid(struct cpu_user_regs *regs)
>   */
>  if ( !is_control_domain(currd) && !is_hardware_domain(currd) )
>  cpuid_count(leaf, subleaf, , , , );
> +
> +/* PV is not supported by XSTATE_PKRU. */
> +a &= ~XSTATE_PKRU;
>  break;
>  }
>  

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/2] xen-blkfront: don't call talk_to_blkback when already connected to blkback

[Bob Liu]

On 06/01/2016 04:33 AM, Konrad Rzeszutek Wilk wrote:
> On Tue, May 31, 2016 at 04:59:16PM +0800, Bob Liu wrote:
>> Sometimes blkfont may receive twice blkback_changed() notification after
>> migration, then talk_to_blkback() will be called twice too and confused
>> xen-blkback.
> 
> Could you enlighten the patch description by having some form of
> state transition here? I am curious how you got the frontend
> to get in XenbusStateConnected (via blkif_recover right) and then
> the backend triggering the update once more?
> 
> Or is just a simple race - the backend moves from XenbusStateConnected->
> XenbusStateConnected - which retriggers the frontend to hit in
> blkback_changed the XenbusStateConnected state and go in there?
> (That would be in conenct_ring changing the state). But I don't
> see how the frontend_changed code get there as we have:
> 
>  770 /*
>  771  * Ensure we connect even when two watches fire in
>  772  * close succession and we miss the intermediate value
>  773  * of frontend_state.
>  774  */
>  775 if (dev->state == XenbusStateConnected)
>  776 break;
>  777 
> 
> ?
> 
> Now what about 'blkfront_connect' being called on the second time?
> 
> Ah, info->connected is probably by then in BLKIF_STATE_CONNECTED
> (as blkif_recover changed) and we just reread the size of the disk.
> 
> Is that how about the flow goes?

blkfrontblkback
blkfront_resume()   
 > talk_to_blkback()
  > Set blkfront to XenbusStateInitialised
Front changed()
 > Connect()
  > Set blkback to 
XenbusStateConnected

blkback_changed()
 > Skip talk_to_blkback()
   because frontstate == XenbusStateInitialised
 > blkfront_connect()
  > Set blkfront to XenbusStateConnected


--
But sometimes blkfront receives
blkback_changed() event more than once!
Not sure why.

blkback_changed()
 > because now frontstate != XenbusStateInitialised
   talk_to_blkback() is also called again
  > blkfront state changed from 
XenbusStateConnected to XenbusStateInitialised
(Which is not correct!)


Front_changed():
 > Do nothing because blkback
   already in 
XenbusStateConnected


Now blkback is XenbusStateConnected but blkfront still XenbusStateInitialised.

>>
>> Signed-off-by: Bob Liu 
>> ---
>>  drivers/block/xen-blkfront.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
>> index ca13df8..01aa460 100644
>> --- a/drivers/block/xen-blkfront.c
>> +++ b/drivers/block/xen-blkfront.c
>> @@ -2485,7 +2485,8 @@ static void blkback_changed(struct xenbus_device *dev,
>>  break;
>>  
>>  case XenbusStateConnected:
>> -if (dev->state != XenbusStateInitialised) {
>> +if ((dev->state != XenbusStateInitialised) &&
>> +(dev->state != XenbusStateConnected)) {
>>  if (talk_to_blkback(dev, info))
>>  break;
>>  }
>> -- 
>> 2.7.4
>>

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2] xen: xenbus: Remove create_workqueue

[Bhaktipriya Shridhar]

System workqueues have been able to handle high level of concurrency
for a long time now and there's no reason to use dedicated workqueues
just to gain concurrency.  Replace dedicated xenbus_frontend_wq with the
use of system_wq.

Unlike a dedicated per-cpu workqueue created with create_workqueue(),
system_wq allows multiple work items to overlap executions even on
the same CPU; however, a per-cpu workqueue doesn't have any CPU
locality or global ordering guarantees unless the target CPU is
explicitly specified and the increase of local concurrency shouldn't
make any difference.

In this case, there is only a single work item, increase of concurrency
level by switching to system_wq should not make any difference.

Signed-off-by: Bhaktipriya Shridhar 
---
 drivers/xen/xenbus/xenbus_probe_frontend.c | 15 +--
 1 file changed, 1 insertion(+), 14 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c 
b/drivers/xen/xenbus/xenbus_probe_frontend.c
index bcb53bd..611a231 100644
--- a/drivers/xen/xenbus/xenbus_probe_frontend.c
+++ b/drivers/xen/xenbus/xenbus_probe_frontend.c
@@ -31,7 +31,6 @@
 #include "xenbus_probe.h"


-static struct workqueue_struct *xenbus_frontend_wq;

 /* device// => - */
 static int frontend_bus_id(char bus_id[XEN_BUS_ID_SIZE], const char *nodename)
@@ -109,13 +108,7 @@ static int xenbus_frontend_dev_resume(struct device *dev)
if (xen_store_domain_type == XS_LOCAL) {
struct xenbus_device *xdev = to_xenbus_device(dev);

-   if (!xenbus_frontend_wq) {
-   pr_err("%s: no workqueue to process delayed resume\n",
-  xdev->nodename);
-   return -EFAULT;
-   }
-
-   queue_work(xenbus_frontend_wq, >work);
+   schedule_work(>work);

return 0;
}
@@ -485,12 +478,6 @@ static int __init xenbus_probe_frontend_init(void)

register_xenstore_notifier(_notifier);

-   if (xen_store_domain_type == XS_LOCAL) {
-   xenbus_frontend_wq = create_workqueue("xenbus_frontend");
-   if (!xenbus_frontend_wq)
-   pr_warn("create xenbus frontend workqueue failed, S3 
resume is likely to fail\n");
-   }
-
return 0;
 }
 subsys_initcall(xenbus_probe_frontend_init);
--
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen: xenbus: Remove create_workqueue

[Bhaktipriya Shridhar]

Sorry about that. Will make the corrections in v2.

Thanks,
Bhaktipriya


On Tue, May 31, 2016 at 9:48 PM, David Vrabel  wrote:
> On 27/05/16 19:50, Bhaktipriya Shridhar wrote:
>> With concurrency managed workqueues, use of dedicated workqueues can be
>> replaced by using system_wq. Drop xenbus_frontend_wq by using system_wq.
>>
>> Since there is only a single work item, increase of concurrency level by
>> switching to system_wq should not break anything.
>>
>> Since the work item could be pending and the code expects it to run
>> once scheduled, flush_work() has been used in xenbus_dev_suspend()
>
> This says flush_work() but...
>>
>> Signed-off-by: Bhaktipriya Shridhar 
>> ---
>>  drivers/xen/xenbus/xenbus_probe.c  |  2 ++
>>  drivers/xen/xenbus/xenbus_probe_frontend.c | 15 +--
>>  2 files changed, 3 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/xen/xenbus/xenbus_probe.c 
>> b/drivers/xen/xenbus/xenbus_probe.c
>> index 33a31cf..bc97019 100644
>> --- a/drivers/xen/xenbus/xenbus_probe.c
>> +++ b/drivers/xen/xenbus/xenbus_probe.c
>> @@ -592,6 +592,8 @@ int xenbus_dev_suspend(struct device *dev)
>>
>>   DPRINTK("%s", xdev->nodename);
>>
>> + cancel_work_sync(>work);
>
> ...cancel_work_sync() is called here.
>
> David

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC v2] dma-mapping: Use unsigned long for dma_attrs

[Krzysztof Kozlowski]

On 05/31/2016 07:04 PM, Christoph Hellwig wrote:
> On Mon, May 30, 2016 at 01:54:06PM +0200, Krzysztof Kozlowski wrote:
>> The dma-mapping core and the implementations do not change the
>> DMA attributes passed by pointer.  Thus the pointer can point to const
>> data.  However the attributes do not have to be a bitfield. Instead
>> unsigned long will do fine:
>>
>> 1. This is just simpler.  Both in terms of reading the code and setting
>>attributes.  Instead of initializing local attributes on the stack and
>>passing pointer to it to dma_set_attr(), just set the bits.
>>
>> 2. It brings safeness and checking for const correctness because the
>>attributes are passed by value.
>>
>> Please have in mind that this is RFC, not finished yet.  Only ARM and
>> ARM64 are fixed (and not everywhere).
>> However other API users also have to be converted which is quite
>> intrusive.  I would rather avoid it until the overall approach is
>> accepted.
> 
> This looks great!  Please continue doing the full conversion.
> 
>> +/**
>> + * List of possible attributes associated with a DMA mapping. The semantics
>> + * of each attribute should be defined in Documentation/DMA-attributes.txt.
>> + */
>> +#define DMA_ATTR_WRITE_BARRIER  BIT(1)
>> +#define DMA_ATTR_WEAK_ORDERING  BIT(2)
>> +#define DMA_ATTR_WRITE_COMBINE  BIT(3)
>> +#define DMA_ATTR_NON_CONSISTENT BIT(4)
>> +#define DMA_ATTR_NO_KERNEL_MAPPING  BIT(5)
>> +#define DMA_ATTR_SKIP_CPU_SYNC  BIT(6)
>> +#define DMA_ATTR_FORCE_CONTIGUOUS   BIT(7)
>> +#define DMA_ATTR_ALLOC_SINGLE_PAGES BIT(8)
> 
> No really for this patch, but I would much prefer to document them next
> to the code in the long run.  Also I really think these BIT() macros
> are a distraction compared to the (1 << N) notation.

Not much difference to me but maybe plain number:
... 0x01u
... 0x02u
?

> 
>> +/**
>> + * dma_get_attr - check for a specific attribute
>> + * @attr: attribute to look for
>> + * @attrs: attributes to check within
>> + */
>> +static inline bool dma_get_attr(unsigned long attr, unsigned long attrs)
>> +{
>> +return !!(attr & attrs);
>> +}
> 
> I'd just kill this helper, much easier to simply open code it in the
> caller.

Keeping it for now helps reducing the number of changes in the patch.
The patch will be quite big as it has to replace all the uses atomically.

I can get rid of the helper in consecutive patch.

Best regards,
Krzysztof



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH] x86/cpuid: fix dom0 crash on skylake machine

[Luwei Kang]

CPUID.0XD.0X0.EAX is from machine value for dom0, and dom0 kernel will xsetbv
with xfeatures_mask that is from CPUID.0XD.0X0.EAX, but handle_xsetbv has
ingored XSTATE_PKRU with hardware protection fault emulation, so dom0 kernel
will crash on skylake machine with PKRU support.

Signed-off-by: Luwei Kang 
---
 xen/arch/x86/traps.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 1ef8401..5e72e44 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1100,6 +1100,9 @@ void pv_cpuid(struct cpu_user_regs *regs)
  */
 if ( !is_control_domain(currd) && !is_hardware_domain(currd) )
 cpuid_count(leaf, subleaf, , , , );
+
+/* PV is not supported by XSTATE_PKRU. */
+a &= ~XSTATE_PKRU;
 break;
 }
 
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [qemu-upstream-4.3-testing test] 95090: trouble: blocked/broken

[osstest service owner]

flight 95090 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95090/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927

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-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  115 days
Testing same since93977  2016-05-10 11:09:16 Z   21 days   92 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

[Xen-devel] handle virtualization exception

[Big Strong]

Virtualization exception is a fault exception caused by specific type of
EPT violations. The vector is 20, which is not defined in linux kernel
(traps.h), also no exception handling function is defined (traps.c). So is
there any way to implement it as a LKM? As it is needed to
set virtualization-exception information area and virtualization exception
handler ((for example, by executing the EPTP-switching VM function), it is
inflexible to implement it in linux kernel directly.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[osstest service owner]

flight 95082 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95082/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. 
vs. 94748
 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 94748

version targeted for testing:
 ovmf 2f7b34b20842fcc485b39c0e1e91313c47b4d090
baseline version:
 ovmf dc99315b8732b6e3032d01319d3f534d440b43d0

Last test of basis94748  2016-05-24 22:43:25 Z7 days
Failing since 94750  2016-05-25 03:43:08 Z6 days   21 attempts
Testing same since94993  2016-05-31 13:42:33 Z0 days2 attempts


People who touched revisions under test:
  Cohen, Eugene 
  Dandan Bi 
  Darbin Reyes 
  Eugene Cohen 
  Fu Siyuan 
  Fu, Siyuan 
  Gary Lin 
  Hao Wu 
  Jeff Fan 
  Jiaxin Wu 
  Katie Dellaquila 
  Laszlo Ersek 
  Liming Gao 
  Marvin H?user 
  Marvin Haeuser 
  Maurice Ma 
  Michael Zimmermann 
  Star Zeng 
  Yonghong Zhu 

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



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.

(No revision log; it would be 754 lines long.)

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [qemu-upstream-4.3-testing test] 95085: trouble: blocked/broken

[osstest service owner]

flight 95085 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95085/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927

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-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  115 days
Testing same since93977  2016-05-10 11:09:16 Z   21 days   91 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

[Xen-devel] [qemu-mainline test] 94994: regressions - FAIL

[osstest service owner]

flight 94994 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94994/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-amd  9 debian-hvm-install   fail REGR. vs. 94856
 test-amd64-amd64-qemuu-nested-intel  9 debian-hvm-install fail REGR. vs. 94856
 test-armhf-armhf-xl  15 guest-start/debian.repeat fail REGR. vs. 94856
 test-armhf-armhf-xl-cubietruck  9 debian-install  fail REGR. vs. 94856
 test-amd64-amd64-pygrub   9 debian-di-install fail REGR. vs. 94856
 test-amd64-amd64-amd64-pvgrub  9 debian-di-installfail REGR. vs. 94856
 test-amd64-amd64-i386-pvgrub  9 debian-di-install fail REGR. vs. 94856
 test-amd64-i386-xl-raw9 debian-di-install fail REGR. vs. 94856
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 94856
 test-armhf-armhf-xl-arndale  15 guest-start/debian.repeat fail REGR. vs. 94856
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail REGR. 
vs. 94856
 test-amd64-i386-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs. 
94856

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-localmigrate fail REGR. vs. 94856
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-localmigrate fail REGR. vs. 94856
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-localmigrate  fail REGR. vs. 94856
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 94856
 test-amd64-amd64-xl-rtds  9 debian-install   fail   like 94856

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuu500acc9c410bcea17148a1072e323c08d12e6a6b
baseline version:
 qemuud6550e9ed2e1a60d889dfb721de00d9a4e3bafbe

Last test of basis94856  2016-05-27 20:14:49 Z4 days
Failing since 94983  2016-05-31 09:40:12 Z0 days2 attempts
Testing same since94994  2016-05-31 15:42:55 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Benjamin Herrenschmidt 
  Bharata B Rao 
  Chen Fan 
  Cédric Le Goater 
  David Gibson 
  Drew Jones 
  Emilio G. Cota 

[Xen-devel] [xen-unstable-smoke test] 95084: tolerable all pass - PUSHED

[osstest service owner]

flight 95084 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95084/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  bbfd2d6ccb31a3aeea49c8f9c7884792ddc26e3b
baseline version:
 xen  1dda826420fff634983e94f97fb8411486acda0d

Last test of basis95081  2016-05-31 18:00:57 Z0 days
Testing same since95084  2016-05-31 20:00:52 Z0 days1 attempts


People who touched revisions under test:
  Chris Patterson 
  Jan Beulich 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt 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 :

+ branch=xen-unstable-smoke
+ revision=bbfd2d6ccb31a3aeea49c8f9c7884792ddc26e3b
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
bbfd2d6ccb31a3aeea49c8f9c7884792ddc26e3b
+ branch=xen-unstable-smoke
+ revision=bbfd2d6ccb31a3aeea49c8f9c7884792ddc26e3b
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.6-testing
+ '[' xbbfd2d6ccb31a3aeea49c8f9c7884792ddc26e3b = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' 

Re: [Xen-devel] [PATCH v3 2/3] svm: iommu: Only call guest_iommu_init() after initialized HVM domain

[Suravee Suthikulanit]

On 5/26/2016 10:44 AM, Jan Beulich wrote:

Suravee Suthikulanit  05/25/16 9:01 PM >>>

On 5/23/2016 6:54 AM, Jan Beulich wrote:

On 22.05.16 at 01:42,  wrote:

From: Suravee Suthikulpanit 

The guest_iommu_init() is currently called by the following code path:

arch/x86/domain.c: arch_domain_create()
  ]- drivers/passthrough/iommu.c: iommu_domain_init()
|- drivers/passthrough/amd/pci_amd_iommu.c: amd_iommu_domain_init();
  |- drivers/passthrough/amd/iommu_guest.c: guest_iommu_init()

At this point, the hvm_domain_initialised() has not been called.
So register_mmio_handler() in guest_iommu_init() silently fails.
This patch moves the iommu_domain_init() to a later point after the
hvm_domain_intialise() instead.


That's one possible approach, which I continue to be not really
happy with. guest_iommu_init() really is HVM-specific, so maybe
no longer calling it from amd_iommu_domain_init() would be the
better solution (instead calling it from hvm_domain_initialise()
would then seem to be the better option). Thoughts?


Then, this goes back to the approach I proposed in the v1 of this patch
series, where I call guest_iommu_init/destroy() in the
svm_domain_initialise/destroy().

However, I'm still not quite clear in why the iommu_domain_init() is
needed before hvm_domain_initialise().


I think the two things are only lightly related. Changing the order of calls is
generally fine, but recognizing that guest_iommu_init() really would better be
called elsewhere makes that re-ordering simply unnecessary.

Jan


So, let discussing these two things separately. I would propose to:

1. Let's just remove the guest_iommu_init() for now since it's not 
functioning, and it seems to not being called at a proper place 
according to Jan. We will revisit this when we re-introduce and fully 
test out the feature.


2. As for the ordering of the iommu_domain_init() and hvm_domain_init() 
, let's continue to discuss to find proper ordering if it needs changing.


Let me know what you guys thinks.

Thanks,
Suravee

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/1] tools/xsplice: cleanup unnecessary "j = ARRAY_SIZE(action_options); "

[Konrad Rzeszutek Wilk]

On Mon, May 30, 2016 at 09:46:02AM +0800, Dongli Zhang wrote:
> Local variable "j" would be used only when "i == ARRAY_SIZE(main_options)"
> is true. Thus, it is not necessary to update "j" when "i ==
> ARRAY_SIZE(main_options)" is false.
> 
> Signed-off-by: Dongli Zhang 

Reviewed-by: Konrad Rzeszutek Wilk 

Wei, it is up to you whether it should go in 4.7 or in 4.8.
This is a cleanup so it has no effect on the code.

> ---
>  tools/misc/xen-xsplice.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/tools/misc/xen-xsplice.c b/tools/misc/xen-xsplice.c
> index ddaa079..811dc57 100644
> --- a/tools/misc/xen-xsplice.c
> +++ b/tools/misc/xen-xsplice.c
> @@ -435,8 +435,7 @@ int main(int argc, char *argv[])
> "'xen-xsplice help'\n", argv[1]);
>  return 1;
>  }
> -} else
> -j = ARRAY_SIZE(action_options);
> +}
>  
>  xch = xc_interface_open(0,0,0);
>  if ( !xch )
> -- 
> 1.9.1
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 00/14] Xen ARM DomU ACPI support

[Boris Ostrovsky]

On 05/31/2016 03:42 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, May 31, 2016 at 12:43:22PM +0800, Shannon Zhao wrote:
>> From: Shannon Zhao 
>>
>> The design of this feature is described as below.
>> Firstly, the toolstack (libxl) generates the ACPI tables according the
>> number of vcpus and gic controller.
> CC-ing Boris - who has been working on exposing ACPI tables
> for PVH guests.
>
> Is there some way of re-using some of the code? 

Indeed it would be good to keep all ACPI code in single place.

I sent a patch series a while ago
(http://lists.xenproject.org/archives/html/xen-devel/2016-04/msg00625.html)
but because of release work it hasn't been reviewed yet. Shannon, can
you take a look at it and see whether you code can make use of what is
proposed there? It builds all the tables that you are building here
except for GTDT and provides libxc interface.

(Copying Roger, Andrew and Jan)

-boris


>> Then, it copies these ACPI tables to DomU memory space and passes
>> them to UEFI firmware through the "ARM multiboot" protocol.
>>
>> At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol
>> and installs these tables like the usual way and passes both ACPI and DT
>> information to the Xen DomU.
>>
>> Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT tables
>> since it's enough now.
>>
>> This has been tested using guest kernel with the Dom0 ACPI support
>> patches which could be fetched from:
>> https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen
>>
>> Shannon Zhao (14):
>>   libxl/arm: Fix the function name in error log
>>   libxl/arm: Factor out codes for generating DTB
>>   libxc: Add placeholders for ACPI tables blob and size
>>   tools: add ACPI tables relevant definitions
>>   libxl/arm: Construct ACPI GTDT table
>>   libxl/arm: Construct ACPI FADT table
>>   libxl/arm: Construct ACPI DSDT table
>>   libxl/arm: Construct ACPI MADT table
>>   libxl/arm: Construct ACPI XSDT table
>>   libxl/arm: Construct ACPI RSDP table
>>   libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ
>>   libxl/arm: Add ACPI module
>>   libxl/arm: initialize memory information of ACPI blob
>>   libxc/xc_dom_core: Copy ACPI tables to guest memory space
>>
>>  tools/libxc/include/acpi_defs.h | 277 
>>  tools/libxc/include/xc_dom.h|  17 ++
>>  tools/libxc/xc_dom_arm.c|  16 +-
>>  tools/libxc/xc_dom_core.c   |  59 +++
>>  tools/libxl/libxl_arm.c | 345 
>> +++-
>>  5 files changed, 706 insertions(+), 8 deletions(-)
>>  create mode 100644 tools/libxc/include/acpi_defs.h
>>
>> -- 
>> 2.0.4
>>
>>
>>
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Build problems with xen 4.7

[Konrad Rzeszutek Wilk]

On Tue, May 31, 2016 at 07:27:24PM +0100, George Dunlap wrote:
> On Fri, May 13, 2016 at 4:23 PM, Konrad Rzeszutek Wilk
>  wrote:
> > On Fri, May 13, 2016 at 03:25:52PM +0100, M A Young wrote:
> >> On Fri, 13 May 2016, Jan Beulich wrote:
> >>
> >> > >>> On 13.05.16 at 15:49,  wrote:
> >> > > ...
> >> > >
> >> > > Still an issue - with 4.7.0-rc1.
> >> >
> >> > And I don't recall anyone having contributed a fix/workaround.
> >> >
> >> > > If I do:
> >> > >
> >> > > $export CFLAGS=" "'
> >> > > $make
> >> > >
> >> > > I end up with:
> >> > > gcc -E -O1 -fno-omit-frame-pointer -m64 -DBUILD_ID -g 
> >> > > -fno-strict-aliasing -std=gnu99
> >> > >[...]
> >> > > :0:0: error: "__OBJECT_FILE__" redefined [-Werror]
> >> > > :0:0: note: this is the location of the previous 
> >> > > definition
> >> > > :0:0: error: "__OBJECT_LABEL__" redefined [-Werror]
> >> > > :0:0: note: this is the location of the previous 
> >> > > definition
> >> > > cc1: all warnings being treated as errors
> >> > > Makefile:62: recipe for target 'compat/callback.i' failed
> >> >
> >> > My previous recommendation stands: Then just don't do this.
> >>
> >> I hacked around it for my test builds (eg. see my test build at
> >> https://copr.fedorainfracloud.org/coprs/myoung/xentest/build/204111/
> >> ) by not setting CFLAGS in the environment, but by instead adding the
> >> recommended Fedora RPM settings into config/StdGNU.mk via a different
> >> environment variable.
> >
> > ah:
> >
> > --- xen-4.7.0/config/StdGNU.mk.orig 2016-04-15 22:56:52.191227591 +0100
> > +++ xen-4.7.0/config/StdGNU.mk  2016-04-15 23:01:40.978829756 +0100
> > @@ -37,6 +37,12 @@
> >
> >  ifneq ($(debug),y)
> >  CFLAGS += -O2 -fomit-frame-pointer -fno-tree-coalesce-vars
> > +ifeq ($(XEN_TARGET_ARCH),x86_64)
> > +#might be cross-compiling so strip out possible x86_32 options
> > +CFLAGS += $(shell echo $(CFLAGS_EXTRA) | sed -e 's/-m32//g' -e 
> > 's/-march=i686//g' -e 's/-mtune=atom//g')
> > +else
> > +CFLAGS += $(CFLAGS_EXTRA)
> > +endif
> >  else
> >  # Less than -O1 produces bad code and large stack frames
> >  CFLAGS += -O1 -fno-omit-frame-pointer
> >
> >
> > And in the spec file:
> > export CFLAGS_EXTRA="$RPM_OPT_FLAGS"
> > make %{?_smp_mflags} %{?efi_flags} prefix=/usr dist-xen
> 
> Something like the above solution worked for me (CentOS 7 -- I'm
> suspecting a similar pattern here).
> 
> Adding CFLAGS="${RPM_OPT_FLAGS}" to my ./configure line made some
> noises as though it was going to work, but none of it actually ended
> up passed to the compiler (whereas it did with the little patch Konrad
> posted).
> 
> Are we going to provide a proper way for distros to add flags like
> this without having to hack the build system?

I like the suggestion he had for config/StdGNU.mk ..
> 
>  -George

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/2] libfsimage: replace deprecated readdir_r() with readdir()

[Chris Patterson]

On Tue, May 31, 2016 at 1:53 PM, Wei Liu  wrote:
> On Tue, May 31, 2016 at 11:43:13AM -0400, Chris Patterson wrote:
>> On Tue, May 31, 2016 at 6:42 AM, George Dunlap  
>> wrote:
>> > On Mon, May 30, 2016 at 3:32 AM, Chris Patterson  wrote:
>> >> From: Chris Patterson 
>> >>
>> >> Replace the usage of readdir_r() with readdir() to address
>> >> a compilation error due to the deprecation of readdir_r.
>> >>
>> >> glibc has deprecated this for their next release (2.24):
>> >> https://sourceware.org/bugzilla/show_bug.cgi?id=19056
>> >>
>> >> Signed-off-by: Chris Patterson 
>> >
>> > Thanks for the patch, Chris.  A bit more background would have been
>> > helpful -- I did some searching and found a description[1] which says:
>> >
>>
>> Thank you. I should have added these details in the commit message or cover.
>>
>> > In the current POSIX.1 specification (POSIX.1-2008), readdir(3) is
>> > not required to be thread-safe.  However, in modern
>> > implementations (including the glibc implementation), concurrent
>> > calls to readdir(3) that specify different directory streams are
>> > thread-safe.  Therefore, the use of readdir_r() is generally
>> > unnecessary in multithreaded programs.  In cases where multiple
>> > threads must read from the same directory stream, using readdir(3)
>> > with external synchronization is still preferable to the use of
>> > readdir_r(), for the reasons given in the points above.
>> >
>> > The use of the specific directory stream is single-threaded, so for
>> > glibc, it looks like using readdir() will be safe.  But libxl needs to
>> > be able to build on a number of libc's that are not glibc and still be
>> > thread-safe.  So we need to either 1) verify that readdir() is thread
>> > safe on all libc's against which we may compile, or 2) add some
>>
>> Is there a list of supported libc libraries?  I can look into it and
>> provide more definitive answers if there are.
>>
>
> We at least care about FreeBSD and NetBSD. Sadly their manuaks don't
> provide statement regarding thread safety for readdir and readdir_r.
> It's better to err on the safe side.
>

I'm far from the expert here, but it would appear that both NetBSD's
and FreeBSD's libc readdir()/readdir_r() implementations are
consistent in their locking mechanisms [1,2].  As such, I would expect
readdir() to be equally as safe as readdir_r() for their users.  As
you noted, there does not appear to be any documented distinction
within their man pages [3,4] with regards to thread safety and it
seems reasonable that they would have documented these limitations, if
present.

[1] FreeBSD: 
https://svnweb.freebsd.org/base/head/lib/libc/gen/readdir.c?view=markup#l98
[2] NetBSD: 
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/gen/readdir.c?rev=1.25.6.1=text/x-cvsweb-markup
[3] FreeBSD readdir manpage:
https://www.freebsd.org/cgi/man.cgi?query=readdir=3
[4] NetBSD readdir manpage: http://netbsd.gw.com/cgi-bin/man-cgi?readdir

Are there other known supported libc implementations?

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/2] xen-blkfront: don't call talk_to_blkback when already connected to blkback

[Konrad Rzeszutek Wilk]

On Tue, May 31, 2016 at 04:59:16PM +0800, Bob Liu wrote:
> Sometimes blkfont may receive twice blkback_changed() notification after
> migration, then talk_to_blkback() will be called twice too and confused
> xen-blkback.

Could you enlighten the patch description by having some form of
state transition here? I am curious how you got the frontend
to get in XenbusStateConnected (via blkif_recover right) and then
the backend triggering the update once more?

Or is just a simple race - the backend moves from XenbusStateConnected->
XenbusStateConnected - which retriggers the frontend to hit in
blkback_changed the XenbusStateConnected state and go in there?
(That would be in conenct_ring changing the state). But I don't
see how the frontend_changed code get there as we have:

 770 /*
 771  * Ensure we connect even when two watches fire in
 772  * close succession and we miss the intermediate value
 773  * of frontend_state.
 774  */
 775 if (dev->state == XenbusStateConnected)
 776 break;
 777 

?

Now what about 'blkfront_connect' being called on the second time?

Ah, info->connected is probably by then in BLKIF_STATE_CONNECTED
(as blkif_recover changed) and we just reread the size of the disk.

Is that how about the flow goes?
> 
> Signed-off-by: Bob Liu 
> ---
>  drivers/block/xen-blkfront.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index ca13df8..01aa460 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -2485,7 +2485,8 @@ static void blkback_changed(struct xenbus_device *dev,
>   break;
>  
>   case XenbusStateConnected:
> - if (dev->state != XenbusStateInitialised) {
> + if ((dev->state != XenbusStateInitialised) &&
> + (dev->state != XenbusStateConnected)) {
>   if (talk_to_blkback(dev, info))
>   break;
>   }
> -- 
> 2.7.4
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [qemu-upstream-4.3-testing test] 94996: trouble: blocked/broken

[osstest service owner]

flight 94996 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94996/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927

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-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  115 days
Testing same since93977  2016-05-10 11:09:16 Z   21 days   90 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

[Xen-devel] [xen-unstable-smoke test] 95081: tolerable all pass - PUSHED

[osstest service owner]

flight 95081 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95081/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  1dda826420fff634983e94f97fb8411486acda0d
baseline version:
 xen  8b3d6858ecbe5f958f45ac5d8e5da6fa5a18266d

Last test of basis94956  2016-05-30 13:00:53 Z1 days
Testing same since95081  2016-05-31 18:00:57 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Roger Pau Monné 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt 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 :

+ branch=xen-unstable-smoke
+ revision=1dda826420fff634983e94f97fb8411486acda0d
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
1dda826420fff634983e94f97fb8411486acda0d
+ branch=xen-unstable-smoke
+ revision=1dda826420fff634983e94f97fb8411486acda0d
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.6-testing
+ '[' x1dda826420fff634983e94f97fb8411486acda0d = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local 

Re: [Xen-devel] [PATCH 00/14] Xen ARM DomU ACPI support

[Konrad Rzeszutek Wilk]

On Tue, May 31, 2016 at 12:43:22PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao 
> 
> The design of this feature is described as below.
> Firstly, the toolstack (libxl) generates the ACPI tables according the
> number of vcpus and gic controller.

CC-ing Boris - who has been working on exposing ACPI tables
for PVH guests.

Is there some way of re-using some of the code? 
> 
> Then, it copies these ACPI tables to DomU memory space and passes
> them to UEFI firmware through the "ARM multiboot" protocol.
> 
> At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol
> and installs these tables like the usual way and passes both ACPI and DT
> information to the Xen DomU.
> 
> Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT tables
> since it's enough now.
> 
> This has been tested using guest kernel with the Dom0 ACPI support
> patches which could be fetched from:
> https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen
> 
> Shannon Zhao (14):
>   libxl/arm: Fix the function name in error log
>   libxl/arm: Factor out codes for generating DTB
>   libxc: Add placeholders for ACPI tables blob and size
>   tools: add ACPI tables relevant definitions
>   libxl/arm: Construct ACPI GTDT table
>   libxl/arm: Construct ACPI FADT table
>   libxl/arm: Construct ACPI DSDT table
>   libxl/arm: Construct ACPI MADT table
>   libxl/arm: Construct ACPI XSDT table
>   libxl/arm: Construct ACPI RSDP table
>   libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ
>   libxl/arm: Add ACPI module
>   libxl/arm: initialize memory information of ACPI blob
>   libxc/xc_dom_core: Copy ACPI tables to guest memory space
> 
>  tools/libxc/include/acpi_defs.h | 277 
>  tools/libxc/include/xc_dom.h|  17 ++
>  tools/libxc/xc_dom_arm.c|  16 +-
>  tools/libxc/xc_dom_core.c   |  59 +++
>  tools/libxl/libxl_arm.c | 345 
> +++-
>  5 files changed, 706 insertions(+), 8 deletions(-)
>  create mode 100644 tools/libxc/include/acpi_defs.h
> 
> -- 
> 2.0.4
> 
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.7] libxl: keep PoD target adjustment by memory fudge after reload_domain_config()

[George Dunlap]

On Tue, May 31, 2016 at 6:42 PM, Wei Liu  wrote:
> From: Vitaly Kuznetsov 
>
> Commit 56fb5fd623 ("libxl: adjust PoD target by memory fudge, too")
> introduced target_memkb adjustment for HVM PoD domains on create. The
> adjustment is however being reset on reload_domain_config() (e.g. when
> we reboot the guest).

It was determined that all of the following...

>  For example:
>
> I'm trying to create HVM PoD domain with the following settings:
> memory=1024
> maxmem=4096
> When the domain boots for the first time I see the following in Xen:
>
> (XEN) nr_pages=262145 ... max_pages=262400 (looks good)
>
> When I reboot the domain I see the following:
> (XEN) nr_pages=261889 ... max_pages=262144  (oops)
>
> After second reboot:
> (XEN) nr_pages=261633 ... max_pages=261888 (even less)
>
> And eventually the domain crashes with "p2m_pod_demand_populate: Dom4 out of
> PoD memory! (tot=261377 ents=787200 dom4)".

has actually nothing to do with this patch; and that actually,
contrary to the description above, the problem is that the adjustment
is *not* being reset.

A better description would be something like this:

---
Commit 56fb5fd623 ("libxl: adjust PoD target by memory fudge, too")
introduced target_memkb adjustment for HVM PoD domains on create,
wherein
the value it wrote to target is always 1MiB lower than the actual
target_memkb.  Unfortunately, on reboot, it is this value which is
read *unmodified* to feed into the next domain creation; from which
1MiB is subtracted *again*.  This means that any guest which reboots
with memory < maxmem will have its memory target decreased by 1MiB on
every boot.

This patch makes it so that when reading target on reboot, we adjust
the value we read *up* by 1MiB, so that the domain will be build with
the appropriate amount of memory and the target will remain the same
after reboot.

This is still not quite a complete fix, as the 1MiB offset is only
subtracted when creating or rebooting; it is not subtracted when 'xl
set-memory' is called.  But it will prevent any situations where
memory is continually increased or decreased.  A better fix will have
to wait until after the release.
---

 -George

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[osstest service owner]

flight 94993 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94993/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 94748
 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 94748

version targeted for testing:
 ovmf 2f7b34b20842fcc485b39c0e1e91313c47b4d090
baseline version:
 ovmf dc99315b8732b6e3032d01319d3f534d440b43d0

Last test of basis94748  2016-05-24 22:43:25 Z6 days
Failing since 94750  2016-05-25 03:43:08 Z6 days   20 attempts
Testing same since94993  2016-05-31 13:42:33 Z0 days1 attempts


People who touched revisions under test:
  Cohen, Eugene 
  Dandan Bi 
  Darbin Reyes 
  Eugene Cohen 
  Fu Siyuan 
  Fu, Siyuan 
  Gary Lin 
  Hao Wu 
  Jeff Fan 
  Jiaxin Wu 
  Katie Dellaquila 
  Laszlo Ersek 
  Liming Gao 
  Marvin H?user 
  Marvin Haeuser 
  Maurice Ma 
  Michael Zimmermann 
  Star Zeng 
  Yonghong Zhu 

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



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.

(No revision log; it would be 754 lines long.)

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Build problems with xen 4.7

[George Dunlap]

On Fri, May 13, 2016 at 4:23 PM, Konrad Rzeszutek Wilk
 wrote:
> On Fri, May 13, 2016 at 03:25:52PM +0100, M A Young wrote:
>> On Fri, 13 May 2016, Jan Beulich wrote:
>>
>> > >>> On 13.05.16 at 15:49,  wrote:
>> > > ...
>> > >
>> > > Still an issue - with 4.7.0-rc1.
>> >
>> > And I don't recall anyone having contributed a fix/workaround.
>> >
>> > > If I do:
>> > >
>> > > $export CFLAGS=" "'
>> > > $make
>> > >
>> > > I end up with:
>> > > gcc -E -O1 -fno-omit-frame-pointer -m64 -DBUILD_ID -g 
>> > > -fno-strict-aliasing -std=gnu99
>> > >[...]
>> > > :0:0: error: "__OBJECT_FILE__" redefined [-Werror]
>> > > :0:0: note: this is the location of the previous definition
>> > > :0:0: error: "__OBJECT_LABEL__" redefined [-Werror]
>> > > :0:0: note: this is the location of the previous definition
>> > > cc1: all warnings being treated as errors
>> > > Makefile:62: recipe for target 'compat/callback.i' failed
>> >
>> > My previous recommendation stands: Then just don't do this.
>>
>> I hacked around it for my test builds (eg. see my test build at
>> https://copr.fedorainfracloud.org/coprs/myoung/xentest/build/204111/
>> ) by not setting CFLAGS in the environment, but by instead adding the
>> recommended Fedora RPM settings into config/StdGNU.mk via a different
>> environment variable.
>
> ah:
>
> --- xen-4.7.0/config/StdGNU.mk.orig 2016-04-15 22:56:52.191227591 +0100
> +++ xen-4.7.0/config/StdGNU.mk  2016-04-15 23:01:40.978829756 +0100
> @@ -37,6 +37,12 @@
>
>  ifneq ($(debug),y)
>  CFLAGS += -O2 -fomit-frame-pointer -fno-tree-coalesce-vars
> +ifeq ($(XEN_TARGET_ARCH),x86_64)
> +#might be cross-compiling so strip out possible x86_32 options
> +CFLAGS += $(shell echo $(CFLAGS_EXTRA) | sed -e 's/-m32//g' -e 
> 's/-march=i686//g' -e 's/-mtune=atom//g')
> +else
> +CFLAGS += $(CFLAGS_EXTRA)
> +endif
>  else
>  # Less than -O1 produces bad code and large stack frames
>  CFLAGS += -O1 -fno-omit-frame-pointer
>
>
> And in the spec file:
> export CFLAGS_EXTRA="$RPM_OPT_FLAGS"
> make %{?_smp_mflags} %{?efi_flags} prefix=/usr dist-xen

Something like the above solution worked for me (CentOS 7 -- I'm
suspecting a similar pattern here).

Adding CFLAGS="${RPM_OPT_FLAGS}" to my ./configure line made some
noises as though it was going to work, but none of it actually ended
up passed to the compiler (whereas it did with the little patch Konrad
posted).

Are we going to provide a proper way for distros to add flags like
this without having to hack the build system?

 -George

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC v2] dma-mapping: Use unsigned long for dma_attrs

[Konrad Rzeszutek Wilk]

On Mon, May 30, 2016 at 01:54:06PM +0200, Krzysztof Kozlowski wrote:
> The dma-mapping core and the implementations do not change the
> DMA attributes passed by pointer.  Thus the pointer can point to const
> data.  However the attributes do not have to be a bitfield. Instead
> unsigned long will do fine:
> 
> 1. This is just simpler.  Both in terms of reading the code and setting
>attributes.  Instead of initializing local attributes on the stack and
>passing pointer to it to dma_set_attr(), just set the bits.
> 
> 2. It brings safeness and checking for const correctness because the
>attributes are passed by value.


.. why not go the next step a do an enum? Perhaps that should be mentioned
as part of the description?

Thanks.
> 
> Please have in mind that this is RFC, not finished yet.  Only ARM and
> ARM64 are fixed (and not everywhere).
> However other API users also have to be converted which is quite
> intrusive.  I would rather avoid it until the overall approach is
> accepted.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  Documentation/DMA-API.txt |   2 +-
>  Documentation/DMA-attributes.txt  |   2 +-
>  arch/arm/include/asm/dma-mapping.h|  13 ++--
>  arch/arm/include/asm/xen/page-coherent.h  |  16 ++---
>  arch/arm/mm/dma-mapping.c |  82 +++
>  arch/arm/xen/mm.c |   4 +-
>  arch/arm64/mm/dma-mapping.c   |  57 
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   2 +-
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c   |   1 -
>  drivers/gpu/drm/exynos/exynos_drm_gem.c   |  20 +++---
>  drivers/gpu/drm/exynos/exynos_drm_gem.h   |   2 +-
>  drivers/iommu/dma-iommu.c |   6 +-
>  drivers/xen/swiotlb-xen.c |  14 ++--
>  include/linux/dma-attrs.h |  71 
>  include/linux/dma-iommu.h |   6 +-
>  include/linux/dma-mapping.h   | 105 
> +-
>  include/linux/swiotlb.h   |  10 +--
>  include/xen/swiotlb-xen.h |  12 ++--
>  lib/dma-noop.c|   9 +--
>  lib/swiotlb.c |  13 ++--
>  20 files changed, 195 insertions(+), 252 deletions(-)
>  delete mode 100644 include/linux/dma-attrs.h
> 
> diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
> index 45ef3f279c3b..0b55cb7c5aaa 100644
> --- a/Documentation/DMA-API.txt
> +++ b/Documentation/DMA-API.txt
> @@ -391,7 +391,7 @@ without the _attrs suffixes, except that they pass an 
> optional
>  struct dma_attrs*.
>  
>  struct dma_attrs encapsulates a set of "DMA attributes". For the
> -definition of struct dma_attrs see linux/dma-attrs.h.
> +definition of struct dma_attrs see linux/dma-mapping.h.
>  
>  The interpretation of DMA attributes is architecture-specific, and
>  each attribute should be documented in Documentation/DMA-attributes.txt.
> diff --git a/Documentation/DMA-attributes.txt 
> b/Documentation/DMA-attributes.txt
> index e8cf9cf873b3..2d455a5cf671 100644
> --- a/Documentation/DMA-attributes.txt
> +++ b/Documentation/DMA-attributes.txt
> @@ -2,7 +2,7 @@
>   ==
>  
>  This document describes the semantics of the DMA attributes that are
> -defined in linux/dma-attrs.h.
> +defined in linux/dma-mapping.h.
>  
>  DMA_ATTR_WRITE_BARRIER
>  --
> diff --git a/arch/arm/include/asm/dma-mapping.h 
> b/arch/arm/include/asm/dma-mapping.h
> index a83570f10124..d009f7911ffc 100644
> --- a/arch/arm/include/asm/dma-mapping.h
> +++ b/arch/arm/include/asm/dma-mapping.h
> @@ -5,7 +5,6 @@
>  
>  #include 
>  #include 
> -#include 
>  #include 
>  
>  #include 
> @@ -174,7 +173,7 @@ static inline void dma_mark_clean(void *addr, size_t 
> size) { }
>   * to be the device-viewed address.
>   */
>  extern void *arm_dma_alloc(struct device *dev, size_t size, dma_addr_t 
> *handle,
> -gfp_t gfp, struct dma_attrs *attrs);
> +gfp_t gfp, unsigned long attrs);
>  
>  /**
>   * arm_dma_free - free memory allocated by arm_dma_alloc
> @@ -191,7 +190,7 @@ extern void *arm_dma_alloc(struct device *dev, size_t 
> size, dma_addr_t *handle,
>   * during and after this call executing are illegal.
>   */
>  extern void arm_dma_free(struct device *dev, size_t size, void *cpu_addr,
> -  dma_addr_t handle, struct dma_attrs *attrs);
> +  dma_addr_t handle, unsigned long attrs);
>  
>  /**
>   * arm_dma_mmap - map a coherent DMA allocation into user space
> @@ -208,7 +207,7 @@ extern void arm_dma_free(struct device *dev, size_t size, 
> void *cpu_addr,
>   */
>  extern int arm_dma_mmap(struct device *dev, struct vm_area_struct *vma,
>   void *cpu_addr, dma_addr_t dma_addr, size_t size,
> - struct dma_attrs *attrs);
> + unsigned long 

Re: [Xen-devel] [PATCH 1/2] libfsimage: replace deprecated readdir_r() with readdir()

[Wei Liu]

On Tue, May 31, 2016 at 11:43:13AM -0400, Chris Patterson wrote:
> On Tue, May 31, 2016 at 6:42 AM, George Dunlap  
> wrote:
> > On Mon, May 30, 2016 at 3:32 AM, Chris Patterson  wrote:
> >> From: Chris Patterson 
> >>
> >> Replace the usage of readdir_r() with readdir() to address
> >> a compilation error due to the deprecation of readdir_r.
> >>
> >> glibc has deprecated this for their next release (2.24):
> >> https://sourceware.org/bugzilla/show_bug.cgi?id=19056
> >>
> >> Signed-off-by: Chris Patterson 
> >
> > Thanks for the patch, Chris.  A bit more background would have been
> > helpful -- I did some searching and found a description[1] which says:
> >
> 
> Thank you. I should have added these details in the commit message or cover.
> 
> > In the current POSIX.1 specification (POSIX.1-2008), readdir(3) is
> > not required to be thread-safe.  However, in modern
> > implementations (including the glibc implementation), concurrent
> > calls to readdir(3) that specify different directory streams are
> > thread-safe.  Therefore, the use of readdir_r() is generally
> > unnecessary in multithreaded programs.  In cases where multiple
> > threads must read from the same directory stream, using readdir(3)
> > with external synchronization is still preferable to the use of
> > readdir_r(), for the reasons given in the points above.
> >
> > The use of the specific directory stream is single-threaded, so for
> > glibc, it looks like using readdir() will be safe.  But libxl needs to
> > be able to build on a number of libc's that are not glibc and still be
> > thread-safe.  So we need to either 1) verify that readdir() is thread
> > safe on all libc's against which we may compile, or 2) add some
> 
> Is there a list of supported libc libraries?  I can look into it and
> provide more definitive answers if there are.
> 

We at least care about FreeBSD and NetBSD. Sadly their manuaks don't
provide statement regarding thread safety for readdir and readdir_r.
It's better to err on the safe side.

Wei.

> > #ifdef-ery to switch to readdir_r() on systems unless we know it's
> > thread-safe.
> >
> > I'm less familiar with best practices for this kind of thing -- Ian,
> > do you have an idea?
> >
> > Thanks again for raising this, Chris.
> >
> >  -George
> >
> > [1] http://man7.org/linux/man-pages/man3/readdir_r.3.html
> >

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen/Makefile: quote HOSTCC and HOSTCXX args

[Wei Liu]

On Tue, May 31, 2016 at 10:22:41AM -0600, Jan Beulich wrote:
> >>> On 31.05.16 at 17:13,  wrote:
> > From: Chris Patterson 
> > 
> > In some cross-compilation environments, the CC/CXX variables may
> > expand out to more than one argument (to include things
> > like --sysroot=...).  Quote these to safely pass along.
> > 
> > Signed-off-by: Chris Patterson 
> 
> Acked-by: Jan Beulich 
> 
> Wei, do we want this in 4.7?

Yes.

I've queued this up.

Wei.

> 
> Jan
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH for-4.7] libxl: keep PoD target adjustment by memory fudge after reload_domain_config()

[Wei Liu]

From: Vitaly Kuznetsov 

Commit 56fb5fd623 ("libxl: adjust PoD target by memory fudge, too")
introduced target_memkb adjustment for HVM PoD domains on create. The
adjustment is however being reset on reload_domain_config() (e.g. when
we reboot the guest). For example:

I'm trying to create HVM PoD domain with the following settings:
memory=1024
maxmem=4096
When the domain boots for the first time I see the following in Xen:

(XEN) nr_pages=262145 ... max_pages=262400 (looks good)

When I reboot the domain I see the following:
(XEN) nr_pages=261889 ... max_pages=262144  (oops)

After second reboot:
(XEN) nr_pages=261633 ... max_pages=261888 (even less)

And eventually the domain crashes with "p2m_pod_demand_populate: Dom4 out of
PoD memory! (tot=261377 ents=787200 dom4)".

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: Wei Liu 
---
Cc: Ian Jackson 
Cc: George Dunlap 
---
 tools/libxl/libxl.c  |  8 
 tools/libxl/libxl_dom.c  | 10 ++
 tools/libxl/libxl_internal.h | 15 +++
 3 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index b9d855b..5aaf02d 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -7229,12 +7229,12 @@ int libxl_retrieve_domain_configuration(libxl_ctx *ctx, 
uint32_t domid,
 LOG(ERROR, "fail to get memory target for domain %d", domid);
 goto out;
 }
-/* Target memory in xenstore is different from what user has
- * asked for. The difference is video_memkb. See
- * libxl_set_memory_target.
+
+/* libxl__get_targetmem_difference() calculates the difference from
+ * what is in xenstore to what we have in the domain build info.
  */
 d_config->b_info.target_memkb = target_memkb +
-d_config->b_info.video_memkb;
+libxl__get_targetmem_difference(gc, _config->b_info);
 
 d_config->b_info.max_memkb = max_memkb;
 }
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 9b20cf5..20fd458 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -490,7 +490,6 @@ int libxl__build_post(libxl__gc *gc, uint32_t domid,
 xs_transaction_t t;
 char **ents;
 int i, rc;
-int64_t mem_target_fudge;
 
 if (info->num_vnuma_nodes && !info->num_vcpu_soft_affinity) {
 rc = set_vnuma_affinity(gc, domid, info);
@@ -523,17 +522,12 @@ int libxl__build_post(libxl__gc *gc, uint32_t domid,
 }
 }
 
-mem_target_fudge =
-(info->type == LIBXL_DOMAIN_TYPE_HVM &&
- info->max_memkb > info->target_memkb)
-? LIBXL_MAXMEM_CONSTANT : 0;
-
 ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2, sizeof(char *));
 ents[0] = "memory/static-max";
 ents[1] = GCSPRINTF("%"PRId64, info->max_memkb);
 ents[2] = "memory/target";
-ents[3] = GCSPRINTF("%"PRId64, info->target_memkb - info->video_memkb
-- mem_target_fudge);
+ents[3] = GCSPRINTF("%"PRId64, info->target_memkb -
+libxl__get_targetmem_difference(gc, info));
 ents[4] = "memory/videoram";
 ents[5] = GCSPRINTF("%"PRId64, info->video_memkb);
 ents[6] = "domid";
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index fac5751..59df53d 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -4107,6 +4107,21 @@ static inline void libxl__update_config_vtpm(libxl__gc 
*gc,
 libxl_uuid_copy(CTX, >uuid, >uuid);
 }
 
+/* Target memory in xenstore is different from what user has
+ * asked for. The difference is video_memkb + (possible) fudge.
+ * See libxl_set_memory_target.
+ */
+static inline
+uint64_t libxl__get_targetmem_difference(libxl__gc *gc,
+ const libxl_domain_build_info *info)
+{
+int64_t mem_target_fudge = (info->type == LIBXL_DOMAIN_TYPE_HVM &&
+info->max_memkb > info->target_memkb)
+? LIBXL_MAXMEM_CONSTANT : 0;
+
+return info->video_memkb + mem_target_fudge;
+}
+
 /* Macros used to compare device identifier. Returns true if the two
  * devices have same identifier. */
 #define COMPARE_DEVID(a, b) ((a)->devid == (b)->devid)
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] xen: xenbus: Remove create_workqueue

[Tejun Heo]

On Tue, May 31, 2016 at 10:26:30PM +0530, Bhaktipriya Shridhar wrote:
> System workqueues have been able to handle high level of concurrency
> for a long time now and there's no reason to use dedicated workqueues
> just to gain concurrency.  Replace dedicated xenbus_frontend_wq with the
> use of system_wq.
> 
> Unlike a dedicated per-cpu workqueue created with create_workqueue(),
> system_wq allows multiple work items to overlap executions even on
> the same CPU; however, a per-cpu workqueue doesn't have any CPU
> locality or global ordering guarantees unless the target CPU is
> explicitly specified and the increase of local concurrency shouldn't
> make any difference.
> 
> In this case, there is only a single work item, increase of concurrency
> level by switching to system_wq should not make any difference.
> 
> Signed-off-by: Bhaktipriya Shridhar 

Acked-by: Tejun Heo 

Thanks.

-- 
tejun

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen/arm: setup: initialize xenheap mappings after boot pages avaiable

[Julien Grall]

Hi Peng,

On 31/05/16 10:58, Peng Fan wrote:



So, need to make sure boot pages are ready before setup xenheap mappings.


init_boot_pages is using mfn_to_virt (see bootmem_region_add), which cannot
work until xenheap_mfn_start is initialized. This is done by
setup_xenheap_mappings.


My bad. I did not catch this point. Thanks for correcting me.



I would be happy to give you hint on how to solve this, but I am not sure to
fully understand your issue. Can you give more details?


I did not met issue on my platform. I just think the logic of this piece code
may cause errors on platform with large memory (>512GB).

How about the following patch?
First loop all the memory banks and calculate ram_size/ram_start/ram_end,
then set xenheap_virt_end/start and xenheap_mfn_end.
Now readly for init boot pages and setup_xenheap_mappings.


Have you tested this patch? I would be surprised to see it working.



diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index dcb23b7..d3a3af3 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -635,13 +635,24 @@ static void __init setup_mm(unsigned long dtb_paddr, 
size_t dtb_size)
  paddr_t bank_start = bootinfo.mem.bank[bank].start;
  paddr_t bank_size = bootinfo.mem.bank[bank].size;
  paddr_t bank_end = bank_start + bank_size;
-paddr_t s, e;

  ram_size = ram_size + bank_size;
  ram_start = min(ram_start,bank_start);
  ram_end = max(ram_end,bank_end);
+}

-setup_xenheap_mappings(bank_start>>PAGE_SHIFT, bank_size>>PAGE_SHIFT);
+total_pages += ram_size >> PAGE_SHIFT;
+
+xenheap_virt_end = XENHEAP_VIRT_START + ram_end - ram_start;


XENHEAP_VIRT_START will be replaced by xenheap_virt_start which is not 
initialized at this time. It is done by setup_xenheap_mappings.


In any case, even if the variable are correctly setup the underlying 
page table are not present.


The easiest way I can think to fix the problem is splitting the bank 
with chunk of 512GB and calling setup_xenheap_mappings, init_boot_pages 
for each chunk.


It is not the nicest way, so I will happy if you find a better one.

Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 5/8] arm/vm_event: get/set registers

[Tamas K Lengyel]

On May 31, 2016 01:48, "Jan Beulich"  wrote:
>
> >>> On 30.05.16 at 21:47,  wrote:
> > On Mon, May 30, 2016 at 5:50 AM, Jan Beulich  wrote:
> > On 30.05.16 at 00:37,  wrote:
> >>> +struct vm_event_regs_arm32 {
> >>> +uint32_t r0_usr;
> >>> +uint32_t r1_usr;
> >>> +uint32_t r2_usr;
> >>> +uint32_t r3_usr;
> >>> +uint32_t r4_usr;
> >>> +uint32_t r5_usr;
> >>> +uint32_t r6_usr;
> >>> +uint32_t r7_usr;
> >>> +uint32_t r8_usr;
> >>> +uint32_t r9_usr;
> >>> +uint32_t r10_usr;
> >>> +uint32_t r12_usr;
> >>> +uint32_t lr_usr;
> >>> +uint32_t fp;
> >>> +uint32_t pc;
> >>> +uint32_t sp_usr;
> >>> +uint32_t sp_svc;
> >>> +uint32_t spsr_svc;
> >>> +};
> >>
> >> It would seem more natural for the "ordinary" registers to be
> >> arranged in the numerical sequence, i.e. fp, r12, sp, lr, pc.
> >
> > Not sure I follow.
>
> For one it is quite natural for someone looking at a sequence of
> register values to assume / expect them to be in natural order.
> And then, having them in natural (numeric) order allows e.g.
> extracting the register identifying bits from an instruction to use
> them as an array index into (part of) this structure.
>
> (For some background: I've been bitten a number of times by
> people sorting x86 registers alphabetically instead or naturally,
> i.e. EAX, EBX, ECX, EDX instead of EAX, ECX, EDX, EBX).

I see, however I believe that would be a very careless use of this struct
from the user as the register sizes are not even necessarily match the
architecture. For example we only define the 64bit x86 registers, so trying
to access it as an array of 32bit registers wouldn't work at all. Plus we
are not doing a full set of registers, and I rather not imply that every
element in the "natural sequence" is present. It may be, it may be not.

>
> >>> +struct vm_event_regs_arm64 {
> >>> +uint64_t x0;
> >>> +uint64_t x1;
> >>> +uint64_t x2;
> >>> +uint64_t x3;
> >>> +uint64_t x4;
> >>> +uint64_t x5;
> >>> +uint64_t x6;
> >>> +uint64_t x7;
> >>> +uint64_t x8;
> >>> +uint64_t x9;
> >>> +uint64_t x10;
> >>> +uint64_t x16;
> >>> +uint64_t lr;
> >>> +uint64_t fp;
> >>> +uint64_t pc;
> >>> +uint64_t sp_el0;
> >>> +uint64_t sp_el1;
> >>> +uint32_t spsr_el1;
> >>> +uint32_t _pad;
> >>> +};
> >>
> >> My ARM knowledge is certainly quite limited, but the incomplete set
> >> of GPRs here is quite obvious: Is there a reason to not make all of
> >> them available here? And if there is, could the criteria of which
> >> registers got put here please be documented in a comment (so that
> >> the next person noticing the incomplete set won't ask again)?
> >
> > There already is a comment in place that explains why we are not
> > sending the full set of registers here.
>
> I've just gone through the entire patch again, and I didn't find any.
> Are you perhaps referring to "Using custom vCPU structs (i.e. not
> hvm_hw_cpu) for both x86 and ARM so as to not fill the vm_event
> ring buffer too quickly"? If so, that's irrelevant here: It explains why
> e.g. floating point registers don't get sent, but it doesn't explain in
> any way why some GPRs are more important than others.
>
> >> I'm also puzzled by fp and lr - I'm not aware of registers of those
> >> names (and gas also doesn't accept them afaict).
> >
> > Not sure why but Xen names x29 fp and x30 lr. See
> > include/asm-arm/arm64/processor.h.
>
> See Julien's reply.
>
> Jan
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v4] AMD IOMMU: Introduce support for IVHD block type 11h

[suravee.suthikulpanit]

From: Suravee Suthikulpanit 

Along with the IVHD block type 10h, newer AMD platforms also come with
types 11h, which is a superset of the older one. Having multiple IVHD
block types in the same platform allows backward compatibility of newer
systems to work with existing drivers.  The driver should only parse
the highest-level (newest) type of IVHD block that it can support.
However, the current driver returns error when encounters with unknown
IVHD block type. This causes existing driver to unnecessarily fail IOMMU
initialization on new systems.

This patch introduces a new logic, which scans through IVRS table looking
for the highest-level supporsted IVHD block type. It also adds support
for the new IVHD block type 11h. More information about the IVHD type 11h
can be found in the AMD I/O Virtualization Technology (IOMMU) Specification
rev 2.62.

http://support.amd.com/TechDocs/48882_IOMMU.pdf

Reviewed-by: Jan Beulich 
Reviewed-by: Andrew Cooper 
Signed-off-by: Suravee Suthikulpanit 
---

Changes from V3:
  * Minor stray space changes.
  * Getting rid of unnecessary default case in swtich statement.
  * Adding reviewed by Jan and Andrew.

Thanks all for review comments.

Suravee

 xen/drivers/passthrough/amd/iommu_acpi.c  | 134 +-
 xen/drivers/passthrough/amd/iommu_init.c  |  10 +-
 xen/include/acpi/actbl2.h |   5 +-
 xen/include/asm-x86/amd-iommu.h   |   1 +
 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h |   1 +
 5 files changed, 106 insertions(+), 45 deletions(-)

diff --git a/xen/drivers/passthrough/amd/iommu_acpi.c 
b/xen/drivers/passthrough/amd/iommu_acpi.c
index 603c02e..200db2d 100644
--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -821,13 +821,27 @@ static u16 __init parse_ivhd_device_special(
 return dev_length;
 }
 
+static inline size_t
+get_ivhd_header_size(const struct acpi_ivrs_hardware *ivhd_block)
+{
+switch ( ivhd_block->header.type )
+{
+case ACPI_IVRS_TYPE_HARDWARE:
+return offsetof(struct acpi_ivrs_hardware, efr_image);
+case ACPI_IVRS_TYPE_HARDWARE_11H:
+return sizeof(struct acpi_ivrs_hardware);
+}
+return 0;
+}
+
 static int __init parse_ivhd_block(const struct acpi_ivrs_hardware *ivhd_block)
 {
 const union acpi_ivhd_device *ivhd_device;
 u16 block_length, dev_length;
+size_t hdr_size = get_ivhd_header_size(ivhd_block) ;
 struct amd_iommu *iommu;
 
-if ( ivhd_block->header.length < sizeof(*ivhd_block) )
+if ( ivhd_block->header.length < hdr_size )
 {
 AMD_IOMMU_DEBUG("IVHD Error: Invalid Block Length!\n");
 return -ENODEV;
@@ -845,7 +859,7 @@ static int __init parse_ivhd_block(const struct 
acpi_ivrs_hardware *ivhd_block)
 }
 
 /* parse Device Entries */
-block_length = sizeof(*ivhd_block);
+block_length = hdr_size;
 while ( ivhd_block->header.length >=
 (block_length + sizeof(struct acpi_ivrs_de_header)) )
 {
@@ -914,34 +928,6 @@ static int __init parse_ivhd_block(const struct 
acpi_ivrs_hardware *ivhd_block)
 return 0;
 }
 
-static int __init parse_ivrs_block(const struct acpi_ivrs_header *ivrs_block)
-{
-const struct acpi_ivrs_hardware *ivhd_block;
-const struct acpi_ivrs_memory *ivmd_block;
-
-switch ( ivrs_block->type )
-{
-case ACPI_IVRS_TYPE_HARDWARE:
-ivhd_block = container_of(ivrs_block, const struct acpi_ivrs_hardware,
-  header);
-return parse_ivhd_block(ivhd_block);
-
-case ACPI_IVRS_TYPE_MEMORY_ALL:
-case ACPI_IVRS_TYPE_MEMORY_ONE:
-case ACPI_IVRS_TYPE_MEMORY_RANGE:
-case ACPI_IVRS_TYPE_MEMORY_IOMMU:
-ivmd_block = container_of(ivrs_block, const struct acpi_ivrs_memory,
-  header);
-return parse_ivmd_block(ivmd_block);
-
-default:
-AMD_IOMMU_DEBUG("IVRS Error: Invalid Block Type!\n");
-return -ENODEV;
-}
-
-return 0;
-}
-
 static void __init dump_acpi_table_header(struct acpi_table_header *table)
 {
 int i;
@@ -978,6 +964,25 @@ static void __init dump_acpi_table_header(struct 
acpi_table_header *table)
 
 }
 
+#define to_ivhd_block(hdr) \
+container_of(hdr, const struct acpi_ivrs_hardware, header)
+#define to_ivmd_block(hdr) \
+container_of(hdr, const struct acpi_ivrs_memory, header)
+
+static inline bool_t is_ivhd_block(u8 type)
+{
+return (type == ACPI_IVRS_TYPE_HARDWARE ||
+type == ACPI_IVRS_TYPE_HARDWARE_11H);
+}
+
+static inline bool_t is_ivmd_block(u8 type)
+{
+return (type == ACPI_IVRS_TYPE_MEMORY_ALL ||
+type == ACPI_IVRS_TYPE_MEMORY_ONE ||
+type == ACPI_IVRS_TYPE_MEMORY_RANGE ||
+type == ACPI_IVRS_TYPE_MEMORY_IOMMU);
+}
+
 static int __init parse_ivrs_table(struct acpi_table_header *table)

Re: [Xen-devel] [PATCH] xen: xenbus: Remove create_workqueue

[David Vrabel]

On 27/05/16 19:50, Bhaktipriya Shridhar wrote:
> With concurrency managed workqueues, use of dedicated workqueues can be
> replaced by using system_wq. Drop xenbus_frontend_wq by using system_wq.
> 
> Since there is only a single work item, increase of concurrency level by
> switching to system_wq should not break anything.
> 
> Since the work item could be pending and the code expects it to run
> once scheduled, flush_work() has been used in xenbus_dev_suspend()

This says flush_work() but...
> 
> Signed-off-by: Bhaktipriya Shridhar 
> ---
>  drivers/xen/xenbus/xenbus_probe.c  |  2 ++
>  drivers/xen/xenbus/xenbus_probe_frontend.c | 15 +--
>  2 files changed, 3 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_probe.c 
> b/drivers/xen/xenbus/xenbus_probe.c
> index 33a31cf..bc97019 100644
> --- a/drivers/xen/xenbus/xenbus_probe.c
> +++ b/drivers/xen/xenbus/xenbus_probe.c
> @@ -592,6 +592,8 @@ int xenbus_dev_suspend(struct device *dev)
> 
>   DPRINTK("%s", xdev->nodename);
> 
> + cancel_work_sync(>work);

...cancel_work_sync() is called here.

David

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] Patch for qemu-trad build with recent gnutls not present/working for RELEASE-4.6.1 on Ubuntu 16.04?

[John McDermott]

Xen Developers,

On Ubuntu 16.04, when I clone from Xenbits and then checkout RELEASE-4.6.1, 
‘make world’ breaks
when it gets to qemu-xen-traditional, with the error shown below. This looks 
like a problem that was patched back at the end of April, but somehow is not 
taking effect for the older code. Everything works fine if I just clone from 
Xenbits, .\configure, etc, without checking out RELEASE-4.6.1.

Sincerely,

John

- - - - - - -

  LINK  i386-dm/qemu-dm
../libqemu_common.a(vnc.o): In function `vnc_start_tls':
/home/mc/qqdebug/xen/tools/qemu-xen-traditional-dir/vnc.c:2180: undefined 
reference to `gnutls_kx_set_priority'
/home/mc/qqdebug/xen/tools/qemu-xen-traditional-dir/vnc.c:2187: undefined 
reference to `gnutls_certificate_type_set_priority'
/home/mc/qqdebug/xen/tools/qemu-xen-traditional-dir/vnc.c:2194: undefined 
reference to `gnutls_protocol_set_priority'
collect2: error: ld returned 1 exit status
Makefile:740: recipe for target 'qemu-dm' failed



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] 4.7 qemu regression: HVM guests fail to boot from xvda

[Konrad Rzeszutek Wilk]

On Tue, May 31, 2016 at 01:16:14PM +0200, Olaf Hering wrote:
> On Tue, May 31, George Dunlap wrote:
> 
> > On Mon, May 30, 2016 at 9:42 PM, Olaf Hering  wrote:
> > > With staging-4.6 this domU boots from xvda, qemu creates an emulated
> > > disk. With staging no disk is found, unless the name is changed to hda.
> > > Looks like qemu-2.6 does not handle xvda either.
> > 
> > This was intentional; see this thread:
> > 
> > https://marc.info/?i=<1444820717-25565-1-git-send-email-anthony.per...@citrix.com>
> > 
> > The idea was to make it possible to create an HVM guest with no
> > emulated disks for guest booting with OVMF which contains PV drivers.
> 
> This breaks the domU becasue it changes its device names from 'xvd' to
> 'hd' if a xenlinux based kernel is used in domU.
> In other words: every SUSE domU out there.

And every Solaris domU too.
> 
> Olaf
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [qemu-upstream-4.3-testing test] 94989: trouble: blocked/broken

[osstest service owner]

flight 94989 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94989/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927

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-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  115 days
Testing same since93977  2016-05-10 11:09:16 Z   21 days   89 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

Re: [Xen-devel] [PATCH] kexec: allow relaxed placement specification via command line

[David Vrabel]

On 31/05/16 13:44, Jan Beulich wrote:
 On 31.05.16 at 12:30,  wrote:
>> On 30/05/16 14:48, Jan Beulich wrote:
>>> --- a/xen/arch/x86/setup.c
>>> +++ b/xen/arch/x86/setup.c
>>> @@ -1044,13 +1044,19 @@ void __init noreturn __start_xen(unsigne
>>>  }
>>>  
>>>  #ifdef CONFIG_KEXEC
>>> -/* Don't overlap with modules. */
>>> -e = consider_modules(s, e, PAGE_ALIGN(kexec_crash_area.size),
>>> - mod, mbi->mods_count, -1);
>>> -if ( !kexec_crash_area.start && (s < e) )
>>
>> I think we want a comment here.
>>
>> /*
>>  * Looking backwards from the crash area limit, find a large enough
>>  * crash area that does not overlap with modules.
>>  */
> 
> Sure, added.
> 
>>> +while ( !kexec_crash_area.start )
>>
>> Does this mean that if an @ is specified we no longer check for
>> overlapping modules?
> 
> We didn't do any more checking before. If you look at the old
> code above, we called consider_modules() only to possibly alter
> e. All the rest of the old code was similarly dependent upon
> !kexec_crash_area.start. That other case is being taken care
> of earlier anyway - see kexec_reserve_area()'s first invocation.
> 
> But yes, it looks like there's an overlap check missing there (iiuc
> relevant really only for the initrd, as that's the only thing the
> memory of which may not get copied but simply directly handed
> to Dom0).

Ok.  Any additional improvement can be done later so if you add the comment,

Reviewed-by: David Vrabel 

David

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/2] libfsimage: replace deprecated readdir_r() with readdir()

[Chris Patterson]

On Tue, May 31, 2016 at 6:42 AM, George Dunlap  wrote:
> On Mon, May 30, 2016 at 3:32 AM, Chris Patterson  wrote:
>> From: Chris Patterson 
>>
>> Replace the usage of readdir_r() with readdir() to address
>> a compilation error due to the deprecation of readdir_r.
>>
>> glibc has deprecated this for their next release (2.24):
>> https://sourceware.org/bugzilla/show_bug.cgi?id=19056
>>
>> Signed-off-by: Chris Patterson 
>
> Thanks for the patch, Chris.  A bit more background would have been
> helpful -- I did some searching and found a description[1] which says:
>

Thank you. I should have added these details in the commit message or cover.

> In the current POSIX.1 specification (POSIX.1-2008), readdir(3) is
> not required to be thread-safe.  However, in modern
> implementations (including the glibc implementation), concurrent
> calls to readdir(3) that specify different directory streams are
> thread-safe.  Therefore, the use of readdir_r() is generally
> unnecessary in multithreaded programs.  In cases where multiple
> threads must read from the same directory stream, using readdir(3)
> with external synchronization is still preferable to the use of
> readdir_r(), for the reasons given in the points above.
>
> The use of the specific directory stream is single-threaded, so for
> glibc, it looks like using readdir() will be safe.  But libxl needs to
> be able to build on a number of libc's that are not glibc and still be
> thread-safe.  So we need to either 1) verify that readdir() is thread
> safe on all libc's against which we may compile, or 2) add some

Is there a list of supported libc libraries?  I can look into it and
provide more definitive answers if there are.

> #ifdef-ery to switch to readdir_r() on systems unless we know it's
> thread-safe.
>
> I'm less familiar with best practices for this kind of thing -- Ian,
> do you have an idea?
>
> Thanks again for raising this, Chris.
>
>  -George
>
> [1] http://man7.org/linux/man-pages/man3/readdir_r.3.html
>

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH] xen/Makefile: quote HOSTCC and HOSTCXX args

[Chris Patterson]

From: Chris Patterson 

In some cross-compilation environments, the CC/CXX variables may
expand out to more than one argument (to include things
like --sysroot=...).  Quote these to safely pass along.

Signed-off-by: Chris Patterson 
---
 xen/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/Makefile b/xen/Makefile
index 0d5f240..b59f95d 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -246,14 +246,14 @@ kconfig := silentoldconfig oldconfig config menuconfig 
defconfig \
randconfig
 .PHONY: $(kconfig)
 $(kconfig):
-   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) 
SRCARCH=$(SRCARCH) HOSTCC=$(HOSTCC) HOSTCXX=$(HOSTCXX) $@
+   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) 
SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" $@
 
 include/config/%.conf: include/config/auto.conf.cmd $(KCONFIG_CONFIG)
-   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) 
SRCARCH=$(SRCARCH) HOSTCC=$(HOSTCC) HOSTCXX=$(HOSTCXX) silentoldconfig
+   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) 
SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" silentoldconfig
 
 # Allow people to just run `make` as before and not force them to configure
 $(KCONFIG_CONFIG):
-   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) 
SRCARCH=$(SRCARCH) HOSTCC=$(HOSTCC) HOSTCXX=$(HOSTCXX) defconfig
+   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) 
SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" defconfig
 
 # Break the dependency chain for the first run
 include/config/auto.conf.cmd: ;
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [qemu-mainline test] 94983: regressions - trouble: broken/fail/pass

[osstest service owner]

flight 94983 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94983/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-qcow2  3 host-install(3)   broken REGR. vs. 94856
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail REGR. vs. 
94856
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail REGR. 
vs. 94856
 test-amd64-i386-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs. 
94856
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs. 
94856

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-localmigrate fail REGR. vs. 94856
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-localmigrate fail REGR. vs. 94856
 test-amd64-amd64-xl-rtds  9 debian-install   fail   like 94856

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuu07e070aac4eeb186905148461f331e43f2b828aa
baseline version:
 qemuud6550e9ed2e1a60d889dfb721de00d9a4e3bafbe

Last test of basis94856  2016-05-27 20:14:49 Z3 days
Testing same since94983  2016-05-31 09:40:12 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Drew Jones 
  Emilio G. Cota 
  Eric Blake 
  Fam Zheng 
  Michael Walle 
  Paolo Bonzini 
  Paul Durrant 
  Peter Lieven 
  Peter Maydell 
  Prasad J Pandit 
  xiaoqiang zhao 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 

Re: [Xen-devel] [PATCH RESEND 00/14] Xen ARM DomU ACPI support

[Shannon Zhao]

Hi Julien,

On 2016年05月31日 18:47, Julien Grall wrote:
> Hi Shannon,
> 
> On 31/05/16 06:02, Shannon Zhao wrote:
>> From: Shannon Zhao 
>>
>> The design of this feature is described as below.
>> Firstly, the toolstack (libxl) generates the ACPI tables according the
>> number of vcpus and gic controller.
>>
>> Then, it copies these ACPI tables to DomU memory space and passes
>> them to UEFI firmware through the "ARM multiboot" protocol.
>>
>> At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol
>> and installs these tables like the usual way and passes both ACPI and DT
>> information to the Xen DomU.
>>
>> Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT tables
>> since it's enough now.
>>
>> This has been tested using guest kernel with the Dom0 ACPI support
>> patches which could be fetched from:
>> https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen
>>
> 
> Where can I find the UEFI firmware? What is the guest configuration to use?
> 
The corresponding UEFI patch can be found from below url:
https://www.mail-archive.com/xen-devel@lists.xen.org/msg69468.html

You can use the above guest kernel with defconfig.

Thanks,
-- 
Shannon

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] 4.7 qemu regression: HVM guests fail to boot from xvda

[Jan Beulich]

>>> On 31.05.16 at 15:41,  wrote:
> On Tue, May 31, 2016 at 1:10 PM, Jan Beulich  wrote:
> On 31.05.16 at 13:32,  wrote:
>>> On Tue, May 31, 2016 at 12:16 PM, Olaf Hering  wrote:
 On Tue, May 31, George Dunlap wrote:

> On Mon, May 30, 2016 at 9:42 PM, Olaf Hering  wrote:
> > With staging-4.6 this domU boots from xvda, qemu creates an emulated
> > disk. With staging no disk is found, unless the name is changed to hda.
> > Looks like qemu-2.6 does not handle xvda either.
>
> This was intentional; see this thread:
>
> 
> https://marc.info/?i=<1444820717-25565-1-git-send-email-anthony.perard@citrix.
> com>
>
> The idea was to make it possible to create an HVM guest with no
> emulated disks for guest booting with OVMF which contains PV drivers.

 This breaks the domU becasue it changes its device names from 'xvd' to
 'hd' if a xenlinux based kernel is used in domU.
 In other words: every SUSE domU out there.
>>>
>>> Sorry, can you expand on this a bit?  Are you saying that on SuSE, if
>>> you specify "vdev=xvda" in your config file, that you'll get PV
>>> devices named "/dev/xvda", but that if you specify "vdev=hda", that
>>> you'll get PV devices but named "/dev/hda"?
>>
>> And just to clarify - this isn't really SUSE-specific, this is how the old
>> XenoLinux blkfront has always behaved. In fact when I saw this code
>> gone from the upstream (pv-ops) variant, I think I had inquired how
>> this is expected to be handling upgrade cases, and I don't think I got
>> much of a useful answer to that.
> 
> Sure, but I think SuSE are basically the only distribution still using
> XenoLinux, right?  Is there actually any open project maintaining the
> XenoLinux fork?  If someone wanted to use XenoLinux, wouldn't their
> options basically be 1) do all the forward-porting themselves from
> some ancient 2.X tree, or 2) use SuSE's port?

Yes.

> Regarding an upgrade: fstab and other tools can be handed UUIDs;

You know how people behave - you tell them "don't use raw
device names" and they still do. (In a few places I'm guilty of this
myself - on kernel command lines, for brevity, I prefer using raw
device names for "root=", but I also know that it's going to be me
to deal with the fallout.)

> and
> an enterprise-grade distribution could probably include udev scripts
> to create symlinks, right?

I guess so. Yet the question is - how would the script know what
symlinks to create? Cross linking between /dev/xvd* and /dev/hd*
(or /dev/sd*) can't be done blindly, as a guest may have e.g. both
xvda and hda specified in its config file (which works with the old
blkfront afaict, but wouldn't work with upstream's).

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0

[Oleksandr Dmytryshyn]

On Fri, May 20, 2016 at 7:05 PM, Edgar E. Iglesias
 wrote:
> Hi,
>
> We have similar needs (not exactly the same) in some of our setups.
> We need to map certain OCMs (On Chip Memories) to dom0. Among other things,
> these are used to communicate with remote accelerators/CPUs that have
> "hardcoded" addresses to these RAMs.
>
> Our approach is more along the lines of Juliens second suggestion. We're
> trying to use the mmio-sram DTS bindings to bring in these memories into
> dom0.
>
> IIUC the Ducati FW issue correctly, you need to allocate a chunk of DDR.
>
> Another possible solution:
> I think you could reserve the memory area by simply not mentioning it
> in the main memory node (these nodes support multiple ranges so you can
> introduce gaps). Then you could for example create an mmio-sram node to
> get the memory explicitely mapped 1:1 into dom0.
>
> Just a moment ago, I posted an RFC for the mmio-sram support to the list.
Hi, Edgar.

How do You access to the mapped OCMs in dom0?
Are genalloc-related functions (gen_pool_get/_alloc/_virt_to_phys)
only way to work with mmio-sram memory?

> Cheers,
> Edgar
>
>
>>
>> Regards,
>>
>> [1]
>> http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg01879.html
>> [2]
>> http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg01894.html
>>
>> --
>> Julien Grall
>>
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [Patch v6 03/11] IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU unmapping (top level ones)

[Xu, Quan]

From: Quan Xu 

Signed-off-by: Quan Xu 
Acked-by: Kevin Tian 
Reviewed-by: Jan Beulich 

CC: Stefano Stabellini 
CC: Julien Grall 
CC: Kevin Tian 
CC: Feng Wu 
CC: Jan Beulich 
CC: Andrew Cooper 
---
 xen/drivers/passthrough/arm/smmu.c|  2 +-
 xen/drivers/passthrough/vtd/iommu.c   | 15 ---
 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h |  2 +-
 xen/include/xen/iommu.h   |  2 +-
 4 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index 54a03a6..1ce4ddf 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -2774,7 +2774,7 @@ static int arm_smmu_map_page(struct domain *d, unsigned 
long gfn,
return guest_physmap_add_entry(d, gfn, mfn, 0, t);
 }
 
-static int arm_smmu_unmap_page(struct domain *d, unsigned long gfn)
+static int __must_check arm_smmu_unmap_page(struct domain *d, unsigned long 
gfn)
 {
/*
 * This function should only be used by gnttab code when the domain
diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index db83949..4844193 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -609,7 +609,7 @@ static void intel_iommu_iotlb_flush_all(struct domain *d)
 }
 
 /* clear one page's page table */
-static void dma_pte_clear_one(struct domain *domain, u64 addr)
+static int __must_check dma_pte_clear_one(struct domain *domain, u64 addr)
 {
 struct domain_iommu *hd = dom_iommu(domain);
 struct dma_pte *page = NULL, *pte = NULL;
@@ -621,7 +621,7 @@ static void dma_pte_clear_one(struct domain *domain, u64 
addr)
 if ( pg_maddr == 0 )
 {
 spin_unlock(>arch.mapping_lock);
-return;
+return 0;
 }
 
 page = (struct dma_pte *)map_vtd_domain_page(pg_maddr);
@@ -631,7 +631,7 @@ static void dma_pte_clear_one(struct domain *domain, u64 
addr)
 {
 spin_unlock(>arch.mapping_lock);
 unmap_vtd_domain_page(page);
-return;
+return 0;
 }
 
 dma_clear_pte(*pte);
@@ -642,6 +642,8 @@ static void dma_pte_clear_one(struct domain *domain, u64 
addr)
 __intel_iommu_iotlb_flush(domain, addr >> PAGE_SHIFT_4K, 1, 1);
 
 unmap_vtd_domain_page(page);
+
+return 0;
 }
 
 static void iommu_free_pagetable(u64 pt_maddr, int level)
@@ -1739,15 +1741,14 @@ static int intel_iommu_map_page(
 return 0;
 }
 
-static int intel_iommu_unmap_page(struct domain *d, unsigned long gfn)
+static int __must_check intel_iommu_unmap_page(struct domain *d,
+   unsigned long gfn)
 {
 /* Do nothing if hardware domain and iommu supports pass thru. */
 if ( iommu_passthrough && is_hardware_domain(d) )
 return 0;
 
-dma_pte_clear_one(d, (paddr_t)gfn << PAGE_SHIFT_4K);
-
-return 0;
+return dma_pte_clear_one(d, (paddr_t)gfn << PAGE_SHIFT_4K);
 }
 
 void iommu_pte_flush(struct domain *d, u64 gfn, u64 *pte,
diff --git a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h 
b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
index 9c51172..57b6cc1 100644
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
@@ -53,7 +53,7 @@ int amd_iommu_update_ivrs_mapping_acpi(void);
 /* mapping functions */
 int amd_iommu_map_page(struct domain *d, unsigned long gfn, unsigned long mfn,
unsigned int flags);
-int amd_iommu_unmap_page(struct domain *d, unsigned long gfn);
+int __must_check amd_iommu_unmap_page(struct domain *d, unsigned long gfn);
 u64 amd_iommu_get_next_table_from_pte(u32 *entry);
 int amd_iommu_reserve_domain_unity_map(struct domain *domain,
u64 phys_addr, unsigned long size,
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 19ba976..73a7f1e 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -168,7 +168,7 @@ struct iommu_ops {
 void (*teardown)(struct domain *d);
 int (*map_page)(struct domain *d, unsigned long gfn, unsigned long mfn,
 unsigned int flags);
-int (*unmap_page)(struct domain *d, unsigned long gfn);
+int __must_check (*unmap_page)(struct domain *d, unsigned long gfn);
 void (*free_page_table)(struct page_info *);
 #ifdef CONFIG_X86
 void (*update_ire_from_apic)(unsigned int apic, unsigned int reg, unsigned 
int value);
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [Patch v6 01/11] IOMMU: handle IOMMU mapping and unmapping failures

[Xu, Quan]

From: Quan Xu 

Treat IOMMU mapping and unmapping failures as a fatal to the DomU
If IOMMU mapping and unmapping failed, crash the DomU and propagate
the error up to the call trees.

No spamming of the log can occur. For DomU, we avoid logging any
message for already dying domains. For Dom0, that'll still be more
verbose than we'd really like, but it at least wouldn't outright
flood the console.

Signed-off-by: Quan Xu 
Reviewed-by: Kevin Tian 

CC: Jan Beulich 
CC: Kevin Tian 

v6:
  1. Enhance commit message, changing "No spamming can occur"
 to "No spamming of the log can occur".
  2. Enhance log messages.
---
 xen/drivers/passthrough/iommu.c | 30 --
 1 file changed, 28 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 9d104d2..673e126 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -240,21 +240,47 @@ int iommu_map_page(struct domain *d, unsigned long gfn, 
unsigned long mfn,
unsigned int flags)
 {
 const struct domain_iommu *hd = dom_iommu(d);
+int rc;
 
 if ( !iommu_enabled || !hd->platform_ops )
 return 0;
 
-return hd->platform_ops->map_page(d, gfn, mfn, flags);
+rc = hd->platform_ops->map_page(d, gfn, mfn, flags);
+if ( unlikely(rc) )
+{
+if ( !d->is_shutting_down && printk_ratelimit() )
+printk(XENLOG_ERR
+   "d%d: IOMMU mapping gfn %#lx to mfn %#lx failed: %d\n",
+   d->domain_id, gfn, mfn, rc);
+
+if ( !is_hardware_domain(d) )
+domain_crash(d);
+}
+
+return rc;
 }
 
 int iommu_unmap_page(struct domain *d, unsigned long gfn)
 {
 const struct domain_iommu *hd = dom_iommu(d);
+int rc;
 
 if ( !iommu_enabled || !hd->platform_ops )
 return 0;
 
-return hd->platform_ops->unmap_page(d, gfn);
+rc = hd->platform_ops->unmap_page(d, gfn);
+if ( unlikely(rc) )
+{
+if ( !d->is_shutting_down && printk_ratelimit() )
+printk(XENLOG_ERR
+   "d%d: IOMMU unmapping gfn %#lx failed: %d\n",
+   d->domain_id, gfn, rc);
+
+if ( !is_hardware_domain(d) )
+domain_crash(d);
+}
+
+return rc;
 }
 
 static void iommu_free_pagetables(unsigned long unused)
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [Patch v6 04/11] IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU mapping (top level ones)

[Xu, Quan]

From: Quan Xu 

Signed-off-by: Quan Xu 
Acked-by: Kevin Tian 

CC: Suravee Suthikulpanit 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Kevin Tian 
CC: Feng Wu 
CC: Jan Beulich 

v6:
  1. Add __must_check annotation to amd_iommu_map_page().
  2. Return the first error instead of the last one.
---
 xen/drivers/passthrough/amd/pci_amd_iommu.c   | 16 ++--
 xen/drivers/passthrough/arm/smmu.c|  4 ++--
 xen/drivers/passthrough/vtd/iommu.c   |  7 ---
 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h |  4 ++--
 xen/include/xen/iommu.h   |  4 ++--
 5 files changed, 24 insertions(+), 11 deletions(-)

diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c 
b/xen/drivers/passthrough/amd/pci_amd_iommu.c
index 70b7475..17c1f6d 100644
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -285,6 +285,8 @@ static void __hwdom_init amd_iommu_hwdom_init(struct domain 
*d)
 
 if ( !iommu_passthrough && !need_iommu(d) )
 {
+int rc = 0;
+
 /* Set up 1:1 page table for dom0 */
 for ( i = 0; i < max_pdx; i++ )
 {
@@ -295,12 +297,22 @@ static void __hwdom_init amd_iommu_hwdom_init(struct 
domain *d)
  * a pfn_valid() check would seem desirable here.
  */
 if ( mfn_valid(pfn) )
-amd_iommu_map_page(d, pfn, pfn, 
-   IOMMUF_readable|IOMMUF_writable);
+{
+int ret;
+
+ret = amd_iommu_map_page(d, pfn, pfn,
+ IOMMUF_readable|IOMMUF_writable);
+if ( !rc )
+rc = ret;
+}
 
 if ( !(i & 0xf) )
 process_pending_softirqs();
 }
+
+if ( rc )
+AMD_IOMMU_DEBUG("d%d: IOMMU mapping failed: %d\n",
+d->domain_id, rc);
 }
 
 for_each_amd_iommu ( iommu )
diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index 1ce4ddf..ee5c89d 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -2745,8 +2745,8 @@ static void arm_smmu_iommu_domain_teardown(struct domain 
*d)
xfree(xen_domain);
 }
 
-static int arm_smmu_map_page(struct domain *d, unsigned long gfn,
-unsigned long mfn, unsigned int flags)
+static int __must_check arm_smmu_map_page(struct domain *d, unsigned long gfn,
+  unsigned long mfn, unsigned int 
flags)
 {
p2m_type_t t;
 
diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index 4844193..e900019 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1687,9 +1687,10 @@ static void iommu_domain_teardown(struct domain *d)
 spin_unlock(>arch.mapping_lock);
 }
 
-static int intel_iommu_map_page(
-struct domain *d, unsigned long gfn, unsigned long mfn,
-unsigned int flags)
+static int __must_check intel_iommu_map_page(struct domain *d,
+ unsigned long gfn,
+ unsigned long mfn,
+ unsigned int flags)
 {
 struct domain_iommu *hd = dom_iommu(d);
 struct dma_pte *page = NULL, *pte = NULL, old, new = { 0 };
diff --git a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h 
b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
index 57b6cc1..ac9f036 100644
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
@@ -51,8 +51,8 @@ int amd_iommu_init(void);
 int amd_iommu_update_ivrs_mapping_acpi(void);
 
 /* mapping functions */
-int amd_iommu_map_page(struct domain *d, unsigned long gfn, unsigned long mfn,
-   unsigned int flags);
+int __must_check amd_iommu_map_page(struct domain *d, unsigned long gfn,
+unsigned long mfn, unsigned int flags);
 int __must_check amd_iommu_unmap_page(struct domain *d, unsigned long gfn);
 u64 amd_iommu_get_next_table_from_pte(u32 *entry);
 int amd_iommu_reserve_domain_unity_map(struct domain *domain,
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 73a7f1e..14041a1 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -166,8 +166,8 @@ struct iommu_ops {
 #endif /* HAS_PCI */
 
 void (*teardown)(struct domain *d);
-int (*map_page)(struct domain *d, unsigned long gfn, unsigned long mfn,
-unsigned int flags);
+int __must_check (*map_page)(struct domain *d, unsigned long gfn,
+ unsigned long mfn, unsigned int flags);
 int 

[Xen-devel] [Patch v6 02/11] IOMMU/MMU: enhance the call trees of IOMMU unmapping and mapping

[Xu, Quan]

From: Quan Xu 

When IOMMU mapping is failed, we issue a best effort rollback, stopping
IOMMU mapping, unmapping the previous IOMMU maps and then reporting the
error up to the call trees. When rollback is not feasible (in early
initialization phase or trade-off of complexity) for the hardware domain,
we do things on a best effort basis, only throwing out an error message.

IOMMU unmapping should perhaps continue despite an error, in an attempt
to do best effort cleanup.

Signed-off-by: Quan Xu 

CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Jun Nakajima 
CC: Kevin Tian 
CC: George Dunlap 

v6:
  1. Limit __must_check annotation to IOMMU functions for this patch set.
  2. Replace 'ret' with a more specific name 'iommu_ret' in __get_page_type().
  3. Return the first error instead of the last one.
---
 xen/arch/x86/mm.c   | 13 -
 xen/arch/x86/mm/p2m-ept.c   | 33 ++---
 xen/arch/x86/mm/p2m-pt.c| 24 +---
 xen/arch/x86/mm/p2m.c   | 16 ++--
 xen/drivers/passthrough/iommu.c | 14 +-
 5 files changed, 82 insertions(+), 18 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 8d10a3e..ae7c8ab 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2467,7 +2467,7 @@ static int __get_page_type(struct page_info *page, 
unsigned long type,
int preemptible)
 {
 unsigned long nx, x, y = page->u.inuse.type_info;
-int rc = 0;
+int rc = 0, iommu_ret = 0;
 
 ASSERT(!(type & ~(PGT_type_mask | PGT_pae_xen_l2)));
 
@@ -2578,11 +2578,11 @@ static int __get_page_type(struct page_info *page, 
unsigned long type,
 if ( d && is_pv_domain(d) && unlikely(need_iommu(d)) )
 {
 if ( (x & PGT_type_mask) == PGT_writable_page )
-iommu_unmap_page(d, mfn_to_gmfn(d, page_to_mfn(page)));
+iommu_ret = iommu_unmap_page(d, mfn_to_gmfn(d, 
page_to_mfn(page)));
 else if ( type == PGT_writable_page )
-iommu_map_page(d, mfn_to_gmfn(d, page_to_mfn(page)),
-   page_to_mfn(page),
-   IOMMUF_readable|IOMMUF_writable);
+iommu_ret = iommu_map_page(d, mfn_to_gmfn(d, 
page_to_mfn(page)),
+   page_to_mfn(page),
+   IOMMUF_readable|IOMMUF_writable);
 }
 }
 
@@ -2599,6 +2599,9 @@ static int __get_page_type(struct page_info *page, 
unsigned long type,
 if ( (x & PGT_partial) && !(nx & PGT_partial) )
 put_page(page);
 
+if ( !rc )
+rc = iommu_ret;
+
 return rc;
 }
 
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 1ed5b47..ebb4343 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -667,6 +667,7 @@ ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, 
mfn_t mfn,
 unsigned long gfn_remainder = gfn;
 unsigned int i, target = order / EPT_TABLE_ORDER;
 int ret, rc = 0;
+bool_t entry_written = 0;
 bool_t direct_mmio = (p2mt == p2m_mmio_direct);
 uint8_t ipat = 0;
 bool_t need_modify_vtd_table = 1;
@@ -812,10 +813,15 @@ ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, 
mfn_t mfn,
 rc = atomic_write_ept_entry(ept_entry, new_entry, target);
 if ( unlikely(rc) )
 old_entry.epte = 0;
-else if ( p2mt != p2m_invalid &&
-  (gfn + (1UL << order) - 1 > p2m->max_mapped_pfn) )
-/* Track the highest gfn for which we have ever had a valid mapping */
-p2m->max_mapped_pfn = gfn + (1UL << order) - 1;
+else
+{
+entry_written = 1;
+
+if ( p2mt != p2m_invalid &&
+ (gfn + (1UL << order) - 1 > p2m->max_mapped_pfn) )
+/* Track the highest gfn for which we have ever had a valid 
mapping */
+p2m->max_mapped_pfn = gfn + (1UL << order) - 1;
+}
 
 out:
 if ( needs_sync )
@@ -831,10 +837,23 @@ out:
 {
 if ( iommu_flags )
 for ( i = 0; i < (1 << order); i++ )
-iommu_map_page(d, gfn + i, mfn_x(mfn) + i, iommu_flags);
+{
+rc = iommu_map_page(d, gfn + i, mfn_x(mfn) + i, 
iommu_flags);
+if ( unlikely(rc) )
+{
+while ( i-- )
+iommu_unmap_page(p2m->domain, gfn + i);
+
+break;
+}
+}
 else
 for ( i = 0; i < (1 << order); i++ )
-iommu_unmap_page(d, gfn + i);
+{
+ret = iommu_unmap_page(d, gfn + i);
+if ( !rc )
+rc 

[Xen-devel] [Patch v6 08/11] IOMMU: propagate IOMMU Device-TLB flush error (leaf ones).

[Xu, Quan]

From: Quan Xu 

Signed-off-by: Quan Xu 
Acked-by: Kevin Tian 
Reviewed-by: Jan Beulich 

CC: Stefano Stabellini 
CC: Julien Grall 
CC: Jan Beulich 
CC: Kevin Tian 
CC: Feng Wu 

v6: Add __must_check annotation to intel_iommu_iotlb_flush_all().
---
 xen/drivers/passthrough/arm/smmu.c  | 13 -
 xen/drivers/passthrough/iommu.c |  8 ++--
 xen/drivers/passthrough/vtd/iommu.c | 32 
 xen/include/xen/iommu.h |  5 +++--
 4 files changed, 33 insertions(+), 25 deletions(-)

diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index ee5c89d..1d21568 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -2540,7 +2540,7 @@ static int force_stage = 2;
  */
 static u32 platform_features = ARM_SMMU_FEAT_COHERENT_WALK;
 
-static void arm_smmu_iotlb_flush_all(struct domain *d)
+static int __must_check arm_smmu_iotlb_flush_all(struct domain *d)
 {
struct arm_smmu_xen_domain *smmu_domain = dom_iommu(d)->arch.priv;
struct iommu_domain *cfg;
@@ -2557,13 +2557,16 @@ static void arm_smmu_iotlb_flush_all(struct domain *d)
arm_smmu_tlb_inv_context(cfg->priv);
}
spin_unlock(_domain->lock);
+
+   return 0;
 }
 
-static void arm_smmu_iotlb_flush(struct domain *d, unsigned long gfn,
- unsigned int page_count)
+static int __must_check arm_smmu_iotlb_flush(struct domain *d,
+ unsigned long gfn,
+ unsigned int page_count)
 {
-/* ARM SMMU v1 doesn't have flush by VMA and VMID */
-arm_smmu_iotlb_flush_all(d);
+   /* ARM SMMU v1 doesn't have flush by VMA and VMID */
+   return arm_smmu_iotlb_flush_all(d);
 }
 
 static struct iommu_domain *arm_smmu_get_domain(struct domain *d,
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index e611e72..098b601 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -320,9 +320,7 @@ int iommu_iotlb_flush(struct domain *d, unsigned long gfn,
 if ( !iommu_enabled || !hd->platform_ops || !hd->platform_ops->iotlb_flush 
)
 return 0;
 
-hd->platform_ops->iotlb_flush(d, gfn, page_count);
-
-return 0;
+return hd->platform_ops->iotlb_flush(d, gfn, page_count);
 }
 
 int iommu_iotlb_flush_all(struct domain *d)
@@ -332,9 +330,7 @@ int iommu_iotlb_flush_all(struct domain *d)
 if ( !iommu_enabled || !hd->platform_ops || 
!hd->platform_ops->iotlb_flush_all )
 return 0;
 
-hd->platform_ops->iotlb_flush_all(d);
-
-return 0;
+return hd->platform_ops->iotlb_flush_all(d);
 }
 
 int __init iommu_setup(void)
diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index c2bf1e2..0788a59 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -559,8 +559,10 @@ static int __must_check iommu_flush_all(void)
 return 0;
 }
 
-static void __intel_iommu_iotlb_flush(struct domain *d, unsigned long gfn,
-int dma_old_pte_present, unsigned int page_count)
+static int __must_check iommu_flush_iotlb(struct domain *d,
+  unsigned long gfn,
+  bool_t dma_old_pte_present,
+  unsigned int page_count)
 {
 struct domain_iommu *hd = dom_iommu(d);
 struct acpi_drhd_unit *drhd;
@@ -598,16 +600,20 @@ static void __intel_iommu_iotlb_flush(struct domain *d, 
unsigned long gfn,
 iommu_flush_write_buffer(iommu);
 }
 }
+
+return 0;
 }
 
-static void intel_iommu_iotlb_flush(struct domain *d, unsigned long gfn, 
unsigned int page_count)
+static int __must_check iommu_flush_iotlb_pages(struct domain *d,
+unsigned long gfn,
+unsigned int page_count)
 {
-__intel_iommu_iotlb_flush(d, gfn, 1, page_count);
+return iommu_flush_iotlb(d, gfn, 1, page_count);
 }
 
-static void intel_iommu_iotlb_flush_all(struct domain *d)
+static int __must_check iommu_flush_iotlb_all(struct domain *d)
 {
-__intel_iommu_iotlb_flush(d, INVALID_GFN, 0, 0);
+return iommu_flush_iotlb(d, INVALID_GFN, 0, 0);
 }
 
 /* clear one page's page table */
@@ -616,6 +622,7 @@ static int __must_check dma_pte_clear_one(struct domain 
*domain, u64 addr)
 struct domain_iommu *hd = dom_iommu(domain);
 struct dma_pte *page = NULL, *pte = NULL;
 u64 pg_maddr;
+int rc = 0;
 
 spin_lock(>arch.mapping_lock);
 /* get last level pte */
@@ -641,11 +648,11 @@ static int __must_check dma_pte_clear_one(struct domain 
*domain, u64 addr)

[Xen-devel] [Patch v6 11/11] vt-d: add __must_check annotation to IOMMU flush pointers and handlers

[Xu, Quan]

From: Quan Xu 

Signed-off-by: Quan Xu 

CC: Jan Beulich 
CC: Kevin Tian 
CC: Feng Wu 
---
 xen/drivers/passthrough/vtd/iommu.c  | 40 ++--
 xen/drivers/passthrough/vtd/iommu.h  | 11 ++
 xen/drivers/passthrough/vtd/qinval.c | 14 ++---
 3 files changed, 34 insertions(+), 31 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index 2cc2c93..32202b6 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -335,10 +335,9 @@ static void iommu_flush_write_buffer(struct iommu *iommu)
 }
 
 /* return value determine if we need a write buffer flush */
-static int flush_context_reg(
-void *_iommu,
-u16 did, u16 source_id, u8 function_mask, u64 type,
-int flush_non_present_entry)
+static int __must_check flush_context_reg(void *_iommu, u16 did, u16 source_id,
+  u8 function_mask, u64 type,
+  bool_t flush_non_present_entry)
 {
 struct iommu *iommu = (struct iommu *) _iommu;
 u64 val = 0;
@@ -389,7 +388,7 @@ static int flush_context_reg(
 }
 
 static int __must_check iommu_flush_context_global(struct iommu *iommu,
-   int flush_non_present_entry)
+   bool_t 
flush_non_present_entry)
 {
 struct iommu_flush *flush = iommu_get_flush(iommu);
 return flush->context(iommu, 0, 0, 0, DMA_CCMD_GLOBAL_INVL,
@@ -399,7 +398,7 @@ static int __must_check iommu_flush_context_global(struct 
iommu *iommu,
 static int __must_check iommu_flush_context_device(struct iommu *iommu,
u16 did, u16 source_id,
u8 function_mask,
-   int flush_non_present_entry)
+   bool_t 
flush_non_present_entry)
 {
 struct iommu_flush *flush = iommu_get_flush(iommu);
 return flush->context(iommu, did, source_id, function_mask,
@@ -408,9 +407,10 @@ static int __must_check iommu_flush_context_device(struct 
iommu *iommu,
 }
 
 /* return value determine if we need a write buffer flush */
-static int flush_iotlb_reg(void *_iommu, u16 did,
-   u64 addr, unsigned int size_order, u64 type,
-   int flush_non_present_entry, int flush_dev_iotlb)
+static int __must_check flush_iotlb_reg(void *_iommu, u16 did, u64 addr,
+unsigned int size_order, u64 type,
+bool_t flush_non_present_entry,
+bool_t flush_dev_iotlb)
 {
 struct iommu *iommu = (struct iommu *) _iommu;
 int tlb_offset = ecap_iotlb_offset(iommu->ecap);
@@ -475,8 +475,8 @@ static int flush_iotlb_reg(void *_iommu, u16 did,
 }
 
 static int __must_check iommu_flush_iotlb_global(struct iommu *iommu,
- int flush_non_present_entry,
- int flush_dev_iotlb)
+ bool_t 
flush_non_present_entry,
+ bool_t flush_dev_iotlb)
 {
 struct iommu_flush *flush = iommu_get_flush(iommu);
 int status;
@@ -494,8 +494,8 @@ static int __must_check iommu_flush_iotlb_global(struct 
iommu *iommu,
 }
 
 static int __must_check iommu_flush_iotlb_dsi(struct iommu *iommu, u16 did,
-  int flush_non_present_entry,
-  int flush_dev_iotlb)
+  bool_t flush_non_present_entry,
+  bool_t flush_dev_iotlb)
 {
 struct iommu_flush *flush = iommu_get_flush(iommu);
 int status;
@@ -514,8 +514,8 @@ static int __must_check iommu_flush_iotlb_dsi(struct iommu 
*iommu, u16 did,
 
 static int __must_check iommu_flush_iotlb_psi(struct iommu *iommu, u16 did,
   u64 addr, unsigned int order,
-  int flush_non_present_entry,
-  int flush_dev_iotlb)
+  bool_t flush_non_present_entry,
+  bool_t flush_dev_iotlb)
 {
 struct iommu_flush *flush = iommu_get_flush(iommu);
 int status;
@@ -549,7 +549,7 @@ static int __must_check iommu_flush_all(void)
 {
 struct acpi_drhd_unit *drhd;
 struct iommu *iommu;
-int flush_dev_iotlb;
+bool_t flush_dev_iotlb;
 int rc = 0;
 
 flush_all_cache();
@@ -597,7 +597,7 @@ static int __must_check iommu_flush_iotlb(struct 

[Xen-devel] [Patch v6 00/11] Check VT-d Device-TLB flush error

[Xu, Quan]

From: Quan Xu 

This patch set is a prereq patch set for Patch:'VT-d Device-TLB flush issue'.

While IOMMU Device-TLB flush timed out, xen calls panic() at present. However 
the existing panic()
is going to be eliminated, so we must propagate the IOMMU Device-TLB flush 
error up to the call trees.

This patch set is also based on the discussion of 'abstract model of IOMMU 
unmaping/mapping failures'

Quan Xu (11):
  IOMMU: handle IOMMU mapping and unmapping failures
  IOMMU/MMU: enhance the call trees of IOMMU unmapping and mapping
  IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU unmapping
(top level ones)
  IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU mapping (top
level ones)
  IOMMU/MMU: propagate IOMMU Device-TLB flush error up to
iommu_iotlb_flush{,_all} (top level ones)
  propagate IOMMU Device-TLB flush error up to EPT update (top level
ones)
  IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU suspending
(top level ones)
  IOMMU: propagate IOMMU Device-TLB flush error (leaf ones).
  vt-d: fix the IOMMU flush issue
  vt-d: propagate the IOMMU Device-TLB flush error up to ME phantom
functions
  vt-d: add __must_check annotation to IOMMU flush pointers and handlers

 xen/arch/arm/p2m.c|   4 +-
 xen/arch/x86/acpi/power.c |  76 +--
 xen/arch/x86/mm.c |  13 +-
 xen/arch/x86/mm/p2m-ept.c |  35 +++-
 xen/arch/x86/mm/p2m-pt.c  |  24 ++-
 xen/arch/x86/mm/p2m.c |  16 +-
 xen/common/memory.c   |  12 +-
 xen/drivers/passthrough/amd/iommu_init.c  |   9 +-
 xen/drivers/passthrough/amd/pci_amd_iommu.c   |  18 +-
 xen/drivers/passthrough/arm/smmu.c|  19 +-
 xen/drivers/passthrough/iommu.c   |  63 +-
 xen/drivers/passthrough/vtd/extern.h  |   3 +-
 xen/drivers/passthrough/vtd/iommu.c   | 285 ++
 xen/drivers/passthrough/vtd/iommu.h   |  11 +-
 xen/drivers/passthrough/vtd/qinval.c  |  14 +-
 xen/drivers/passthrough/vtd/quirks.c  |  27 ++-
 xen/drivers/passthrough/x86/iommu.c   |   5 +-
 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h |   8 +-
 xen/include/asm-x86/iommu.h   |   3 +-
 xen/include/xen/iommu.h   |  20 +-
 20 files changed, 479 insertions(+), 186 deletions(-)

-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [Patch v6 07/11] IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU suspending (top level ones)

[Xu, Quan]

From: Quan Xu 

Signed-off-by: Quan Xu 

CC: Jan Beulich 
CC: Liu Jinsong 
CC: Keir Fraser 
CC: Andrew Cooper 
CC: Suravee Suthikulpanit 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Kevin Tian 
CC: Feng Wu 

v6:
  1. Drop comments in enum dev_power_saved.
  2. If console_suspend() fails, return SAVED_NONE.
  3. Put off leaf ones (in iommu_flush_all()) in later patch.
---
 xen/arch/x86/acpi/power.c | 76 ---
 xen/drivers/passthrough/amd/iommu_init.c  |  9 +++-
 xen/drivers/passthrough/amd/pci_amd_iommu.c   |  2 +-
 xen/drivers/passthrough/iommu.c   |  6 ++-
 xen/drivers/passthrough/vtd/iommu.c   | 35 
 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h |  2 +-
 xen/include/xen/iommu.h   |  4 +-
 7 files changed, 99 insertions(+), 35 deletions(-)

diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index 2885e31..e516fbd 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -43,36 +43,70 @@ struct acpi_sleep_info acpi_sinfo;
 
 void do_suspend_lowlevel(void);
 
+enum dev_power_saved
+{
+SAVED_NONE,
+SAVED_CONSOLE,
+SAVED_TIME,
+SAVED_I8259A,
+SAVED_IOAPIC,
+SAVED_IOMMU,
+SAVED_LAPIC,
+SAVED_ALL,
+};
+
 static int device_power_down(void)
 {
-console_suspend();
+if ( console_suspend() )
+return SAVED_NONE;
 
-time_suspend();
+if ( time_suspend() )
+return SAVED_CONSOLE;
 
-i8259A_suspend();
+if ( i8259A_suspend() )
+return SAVED_TIME;
 
+/* ioapic_suspend cannot fail */
 ioapic_suspend();
 
-iommu_suspend();
+if ( iommu_suspend() )
+return SAVED_IOAPIC;
 
-lapic_suspend();
+if ( lapic_suspend() )
+return SAVED_IOMMU;
 
-return 0;
+return SAVED_NONE;
 }
 
-static void device_power_up(void)
+static void device_power_up(enum dev_power_saved saved)
 {
-lapic_resume();
-
-iommu_resume();
-
-ioapic_resume();
-
-i8259A_resume();
-
-time_resume();
-
-console_resume();
+switch ( saved )
+{
+case SAVED_ALL:
+case SAVED_LAPIC:
+lapic_resume();
+/* fall through */
+case SAVED_IOMMU:
+iommu_resume();
+/* fall through */
+case SAVED_IOAPIC:
+ioapic_resume();
+/* fall through */
+case SAVED_I8259A:
+i8259A_resume();
+/* fall through */
+case SAVED_TIME:
+time_resume();
+/* fall through */
+case SAVED_CONSOLE:
+console_resume();
+/* fall through */
+case SAVED_NONE:
+break;
+default:
+BUG();
+break;
+}
 }
 
 static void freeze_domains(void)
@@ -169,6 +203,10 @@ static int enter_state(u32 state)
 {
 printk(XENLOG_ERR "Some devices failed to power down.");
 system_state = SYS_STATE_resume;
+
+if ( error > 0 )
+device_power_up(error);
+
 goto done;
 }
 
@@ -196,7 +234,7 @@ static int enter_state(u32 state)
 write_cr4(cr4 & ~X86_CR4_MCE);
 write_efer(read_efer());
 
-device_power_up();
+device_power_up(SAVED_ALL);
 
 mcheck_init(_cpu_data, 0);
 write_cr4(cr4);
diff --git a/xen/drivers/passthrough/amd/iommu_init.c 
b/xen/drivers/passthrough/amd/iommu_init.c
index 4536106..0b68596 100644
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -1339,7 +1339,14 @@ static void invalidate_all_devices(void)
 iterate_ivrs_mappings(_invalidate_all_devices);
 }
 
-void amd_iommu_suspend(void)
+int amd_iommu_suspend(void)
+{
+amd_iommu_crash_shutdown();
+
+return 0;
+}
+
+void amd_iommu_crash_shutdown(void)
 {
 struct amd_iommu *iommu;
 
diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c 
b/xen/drivers/passthrough/amd/pci_amd_iommu.c
index 17c1f6d..9488eb0 100644
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -638,6 +638,6 @@ const struct iommu_ops amd_iommu_ops = {
 .suspend = amd_iommu_suspend,
 .resume = amd_iommu_resume,
 .share_p2m = amd_iommu_share_p2m,
-.crash_shutdown = amd_iommu_suspend,
+.crash_shutdown = amd_iommu_crash_shutdown,
 .dump_p2m_table = amd_dump_p2m_table,
 };
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index e9b2855..e611e72 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -380,10 +380,12 @@ int __init iommu_setup(void)
 return rc;
 }
 
-void iommu_suspend()
+int iommu_suspend()
 {
 if ( iommu_enabled )
-iommu_get_ops()->suspend();
+return iommu_get_ops()->suspend();
+
+return 0;
 }
 
 void iommu_resume()
diff --git 

[Xen-devel] [Patch v6 05/11] IOMMU/MMU: propagate IOMMU Device-TLB flush error up to iommu_iotlb_flush{, _all} (top level ones)

[Xu, Quan]

From: Quan Xu 

Signed-off-by: Quan Xu 
Reviewed-by: Jan Beulich 

CC: Stefano Stabellini 
CC: Julien Grall 
CC: Jan Beulich 
CC: Kevin Tian 

v6: Remove __must_check annotation from xenmem_add_to_physmap().
---
 xen/arch/arm/p2m.c  |  4 +++-
 xen/common/memory.c | 12 ++--
 xen/drivers/passthrough/iommu.c | 13 +
 xen/drivers/passthrough/x86/iommu.c |  5 +++--
 xen/include/xen/iommu.h |  5 +++--
 5 files changed, 28 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 838d004..68679a3 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1178,7 +1178,9 @@ out:
 if ( flush )
 {
 flush_tlb_domain(d);
-iommu_iotlb_flush(d, sgfn, egfn - sgfn);
+ret = iommu_iotlb_flush(d, sgfn, egfn - sgfn);
+if ( !rc )
+rc = ret;
 }
 
 while ( (pg = page_list_remove_head(_pages)) )
diff --git a/xen/common/memory.c b/xen/common/memory.c
index ccc6436..46b1d9f 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -683,9 +683,17 @@ static int xenmem_add_to_physmap(struct domain *d,
 #ifdef CONFIG_HAS_PASSTHROUGH
 if ( need_iommu(d) )
 {
+int ret;
+
 this_cpu(iommu_dont_flush_iotlb) = 0;
-iommu_iotlb_flush(d, xatp->idx - done, done);
-iommu_iotlb_flush(d, xatp->gpfn - done, done);
+
+ret = iommu_iotlb_flush(d, xatp->idx - done, done);
+if ( unlikely(ret) && rc >= 0 )
+rc = ret;
+
+ret = iommu_iotlb_flush(d, xatp->gpfn - done, done);
+if ( unlikely(ret) && rc >= 0 )
+rc = ret;
 }
 #endif
 
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 25501cd..e9b2855 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -312,24 +312,29 @@ static void iommu_free_pagetables(unsigned long unused)
 cpumask_cycle(smp_processor_id(), 
_online_map));
 }
 
-void iommu_iotlb_flush(struct domain *d, unsigned long gfn, unsigned int 
page_count)
+int iommu_iotlb_flush(struct domain *d, unsigned long gfn,
+  unsigned int page_count)
 {
 const struct domain_iommu *hd = dom_iommu(d);
 
 if ( !iommu_enabled || !hd->platform_ops || !hd->platform_ops->iotlb_flush 
)
-return;
+return 0;
 
 hd->platform_ops->iotlb_flush(d, gfn, page_count);
+
+return 0;
 }
 
-void iommu_iotlb_flush_all(struct domain *d)
+int iommu_iotlb_flush_all(struct domain *d)
 {
 const struct domain_iommu *hd = dom_iommu(d);
 
 if ( !iommu_enabled || !hd->platform_ops || 
!hd->platform_ops->iotlb_flush_all )
-return;
+return 0;
 
 hd->platform_ops->iotlb_flush_all(d);
+
+return 0;
 }
 
 int __init iommu_setup(void)
diff --git a/xen/drivers/passthrough/x86/iommu.c 
b/xen/drivers/passthrough/x86/iommu.c
index b64b98f..a18a608 100644
--- a/xen/drivers/passthrough/x86/iommu.c
+++ b/xen/drivers/passthrough/x86/iommu.c
@@ -104,8 +104,9 @@ int arch_iommu_populate_page_table(struct domain *d)
 this_cpu(iommu_dont_flush_iotlb) = 0;
 
 if ( !rc )
-iommu_iotlb_flush_all(d);
-else if ( rc != -ERESTART )
+rc = iommu_iotlb_flush_all(d);
+
+if ( rc && rc != -ERESTART )
 iommu_teardown(d);
 
 return rc;
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 14041a1..22a2002 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -200,8 +200,9 @@ int iommu_do_pci_domctl(struct xen_domctl *, struct domain 
*d,
 int iommu_do_domctl(struct xen_domctl *, struct domain *d,
 XEN_GUEST_HANDLE_PARAM(xen_domctl_t));
 
-void iommu_iotlb_flush(struct domain *d, unsigned long gfn, unsigned int 
page_count);
-void iommu_iotlb_flush_all(struct domain *d);
+int __must_check iommu_iotlb_flush(struct domain *d, unsigned long gfn,
+   unsigned int page_count);
+int __must_check iommu_iotlb_flush_all(struct domain *d);
 
 /*
  * The purpose of the iommu_dont_flush_iotlb optional cpu flag is to
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [Patch v6 06/11] propagate IOMMU Device-TLB flush error up to EPT update (top level ones)

[Xu, Quan]

From: Quan Xu 

Propagate the IOMMU Device-TLB flush error up to the ept_set_entry(),
when VT-d shares EPT page table.

Signed-off-by: Quan Xu 
Acked-by: Kevin Tian 
Reviewed-by: Jan Beulich 

CC: Jun Nakajima 
CC: Kevin Tian 
CC: George Dunlap 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Feng Wu 
---
 xen/arch/x86/mm/p2m-ept.c   | 2 +-
 xen/drivers/passthrough/vtd/iommu.c | 6 --
 xen/include/asm-x86/iommu.h | 3 ++-
 3 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index ebb4343..dab3215 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -832,7 +832,7 @@ out:
  need_modify_vtd_table )
 {
 if ( iommu_hap_pt_share )
-iommu_pte_flush(d, gfn, _entry->epte, order, vtd_pte_present);
+rc = iommu_pte_flush(d, gfn, _entry->epte, order, 
vtd_pte_present);
 else
 {
 if ( iommu_flags )
diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index e900019..5366267 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1752,8 +1752,8 @@ static int __must_check intel_iommu_unmap_page(struct 
domain *d,
 return dma_pte_clear_one(d, (paddr_t)gfn << PAGE_SHIFT_4K);
 }
 
-void iommu_pte_flush(struct domain *d, u64 gfn, u64 *pte,
- int order, int present)
+int iommu_pte_flush(struct domain *d, u64 gfn, u64 *pte,
+int order, int present)
 {
 struct acpi_drhd_unit *drhd;
 struct iommu *iommu = NULL;
@@ -1778,6 +1778,8 @@ void iommu_pte_flush(struct domain *d, u64 gfn, u64 *pte,
order, !present, flush_dev_iotlb) )
 iommu_flush_write_buffer(iommu);
 }
+
+return 0;
 }
 
 static int __init vtd_ept_page_compatible(struct iommu *iommu)
diff --git a/xen/include/asm-x86/iommu.h b/xen/include/asm-x86/iommu.h
index e82a2f0..815d77e 100644
--- a/xen/include/asm-x86/iommu.h
+++ b/xen/include/asm-x86/iommu.h
@@ -27,7 +27,8 @@ int iommu_setup_hpet_msi(struct msi_desc *);
 
 /* While VT-d specific, this must get declared in a generic header. */
 int adjust_vtd_irq_affinities(void);
-void iommu_pte_flush(struct domain *d, u64 gfn, u64 *pte, int order, int 
present);
+int __must_check iommu_pte_flush(struct domain *d, u64 gfn, u64 *pte,
+ int order, int present);
 bool_t iommu_supports_eim(void);
 int iommu_enable_x2apic_IR(void);
 void iommu_disable_x2apic_IR(void);
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [Patch v6 10/11] vt-d: propagate the IOMMU Device-TLB flush error up to ME phantom functions

[Xu, Quan]

From: Quan Xu 

Signed-off-by: Quan Xu 
Reviewed-by: Jan Beulich 

CC: Jan Beulich 
CC: Kevin Tian 
CC: Feng Wu 

v6: Don't needlessly split the function header onto two lines.
---
 xen/drivers/passthrough/vtd/extern.h |  3 ++-
 xen/drivers/passthrough/vtd/iommu.c  |  8 
 xen/drivers/passthrough/vtd/quirks.c | 27 +--
 3 files changed, 23 insertions(+), 15 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/extern.h 
b/xen/drivers/passthrough/vtd/extern.h
index cbe0286..6772839 100644
--- a/xen/drivers/passthrough/vtd/extern.h
+++ b/xen/drivers/passthrough/vtd/extern.h
@@ -91,7 +91,8 @@ int is_igd_vt_enabled_quirk(void);
 void platform_quirks_init(void);
 void vtd_ops_preamble_quirk(struct iommu* iommu);
 void vtd_ops_postamble_quirk(struct iommu* iommu);
-void me_wifi_quirk(struct domain *domain, u8 bus, u8 devfn, int map);
+int __must_check me_wifi_quirk(struct domain *domain,
+   u8 bus, u8 devfn, int map);
 void pci_vtd_quirk(const struct pci_dev *);
 bool_t platform_supports_intremap(void);
 bool_t platform_supports_x2apic(void);
diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index 720b867..2cc2c93 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1473,8 +1473,8 @@ int domain_context_mapping_one(
 
 unmap_vtd_domain_page(context_entries);
 
-if ( !seg )
-me_wifi_quirk(domain, bus, devfn, MAP_ME_PHANTOM_FUNC);
+if ( !seg && !rc )
+rc = me_wifi_quirk(domain, bus, devfn, MAP_ME_PHANTOM_FUNC);
 
 return rc;
 }
@@ -1635,8 +1635,8 @@ int domain_context_unmap_one(
 spin_unlock(>lock);
 unmap_vtd_domain_page(context_entries);
 
-if ( !iommu->intel->drhd->segment )
-me_wifi_quirk(domain, bus, devfn, UNMAP_ME_PHANTOM_FUNC);
+if ( !iommu->intel->drhd->segment && !rc )
+rc = me_wifi_quirk(domain, bus, devfn, UNMAP_ME_PHANTOM_FUNC);
 
 return rc;
 }
diff --git a/xen/drivers/passthrough/vtd/quirks.c 
b/xen/drivers/passthrough/vtd/quirks.c
index 473d1fc..91f96ac 100644
--- a/xen/drivers/passthrough/vtd/quirks.c
+++ b/xen/drivers/passthrough/vtd/quirks.c
@@ -331,10 +331,12 @@ void __init platform_quirks_init(void)
  * assigning Intel integrated wifi device to a guest.
  */
 
-static void map_me_phantom_function(struct domain *domain, u32 dev, int map)
+static int __must_check map_me_phantom_function(struct domain *domain,
+u32 dev, int map)
 {
 struct acpi_drhd_unit *drhd;
 struct pci_dev *pdev;
+int rc;
 
 /* find ME VT-d engine base on a real ME device */
 pdev = pci_get_pdev(0, 0, PCI_DEVFN(dev, 0));
@@ -342,23 +344,26 @@ static void map_me_phantom_function(struct domain 
*domain, u32 dev, int map)
 
 /* map or unmap ME phantom function */
 if ( map )
-domain_context_mapping_one(domain, drhd->iommu, 0,
-   PCI_DEVFN(dev, 7), NULL);
+rc = domain_context_mapping_one(domain, drhd->iommu, 0,
+PCI_DEVFN(dev, 7), NULL);
 else
-domain_context_unmap_one(domain, drhd->iommu, 0,
- PCI_DEVFN(dev, 7));
+rc = domain_context_unmap_one(domain, drhd->iommu, 0,
+  PCI_DEVFN(dev, 7));
+
+return rc;
 }
 
-void me_wifi_quirk(struct domain *domain, u8 bus, u8 devfn, int map)
+int me_wifi_quirk(struct domain *domain, u8 bus, u8 devfn, int map)
 {
 u32 id;
+int rc = 0;
 
 id = pci_conf_read32(0, 0, 0, 0, 0);
 if ( IS_CTG(id) )
 {
 /* quit if ME does not exist */
 if ( pci_conf_read32(0, 0, 3, 0, 0) == 0x )
-return;
+return 0;
 
 /* if device is WLAN device, map ME phantom device 0:3.7 */
 id = pci_conf_read32(0, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), 0);
@@ -372,7 +377,7 @@ void me_wifi_quirk(struct domain *domain, u8 bus, u8 devfn, 
int map)
 case 0x423b8086:
 case 0x423c8086:
 case 0x423d8086:
-map_me_phantom_function(domain, 3, map);
+rc = map_me_phantom_function(domain, 3, map);
 break;
 default:
 break;
@@ -382,7 +387,7 @@ void me_wifi_quirk(struct domain *domain, u8 bus, u8 devfn, 
int map)
 {
 /* quit if ME does not exist */
 if ( pci_conf_read32(0, 0, 22, 0, 0) == 0x )
-return;
+return 0;
 
 /* if device is WLAN device, map ME phantom device 0:22.7 */
 id = pci_conf_read32(0, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), 0);
@@ -398,12 +403,14 @@ void me_wifi_quirk(struct domain *domain, u8 bus, u8 
devfn, int map)
 case 0x42388086:/* Puma Peak */
 case 0x422b8086:
  

[Xen-devel] [Patch v6 09/11] vt-d: fix the IOMMU flush issue

[Xu, Quan]

From: Quan Xu 

The propagation value from IOMMU flush interfaces may be positive, which
indicates callers need to flush cache, not one of faliures.

when the propagation value is positive, this patch fixes this flush issue
as follows:
  - call iommu_flush_write_buffer() to flush cache.
  - return zero.

Signed-off-by: Quan Xu 

CC: Kevin Tian 
CC: Feng Wu 
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 

v6:
  1. Drop blank lines.
  2. Change '(((u16)bus) << 8) | devfn' to 'PCI_BDF2(bus, devfn)'.
  3. Introduce rc for iommu_flush_context_device() / ret for
 iommu_flush_iotlb_dsi(), adding  ASSERT() behind.
  4. Enhance comments.
  5. Fix iommu_flush_context_*().
---
 xen/drivers/passthrough/vtd/iommu.c | 170 +++-
 1 file changed, 128 insertions(+), 42 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index 0788a59..720b867 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -388,17 +388,18 @@ static int flush_context_reg(
 return 0;
 }
 
-static int iommu_flush_context_global(
-struct iommu *iommu, int flush_non_present_entry)
+static int __must_check iommu_flush_context_global(struct iommu *iommu,
+   int flush_non_present_entry)
 {
 struct iommu_flush *flush = iommu_get_flush(iommu);
 return flush->context(iommu, 0, 0, 0, DMA_CCMD_GLOBAL_INVL,
  flush_non_present_entry);
 }
 
-static int iommu_flush_context_device(
-struct iommu *iommu, u16 did, u16 source_id,
-u8 function_mask, int flush_non_present_entry)
+static int __must_check iommu_flush_context_device(struct iommu *iommu,
+   u16 did, u16 source_id,
+   u8 function_mask,
+   int flush_non_present_entry)
 {
 struct iommu_flush *flush = iommu_get_flush(iommu);
 return flush->context(iommu, did, source_id, function_mask,
@@ -473,8 +474,9 @@ static int flush_iotlb_reg(void *_iommu, u16 did,
 return 0;
 }
 
-static int iommu_flush_iotlb_global(struct iommu *iommu,
-int flush_non_present_entry, int flush_dev_iotlb)
+static int __must_check iommu_flush_iotlb_global(struct iommu *iommu,
+ int flush_non_present_entry,
+ int flush_dev_iotlb)
 {
 struct iommu_flush *flush = iommu_get_flush(iommu);
 int status;
@@ -491,8 +493,9 @@ static int iommu_flush_iotlb_global(struct iommu *iommu,
 return status;
 }
 
-static int iommu_flush_iotlb_dsi(struct iommu *iommu, u16 did,
-int flush_non_present_entry, int flush_dev_iotlb)
+static int __must_check iommu_flush_iotlb_dsi(struct iommu *iommu, u16 did,
+  int flush_non_present_entry,
+  int flush_dev_iotlb)
 {
 struct iommu_flush *flush = iommu_get_flush(iommu);
 int status;
@@ -509,9 +512,10 @@ static int iommu_flush_iotlb_dsi(struct iommu *iommu, u16 
did,
 return status;
 }
 
-static int iommu_flush_iotlb_psi(
-struct iommu *iommu, u16 did, u64 addr, unsigned int order,
-int flush_non_present_entry, int flush_dev_iotlb)
+static int __must_check iommu_flush_iotlb_psi(struct iommu *iommu, u16 did,
+  u64 addr, unsigned int order,
+  int flush_non_present_entry,
+  int flush_dev_iotlb)
 {
 struct iommu_flush *flush = iommu_get_flush(iommu);
 int status;
@@ -546,17 +550,43 @@ static int __must_check iommu_flush_all(void)
 struct acpi_drhd_unit *drhd;
 struct iommu *iommu;
 int flush_dev_iotlb;
+int rc = 0;
 
 flush_all_cache();
 for_each_drhd_unit ( drhd )
 {
 iommu = drhd->iommu;
-iommu_flush_context_global(iommu, 0);
-flush_dev_iotlb = find_ats_dev_drhd(iommu) ? 1 : 0;
-iommu_flush_iotlb_global(iommu, 0, flush_dev_iotlb);
+/*
+ * The current logic for rc returns:
+ *   - positive  invoke iommu_flush_write_buffer to flush cache.
+ *   - zero  on success.
+ *   - negative  on failure. Continue to flush IOMMU IOTLB on a
+ *   best effort basis.
+ *
+ * Moreover, IOMMU flush handlers flush_context_qi and flush_iotlb_qi
+ * (or flush_context_reg and flush_iotlb_reg, deep functions in the
+ * call trees of iommu_flush_context_global and 
iommu_flush_iotlb_global)
+ * are with the same logic to bubble up positive return value.
+ */
+rc = 

[Xen-devel] [PATCH v2] arm/acpi: Add Server Base System Architecture UART support

[Shanker Donthineni]

The ARM Server Base System Architecture describes a generic UART
interface. It doesn't support clock control registers, modem
control, DMA and hardware flow control features. So, extend the
driver probe() to handle SBSA interface and skip the accessing
PL011 registers that are not described in SBSA document.

Signed-off-by: Shanker Donthineni 
---
Changes since v1:
   Don't access UART registers that are not part of SBSA document.
   Move setting baudrate function to a separate function.

 xen/drivers/char/pl011.c | 56 +++-
 1 file changed, 41 insertions(+), 15 deletions(-)

diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index 1212d5c..b57f3b0 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -41,6 +41,7 @@ static struct pl011 {
 /* struct timer timer; */
 /* unsigned int timeout_ms; */
 /* bool_t probing, intr_works; */
+bool sbsa;  /* ARM SBSA generic interface */
 } pl011_com = {0};
 
 /* These parity settings can be ORed directly into the LCR. */
@@ -81,17 +82,10 @@ static void pl011_interrupt(int irq, void *data, struct 
cpu_user_regs *regs)
 }
 }
 
-static void __init pl011_init_preirq(struct serial_port *port)
+static void __init pl011_init_baudrate(struct serial_port *port)
 {
 struct pl011 *uart = port->uart;
 unsigned int divisor;
-unsigned int cr;
-
-/* No interrupts, please. */
-pl011_write(uart, IMSC, 0);
-
-/* Definitely no DMA */
-pl011_write(uart, DMACR, 0x0);
 
 /* Line control and baud-rate generator. */
 if ( uart->baud != BAUD_AUTO )
@@ -114,6 +108,24 @@ static void __init pl011_init_preirq(struct serial_port 
*port)
 | FEN
 | ((uart->stop_bits - 1) << 3)
 | uart->parity);
+}
+
+static void __init pl011_init_preirq(struct serial_port *port)
+{
+struct pl011 *uart = port->uart;
+unsigned int cr;
+
+/* No interrupts, please. */
+pl011_write(uart, IMSC, 0);
+
+if ( !uart->sbsa )
+{
+/* Definitely no DMA */
+pl011_write(uart, DMACR, 0x0);
+
+/* Configure baudrate */
+   pl011_init_baudrate(port);
+}
 /* Clear errors */
 pl011_write(uart, RSR, 0);
 
@@ -121,10 +133,13 @@ static void __init pl011_init_preirq(struct serial_port 
*port)
 pl011_write(uart, IMSC, 0);
 pl011_write(uart, ICR, ALLI);
 
-/* Enable the UART for RX and TX; keep RTS and DTR */
-cr = pl011_read(uart, CR);
-cr &= RTS | DTR;
-pl011_write(uart, CR, cr | RXE | TXE | UARTEN);
+if ( !uart->sbsa )
+{
+/* Enable the UART for RX and TX; keep RTS and DTR */
+cr = pl011_read(uart, CR);
+cr &= RTS | DTR;
+pl011_write(uart, CR, cr | RXE | TXE | UARTEN);
+}
 }
 
 static void __init pl011_init_postirq(struct serial_port *port)
@@ -226,7 +241,7 @@ static struct uart_driver __read_mostly pl011_driver = {
 .vuart_info   = pl011_vuart,
 };
 
-static int __init pl011_uart_init(int irq, u64 addr, u64 size)
+static int __init pl011_uart_init(int irq, u64 addr, u64 size, bool sbsa)
 {
 struct pl011 *uart;
 
@@ -237,6 +252,7 @@ static int __init pl011_uart_init(int irq, u64 addr, u64 
size)
 uart->data_bits = 8;
 uart->parity= PARITY_NONE;
 uart->stop_bits = 1;
+uart->sbsa = sbsa;
 
 uart->regs = ioremap_nocache(addr, size);
 if ( !uart->regs )
@@ -285,7 +301,7 @@ static int __init pl011_dt_uart_init(struct dt_device_node 
*dev,
 return -EINVAL;
 }
 
-res = pl011_uart_init(res, addr, size);
+res = pl011_uart_init(res, addr, size, false);
 if ( res < 0 )
 {
 printk("pl011: Unable to initialize\n");
@@ -315,6 +331,7 @@ static int __init pl011_acpi_uart_init(const void *data)
 {
 acpi_status status;
 struct acpi_table_spcr *spcr = NULL;
+bool sbsa;
 int res;
 
 status = acpi_get_table(ACPI_SIG_SPCR, 0,
@@ -326,17 +343,21 @@ static int __init pl011_acpi_uart_init(const void *data)
 return -EINVAL;
 }
 
+sbsa = (spcr->interface_type == ACPI_DBG2_SBSA_32) ? true : false;
+
 /* trigger/polarity information is not available in spcr */
 irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH);
 
 res = pl011_uart_init(spcr->interrupt, spcr->serial_port.address,
-  PAGE_SIZE);
+  PAGE_SIZE, sbsa);
 if ( res < 0 )
 {
 printk("pl011: Unable to initialize\n");
 return res;
 }
 
+
+
 return 0;
 }
 
@@ -344,6 +365,11 @@ ACPI_DEVICE_START(apl011, "PL011 UART", DEVICE_SERIAL)
 .class_type = ACPI_DBG2_PL011,
 .init = pl011_acpi_uart_init,
 ACPI_DEVICE_END
+
+ACPI_DEVICE_START(asbsa32_uart, "SBSA32 UART", DEVICE_SERIAL)
+.class_type = ACPI_DBG2_SBSA_32,
+.init = pl011_acpi_uart_init,
+ACPI_DEVICE_END
 #endif
 
 /*
-- 
Qualcomm Technologies, Inc. on behalf of Qualcomm 

Re: [Xen-devel] 4.7 qemu regression: HVM guests fail to boot from xvda

[George Dunlap]

On Tue, May 31, 2016 at 1:10 PM, Jan Beulich  wrote:
 On 31.05.16 at 13:32,  wrote:
>> On Tue, May 31, 2016 at 12:16 PM, Olaf Hering  wrote:
>>> On Tue, May 31, George Dunlap wrote:
>>>
 On Mon, May 30, 2016 at 9:42 PM, Olaf Hering  wrote:
 > With staging-4.6 this domU boots from xvda, qemu creates an emulated
 > disk. With staging no disk is found, unless the name is changed to hda.
 > Looks like qemu-2.6 does not handle xvda either.

 This was intentional; see this thread:

 https://marc.info/?i=<1444820717-25565-1-git-send-email-anthony.per...@citrix.com>

 The idea was to make it possible to create an HVM guest with no
 emulated disks for guest booting with OVMF which contains PV drivers.
>>>
>>> This breaks the domU becasue it changes its device names from 'xvd' to
>>> 'hd' if a xenlinux based kernel is used in domU.
>>> In other words: every SUSE domU out there.
>>
>> Sorry, can you expand on this a bit?  Are you saying that on SuSE, if
>> you specify "vdev=xvda" in your config file, that you'll get PV
>> devices named "/dev/xvda", but that if you specify "vdev=hda", that
>> you'll get PV devices but named "/dev/hda"?
>
> And just to clarify - this isn't really SUSE-specific, this is how the old
> XenoLinux blkfront has always behaved. In fact when I saw this code
> gone from the upstream (pv-ops) variant, I think I had inquired how
> this is expected to be handling upgrade cases, and I don't think I got
> much of a useful answer to that.

Sure, but I think SuSE are basically the only distribution still using
XenoLinux, right?  Is there actually any open project maintaining the
XenoLinux fork?  If someone wanted to use XenoLinux, wouldn't their
options basically be 1) do all the forward-porting themselves from
some ancient 2.X tree, or 2) use SuSE's port?

Regarding an upgrade: fstab and other tools can be handed UUIDs; and
an enterprise-grade distribution could probably include udev scripts
to create symlinks, right?

The reality is though that the 'vdev=' way of specifying things is a
bit of a mess.  There's no way to specify, "Please make this
emulated-only (i.e., no backing PV drivers)"; there's no way of
hot-plugging in an emulated device;  

 -George

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[osstest service owner]

flight 94971 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94971/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. 
vs. 94748
 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 94748

version targeted for testing:
 ovmf 5c944a654a687a06e03b971120faace870dc91f7
baseline version:
 ovmf dc99315b8732b6e3032d01319d3f534d440b43d0

Last test of basis94748  2016-05-24 22:43:25 Z6 days
Failing since 94750  2016-05-25 03:43:08 Z6 days   19 attempts
Testing same since94971  2016-05-31 04:28:47 Z0 days1 attempts


People who touched revisions under test:
  Cohen, Eugene 
  Dandan Bi 
  Darbin Reyes 
  Eugene Cohen 
  Fu Siyuan 
  Fu, Siyuan 
  Gary Lin 
  Hao Wu 
  Jeff Fan 
  Jiaxin Wu 
  Katie Dellaquila 
  Laszlo Ersek 
  Liming Gao 
  Marvin H?user 
  Marvin Haeuser 
  Maurice Ma 
  Michael Zimmermann 
  Star Zeng 
  Yonghong Zhu 

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



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.

(No revision log; it would be 727 lines long.)

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] build: fix assembler instruction tests again

[Wei Liu]

On Tue, May 31, 2016 at 06:48:48AM -0600, Jan Beulich wrote:
> >>> On 31.05.16 at 14:25,  wrote:
> > On Mon, May 30, 2016 at 03:52:57AM -0600, Jan Beulich wrote:
> >> Commit 7fb252bd41 ("build/xen: fix assembler instruction tests") added
> >> $(AFLAGS) here, which results in all of those tests now failing.
> >> Certain items need to be removed for things to work again.
> >> 
> >> Signed-off-by: Jan Beulich 
> >> 
> > 
> > Release-acked-by: Wei Liu 
> 
> Thanks, but - does this also imply an ordinary (REST maintainer) ack
> by you?
> 

Oops, I should have been explicit. Sorry.

Acked-by: Wei Liu 


> Jan
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] build: fix assembler instruction tests again

[Jan Beulich]

>>> On 31.05.16 at 14:25,  wrote:
> On Mon, May 30, 2016 at 03:52:57AM -0600, Jan Beulich wrote:
>> Commit 7fb252bd41 ("build/xen: fix assembler instruction tests") added
>> $(AFLAGS) here, which results in all of those tests now failing.
>> Certain items need to be removed for things to work again.
>> 
>> Signed-off-by: Jan Beulich 
>> 
> 
> Release-acked-by: Wei Liu 

Thanks, but - does this also imply an ordinary (REST maintainer) ack
by you?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] kexec: allow relaxed placement specification via command line

[Jan Beulich]

>>> On 31.05.16 at 12:30,  wrote:
> On 30/05/16 14:48, Jan Beulich wrote:
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -1044,13 +1044,19 @@ void __init noreturn __start_xen(unsigne
>>  }
>>  
>>  #ifdef CONFIG_KEXEC
>> -/* Don't overlap with modules. */
>> -e = consider_modules(s, e, PAGE_ALIGN(kexec_crash_area.size),
>> - mod, mbi->mods_count, -1);
>> -if ( !kexec_crash_area.start && (s < e) )
> 
> I think we want a comment here.
> 
> /*
>  * Looking backwards from the crash area limit, find a large enough
>  * crash area that does not overlap with modules.
>  */

Sure, added.

>> +while ( !kexec_crash_area.start )
> 
> Does this mean that if an @ is specified we no longer check for
> overlapping modules?

We didn't do any more checking before. If you look at the old
code above, we called consider_modules() only to possibly alter
e. All the rest of the old code was similarly dependent upon
!kexec_crash_area.start. That other case is being taken care
of earlier anyway - see kexec_reserve_area()'s first invocation.

But yes, it looks like there's an overlap check missing there (iiuc
relevant really only for the initrd, as that's the only thing the
memory of which may not get copied but simply directly handed
to Dom0).

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] build: fix assembler instruction tests again

[Wei Liu]

On Mon, May 30, 2016 at 03:52:57AM -0600, Jan Beulich wrote:
> Commit 7fb252bd41 ("build/xen: fix assembler instruction tests") added
> $(AFLAGS) here, which results in all of those tests now failing.
> Certain items need to be removed for things to work again.
> 
> Signed-off-by: Jan Beulich 
> 

Release-acked-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] 4.7 qemu regression: HVM guests fail to boot from xvda

[Jan Beulich]

>>> On 31.05.16 at 14:00,  wrote:
> Really 'vdev' string in the the guest config file is only meant to
> tell libxl how it should behave -- it should ideally not have any
> effect on what devices you see in the backend.  And furthermore, it
> seems to me that when Linux upstream rejected the idea of the pv
> drivers stealing the "hd*" namespace, that SuSE's xenlinux should have
> followed suit and had the pv drivers only create devices named xvd*.
> 
> But I recognize if you're selling an enterprise kernel, those sorts of
> "you should have done this X years ago" doesn't really help you keep
> your promises to your users now. :-)

Not just that: We'd have had the problems converting guests
back then which we're having now. Yet I think such problems
shouldn't have got introduced in the first place. But yes, since
when would Linux maintainers care much about Xen-specific
issues... (And all of this is not to say that I'm convinced this
stealing of hd* and sd* name spaces was a good idea.)

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [qemu-upstream-4.3-testing test] 94979: trouble: blocked/broken

[osstest service owner]

flight 94979 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94979/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927

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-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  114 days
Testing same since93977  2016-05-10 11:09:16 Z   21 days   88 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

Re: [Xen-devel] 4.7 qemu regression: HVM guests fail to boot from xvda

[Jan Beulich]

>>> On 31.05.16 at 13:32,  wrote:
> On Tue, May 31, 2016 at 12:16 PM, Olaf Hering  wrote:
>> On Tue, May 31, George Dunlap wrote:
>>
>>> On Mon, May 30, 2016 at 9:42 PM, Olaf Hering  wrote:
>>> > With staging-4.6 this domU boots from xvda, qemu creates an emulated
>>> > disk. With staging no disk is found, unless the name is changed to hda.
>>> > Looks like qemu-2.6 does not handle xvda either.
>>>
>>> This was intentional; see this thread:
>>>
>>> https://marc.info/?i=<1444820717-25565-1-git-send-email-anthony.per...@citrix.com>
>>>
>>> The idea was to make it possible to create an HVM guest with no
>>> emulated disks for guest booting with OVMF which contains PV drivers.
>>
>> This breaks the domU becasue it changes its device names from 'xvd' to
>> 'hd' if a xenlinux based kernel is used in domU.
>> In other words: every SUSE domU out there.
> 
> Sorry, can you expand on this a bit?  Are you saying that on SuSE, if
> you specify "vdev=xvda" in your config file, that you'll get PV
> devices named "/dev/xvda", but that if you specify "vdev=hda", that
> you'll get PV devices but named "/dev/hda"?

And just to clarify - this isn't really SUSE-specific, this is how the old
XenoLinux blkfront has always behaved. In fact when I saw this code
gone from the upstream (pv-ops) variant, I think I had inquired how
this is expected to be handling upgrade cases, and I don't think I got
much of a useful answer to that.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] 4.7 qemu regression: HVM guests fail to boot from xvda

[Olaf Hering]

On Tue, May 31, George Dunlap wrote:

> Do you have a concrete proposal?

I have to give it some more thought what the impact really is, what
config variants are affected.

Olaf

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] 4.7 qemu regression: HVM guests fail to boot from xvda

[George Dunlap]

On Tue, May 31, 2016 at 12:41 PM, Olaf Hering  wrote:
> On Tue, May 31, George Dunlap wrote:
>
>> Sorry, can you expand on this a bit?  Are you saying that on SuSE, if
>> you specify "vdev=xvda" in your config file, that you'll get PV
>> devices named "/dev/xvda", but that if you specify "vdev=hda", that
>> you'll get PV devices but named "/dev/hda"?
>
> Yes, thats exactly what the xenlinux block frontend does.
> pvops forces xvda, independent of the name 'vdev' in domU.cfg.
> Up to xen-4.2 'vdev=hd*' was required to tell qemu to create an emulated
> disk to boot from. Starting with xen-4.3 qemu also recognized
> 'vdev=xvd*' for the emulated disk. And starting with xen-4.7 qemu
> requires 'xvda=hd*' again.
>
> I think if some domU.cfg for xen-4.3+ has 'vdev=xvd*' and the domU uses
> for some reason kernel names in config files and the domU uses a
> xenlinux kernel, then changing domU.cfg to 'hd*' will allow the guest to
> boot again. But its userland will miss the /dev/xvd* device nodes.
> That probably remained unnoticed during testing the referenced commit if
> a pvops based kernel was used.

Or if -- as is the case for most of my own test systems -- filesystem
UUIDs are used rather than device names.  (This means things work the
same on PV with PV disks, HVM with PV disks, and HVM with emulated
disks -- for instance, if you're using nested virtualization and your
L1 dom0 can't access L0 xenbus.)

Do you have a concrete proposal?

Anthony, does the OVMF-with-pv-only-drivers actually still work at the moment?

Really 'vdev' string in the the guest config file is only meant to
tell libxl how it should behave -- it should ideally not have any
effect on what devices you see in the backend.  And furthermore, it
seems to me that when Linux upstream rejected the idea of the pv
drivers stealing the "hd*" namespace, that SuSE's xenlinux should have
followed suit and had the pv drivers only create devices named xvd*.

But I recognize if you're selling an enterprise kernel, those sorts of
"you should have done this X years ago" doesn't really help you keep
your promises to your users now. :-)

 -George

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 3/4] VMX: Assign the right value to 'NDST' field in a concern case

[Jan Beulich]

>>> On 31.05.16 at 12:27,  wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Friday, May 27, 2016 10:00 PM
>> >>> On 26.05.16 at 15:39,  wrote:
>> > Normally, in vmx_cpu_block() 'NDST' filed should have the same
>> > value with 'dest' or 'MASK_INSR(dest, PI_xAPIC_NDST_MASK)' depending
>> > on whether x2apic is enabled. However, in the following scenario,
>> > 'NDST' has different value:
>> >
>> > 'vcpu_block' hook gets assigned in vmx_pi_hooks_assign(), but all
>> > other three PI hooks have not been assigned or not been excuted yet.
>> > And during this interval, we are running in vmx_vcpu_block(), then
>> > 'NDST' may have different value.
>> 
>> How about simply assigning vcpu_block last? Or alternatively
>> holding pi_blocking_list_lock around all four assignments? Or
>> (maybe in addition to one of these) writing something sensible in
>> vmx_pi_hooks_assign() before doing the hook assignments? 
> 
> The problem is vmx_vcpu_block() can still get called first, since
> the other ones might not get called yet.

That refers to the first two questions, yet the third (unanswered
one) was added by me because I anticipated that response. So
what's wrong with that last option?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 2/4] VMX: Cleanup PI per-cpu blocking list when vcpu is destroyed

[Jan Beulich]

>>> On 31.05.16 at 12:22,  wrote:

> 
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Friday, May 27, 2016 9:49 PM
>> To: Wu, Feng 
>> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
>> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
>> de...@lists.xen.org; konrad.w...@oracle.com; k...@xen.org 
>> Subject: Re: [PATCH v2 2/4] VMX: Cleanup PI per-cpu blocking list when vcpu 
> is
>> destroyed
>> 
>> >>> On 26.05.16 at 15:39,  wrote:
>> > --- a/xen/arch/x86/hvm/vmx/vmx.c
>> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> > @@ -366,6 +366,7 @@ static void vmx_vcpu_destroy(struct vcpu *v)
>> >  vmx_destroy_vmcs(v);
>> >  vpmu_destroy(v);
>> >  passive_domain_destroy(v);
>> > +vmx_pi_blocking_cleanup(v);
>> >  }
>> 
>> Isn't this redundant with the cleanup done when the last device
>> gets removed (via pci_release_devices()) during domain cleanup?
> 
> We need to handle the following two cases:
> - the last device gets removed (via 'xl pci-detach ...'), and the guest
> is running after that. The logical in vmx_pi_hooks_deassign() cover
> this case.
> - the guest is shutting down. It is covered here.

Exactly. Yet that latter case is already being taken care of by the
former: When the guest is shutting down, its last device will get
removed anyway.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 1/4] VMX: Properly handle pi when all the assigned devices are removed

[Jan Beulich]

>>> On 31.05.16 at 12:22,  wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Friday, May 27, 2016 9:43 PM
>> >>> On 26.05.16 at 15:39,  wrote:
>> > --- a/xen/arch/x86/hvm/vmx/vmx.c
>> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> > @@ -113,7 +113,19 @@ static void vmx_vcpu_block(struct vcpu *v)
>> >_cpu(vmx_pi_blocking, v->processor).lock;
>> >  struct pi_desc *pi_desc = >arch.hvm_vmx.pi_desc;
>> >
>> > -spin_lock_irqsave(pi_blocking_list_lock, flags);
>> > +spin_lock_irqsave(>arch.hvm_vmx.pi_hotplug_lock, flags);
>> > +if ( unlikely(v->arch.hvm_vmx.pi_blocking_cleaned_up) )
>> > +{
>> > +/*
>> > + * The vcpu is to be destroyed and it has already been removed
>> > + * from the per-CPU list if it is blocking, we shouldn't add
>> > + * new vCPU to the list.
>> > + */
>> 
>> This comment appears to be stale wrt the implementation further
>> down. But see there for whether it's the comment or the code
>> that need to change.
>> 
>> > +spin_unlock_irqrestore(>arch.hvm_vmx.pi_hotplug_lock, flags);
>> > +return;
>> > +}
>> > +
>> > +spin_lock(pi_blocking_list_lock);
>> 
>> There doesn't appear to be an active problem with this, but
>> taking a global lock inside a per-vCPU one feels bad. Both here
>> and in vmx_pi_blocking_cleanup() I can't see why the global
>> lock alone won't do - you acquire it anyway.
> 
> The purpose of ' v->arch.hvm_vmx.pi_hotplug_lock ' is to make
> sure things go right when vmx_pi_blocking_cleanup() and
> vmx_vcpu_block() are running concurrently. However, the lock
> 'pi_blocking_list_lock' in vmx_pi_blocking_cleanup() refers to
> ' v->arch.hvm_vmx.pi_blocking.lock ' while 'pi_blocking_list_lock'
> in vmx_vcpu_block() is '_cpu(vmx_pi_blocking, v->processor).lock'.
> These two can be different, please consider the following scenario:
> 
> vmx_pi_blocking_cleanup() gets called when the vcpu is in blocking
> state and 'v->arch.hvm_vmx.pi_blocking.lock' points to the per-cpu
> lock of pCPU0, and when acquiring the lock in this function, another
> one wins, (such as vmx_pi_do_resume() or pi_wakeup_interrupt()),
> so we are spinning in vmx_pi_blocking_cleanup(). After the vCPU
> is woken up, it is running on pCPU1, then sometime later, the vCPU
> is blocking again and in vmx_vcpu_block() and if the previous
> vmx_pi_blocking_cleanup() still doesn't finish its job. Then we
> acquire a different lock (it is pCPU1 this time)in vmx_vcpu_block()
> compared to the one in vmx_pi_blocking_cleanup. This can break
> things, since we might still put the vCPU to the per-cpu blocking list
> after vCPU is destroyed or the last assigned device is detached.

Makes sense. Then the next question is whether you really need
to hold both locks at the same time. Please understand that I'd
really prefer for this to have a simpler solution - the original code
was already more complicated than one would really think it should
be, and now it's getting worse. While I can't immediately suggest
alternatives, it feels like the solution to the current problem may
rather be simplification instead of making things even more
complicated.

>> >  void vmx_pi_hooks_deassign(struct domain *d)
>> >  {
>> > +struct vcpu *v;
>> > +
>> >  if ( !iommu_intpost || !has_hvm_container_domain(d) )
>> >  return;
>> >
>> > -ASSERT(d->arch.hvm_domain.vmx.vcpu_block);
>> > -
>> > -d->arch.hvm_domain.vmx.vcpu_block = NULL;
>> > -d->arch.hvm_domain.vmx.pi_switch_from = NULL;
>> > -d->arch.hvm_domain.vmx.pi_switch_to = NULL;
>> > -d->arch.hvm_domain.vmx.pi_do_resume = NULL;
>> > +for_each_vcpu ( d, v )
>> > +vmx_pi_blocking_cleanup(v);
>> 
>> If you keep the hooks in place, why is it relevant to do the cleanup
>> here instead of just at domain death? As suggested before, if you
>> did it there, you'd likely get away without adding the new per-vCPU
>> flag.
> 
> I don't quite understand this. Adding the cleanup here is to handle
> the corner case when the last assigned device is detached from the
> domain.

There's nothing to be cleaned up really if that de-assign isn't a
result of the domain being brought down.

> Why do you think we don't need to per-vCPU flag, we need
> to set it here to indicate that the vCPU is cleaned up, and in
> vmx_vcpu_block(), we cannot put the vCPUs with this flag set to the
> per-cpu blocking list. Do I miss something?

When clean up is done only at domain destruction time, there's
per-domain state already that can be checked instead of this
per-vCPU flag.

>> Furthermore, if things remain the way they are now, a per-domain
>> flag would suffice.
> 
> vmx_pi_blocking_cleanup() is called in vmx_cpu_destroy(), which can
> be called during domain destroy or vcpu_initialise() if it meets some
> errors. For the latter case, if we use per-domain flag and set it in
> vmx_pi_blocking_clean(), that should be problematic, since it will
> 

Re: [Xen-devel] 4.7 qemu regression: HVM guests fail to boot from xvda

[Olaf Hering]

On Tue, May 31, George Dunlap wrote:

> Sorry, can you expand on this a bit?  Are you saying that on SuSE, if
> you specify "vdev=xvda" in your config file, that you'll get PV
> devices named "/dev/xvda", but that if you specify "vdev=hda", that
> you'll get PV devices but named "/dev/hda"?

Yes, thats exactly what the xenlinux block frontend does.
pvops forces xvda, independent of the name 'vdev' in domU.cfg.
Up to xen-4.2 'vdev=hd*' was required to tell qemu to create an emulated
disk to boot from. Starting with xen-4.3 qemu also recognized
'vdev=xvd*' for the emulated disk. And starting with xen-4.7 qemu
requires 'xvda=hd*' again.

I think if some domU.cfg for xen-4.3+ has 'vdev=xvd*' and the domU uses
for some reason kernel names in config files and the domU uses a
xenlinux kernel, then changing domU.cfg to 'hd*' will allow the guest to
boot again. But its userland will miss the /dev/xvd* device nodes.
That probably remained unnoticed during testing the referenced commit if
a pvops based kernel was used.

Olaf

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] arm/acpi: Fix the deadlock in function vgic_lock_rank()

[Wei Liu]

On Tue, May 31, 2016 at 10:40:13AM +0100, Stefano Stabellini wrote:
> On Mon, 30 May 2016, Julien Grall wrote:
> > (CC Wei Liu)
> > 
> > Hi Stefano,
> > 
> > On 30/05/2016 14:16, Stefano Stabellini wrote:
> > > On Fri, 27 May 2016, Julien Grall wrote:
> > > > Hello Shanker,
> > > > 
> > > > On 27/05/16 01:39, Shanker Donthineni wrote:
> > > > > Commit 9d77b3c01d1261c (Configure SPI interrupt type and route to
> > > > > Dom0 dynamically) causing dead loop inside the spinlock function.
> > > > > Note that spinlocks in XEN are not recursive. Re-acquiring a spinlock
> > > > > that has already held by calling CPU leads to deadlock. This happens
> > > > > whenever dom0 does writes to GICD regs ISENABLER/ICENABLER.
> > > > 
> > > > Thank you for spotting it, I have not noticed it while I was  reviewing,
> > > > only
> > > > tested on a model without any SPIs.
> > > > 
> > > > > The following call trace explains the problem.
> > > > > 
> > > > > DOM0 writes GICD_ISENABLER/GICD_ICENABLER
> > > > >vgic_v3_distr_common_mmio_write()
> > > > >  vgic_lock_rank()  -->  acquiring first time
> > > > >vgic_enable_irqs()
> > > > >  route_irq_to_guest()
> > > > >gic_route_irq_to_guest()
> > > > >  vgic_get_target_vcpu()
> > > > >vgic_lock_rank()  -->  attemping acquired lock
> > > > > 
> > > > > The simple fix release spinlock before calling vgic_enable_irqs()
> > > > > and vgic_disable_irqs().
> > > > 
> > > > You should explain why you think it is valid to release the lock 
> > > > earlier.
> > > > 
> > > > In this case, I think the fix is not correct because the lock is
> > > > protecting
> > > > both the register value and the internal state in Xen (modified by
> > > > vgic_enable_irqs). By releasing the lock earlier, they may become
> > > > inconsistent
> > > > if another vCPU is disabling the IRQs at the same time.
> > > 
> > > I agree, the vgic_enable_irqs call need to stay within the
> > > vgic_lock_rank/vgic_unlock_rank region.
> > > 
> > > 
> > > > I cannot find an easy fix which does not involve release the lock. When 
> > > > I
> > > > was
> > > > reviewing this patch, I suggested to split the IRQ configuration from 
> > > > the
> > > > routing.
> > > 
> > > Yes, the routing doesn't need to be done from vgic_enable_irqs. It is
> > > not nice. That would be the ideal fix, but it is not trivial.
> > > 
> > > For 4.7 we could consider reverting 9d77b3c01d1261c. The only other
> > > thing that I can come up with which is simple would be improving
> > > gic_route_irq_to_guest to cope with callers that have the vgic rank lock
> > > already held (see below, untested) but it's pretty ugly.
> > 
> > We are close to release Xen 4.7, so I think we should avoid to touch the
> > common interrupt code (i.e not only used by ACPI).
> 
> Agreed. Wei, are you OK with this?
> 

Bare in mind that I haven't looked into the issue in details, but in
principle I agree we should avoid touching common code at this stage.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] build: fix assembler instruction tests again

[Roger Pau Monne]

On Mon, May 30, 2016 at 03:52:57AM -0600, Jan Beulich wrote:
> Commit 7fb252bd41 ("build/xen: fix assembler instruction tests") added
> $(AFLAGS) here, which results in all of those tests now failing.
> Certain items need to be removed for things to work again.
> 
> Signed-off-by: Jan Beulich 

Acked-by: Roger Pau Monné 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] 4.7 qemu regression: HVM guests fail to boot from xvda

[George Dunlap]

On Tue, May 31, 2016 at 12:16 PM, Olaf Hering  wrote:
> On Tue, May 31, George Dunlap wrote:
>
>> On Mon, May 30, 2016 at 9:42 PM, Olaf Hering  wrote:
>> > With staging-4.6 this domU boots from xvda, qemu creates an emulated
>> > disk. With staging no disk is found, unless the name is changed to hda.
>> > Looks like qemu-2.6 does not handle xvda either.
>>
>> This was intentional; see this thread:
>>
>> https://marc.info/?i=<1444820717-25565-1-git-send-email-anthony.per...@citrix.com>
>>
>> The idea was to make it possible to create an HVM guest with no
>> emulated disks for guest booting with OVMF which contains PV drivers.
>
> This breaks the domU becasue it changes its device names from 'xvd' to
> 'hd' if a xenlinux based kernel is used in domU.
> In other words: every SUSE domU out there.

Sorry, can you expand on this a bit?  Are you saying that on SuSE, if
you specify "vdev=xvda" in your config file, that you'll get PV
devices named "/dev/xvda", but that if you specify "vdev=hda", that
you'll get PV devices but named "/dev/hda"?

 -George

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[osstest service owner]

flight 94967 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94967/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-rtds  6 xen-boot   fail in 94959 pass in 94967
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat   fail pass in 94959

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  9 debian-install   fail blocked in 94959
 build-amd64-rumpuserxen   6 xen-buildfail   like 94959
 build-i386-rumpuserxen6 xen-buildfail   like 94959
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94959
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 94959
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 94959
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94959

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  8b3d6858ecbe5f958f45ac5d8e5da6fa5a18266d
baseline version:
 xen  8b3d6858ecbe5f958f45ac5d8e5da6fa5a18266d

Last test of basis94967  2016-05-31 01:56:51 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 16952 days0 attempts

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern   

Re: [Xen-devel] 4.7 qemu regression: HVM guests fail to boot from xvda

[Olaf Hering]

On Tue, May 31, George Dunlap wrote:

> On Mon, May 30, 2016 at 9:42 PM, Olaf Hering  wrote:
> > With staging-4.6 this domU boots from xvda, qemu creates an emulated
> > disk. With staging no disk is found, unless the name is changed to hda.
> > Looks like qemu-2.6 does not handle xvda either.
> 
> This was intentional; see this thread:
> 
> https://marc.info/?i=<1444820717-25565-1-git-send-email-anthony.per...@citrix.com>
> 
> The idea was to make it possible to create an HVM guest with no
> emulated disks for guest booting with OVMF which contains PV drivers.

This breaks the domU becasue it changes its device names from 'xvd' to
'hd' if a xenlinux based kernel is used in domU.
In other words: every SUSE domU out there.

Olaf

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V3] arm/gic-v3: Fix ACPI probe fail on GICv4 hardware

[Julien Grall]

Hi Shanker,

On 27/05/16 19:32, Shanker Donthineni wrote:

The current driver ACPI probe fails on hardware which has GICv4
version, even though it is fully compatible to GICv3. This patch
fixed the issue by registering the same probe function for GICv4
hardware.

Signed-off-by: Shanker Donthineni 


Acked-by: Julien Grall 

Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen/arm64: config: correct VMAP_VIRT_END

[Julien Grall]

Hi Peng,

On 27/05/16 11:23, Peng Fan wrote:

To ARM64, we should use '(VMAP_VIRT_START + GB(1))' as VMAP_VIRT_END,


s/To/For/


but not '(VMAP_VIRT_START + GB(1) - 1)'.

Seeing 'vm_end[type] = PFN_DOWN(end - start);' in vm_init_type,
if not correct VMAP_VIRT_END, one page is wasted.


I find difficult to parse the commit message. How about:

"xen/arm64: config: Correctly define VMAP_VIRT_END

The vmap initialization code (vm_init_type) will round down the end of 
the region to a page-aligned address.


On ARM64, the default vmap region is located between 1G and 2G. Based on 
the initialization code, the end address is excluded of the region.


Therefore the current definition of VMAP_VIRT_END will lead the vmap 
code to not use the last 4K of the region.


Fix it by defining VMAP_VIRT_END as "VMAP_VIRT_START + GB(1)".
"



Signed-off-by: Peng Fan 
Cc: Julien Grall 
Cc: Stefano Stabellini 
---

I found X86 use '(VMAP_VIRT_START + GB(64))' and ARM32 use XENHEAP_VIRT_START,
both are aligned address. So, I think ARM64 may also need to use aligned
address. I am not very sure (:


Correct, this should be aligned to avoid wasting a page.



  xen/include/asm-arm/config.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 2d11b62..f92c0a0 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -147,7 +147,7 @@
  #define SLOT0_ENTRY_SIZE  SLOT0(1)

  #define VMAP_VIRT_START  GB(1)
-#define VMAP_VIRT_END(VMAP_VIRT_START + GB(1) - 1)
+#define VMAP_VIRT_END(VMAP_VIRT_START + GB(1))

  #define FRAMETABLE_VIRT_START  GB(32)
  #define FRAMETABLE_SIZEGB(32)



Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] 4.7 qemu regression: HVM guests fail to boot from xvda

[George Dunlap]

On Mon, May 30, 2016 at 9:42 PM, Olaf Hering  wrote:
> With staging-4.6 this domU boots from xvda, qemu creates an emulated
> disk. With staging no disk is found, unless the name is changed to hda.
> Looks like qemu-2.6 does not handle xvda either.

This was intentional; see this thread:

https://marc.info/?i=<1444820717-25565-1-git-send-email-anthony.per...@citrix.com>

The idea was to make it possible to create an HVM guest with no
emulated disks for guest booting with OVMF which contains PV drivers.

 -George

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.7 1/2] build/clang: disable the usage of the integrated clang assembler

[Jan Beulich]

>>> On 31.05.16 at 12:31,  wrote:
> On Tue, May 31, 2016 at 02:16:49AM -0600, Jan Beulich wrote:
>> >>> On 30.05.16 at 18:27,  wrote:
>> > For all the build process, not only the assembly-only files.
>> > 
>> > This prevents assembling certain code with the integrated assembler, while
>> > other code would be assembled by the external assembler.
>> 
>> Without you giving a reason why this needs to be that way, I don't
>> think this is an acceptable change. I, for one, don't see why in a
>> clang build we shouldn't use as much of clang as possible (and hence
>> limit exceptions to a minimum).
> 
> For once, the external and the integrated assembler might have a different 
> set of features, so we would have to execute some of the checks twice 
> against each of them and then choose the minimum set of features that are 
> supported by both, IMHO we don't want to get down that road.

Why not? These checks already say which flags they want to update.
And I don't think many CONFIG_AS_* uses exist in .S files, so the
amount of redundancy (to also update AFLAGS) would be small (or
even zero).

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] kexec: allow relaxed placement specification via command line

[Jan Beulich]

>>> On 31.05.16 at 12:24,  wrote:
> On 30/05/16 14:48, Jan Beulich wrote:
>> Rather than just allowing a fixed address or fully automatic placement,
>> also allow for specifying an upper bound. Especially on EFI systems,
>> where firmware memory use is commonly less predictable than on legacy
>> BIOS ones, this makes success of the reservation more likely when
>> automatic placement is not an option (e.g. because of special DMA
>> restrictions of devices involved in actually carrying out the dump).
>>
>> Also take the opportunity to actually add text to the "crashkernel"
>> entry in the command line option doc.
>>
>> Signed-off-by: Jan Beulich 
>>
>> --- a/docs/misc/xen-command-line.markdown
>> +++ b/docs/misc/xen-command-line.markdown
>> @@ -458,7 +458,18 @@ Specify the maximum address to allocate
>>  combination with the `low_crashinfo` command line option.
>>  
>>  ### crashkernel
>> -> `= :[,...][@]`
>> +> `= :[,...][{@,<}]`
>> +> `= [{@,<}]`
>> +
>> +Specify sizes and optionally placement of the kexec reservation area.
>> +The `:' pairs indicate how much memory to set
> 
> For markdown, you need to use matching ` ` pairs for formatting the
> containing text as monospace.

Oh, okay. I meant to copy what was there, and now I see that
I didn't look right. Fixed.

> Other than this, Reviewed-by: Andrew Cooper 

Thanks, Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RESEND 00/14] Xen ARM DomU ACPI support

[Julien Grall]

Hi Shannon,

On 31/05/16 06:02, Shannon Zhao wrote:

From: Shannon Zhao 

The design of this feature is described as below.
Firstly, the toolstack (libxl) generates the ACPI tables according the
number of vcpus and gic controller.

Then, it copies these ACPI tables to DomU memory space and passes
them to UEFI firmware through the "ARM multiboot" protocol.

At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol
and installs these tables like the usual way and passes both ACPI and DT
information to the Xen DomU.

Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT tables
since it's enough now.

This has been tested using guest kernel with the Dom0 ACPI support
patches which could be fetched from:
https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen


Where can I find the UEFI firmware? What is the guest configuration to use?

Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] ARM Xen Bug #45: Is there a solution?

[Julien Grall]

Hello Dirk,

On 27/05/16 13:34, Dirk Behme wrote:

On 26.05.2016 11:00, Julien Grall wrote:

On 25/05/2016 16:10, Dirk Behme wrote:

On 24.05.2016 22:05, Julien Grall wrote:

On 24/05/2016 14:39, Dirk Behme wrote:

On 23.05.2016 22:15, Julien Grall wrote:

All the devices (UART included) used by Xen will return DOMID_XEN when
dt_device_used_by is called to the node.

You could use it to collect the clocks of all those devices and gather
the value in a single property to be created in the hypervisor node.



Anything like below (untested) [1]?


Yes.


I'm unhappy about the global variables and the max clocks, though.


How about moving those variables in the structure kernel_info?



Best regards

Dirk

[1]

---
  xen/arch/arm/domain_build.c |   24 
  1 file changed, 24 insertions(+)

Index: xen.git/xen/arch/arm/domain_build.c
===
--- xen.git.orig/xen/arch/arm/domain_build.c
+++ xen.git/xen/arch/arm/domain_build.c
@@ -42,6 +42,10 @@ static void __init parse_dom0_mem(const
  }
  custom_param("dom0_mem", parse_dom0_mem);

+#define MAX_DT_CLOCKS 256
+static unsigned char dt_clocks[MAX_DT_CLOCKS];
+static unsigned int clk_cnt;
+
  //#define DEBUG_DT

  #ifdef DEBUG_DT
@@ -657,6 +661,10 @@ static int make_hypervisor_node(const st
  if ( res )
  return res;

+res = fdt_property(fdt, "clocks", dt_clocks, clk_cnt);
+if ( res )
+return res;
+
  res = fdt_end_node(fdt);

  return res;
@@ -1213,9 +1221,11 @@ static int handle_node(struct domain *d,
  { /* sentinel */ },
  };
  struct dt_device_node *child;
+unsigned int len;
  int res;
  const char *name;
  const char *path;
+const char *clocks;

  path = dt_node_full_name(node);

@@ -1246,6 +1256,20 @@ static int handle_node(struct domain *d,
  if ( dt_device_used_by(node) == DOMID_XEN )
  {
  DPRINT("  Skip it (used by Xen)\n");
+
+/*
+ * Remember the clock used by the skipped node
+ * We add it later to the hypervisor node to make the
+ * Linux kernel aware of its usage
+ */
+clocks = dt_get_property(node, "clocks", );
+if ( clk_cnt + len >= MAX_DT_CLOCKS ) {
+printk("Failed to remember the clock node of %s\n", path);
+printk("Use the Linux kernel command 'clk_ignore_unused'\n");
+return 0;
+}
+memcpy(_clocks[clk_cnt], clocks, len);
+clk_cnt += len;
  return 0;
  }



--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/2] libfsimage: replace deprecated readdir_r() with readdir()

[George Dunlap]

On Mon, May 30, 2016 at 3:32 AM, Chris Patterson  wrote:
> From: Chris Patterson 
>
> Replace the usage of readdir_r() with readdir() to address
> a compilation error due to the deprecation of readdir_r.
>
> glibc has deprecated this for their next release (2.24):
> https://sourceware.org/bugzilla/show_bug.cgi?id=19056
>
> Signed-off-by: Chris Patterson 

Thanks for the patch, Chris.  A bit more background would have been
helpful -- I did some searching and found a description[1] which says:

In the current POSIX.1 specification (POSIX.1-2008), readdir(3) is
not required to be thread-safe.  However, in modern
implementations (including the glibc implementation), concurrent
calls to readdir(3) that specify different directory streams are
thread-safe.  Therefore, the use of readdir_r() is generally
unnecessary in multithreaded programs.  In cases where multiple
threads must read from the same directory stream, using readdir(3)
with external synchronization is still preferable to the use of
readdir_r(), for the reasons given in the points above.

The use of the specific directory stream is single-threaded, so for
glibc, it looks like using readdir() will be safe.  But libxl needs to
be able to build on a number of libc's that are not glibc and still be
thread-safe.  So we need to either 1) verify that readdir() is thread
safe on all libc's against which we may compile, or 2) add some
#ifdef-ery to switch to readdir_r() on systems unless we know it's
thread-safe.

I'm less familiar with best practices for this kind of thing -- Ian,
do you have an idea?

Thanks again for raising this, Chris.

 -George

[1] http://man7.org/linux/man-pages/man3/readdir_r.3.html

> ---
>  tools/libfsimage/common/fsimage_plugin.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/libfsimage/common/fsimage_plugin.c 
> b/tools/libfsimage/common/fsimage_plugin.c
> index 3fa06c7..03212e1 100644
> --- a/tools/libfsimage/common/fsimage_plugin.c
> +++ b/tools/libfsimage/common/fsimage_plugin.c
> @@ -147,7 +147,7 @@ static int load_plugins(void)
>
> bzero(dp, sizeof (struct dirent) + name_max + 1);
>
> -   while (readdir_r(dir, dp, ) == 0 && dpp != NULL) {
> +   while ((dpp = readdir(dir)) != NULL) {
> if (strcmp(dpp->d_name, ".") == 0)
> continue;
> if (strcmp(dpp->d_name, "..") == 0)
> --
> 2.1.4
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 15/15] xen/arm: arm64: Document Cortex-A57 erratum 834220

[Julien Grall]

Hi Stefano,

On 31/05/16 10:34, Stefano Stabellini wrote:

On Mon, 30 May 2016, Julien Grall wrote:

On 30/05/2016 17:19, Stefano Stabellini wrote:

"Erratum #834220: Xen needs to check that the Stage 1 translation does not
generate a fault before handling Stage 2 fault. If it is a stage 1
translation
fault, return to the guest to let the project injecting the correct fault.

XXX: This can be optimized to avoid some unnecessary translation."


What about adding a lengthy and detailed description of the erratum
elsewhere and just having a one liner at the call sites, such as:


I don't see any problem to have "lengthy" comment twice. It could actually be
3 lines because the last one is a TODO.


In my experience comments tend to be modified and when it happens, not
all the instances get always updated. That's why I would prefer to have
only one good explanation somewhere and then references to it.

That said, they are just comments, even if they don't get properly
updated the code won't break because of that (not immediately at least).
So I am not going to be headstrong on this.



I thought about merging some bits of do_trap_instr_abort_guest and
do_trap_data_abort_guest, but at first glance it is not that simple.


/* Erratum #834220: check Stage1 translation does not generate faults first!
*/

so that developers can easily grep for #834220 through the code to have
the full explanation?


Where would you put the full explanation? do_trap_hypervisor does not make
sense because it does not deal with the erratum. When we will come back in few
months time, we will wonder why the comment is there.


docs/misc/arm/silicon-errata.txt?
do_trap_instr_abort_guest or do_trap_data_abort_guest but not both (only
a reference in the other?


silicon-errata.txt could be a good place.

Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 10/15] xen/arm: Detect silicon revision and set cap bits accordingly

[Julien Grall]

Hi Stefano,

On 31/05/16 10:27, Stefano Stabellini wrote:

On Mon, 30 May 2016, Julien Grall wrote:

On 30/05/2016 16:02, Stefano Stabellini wrote:

On Mon, 23 May 2016, Julien Grall wrote:

After each CPU has been started, we iterate through a list of CPU
errata to detect CPUs which need from hypervisor code patches.

For each bug there is a function which check if that a particular CPU is
affected. This needs to be done on every CPUs to cover heterogenous
system properly.

If a certain erratum has been detected, the capability bit will be set
and later the call to apply_alternatives() will trigger the actual code
patching.

The code is based on the file arch/arm64/kernel/cpu_errata.c in Linux
v4.6-rc3.

Signed-off-by: Julien Grall 

---
 Changes in v2:
 - Use XENLOG_INFO for the loglevel of the message
---
  xen/arch/arm/Makefile|  1 +
  xen/arch/arm/cpuerrata.c | 26 ++
  xen/arch/arm/cpufeature.c| 16 
  xen/arch/arm/setup.c |  3 +++
  xen/arch/arm/smpboot.c   |  3 +++
  xen/include/asm-arm/cpuerrata.h  |  6 ++
  xen/include/asm-arm/cpufeature.h | 15 +++
  7 files changed, 70 insertions(+)
  create mode 100644 xen/arch/arm/cpuerrata.c
  create mode 100644 xen/include/asm-arm/cpuerrata.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 2d330aa..307578c 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -7,6 +7,7 @@ subdir-$(CONFIG_ACPI) += acpi
  obj-$(CONFIG_ALTERNATIVE) += alternative.o
  obj-y += bootfdt.o
  obj-y += cpu.o
+obj-y += cpuerrata.o
  obj-y += cpufeature.o
  obj-y += decode.o
  obj-y += device.o
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
new file mode 100644
index 000..52d39f8
--- /dev/null
+++ b/xen/arch/arm/cpuerrata.c
@@ -0,0 +1,26 @@
+#include 
+#include 
+#include 
+
+#define MIDR_RANGE(model, min, max) \
+.matches = is_affected_midr_range,  \
+.midr_model = model,\
+.midr_range_min = min,  \
+.midr_range_max = max
+
+static bool_t __maybe_unused


I would remove __maybe_unused given that you are going to use this
function in later patches.


The user can decide to disable all the errata, so this function will be
unused.

Also, if I drop the __may_unused now, the compilation will fail because nobody
is use it so far.


Ah, I see.



+is_affected_midr_range(const struct arm_cpu_capabilities *entry)
+{
+return MIDR_IS_CPU_MODEL_RANGE(boot_cpu_data.midr.bits,
entry->midr_model,
+   entry->midr_range_min,
+   entry->midr_range_max);
+}
+
+static const struct arm_cpu_capabilities arm_errata[] = {
+{},
+};
+
+void check_local_cpu_errata(void)
+{
+update_cpu_capabilities(arm_errata, "enabled workaround for");
+}


update_cpu_capabilities should actually be called on arm64 only, right?
Given that runtime patching is unimplemented on arm32. I wouldn't want
to rely on the fact that we don't have any arm32 workarounds at the
moment.


Whilst runtime patching is making use of the cpu features, not all the
features (or erratum) may require runtime patching.

So I deliberately keep this code enabled on ARM32.


All right. But then what is stopping people from reading
docs/misc/arm/silicon-errata.txt and trying to use it on arm32?


silicon-errata does not always mean runtime patching. It is possible to 
workaround in a different way (see for instance #834220 or #852523) or 
check a flag because it is not in hot path (such as erratum during the 
initialization).





diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
index 7a1b56b..088625b 100644
--- a/xen/arch/arm/cpufeature.c
+++ b/xen/arch/arm/cpufeature.c
@@ -24,6 +24,22 @@

  DECLARE_BITMAP(cpu_hwcaps, ARM_NCAPS);

+void update_cpu_capabilities(const struct arm_cpu_capabilities *caps,
+ const char *info)


The info parameter is unnecessary.


It is used in the printk below:

printk(XENLOG_INFO "%s: %s\n", info, caps[i].desc);


I know. Couldn't you just write the message directly below? It doesn't
look like that passing around that string is adding much value to the
code.


Because we will gain soon support of ARMv8.1 features which will use the 
same function to update the capabilities.


Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] OvmfPkg: Add ACPI support for Virt Xen ARM

[Laszlo Ersek]

On 05/31/16 06:59, Shannon Zhao wrote:
> From: Shannon Zhao 
> 
> Add ACPI support for Virt Xen ARM and it gets the ACPI tables through
> Xen ARM multiboot protocol.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Shannon Zhao 
> ---
> The corresponding Xen patches can be fetched from:
> http://git.linaro.org/people/shannon.zhao/xen.git/shortlog/refs/heads/domu_acpi
> ---
>  ArmVirtPkg/ArmVirtXen.dsc |   6 +
>  ArmVirtPkg/ArmVirtXen.fdf |   6 +
>  OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h|   6 +
>  OvmfPkg/AcpiPlatformDxe/XenArmAcpi.c  | 207 
> ++
>  OvmfPkg/AcpiPlatformDxe/XenArmAcpiPlatform.c  |  38 
>  OvmfPkg/AcpiPlatformDxe/XenArmAcpiPlatformDxe.inf |  59 ++
>  6 files changed, 322 insertions(+)
>  create mode 100644 OvmfPkg/AcpiPlatformDxe/XenArmAcpi.c
>  create mode 100644 OvmfPkg/AcpiPlatformDxe/XenArmAcpiPlatform.c
>  create mode 100644 OvmfPkg/AcpiPlatformDxe/XenArmAcpiPlatformDxe.inf

Jordan and I might disagree about this patch, but here's my comments
about it:

I don't think this patch belongs under OvmfPkg. Namely, the only file
that XenArmAcpiPlatformDxe reuses from the existing
OvmfPkg/AcpiPlatformDxe/ directory is "EntryPoint.c", which is (a)
trivial, (b) its conditions and branches should be possible to evaluate
statically for aarch64 Xen. (PcdPciDisableBusEnumeration should be set
to TRUE in ArmVirtXen.dsc.)

Second, the new code uses the FDT library directly (from EmbeddedPkg),
and accesses QEMU's DTB directly (with the fdt_*() APIs). However, in
ArmVirtPkg we have moved away from this, and now we have a custom
(edk2-only, non-standard) FdtClient protocol for accessing the FDT.
Please see:
- ArmVirtPkg/Include/Protocol/FdtClient.h
- ArmVirtPkg/FdtClientDxe/

In order to rebase this patch to the FDT Client Protocol, while keeping
it under OvmfPkg, the "XenArmAcpiPlatformDxe.inf" file would have to
list "ArmVirtPkg/ArmVirtPkg.dec" in the [Packages] section. I think that
would be very ugly. Thus far we have managed to avoid mutual references
between OvmfPkg and ArmVirtPkg: OvmfPkg doesn't consume anything from
ArmVirtPkg, and that's how things should stay in my opinion.

Which is why I suggest to implement this functionality entirely under
ArmVirtPkg, and using the FDT Client Protocol at that.

If a non-trivial chunk of functionality can be identified between
OvmfPkg and ArmVirtPkg in this regard (that currently exists under
OvmfPkg/AcpiPlatformDxe/), then it should be extracted into a library
(under OvmfPkg/Include/Library and OvmfPkg/Library), and the ArmVirtPkg
code should become a client of that library. (You can find many similar
OvmfPkg/Library/ resolutions in the ArmVirtPkg/ DSC files.)

NB: Ard is going to be on vacation for a while, and I think we should
definitely await his feedback on this. First, my participation in
ArmVirtXen matters is quite minimal. Second, Ard designed the FDT Client
Protocol; in case you need extensions to the current APIs for
implementing the feature, then Ard is the one to review them.

Thanks,
Laszlo

> diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
> index 594ca64..a0d197f 100644
> --- a/ArmVirtPkg/ArmVirtXen.dsc
> +++ b/ArmVirtPkg/ArmVirtXen.dsc
> @@ -216,3 +216,9 @@
>  
>OvmfPkg/XenBusDxe/XenBusDxe.inf
>OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
> +
> +  #
> +  # ACPI Support
> +  #
> +  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
> +  OvmfPkg/AcpiPlatformDxe/XenArmAcpiPlatformDxe.inf
> diff --git a/ArmVirtPkg/ArmVirtXen.fdf b/ArmVirtPkg/ArmVirtXen.fdf
> index 13412f9..da30e87 100644
> --- a/ArmVirtPkg/ArmVirtXen.fdf
> +++ b/ArmVirtPkg/ArmVirtXen.fdf
> @@ -179,6 +179,12 @@ READ_LOCK_STATUS   = TRUE
>INF OvmfPkg/XenBusDxe/XenBusDxe.inf
>INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
>  
> +  #
> +  # ACPI Support
> +  #
> +  INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
> +  INF OvmfPkg/AcpiPlatformDxe/XenArmAcpiPlatformDxe.inf
> +
>  [FV.FVMAIN_COMPACT]
>  FvAlignment= 16
>  ERASE_POLARITY = 1
> diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h 
> b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
> index 08dd7f8..325d7e6 100644
> --- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
> +++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
> @@ -69,6 +69,12 @@ InstallXenTables (
>  
>  EFI_STATUS
>  EFIAPI
> +InstallXenArmTables (
> +  IN   EFI_ACPI_TABLE_PROTOCOL   *AcpiProtocol
> +  );
> +
> +EFI_STATUS
> +EFIAPI
>  InstallQemuFwCfgTables (
>IN   EFI_ACPI_TABLE_PROTOCOL   *AcpiProtocol
>);
> diff --git a/OvmfPkg/AcpiPlatformDxe/XenArmAcpi.c 
> b/OvmfPkg/AcpiPlatformDxe/XenArmAcpi.c
> new file mode 100644
> index 000..c3a351c
> --- /dev/null
> +++ b/OvmfPkg/AcpiPlatformDxe/XenArmAcpi.c
> @@ -0,0 +1,207 @@
> +/** @file
> +  OVMF ACPI Xen ARM support
> +
> +  Copyright (C) 2016, Linaro Ltd. All rights reserved.
> +
> 

Re: [Xen-devel] [PATCH v2 4/4] VMX: fixup PI descritpor when cpu is offline

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, May 27, 2016 10:57 PM
> To: Wu, Feng 
> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
> de...@lists.xen.org; konrad.w...@oracle.com; k...@xen.org
> Subject: Re: [PATCH v2 4/4] VMX: fixup PI descritpor when cpu is offline
> 
> >>> On 26.05.16 at 15:39,  wrote:
> > @@ -102,9 +103,10 @@ void vmx_pi_per_cpu_init(unsigned int cpu)
> >  {
> >  INIT_LIST_HEAD(_cpu(vmx_pi_blocking, cpu).list);
> >  spin_lock_init(_cpu(vmx_pi_blocking, cpu).lock);
> > +per_cpu(vmx_pi_blocking, cpu).down = 0;
> 
> This seems pointless - per-CPU data starts out all zero (and there
> are various places already which rely on that).
> 
> > @@ -122,10 +124,25 @@ static void vmx_vcpu_block(struct vcpu *v)
> >   * new vCPU to the list.
> >   */
> >  spin_unlock_irqrestore(>arch.hvm_vmx.pi_hotplug_lock, flags);
> > -return;
> > +return 1;
> >  }
> >
> >  spin_lock(pi_blocking_list_lock);
> > +if ( unlikely(per_cpu(vmx_pi_blocking, v->processor).down) )
> 
> Is this something that can actually happen? vmx_pi_desc_fixup()
> runs in stop-machine context, i.e. no CPU can actively be here (or
> anywhere near the arch_vcpu_block() call sites).

This is related to scheduler, maybe Dario can give some input about
this. Dario?

> 
> > +{
> > +/*
> > + * We being here means that the v->processor is going away, and all
> > + * the vcpus on its blocking list were removed from it. Hence we
> > + * cannot add new vcpu to it. Besides that, we return -1 to
> > + * prevent the vcpu from being blocked. This is needed because
> > + * if the vCPU is continue to block and here we don't put it
> > + * in a per-cpu blocking list, it might not be woken up by the
> > + * notification event.
> > + */
> > +spin_unlock(pi_blocking_list_lock);
> > +spin_unlock_irqrestore(>arch.hvm_vmx.pi_hotplug_lock, flags);
> > +return 0;
> 
> The comment says you mean to return -1 here...
> 
> > +void vmx_pi_desc_fixup(int cpu)
> 
> unsigned int
> 
> > +{
> > +unsigned int new_cpu, dest;
> > +unsigned long flags;
> > +struct arch_vmx_struct *vmx, *tmp;
> > +spinlock_t *new_lock, *old_lock = _cpu(vmx_pi_blocking, cpu).lock;
> > +struct list_head *blocked_vcpus = _cpu(vmx_pi_blocking, cpu).list;
> > +
> > +if ( !iommu_intpost )
> > +return;
> > +
> > +spin_lock_irqsave(old_lock, flags);
> > +per_cpu(vmx_pi_blocking, cpu).down = 1;
> > +
> > +list_for_each_entry_safe(vmx, tmp, blocked_vcpus, pi_blocking.list)
> > +{
> > +/*
> > + * We need to find an online cpu as the NDST of the PI descriptor, 
> > it
> > + * doesn't matter whether it is within the cpupool of the domain or
> > + * not. As long as it is online, the vCPU will be woken up once the
> > + * notification event arrives.
> > + */
> > +new_cpu = cpu;
> > +restart:
> 
> Labels indented by at least one blank please. Or even better, get
> things done without goto.
> 
> > +while ( 1 )
> > +{
> > +new_cpu = (new_cpu + 1) % nr_cpu_ids;
> > +if ( cpu_online(new_cpu) )
> > +break;
> > +}
> 
> Please don't open code things like cpumask_cycle(). But with the
> restart logic likely unnecessary (see below), this would probably
> better become cpumask_any() then.
> 
> > +new_lock = _cpu(vmx_pi_blocking, cpu).lock;
> 
> DYM new_cpu here? In fact with ...
> 
> > +spin_lock(new_lock);
> 
> ... this I can't see how you would have successfully tested this
> new code path, as I can't see how this would end in other than
> a deadlock (as you hold this very lock already).
> 
> > +/*
> > + * After acquiring the blocking list lock for the new cpu, we need
> > + * to check whether new_cpu is still online.
> 
> How could it have gone offline? 

And I think this also needs Dario's confirm, as he is the scheduler expert.

> As mentioned, CPUs get brought
> down in stop-machine context (and btw for the very reason of
> avoiding complexity like this).
> 
> > + * If '.down' is true, it mean 'new_cpu' is also going to be 
> > offline,
> > + * so just go back to find another one, otherwise, there are two
> > + * possibilities:
> > + *   case 1 - 'new_cpu' is online.
> > + *   case 2 - 'new_cpu' is about to be offline, but doesn't get to
> > + *the point where '.down' is set.
> > + * In either case above, we can just set 'new_cpu' to 'NDST' field.
> > + * For case 2 the 'NDST' field will be set to another online cpu 
> > when
> > + * we get to this function for 'new_cpu' some time later.
> > +   

Re: [Xen-devel] [PATCH for-4.7 1/2] build/clang: disable the usage of the integrated clang assembler

[Roger Pau Monne]

On Tue, May 31, 2016 at 02:16:49AM -0600, Jan Beulich wrote:
> >>> On 30.05.16 at 18:27,  wrote:
> > For all the build process, not only the assembly-only files.
> > 
> > This prevents assembling certain code with the integrated assembler, while
> > other code would be assembled by the external assembler.
> 
> Without you giving a reason why this needs to be that way, I don't
> think this is an acceptable change. I, for one, don't see why in a
> clang build we shouldn't use as much of clang as possible (and hence
> limit exceptions to a minimum).

For once, the external and the integrated assembler might have a different 
set of features, so we would have to execute some of the checks twice 
against each of them and then choose the minimum set of features that are 
supported by both, IMHO we don't want to get down that road.

Roger.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] kexec: allow relaxed placement specification via command line

[David Vrabel]

On 30/05/16 14:48, Jan Beulich wrote:
> Rather than just allowing a fixed address or fully automatic placement,
> also allow for specifying an upper bound. Especially on EFI systems,
> where firmware memory use is commonly less predictable than on legacy
> BIOS ones, this makes success of the reservation more likely when
> automatic placement is not an option (e.g. because of special DMA
> restrictions of devices involved in actually carrying out the dump).
> 
> Also take the opportunity to actually add text to the "crashkernel"
> entry in the command line option doc.

> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -1044,13 +1044,19 @@ void __init noreturn __start_xen(unsigne
>  }
>  
>  #ifdef CONFIG_KEXEC
> -/* Don't overlap with modules. */
> -e = consider_modules(s, e, PAGE_ALIGN(kexec_crash_area.size),
> - mod, mbi->mods_count, -1);
> -if ( !kexec_crash_area.start && (s < e) )

I think we want a comment here.

/*
 * Looking backwards from the crash area limit, find a large enough
 * crash area that does not overlap with modules.
 */

> +while ( !kexec_crash_area.start )

Does this mean that if an @ is specified we no longer check for
overlapping modules?

>  {
> -e = (e - kexec_crash_area.size) & PAGE_MASK;
> -kexec_crash_area.start = e;
> +/* Don't overlap with modules. */
> +e = consider_modules(s, e, PAGE_ALIGN(kexec_crash_area.size),
> + mod, mbi->mods_count, -1);
> +if ( s >= e )
> +break;
> +if ( e > kexec_crash_area_limit )
> +{
> +e = kexec_crash_area_limit & PAGE_MASK;
> +continue;
> +}
> +kexec_crash_area.start = (e - kexec_crash_area.size) & PAGE_MASK;
>  }
>  #endif
>  }

David


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 3/4] VMX: Assign the right value to 'NDST' field in a concern case

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, May 27, 2016 10:00 PM
> To: Wu, Feng 
> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
> de...@lists.xen.org; konrad.w...@oracle.com; k...@xen.org
> Subject: Re: [PATCH v2 3/4] VMX: Assign the right value to 'NDST' field in a
> concern case
> 
> >>> On 26.05.16 at 15:39,  wrote:
> > Normally, in vmx_cpu_block() 'NDST' filed should have the same
> > value with 'dest' or 'MASK_INSR(dest, PI_xAPIC_NDST_MASK)' depending
> > on whether x2apic is enabled. However, in the following scenario,
> > 'NDST' has different value:
> >
> > 'vcpu_block' hook gets assigned in vmx_pi_hooks_assign(), but all
> > other three PI hooks have not been assigned or not been excuted yet.
> > And during this interval, we are running in vmx_vcpu_block(), then
> > 'NDST' may have different value.
> 
> How about simply assigning vcpu_block last? Or alternatively
> holding pi_blocking_list_lock around all four assignments? Or
> (maybe in addition to one of these) writing something sensible in
> vmx_pi_hooks_assign() before doing the hook assignments? 

The problem is vmx_vcpu_block() can still get called first, since
the other ones might not get called yet.

> Of course much depends on whether the ASSERT() you replace was
> meant just as a sanity check, or instead logic elsewhere relies on
> NDST having the right value already before getting into
> vmx_vcpu_block().

The point is we need to make sure NDST have the right value
after leaving vmx_vcpu_block().

> 
> Also, rather than saying twice that NDST has a different value in
> that case, how about stating what exact value it has then and
> why that's not what we want/need? (Same goes for the code
> comment then.)

Sure, will add this in the next version.

> 
> > This patch fix this concern case.
> 
> Here as well as in earlier patches - do you perhaps mean "corner
> case"?

Sorry for the typo.

Thanks,
Feng

> 
> Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] kexec: allow relaxed placement specification via command line

[Andrew Cooper]

On 30/05/16 14:48, Jan Beulich wrote:
> Rather than just allowing a fixed address or fully automatic placement,
> also allow for specifying an upper bound. Especially on EFI systems,
> where firmware memory use is commonly less predictable than on legacy
> BIOS ones, this makes success of the reservation more likely when
> automatic placement is not an option (e.g. because of special DMA
> restrictions of devices involved in actually carrying out the dump).
>
> Also take the opportunity to actually add text to the "crashkernel"
> entry in the command line option doc.
>
> Signed-off-by: Jan Beulich 
>
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -458,7 +458,18 @@ Specify the maximum address to allocate
>  combination with the `low_crashinfo` command line option.
>  
>  ### crashkernel
> -> `= :[,...][@]`
> +> `= :[,...][{@,<}]`
> +> `= [{@,<}]`
> +
> +Specify sizes and optionally placement of the kexec reservation area.
> +The `:' pairs indicate how much memory to set

For markdown, you need to use matching ` ` pairs for formatting the
containing text as monospace.

Other than this, Reviewed-by: Andrew Cooper 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC 10/16] xen/arm: Introduce alternative runtime patching

[Julien Grall]

Hi Stefano,

On 31/05/16 10:21, Stefano Stabellini wrote:

On Mon, 30 May 2016, Julien Grall wrote:

Hi Stefano,

On 30/05/2016 15:45, Stefano Stabellini wrote:

On Mon, 23 May 2016, Julien Grall wrote:

Hi Stefano,

On 21/05/16 16:09, Stefano Stabellini wrote:

On Thu, 5 May 2016, Julien Grall wrote:

+void __init apply_alternatives_all(void)
+{
+int ret;
+
+   /* better not try code patching on a live SMP system */
+ret = stop_machine_run(__apply_alternatives_multi_stop, NULL,
NR_CPUS);


Why not just call stop_machine_run, passing 0 as the cpu to run
__apply_alternatives_multi_stop on? Given that you already have
secondary cpus spinning in __apply_alternatives_multi_stop.  What am I
missing?


Someone as to call __apply_alternatives_multi_stop on secondary CPUs.


Why? Secondary cpus would be just left spinning at the beginning of the
function. You might as well leave them spinning in
stopmachine_wait_state.



Because, we may need to patch the stop_machine state machine (spinlock,...).
So the safest place whilst the code is patched is
__apply_alternatives_multi_stop.

Note that there is a comment on top of __apply_alternatives_multi_stop to
explain the reason.


Have you tried patching stop_machine? What if you need to patch
__apply_alternatives_multi_stop? :-)


We have to define a safe place where the CPUs could spin. I.e the 
instructions will not be patched.
Whilst stop_machine may not be patched today, it is common code and we 
don't know how this will evolve in the future.


By spinning in __apply_alternatives_multi_stop we protect us against 
modification in the common code and tricky bug (yes it might be 
difficult to hit and debug).


Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 2/4] VMX: Cleanup PI per-cpu blocking list when vcpu is destroyed

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, May 27, 2016 9:49 PM
> To: Wu, Feng 
> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
> de...@lists.xen.org; konrad.w...@oracle.com; k...@xen.org
> Subject: Re: [PATCH v2 2/4] VMX: Cleanup PI per-cpu blocking list when vcpu is
> destroyed
> 
> >>> On 26.05.16 at 15:39,  wrote:
> > --- a/xen/arch/x86/hvm/vmx/vmx.c
> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
> > @@ -366,6 +366,7 @@ static void vmx_vcpu_destroy(struct vcpu *v)
> >  vmx_destroy_vmcs(v);
> >  vpmu_destroy(v);
> >  passive_domain_destroy(v);
> > +vmx_pi_blocking_cleanup(v);
> >  }
> 
> Isn't this redundant with the cleanup done when the last device
> gets removed (via pci_release_devices()) during domain cleanup?

We need to handle the following two cases:
- the last device gets removed (via 'xl pci-detach ...'), and the guest
is running after that. The logical in vmx_pi_hooks_deassign() cover
this case.
- the guest is shutting down. It is covered here.

Thanks,
Feng

> 
> Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 1/4] VMX: Properly handle pi when all the assigned devices are removed

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, May 27, 2016 9:43 PM
> To: Wu, Feng 
> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
> de...@lists.xen.org; konrad.w...@oracle.com; k...@xen.org
> Subject: Re: [PATCH v2 1/4] VMX: Properly handle pi when all the assigned
> devices are removed
> 
> >>> On 26.05.16 at 15:39,  wrote:
> > --- a/xen/arch/x86/hvm/vmx/vmx.c
> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
> > @@ -113,7 +113,19 @@ static void vmx_vcpu_block(struct vcpu *v)
> > _cpu(vmx_pi_blocking, v->processor).lock;
> >  struct pi_desc *pi_desc = >arch.hvm_vmx.pi_desc;
> >
> > -spin_lock_irqsave(pi_blocking_list_lock, flags);
> > +spin_lock_irqsave(>arch.hvm_vmx.pi_hotplug_lock, flags);
> > +if ( unlikely(v->arch.hvm_vmx.pi_blocking_cleaned_up) )
> > +{
> > +/*
> > + * The vcpu is to be destroyed and it has already been removed
> > + * from the per-CPU list if it is blocking, we shouldn't add
> > + * new vCPU to the list.
> > + */
> 
> This comment appears to be stale wrt the implementation further
> down. But see there for whether it's the comment or the code
> that need to change.
> 
> > +spin_unlock_irqrestore(>arch.hvm_vmx.pi_hotplug_lock, flags);
> > +return;
> > +}
> > +
> > +spin_lock(pi_blocking_list_lock);
> 
> There doesn't appear to be an active problem with this, but
> taking a global lock inside a per-vCPU one feels bad. Both here
> and in vmx_pi_blocking_cleanup() I can't see why the global
> lock alone won't do - you acquire it anyway.

The purpose of ' v->arch.hvm_vmx.pi_hotplug_lock ' is to make
sure things go right when vmx_pi_blocking_cleanup() and
vmx_vcpu_block() are running concurrently. However, the lock
'pi_blocking_list_lock' in vmx_pi_blocking_cleanup() refers to
' v->arch.hvm_vmx.pi_blocking.lock ' while 'pi_blocking_list_lock'
in vmx_vcpu_block() is '_cpu(vmx_pi_blocking, v->processor).lock'.
These two can be different, please consider the following scenario:

vmx_pi_blocking_cleanup() gets called when the vcpu is in blocking
state and 'v->arch.hvm_vmx.pi_blocking.lock' points to the per-cpu
lock of pCPU0, and when acquiring the lock in this function, another
one wins, (such as vmx_pi_do_resume() or pi_wakeup_interrupt()),
so we are spinning in vmx_pi_blocking_cleanup(). After the vCPU
is woken up, it is running on pCPU1, then sometime later, the vCPU
is blocking again and in vmx_vcpu_block() and if the previous
vmx_pi_blocking_cleanup() still doesn't finish its job. Then we
acquire a different lock (it is pCPU1 this time)in vmx_vcpu_block()
compared to the one in vmx_pi_blocking_cleanup. This can break
things, since we might still put the vCPU to the per-cpu blocking list
after vCPU is destroyed or the last assigned device is detached.

> 
> > +static void vmx_pi_blocking_cleanup(struct vcpu *v)
> > +{
> > +unsigned long flags;
> > +spinlock_t *pi_blocking_list_lock;
> > +
> > +if ( !iommu_intpost )
> > +return;
> 
> If the function is to remain to be called from just the body of a loop
> over all vCPU-s, please make that loop conditional upon iommu_intpost
> instead of checking it here (and bailing) for every vCPU.
> 
> > +spin_lock_irqsave(>arch.hvm_vmx.pi_hotplug_lock, flags);
> > +v->arch.hvm_vmx.pi_blocking_cleaned_up = 1;
> > +
> > +pi_blocking_list_lock = v->arch.hvm_vmx.pi_blocking.lock;
> > +if (pi_blocking_list_lock == NULL)
> 
> Coding style.
> 
> > +{
> > +spin_unlock_irqrestore(>arch.hvm_vmx.pi_hotplug_lock, flags);
> > +return;
> > +}
> > +
> > +spin_lock(pi_blocking_list_lock);
> > +if ( v->arch.hvm_vmx.pi_blocking.lock != NULL )
> > +{
> > +ASSERT(v->arch.hvm_vmx.pi_blocking.lock == pi_blocking_list_lock);
> > +list_del(>arch.hvm_vmx.pi_blocking.list);
> > +v->arch.hvm_vmx.pi_blocking.lock = NULL;
> > +}
> > +spin_unlock(pi_blocking_list_lock);
> > +spin_unlock_irqrestore(>arch.hvm_vmx.pi_hotplug_lock, flags);
> > +}
> > +
> >  /* This function is called when pcidevs_lock is held */
> >  void vmx_pi_hooks_assign(struct domain *d)
> >  {
> > +struct vcpu *v;
> > +
> >  if ( !iommu_intpost || !has_hvm_container_domain(d) )
> >  return;
> >
> > -ASSERT(!d->arch.hvm_domain.vmx.vcpu_block);
> > +for_each_vcpu ( d, v )
> > +v->arch.hvm_vmx.pi_blocking_cleaned_up = 0;
> >
> > -d->arch.hvm_domain.vmx.vcpu_block = vmx_vcpu_block;
> > -d->arch.hvm_domain.vmx.pi_switch_from = vmx_pi_switch_from;
> > -d->arch.hvm_domain.vmx.pi_switch_to = vmx_pi_switch_to;
> > -d->arch.hvm_domain.vmx.pi_do_resume = vmx_pi_do_resume;
> > +if ( !d->arch.hvm_domain.vmx.vcpu_block )
> > +{
> > +d->arch.hvm_domain.vmx.vcpu_block = vmx_vcpu_block;
> > +

Re: [Xen-devel] [PATCH v2 0/4] VMX: Properly handle pi descriptor and per-cpu blocking list

[Wu, Feng]

> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Friday, May 27, 2016 1:21 AM
> To: Wu, Feng ; xen-devel@lists.xen.org
> Cc: k...@xen.org; Tian, Kevin ; jbeul...@suse.com;
> andrew.coop...@citrix.com; george.dun...@eu.citrix.com;
> konrad.w...@oracle.com
> Subject: Re: [PATCH v2 0/4] VMX: Properly handle pi descriptor and per-cpu
> blocking list
> 
> Hi Feng,
> 
> On Thu, 2016-05-26 at 21:39 +0800, Feng Wu wrote:
> > Feng Wu (4):
> >   VMX: Properly handle pi when all the assigned devices are removed
> >   VMX: Cleanup PI per-cpu blocking list when vcpu is destroyed
> >   VMX: Assign the right value to 'NDST' field in a concern case
> >   VMX: fixup PI descritpor when cpu is offline
> >
> I need some time to carefully look at this series, and I don't have
> such amount of time right now. I'll try to look at it and send my
> comments either tomorrow or on Monday.

Thanks for your time!

> 
> However, allow me to just say that, from a quick glance, the various
> solutions does not look really convincing to me. Basically, you've
> added:
>  - a couple of flags (pi_blocking_cleaned_up, down)
>  - a new spinlock (pi_hotplug_lock)
> 
> And yet, neither the various changelogs, nor code comments explain much
> about what the lock serializes and protects, and/or what the flags
> represent ad how they should be used.
> 
> So, if you want try argumenting a bit on what was your line of
> reasoning when doing things this way, that would be helpful (at least
> to me).

'pi_hotplug_lock' is trying to protect the following scenario:
vmx_pi_blocking_cleanup() gets called either when the last assigned
device is detached or the vCPU is going to be destroyed, and at the
same time vmx_vcpu_block() is running. We need to make sure
after all the blocking vCPU is cleaned up, we should not add new
vCPU to the per-cpu blocking list. And that is why I introduce
' pi_blocking_cleaned_up' for each vCPU, which being set to
1 means that we cannot add it to the blocking list in vmx_vcpu_block().

For the other flag 'down', it is used for the following scenario:
When a pCPU is going away and meanwhile vmx_vcpu_block() is
called, we should not put the vCPU to a per-cpu blocking list, which
is going away. Another usage of 'down' is to control that the online
cpu we choose in vmx_pi_desc_fixup() is not going away as mentioned
in the comments in this function.

> 
> I'm also non-convinced that, in patch 4, the right thing to do is to
> just to pick-up a random online pCPU. At some point, during v1 review,
> I mentioned arch_move_irqs(), because it seemed to me the place from
> where you actually have the proper information available (i.e., where
> the vcpu is actually going, e.g. because the pCPU is on is going
> away!). It may well be the case that I'm wrong about it being suitable,
> and I'll look better at what you actually have implemented, but at a
> first glance, it looks cumbersome.
> 
> For instance, now arch_vcpu_block() returns a value and, as you say
> yourself in a comment, that is for (potentially) preventing a vcpu to
> block. So the behavior of schedule.c:vcpu_block(), now depends on your
> new flag per_cpu(vmx_pi_blocking, v->processor).down. Again, I'll look
> better, but this has few chances of being right (at least logically).

Like in vcpu_block(),it will check events before actually blocking the vcpu,
here we just introduce another case in which the vCPU cannot be blocked.
I don't know why you think this is problematic?

> 
> Finally, you're calling *per-vCPU* things foo_hotplug_bar, which is
> rather confusing, as it makes one thinking that they're related to
> *pCPU* hotplug.

The purpose is, we need to remove the vCPUs in the blocking list
of the pCPU which is about to go away. Do you think how should we
do for it?

Thanks,
Feng

> 
> Thanks and Regards,
> Dario
> --
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] VMX: relax incoming BNDCFGS check

[Andrew Cooper]

On 30/05/16 11:05, Jan Beulich wrote:
> Accepting zero here even when !cpu_has_mpx makes the restore side
> symmetric to the save logic (which avoids saving the value if zero),
> i.e. makes either side independent of the logic on the other side.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen: xen-pciback: Remove create_workqueue

[David Vrabel]

On 27/05/16 17:32, Konrad Rzeszutek Wilk wrote:
> On Fri, May 27, 2016 at 12:08:22PM -0400, Tejun Heo wrote:
>> Hello,
>>
>> On Fri, May 27, 2016 at 12:01:14PM -0400, Konrad Rzeszutek Wilk wrote:
>>> On Fri, May 27, 2016 at 09:24:11PM +0530, Bhaktipriya Shridhar wrote:
 With concurrency managed workqueues, use of dedicated workqueues can be
 replaced by using system_wq. Drop host->intr_wq by using
>>   ^
>>xen_pcibk_wq
 system_wq.

 Since there is only a single work item, increase of concurrency level by
 switching to system_wq should not break anything.
>>>
>>> _should_ not? Hehe. I presume this has not been tested?
>>
>> Yeah, this is a part of sweeping conversions and it's challenging (and
>> often impossible for specific drivers) to setup test environments.
>> xen isn't as bad but can still be a pretty specialized setup.  The
>> conversions aren't high risk and shouldn't be too difficult to root
>> cause when something goes south.  We'd greatly appreciate any helps
>> with reviewing and testing.
>>
 cancel_work_sync() has been used in xen_pcibk_disconnect() to ensure that
 work item is not pending or executing by the time exit path runs.

 Signed-off-by: Bhaktipriya Shridhar 
 @@ -76,8 +75,7 @@ static void xen_pcibk_disconnect(struct xen_pcibk_device 
 *pdev)
/* If the driver domain started an op, make sure we complete it
 * before releasing the shared memory */

 -  /* Note, the workqueue does not use spinlocks at all.*/
 -  flush_workqueue(xen_pcibk_wq);
 +  cancel_work_sync(>op_work);
>>
>> Should it be flush_work() instead?  Is it okay for a pdev->op_work to
>> be queued and canceled without actually getting executed?
> 
> It should really flush them. The comment above says so, but in reality it
> does not matter that much as we tearing down the communication. As long as
> the pdev->op_work either completes or is never executed - we are fine.

The comment should be updated to reflect this.

David

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] arm/acpi: Fix the deadlock in function vgic_lock_rank()

[Julien Grall]

Hi Stefano,

On 31/05/16 10:40, Stefano Stabellini wrote:

On Mon, 30 May 2016, Julien Grall wrote:

ACPI can only be enabled in expert mode and will be a tech-preview for Xen
4.7. So I would revert the patch.  SPIs will not be routed, but it is better
than a deadlock.

I would also replace the patch with a warning until the issue will be fixed in
Xen 4.8.

Any opinions?


+int gic_route_irq_to_guest(struct domain *d, unsigned int virq,
+   struct irq_desc *desc, unsigned int priority)
+{
+unsigned long flags;
+int lock = 0, retval;
+struct vgic_irq_rank *rank;
+
+/* Use vcpu0 to retrieve the pending_irq struct. Given that we only
+ * route SPIs to guests, it doesn't make any difference. */
+rank = vgic_rank_irq(d->vcpu[0], virq);
+
+/* Take the rank spinlock unless it has already been taken by the
+ * caller. */
+if ( !spin_is_locked(>lock) ) {


AFAICT, spin_is_locked only tell us that someone has locked the rank. So this
would be unsafe.


The code is checking if the lock is already taken, and if it is not
taken, it will take the lock. The purpose of this code is to
allow gic_route_irq_to_guest to be called by both functions which
already have the lock held and functions that do not. The same goal
could be achieved by duplicating gic_route_irq_to_guest into two
identical functions except for the lock taking. That would be
admittedly a more obvious fix but also a particularly ugly one.


spin_is_locked does not work as you expect. The function will not tell 
you if the lock was taken by the current CPU, but if the lock was taken 
by *a* CPU.


It would be possible to have CPU A calling this function and have CPU B 
with the lock taken. So the data structure would be accessed by 2 CPUs 
concurrently, which is unsafe.


Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [BUG] Xen panic with VT-d PI

[Wu, Feng]

> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Friday, May 27, 2016 12:11 AM
> To: Wu, Feng ; Wei Liu 
> Cc: Xen-devel ; Hao, Xudong
> 
> Subject: Re: [Xen-devel] [BUG] Xen panic with VT-d PI
> 
> On Thu, 2016-05-26 at 13:03 +, Wu, Feng wrote:
> > > On Thu, May 26, 2016 at 01:56:28AM +, Wu, Feng wrote:
> > > >
> > > > The patch fixing this issue has already been sent to upstream.
> > > >
> > > > " [PATCH 0/3] VMX: Properly handle pi descriptor and per-cpu
> > > > blocking list "
> > > >
> > > > v2 will be sent out soon.
> > > >
> > > I just went through that thread. There are some open questions.
> > > Also Jan
> > > requested that you explore other possible options.
> > >
> > > My current plan is to not block the release for this -- we're very
> > > close
> > > to the anticipated release date, and posted-interrupt is either
> > > technical preview or experimental, so bugs there are expected.
> > >
> > > This issue will be listed as a known issue for PI. And you can
> > > continue
> > > to develop a fix for it. Your fix will be integrated with next
> > > version
> > > of Xen. Then you can request for backport to 4.7 if you want to.
> > >
> > > What do you think about this plan?
> > I am going to send out the next version of this series, let's see how
> > it is going on. But basically, I am fine with your release plan.
> >
> This does not have anything to do with Wei's plan (with which I also
> agree), but are you sure that the bug being reported here is related to
> and would be fixed by the patch you're mentioning?

Yes, this bug is caused by device hotplug, which is fixed in this patch
set.

> 
> Have you also seen it, and is that what led to the patch? If yes,
> please, add a bit more information (including excerpts of, or insights
> about the splat) in the patch changelog.

The bug leads to this patch, and I also saw issues beyond it, such as,
the domain destroy, pCPU hotplug cases. Sure, I will add some info
about it in the next version.

Thanks,
Feng

> 
> Regards,
> Dario
> --
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel