Re: [Xen-devel] [PATCH 1/1] xen/time: do not decrease steal time after live migration on xen

[Dongli Zhang]

Hi Boris,

- boris.ostrov...@oracle.com wrote:

> On 10/19/2017 04:02 AM, Dongli Zhang wrote:
> > After guest live migration on xen, steal time in /proc/stat
> > (cpustat[CPUTIME_STEAL]) might decrease because steal returned by
> > xen_steal_lock() might be less than this_rq()->prev_steal_time which
> is
> > derived from previous return value of xen_steal_clock().
> >
> > For instance, steal time of each vcpu is 335 before live migration.
> >
> > cpu  198 0 368 200064 1962 0 0 1340 0 0
> > cpu0 38 0 81 50063 492 0 0 335 0 0
> > cpu1 65 0 97 49763 634 0 0 335 0 0
> > cpu2 38 0 81 50098 462 0 0 335 0 0
> > cpu3 56 0 107 50138 374 0 0 335 0 0
> >
> > After live migration, steal time is reduced to 312.
> >
> > cpu  200 0 370 200330 1971 0 0 1248 0 0
> > cpu0 38 0 82 50123 500 0 0 312 0 0
> > cpu1 65 0 97 49832 634 0 0 312 0 0
> > cpu2 39 0 82 50167 462 0 0 312 0 0
> > cpu3 56 0 107 50207 374 0 0 312 0 0
> >
> > The code in this patch is borrowed from do_stolen_accounting() which
> has
> > already been removed from linux source code since commit
> ecb23dc6f2ef
> > ("xen: add steal_clock support on x86"). The core idea of both
> > do_stolen_accounting() and this patch is to avoid accounting new
> steal
> > clock if it is smaller than previous old steal clock.
> >
> > Similar and more severe issue would impact prior linux 4.8-4.10 as
> > discussed by Michael Las at
> >
> https://0xstubs.org/debugging-a-flaky-cpu-steal-time-counter-on-a-paravirtualized-xen-guest,
> > which would overflow steal time and lead to 100% st usage in top
> command
> > for linux 4.8-4.10. A backport of this patch would fix that issue.
> >
> > References:
> https://0xstubs.org/debugging-a-flaky-cpu-steal-time-counter-on-a-paravirtualized-xen-guest
> > Signed-off-by: Dongli Zhang 
> > ---
> >  drivers/xen/time.c | 15 ++-
> >  1 file changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/xen/time.c b/drivers/xen/time.c
> > index ac5f23f..2b3a996 100644
> > --- a/drivers/xen/time.c
> > +++ b/drivers/xen/time.c
> > @@ -19,6 +19,8 @@
> >  /* runstate info updated by Xen */
> >  static DEFINE_PER_CPU(struct vcpu_runstate_info, xen_runstate);
> >
> > +static DEFINE_PER_CPU(u64, xen_old_steal);
> > +
> >  /* return an consistent snapshot of 64-bit time/counter value */
> >  static u64 get64(const u64 *p)
> >  {
> > @@ -83,9 +85,20 @@ bool xen_vcpu_stolen(int vcpu)
> >  u64 xen_steal_clock(int cpu)
> >  {
> > struct vcpu_runstate_info state;
> > +   u64 xen_new_steal;
> > +   s64 steal_delta;
> >
> > xen_get_runstate_snapshot_cpu(, cpu);
> > -   return state.time[RUNSTATE_runnable] +
> state.time[RUNSTATE_offline];
> > +   xen_new_steal = state.time[RUNSTATE_runnable]
> > +   + state.time[RUNSTATE_offline];
> > +   steal_delta = xen_new_steal - per_cpu(xen_old_steal, cpu);
> > +
> > +   if (steal_delta < 0)
> > +   xen_new_steal = per_cpu(xen_old_steal, cpu);
> > +   else
> > +   per_cpu(xen_old_steal, cpu) = xen_new_steal;
> > +
> > +   return xen_new_steal;
> >  }
> >
> >  void xen_setup_runstate_info(int cpu)
> 
> Can we stash state.time[] during suspend and then add stashed values
> inside xen_get_runstate_snapshot_cpu()?


Would you like to stash state.time[] during do_suspend() (or xen_suspend()) or
code below is expected:

-

--- a/drivers/xen/time.c
+++ b/drivers/xen/time.c
@@ -19,6 +19,8 @@
 /* runstate info updated by Xen */
 static DEFINE_PER_CPU(struct vcpu_runstate_info, xen_runstate);
 
+static DEFINE_PER_CPU(u64[4], old_runstate_time);
+
 /* return an consistent snapshot of 64-bit time/counter value */
 static u64 get64(const u64 *p)
 {
@@ -52,6 +54,8 @@ static void xen_get_runstate_snapshot_cpu(struct 
vcpu_runstate_info *res,
 {
u64 state_time;
struct vcpu_runstate_info *state;
+   int i;
+   s64 time_delta;
 
BUG_ON(preemptible());
 
@@ -64,6 +68,17 @@ static void xen_get_runstate_snapshot_cpu(struct 
vcpu_runstate_info *res,
rmb();  /* Hypervisor might update data. */
} while (get64(>state_entry_time) != state_time ||
 (state_time & XEN_RUNSTATE_UPDATE));
+
+   for (i = 0; i < 4; i++) {
+   if (i == RUNSTATE_runnable || i == RUNSTATE_offline) {
+   time_delta = res->time[i] - per_cpu(old_runstate_time, 
cpu)[i];
+
+   if (unlikely(time_delta < 0))
+   res->time[i] = per_cpu(old_runstate_time, 
cpu)[i];
+   else
+   per_cpu(old_runstate_time, cpu)[i] = 
res->time[i];
+   }
+   }
 }

-

Thank you very much!

Dongli Zhang

> 
> This will make xen_steal_clock() simpler.
> 
> -boris
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> 

Re: [Xen-devel] [PATCH V3 13/29] x86/vvtd: Set Interrupt Remapping Table Pointer through GCMD

[Chao Gao]

On Thu, Oct 19, 2017 at 12:56:45PM +0100, Roger Pau Monné wrote:
>On Thu, Sep 21, 2017 at 11:01:54PM -0400, Lan Tianyu wrote:
>> From: Chao Gao 
>> 
>> Software sets this field to set/update the interrupt remapping table pointer
>> used by hardware. The interrupt remapping table pointer is specified through
>> the Interrupt Remapping Table Address (IRTA_REG) register.
>> 
>> This patch emulates this operation and adds some new fields in VVTD to track
>> info (e.g. the table's gfn and max supported entries) of interrupt remapping
>> table.
>> 
>> Signed-off-by: Chao Gao 
>> Signed-off-by: Lan Tianyu 
>> 
>> ---
>> @@ -148,6 +205,18 @@ static int vvtd_write(struct vcpu *v, unsigned long 
>> addr,
>>  break;
>>  }
>>  }
>> +else /* len == 8 */
>> +{
>> +switch ( offset )
>> +{
>> +case DMAR_IRTA_REG:
>> +vvtd_set_reg_quad(vvtd, DMAR_IRTA_REG, val);
>
>I have kind of a generic comment regarding the handlers in general,
>which I will just make here. Don't you need some kind of locking to
>prevent concurrent read/write accesses to the registers?

I think guest should be responsible to avoid concurrency.
Xen only needs to not be fooled (crashed) by a malicious guest.

>
>Also the 'if' to handle different sized accesses to the same registers
>seems quite cumbersome. I would think there's a better way to handle
>this with a single switch statement.

Will use only one switch statement and maybe add if-else for the
cases which can be accessed with different size.

Thanks
chao

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 

[Xen-devel] [xen-4.8-testing test] 114689: tolerable FAIL - PUSHED

[osstest service owner]

flight 114689 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114689/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-xtf-amd64-amd64-4 48 xtf/test-hvm64-lbr-tsx-vmentry fail in 114661 pass 
in 114689
 test-amd64-i386-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail in 
114661 pass in 114689
 test-xtf-amd64-amd64-1   49 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 114661
 test-armhf-armhf-libvirt-xsm 16 guest-start/debian.repeat  fail pass in 114661
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 18 guest-start/debianhvm.repeat 
fail pass in 114661

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop   fail blocked in 114538
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop  fail blocked in 114538
 test-xtf-amd64-amd64-2  49 xtf/test-hvm64-lbr-tsx-vmentry fail like 114505
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 114538
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114538
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114538
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114538
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 114538
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 build-i386-prev   7 xen-build/dist-test  fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 build-amd64-prev  7 xen-build/dist-test  fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  0c647de4db305a0b02f73684f9637acbf7b7f92a
baseline version:
 xen  bdc2ae68e2ecba1c3f55ad953189fe33362d1c51

Last test of basis   114538  2017-10-15 19:49:57 Z4 days
Testing same since   114661  2017-10-17 20:41:48 Z2 days2 attempts


People who touched revisions under test:
  Bernd Kuhls 
  Thomas Petazzoni 
  Wei Liu 

jobs:
 build-amd64-xsm 

Re: [Xen-devel] [PATCH V3 12/29] x86/vvtd: Add MMIO handler for VVTD

[Chao Gao]

On Thu, Oct 19, 2017 at 12:34:54PM +0100, Roger Pau Monné wrote:
>On Thu, Sep 21, 2017 at 11:01:53PM -0400, Lan Tianyu wrote:
>> From: Chao Gao 
>> 
>> This patch adds VVTD MMIO handler to deal with MMIO access.
>> 
>> Signed-off-by: Chao Gao 
>> Signed-off-by: Lan Tianyu 
>> ---
>>  xen/drivers/passthrough/vtd/vvtd.c | 91 
>> ++
>>  1 file changed, 91 insertions(+)
>> 
>> diff --git a/xen/drivers/passthrough/vtd/vvtd.c 
>> b/xen/drivers/passthrough/vtd/vvtd.c
>> index c851ec7..a3002c3 100644
>> --- a/xen/drivers/passthrough/vtd/vvtd.c
>> +++ b/xen/drivers/passthrough/vtd/vvtd.c
>> @@ -47,6 +47,29 @@ struct vvtd {
>>  struct page_info *regs_page;
>>  };
>>  
>> +/* Setting viommu_verbose enables debugging messages of vIOMMU */
>> +bool __read_mostly viommu_verbose;
>> +boolean_runtime_param("viommu_verbose", viommu_verbose);
>> +
>> +#ifndef NDEBUG
>> +#define vvtd_info(fmt...) do {\
>> +if ( viommu_verbose ) \
>> +gprintk(XENLOG_G_INFO, ## fmt);   \
>
>If you use gprintk you should use XENLOG_INFO, the '_G_' variants are
>only used with plain printk.
>
>> +} while(0)
>> +#define vvtd_debug(fmt...) do {   \
>> +if ( viommu_verbose && printk_ratelimit() )   \
>
>Not sure why you need printk_ratelimit, XENLOG_G_DEBUG is already
>rate-limited.
>
>> +printk(XENLOG_G_DEBUG fmt);   \
>
>Any reason why vvtd_info uses gprintk and here you use printk?
>
>> +} while(0)
>> +#else
>> +#define vvtd_info(fmt...) do {} while(0)
>> +#define vvtd_debug(fmt...) do {} while(0)
>
>No need for 'fmt...' just '...' will suffice since you are discarding
>the parameters anyway.
>
>> +#endif
>> +
>> +struct vvtd *domain_vvtd(struct domain *d)
>> +{
>> +return (d->viommu) ? d->viommu->priv : NULL;
>
>Unneeded parentheses around d->viommu.
>
>Also, it seems wring to call domain_vvtd with !d->viommu. So I think
>this helper should just be removed, and d->viommu->priv fetched
>directly.
>
>> +}
>> +
>>  static inline void vvtd_set_reg(struct vvtd *vtd, uint32_t reg, uint32_t 
>> value)
>>  {
>>  vtd->regs->data32[reg/sizeof(uint32_t)] = value;
>> @@ -68,6 +91,73 @@ static inline uint64_t vvtd_get_reg_quad(struct vvtd 
>> *vtd, uint32_t reg)
>>  return vtd->regs->data64[reg/sizeof(uint64_t)];
>>  }
>>  
>> +static int vvtd_in_range(struct vcpu *v, unsigned long addr)
>> +{
>> +struct vvtd *vvtd = domain_vvtd(v->domain);
>> +
>> +if ( vvtd )
>> +return (addr >= vvtd->base_addr) &&
>> +   (addr < vvtd->base_addr + PAGE_SIZE);
>
>So the register set covers a PAGE_SIZE, but hvm_hw_vvtd_regs only
>covers from 0 to 1024B, it seems like there's something wrong here...
>
>> +return 0;
>> +}
>> +
>> +static int vvtd_read(struct vcpu *v, unsigned long addr,
>> + unsigned int len, unsigned long *pval)
>> +{
>> +struct vvtd *vvtd = domain_vvtd(v->domain);
>> +unsigned int offset = addr - vvtd->base_addr;
>> +
>> +vvtd_info("Read offset %x len %d\n", offset, len);
>> +
>> +if ( (len != 4 && len != 8) || (offset & (len - 1)) )
>
>What value does hardware return when performing unaligned reads or
>reads with wrong size?

According to VT-d spec section 10.2, "Software must access 64-bit and
128-bit registers as either aligned quadwords or aligned doublewords".
I am afraid there is no specific hardware action for unaligned access
information. We can treat it as undefined? Then do nothing.
But I did see windows driver has such accesses. We need to add a
workaround for windows later.

>
>Here you return with pval not set, which is dangerous.

Indeed. But I need check whether the pval is initialized by the caller.
If that, it is safe.

>
>> +return X86EMUL_OKAY;
>> +
>> +if ( len == 4 )
>> +*pval = vvtd_get_reg(vvtd, offset);
>> +else
>> +*pval = vvtd_get_reg_quad(vvtd, offset);
>
>...yet here you don't check for offset < 1024.
>
>> +
>> +return X86EMUL_OKAY;
>> +}
>> +
>> +static int vvtd_write(struct vcpu *v, unsigned long addr,
>> +  unsigned int len, unsigned long val)
>> +{
>> +struct vvtd *vvtd = domain_vvtd(v->domain);
>> +unsigned int offset = addr - vvtd->base_addr;
>> +
>> +vvtd_info("Write offset %x len %d val %lx\n", offset, len, val);
>> +
>> +if ( (len != 4 && len != 8) || (offset & (len - 1)) )
>> +return X86EMUL_OKAY;
>> +
>> +if ( len == 4 )
>> +{
>> +switch ( offset )
>> +{
>> +case DMAR_IEDATA_REG:
>> +case DMAR_IEADDR_REG:
>> +case DMAR_IEUADDR_REG:
>> +case DMAR_FEDATA_REG:
>> +case DMAR_FEADDR_REG:
>> +case DMAR_FEUADDR_REG:
>> +vvtd_set_reg(vvtd, offset, val);
>
>Hm, so you are using a full page when you only care for 6 4B
>registers? Seem like quite of a waste of memory.

Registers are 

Re: [Xen-devel] [PATCH V3 11/29] x86/hvm: Introduce a emulated VTD for HVM

[Chao Gao]

On Thu, Oct 19, 2017 at 12:20:35PM +0100, Roger Pau Monné wrote:
>On Thu, Sep 21, 2017 at 11:01:52PM -0400, Lan Tianyu wrote:
>> From: Chao Gao 
>> 
>> This patch adds create/destroy function for the emulated VTD
>> and adapts it to the common VIOMMU abstraction.
>> 
>> Signed-off-by: Chao Gao 
>> Signed-off-by: Lan Tianyu 
>> ---
>>  
>> -obj-y += iommu.o
>>  obj-y += dmar.o
>> -obj-y += utils.o
>> -obj-y += qinval.o
>>  obj-y += intremap.o
>> +obj-y += iommu.o
>> +obj-y += qinval.o
>>  obj-y += quirks.o
>> +obj-y += utils.o
>
>Why do you need to shuffle the list above?

I placed them in alphabetic order.

>
>Also I'm not sure the Intel vIOMMU implementation should live here. As
>you can see the path is:
>
>xen/drivers/passthrough/vtd/
>
>The vIOMMU is not tied to passthrough at all, so I would rather place
>it in:
>
>xen/drivers/vvtd/
>
>Or maybe you can create something like:
>
>xen/drivers/viommu/
>
>So that all vIOMMU implementations can share some code.
>

vvtd and vtd use the same header files (i.g. vtd.h). That is why we put
it there.  If that, we shoule move the related header files to a public
directory.

>>  #define cap_isoch(c)(((c) >> 23) & 1)
>>  #define cap_qos(c)(((c) >> 22) & 1)
>>  #define cap_mgaw(c)c) >> 16) & 0x3f) + 1)
>> -#define cap_sagaw(c)(((c) >> 8) & 0x1f)
>> +#define cap_set_mgaw(c) c) - 1) & 0x3f) << 16)
>> +#define cap_sagaw(c)(((c) >> DMA_CAP_SAGAW_SHIFT) & 0x1f)
>>  #define cap_caching_mode(c)(((c) >> 7) & 1)
>>  #define cap_phmr(c)(((c) >> 6) & 1)
>>  #define cap_plmr(c)(((c) >> 5) & 1)
>> @@ -104,10 +113,16 @@
>>  #define ecap_niotlb_iunits(e)e) >> 24) & 0xff) + 1)
>>  #define ecap_iotlb_offset(e) e) >> 8) & 0x3ff) * 16)
>>  #define ecap_coherent(e) ((e >> 0) & 0x1)
>> -#define ecap_queued_inval(e) ((e >> 1) & 0x1)
>> +#define DMA_ECAP_QI_SHIFT1
>> +#define DMA_ECAP_QI  (1ULL << DMA_ECAP_QI_SHIFT)
>> +#define ecap_queued_inval(e) ((e >> DMA_ECAP_QI_SHIFT) & 0x1)
>
>Looks like this could be based on MASK_EXTR instead, but seeing how
>the file is full of open-coded mask extracts I'm not sure it's worth
>it anymore.
>
>>  #define ecap_dev_iotlb(e)((e >> 2) & 0x1)
>> -#define ecap_intr_remap(e)   ((e >> 3) & 0x1)
>> -#define ecap_eim(e)  ((e >> 4) & 0x1)
>> +#define DMA_ECAP_IR_SHIFT3
>> +#define DMA_ECAP_IR  (1ULL << DMA_ECAP_IR_SHIFT)
>> +#define ecap_intr_remap(e)   ((e >> DMA_ECAP_IR_SHIFT) & 0x1)
>> +#define DMA_ECAP_EIM_SHIFT   4
>> +#define DMA_ECAP_EIM (1ULL << DMA_ECAP_EIM_SHIFT)
>> +#define ecap_eim(e)  ((e >> DMA_ECAP_EIM_SHIFT) & 0x1)
>
>Maybe worth placing all the DMA_ECAP_* defines in a separate section?
>Seems like how it's done for other features like DMA_FSTS or
>DMA_CCMD.

Got it.

>> +
>> +/* Supported capabilities by vvtd */
>> +unsigned int vvtd_caps = VIOMMU_CAP_IRQ_REMAPPING;
>
>static?
>
>Or even better, why is this not a define like VIOMMU_MAX_CAPS or
>similar.

Yeah. It should be renamed to VVTD_MAX_CAPS.

>
>> +
>> +union hvm_hw_vvtd_regs {
>> +uint32_t data32[256];
>> +uint64_t data64[128];
>> +};
>
>Do you really need to store all the register space instead of only
>storing specific registers?

I prefer to store all the registers for we don't need a trick to map
the real offset in hardware to the index in the array.

>
>> +
>> +struct vvtd {
>> +/* Address range of remapping hardware register-set */
>> +uint64_t base_addr;
>> +uint64_t length;
>
>The length field doesn't seem to be used below.

will remove it.

>
>> +/* Point back to the owner domain */
>> +struct domain *domain;
>> +union hvm_hw_vvtd_regs *regs;
>
>Does this need to be a pointer?

Seems not.
>
>> +struct page_info *regs_page;
>> +};
>> +
>> +static int vvtd_create(struct domain *d, struct viommu *viommu)
>> +{
>> +struct vvtd *vvtd;
>> +int ret;
>> +
>> +if ( !is_hvm_domain(d) || (viommu->base_address & (PAGE_SIZE - 1)) ||
>> +(~vvtd_caps & viommu->caps) )
>> +return -EINVAL;
>> +
>> +ret = -ENOMEM;
>> +vvtd = xzalloc_bytes(sizeof(struct vvtd));
>> +if ( !vvtd )
>> +return ret;
>> +
>> +vvtd->regs_page = alloc_domheap_page(d, MEMF_no_owner);
>> +if ( !vvtd->regs_page )
>> +goto out1;
>> +
>> +vvtd->regs = __map_domain_page_global(vvtd->regs_page);
>> +if ( !vvtd->regs )
>> +goto out2;
>> +clear_page(vvtd->regs);
>
>Not sure why vvtd->regs needs to be a pointer, and why it needs to use
>a full page. AFAICT the size of hvm_hw_vvtd_regs is 1024B, so you are
>wasting 3/4 of a page.

I will define registers as an array directly and 
shrink the size to the number we are really used now.

>> +struct viommu_ops vvtd_hvm_vmx_ops = {
>> +.create = vvtd_create,
>> +.destroy = vvtd_destroy
>> +};
>> +
>> 

[Xen-devel] [linux-3.18 baseline-only test] 72332: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 72332 linux-3.18 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72332/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-intel 13 xen-install/l1 fail REGR. vs. 72235

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail REGR. vs. 72235

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail like 72235
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   like 72235
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   like 72235
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   like 72235
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 72235
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 72235
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 72235
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 72235
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-armhf-armhf-xl-midway   13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass

version targeted for testing:
 linux1e8e6b30d014eb77278edb4cd9bee72f0255996f
baseline version:
 linux3e2bb7d281edae5a0732023061402e4a7231dffc

Last test of basis72235  2017-10-14 14:18:24 Z5 days
Testing same since72332  2017-10-19 20:52:18 Z0 days

Re: [Xen-devel] [PATCH V3 10/29] vtd: add and align register definitions

[Chao Gao]

On Thu, Oct 19, 2017 at 11:21:35AM +0100, Roger Pau Monné wrote:
>On Thu, Sep 21, 2017 at 11:01:51PM -0400, Lan Tianyu wrote:
>> From: Chao Gao 
>> 
>> No functional changes.
>> 
>> Signed-off-by: Chao Gao 
>> Signed-off-by: Lan Tianyu 
>
>Reviewed-by: Roger Pau Monné 

Thanks

>
>Would have been nice to maybe split this into two, one patch that
>simply fixes the alignment and another one that introduces the new
>defines (or even introduce the new defines when they are actually
>needed).

Will divide it into two parts.

Thanks
Chao

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

Re: [Xen-devel] [PATCH V3 7/29] tools/libxl: build DMAR table for a guest with one virtual VTD

[Chao Gao]

On Thu, Oct 19, 2017 at 11:00:27AM +0100, Roger Pau Monné wrote:
>On Thu, Sep 21, 2017 at 11:01:48PM -0400, Lan Tianyu wrote:
>> From: Chao Gao 
>> 
>> A new logic is added to build ACPI DMAR table in tool stack for a guest
>> with one virtual VTD and pass through it to guest via existing mechanism. If
>> there already are ACPI tables needed to pass through, we joint the tables.
>> 
>> Signed-off-by: Chao Gao 
>> Signed-off-by: Lan Tianyu 
>> 
>> ---
>> +/*
>> + * For hvm, we don't need build acpi in libxl. Instead, it's built in 
>> hvmloader.
>> + * But if one hvm has virtual VTD(s), we build DMAR table for it and joint 
>> this
>> + * table with existing content in acpi_modules in order to employ HVM
>> + * firmware pass-through mechanism to pass-through DMAR table.
>> + */
>> +static int libxl__dom_load_acpi_hvm(libxl__gc *gc,
>> +const libxl_domain_build_info *b_info,
>> +struct xc_dom_image *dom)
>> +{
>
>AFAICT there's some code duplication between libxl__dom_load_acpi_hvm
>and libxl__dom_load_acpi_pvh, isn't there a chance you could put this
>in a common function?

Will give it a shot.

>
>> +struct acpi_config config = { 0 };
>> +struct acpi_ctxt ctxt;
>> +void *table;
>> +uint32_t len;
>> +
>> +if ((b_info->type != LIBXL_DOMAIN_TYPE_HVM) ||
>> +(b_info->device_model_version == LIBXL_DEVICE_MODEL_VERSION_NONE) ||
>> +(b_info->num_viommus != 1) ||
>> +(b_info->viommu[0].type != LIBXL_VIOMMU_TYPE_INTEL_VTD))
>> +return 0;
>> +
>> +ctxt.mem_ops.alloc = acpi_memalign;
>> +ctxt.mem_ops.v2p = virt_to_phys;
>> +ctxt.mem_ops.free = acpi_mem_free;
>> +
>> +if (libxl_defbool_val(b_info->viommu[0].intremap))
>> +config.iommu_intremap_supported = true;
>> +/* x2apic is always enabled since in no case we must disable it */
>> +config.iommu_x2apic_supported = true;
>> +config.iommu_base_addr = b_info->viommu[0].base_addr;
>
>I don't see libxl__dom_load_acpi_pvh setting any of the vIOMMU fields.

I didn't try to enable vIOMMU for PVH. I will attemp to add vIOMMU
support for PVH and put those patches at the end of this series. 

>
>> +int libxl__dom_load_acpi(libxl__gc *gc,
>> + const libxl_domain_build_info *b_info,
>> + struct xc_dom_image *dom)
>> +{
>> +
>> +if (b_info->type != LIBXL_DOMAIN_TYPE_HVM)
>> +return 0;
>
>Keep in mind a new PVH domain type has been introduced recently in
>libxl, you will have to change this to b_info->type == LIBXL_DOMAIN_TYPE_PV.

Thanks for your kind reminder.

Chao


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

Re: [Xen-devel] [PATCH V3 6/29] tools/libxl: Add a user configurable parameter to control vIOMMU attributes

[Chao Gao]

On Thu, Oct 19, 2017 at 10:49:22AM +0100, Roger Pau Monné wrote:
>On Thu, Sep 21, 2017 at 11:01:47PM -0400, Lan Tianyu wrote:
>> From: Chao Gao 
>> 
>> A field, viommu_info, is added to struct libxl_domain_build_info. Several
>> attributes can be specified by guest config file for virtual IOMMU. These
>> attributes are used for DMAR construction and vIOMMU creation.
>
>IMHO this should come much later in the series, ideally you would
>introduce the xl/libxl code in the last patches, together with the
>xl.cfg man page change.

It can be put to the end of this series. But I prefer to introduce the
vIOMMU from up to down (means the use interface goes first and then how
to implement a vIOMMU step by step) for it may be easier to understand. 

>
>> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
>> index 9123585..decd7a8 100644
>> --- a/tools/libxl/libxl_create.c
>> +++ b/tools/libxl/libxl_create.c
>> @@ -27,6 +27,8 @@
>>  
>>  #include 
>>  
>> +#define VIOMMU_VTD_BASE_ADDR0xfed9ULL
>
>This should be in libxl_arch.h see LAPIC_BASE_ADDRESS.

Agree.

>
>> +
>>  int libxl__domain_create_info_setdefault(libxl__gc *gc,
>>   libxl_domain_create_info *c_info)
>>  {
>> @@ -59,6 +61,47 @@ void libxl__rdm_setdefault(libxl__gc *gc, 
>> libxl_domain_build_info *b_info)
>>  LIBXL_RDM_MEM_BOUNDARY_MEMKB_DEFAULT;
>>  }
>>  
>> +static int libxl__viommu_set_default(libxl__gc *gc,
>> + libxl_domain_build_info *b_info)
>> +{
>> +int i;
>> +
>> +if (!b_info->num_viommus)
>> +return 0;
>> +
>> +for (i = 0; i < b_info->num_viommus; i++) {
>> +libxl_viommu_info *viommu = _info->viommu[i];
>> +
>> +if (libxl_defbool_is_default(viommu->intremap))
>> +libxl_defbool_set(>intremap, true);
>> +
>> +if (!libxl_defbool_val(viommu->intremap)) {
>> +LOGE(ERROR, "Cannot create one virtual VTD without intremap");
>> +return ERROR_INVAL;
>> +}
>> +
>> +if (viommu->type == LIBXL_VIOMMU_TYPE_INTEL_VTD) {
>> +/*
>> + * If there are multiple vIOMMUs, we need arrange all vIOMMUs to
>> + * avoid overlap. Put a check here in case we get here for 
>> multiple
>> + * vIOMMUs case.
>> + */
>> +if (b_info->num_viommus > 1) {
>> +LOGE(ERROR, "Multiple vIOMMUs support is under 
>> implementation");
>
>s/LOGE/LOG/ LOGE should only be used when errno is set (which is not
>the case here).

yes.

>
>> +return ERROR_INVAL;
>> +}
>> +
>> +/* Set default values to unexposed fields */
>> +viommu->base_addr = VIOMMU_VTD_BASE_ADDR;
>> +
>> +/* Set desired capbilities */
>> +viommu->cap = VIOMMU_CAP_IRQ_REMAPPING;
>
>I'm not sure whether this code should be in libxl_x86.c, but
>libxl__domain_build_info_setdefault is already quite messed up, so I
>guess it's fine.
>
>> +}
>
>Shouldn't this be:
>
>switch(viommu->type) {
>case LIBXL_VIOMMU_TYPE_INTEL_VTD:
>...
>break;
>
>default:
>return ERROR_INVAL;
>}
>
>So that you catch type being set to an invalid vIOMMU type?

sure. Will update.

>
>> +if (d_config->b_info.num_viommus > 1) {
>> +ret = ERROR_INVAL;
>> +LOGD(ERROR, domid, "Cannot support multiple vIOMMUs");
>> +goto error_out;
>> +}
>
>Er, you already have this check in libxl__viommu_set_default, and in
>any case I would just rely on the hypervisor failing to create more
>than one vIOMMU per domain, rather than adding the same check here.

It is fine to me. Will remove all checks against viommu numbers in
toolstack.

Thanks
chao

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  6ccf25d46c18ff274e68dde8c8da3c656f7699e2
baseline version:
 xen  0c8055c2f45f489aff67f4d362f3fdc192cc2d94

Last test of basis   114776  2017-10-19 21:04:07 Z0 days
Testing same since   114780  2017-10-20 00:16:39 Z0 days1 attempts


People who touched revisions under test:
  Julien Grall 

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=6ccf25d46c18ff274e68dde8c8da3c656f7699e2
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.
 PERLLIB=.:.
+++ 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 
6ccf25d46c18ff274e68dde8c8da3c656f7699e2
+ branch=xen-unstable-smoke
+ revision=6ccf25d46c18ff274e68dde8c8da3c656f7699e2
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.:.
 PERLLIB=.:.:.
+++ 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
+++ export PERLLIB=.:.:.:.
+++ PERLLIB=.:.:.:.
++ 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.9-testing
+ '[' x6ccf25d46c18ff274e68dde8c8da3c656f7699e2 = 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/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : 

Re: [Xen-devel] [PATCH V3 22/29] x86/vioapic: extend vioapic_get_vector() to support remapping format RTE

[Chao Gao]

On Thu, Oct 19, 2017 at 09:56:34AM -0600, Jan Beulich wrote:
 On 19.10.17 at 17:49,  wrote:
>> On Thu, Sep 21, 2017 at 11:02:03PM -0400, Lan Tianyu wrote:
>>> --- a/xen/arch/x86/hvm/vioapic.c
>>> +++ b/xen/arch/x86/hvm/vioapic.c
>>> @@ -561,11 +561,25 @@ int vioapic_get_vector(const struct domain *d, 
>>> unsigned int gsi)
>>>  {
>>>  unsigned int pin;
>>>  const struct hvm_vioapic *vioapic = gsi_vioapic(d, gsi, );
>>> +struct arch_irq_remapping_request request;
>>>  
>>>  if ( !vioapic )
>>>  return -EINVAL;
>>>  
>>> -return vioapic->redirtbl[pin].fields.vector;
>>> +irq_request_ioapic_fill(, vioapic->id, 
>>> vioapic->redirtbl[pin].bits);
>>> +if ( viommu_check_irq_remapping(vioapic->domain, ) )
>>> +{
>>> +int err;
>>> +struct arch_irq_remapping_info info;
>>> +
>>> +err = viommu_get_irq_info(vioapic->domain, , );
>>> +return !err ? info.vector : err;
>> 
>> You can simplify this as return err :? info.vector;
>
>At which point the local variable becomes pretty pointless.

Maybe we can remove 'err' and return
unlikely(viommu_get_irq_info(...)) ?: info.vector;

Thanks
Chao

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

Re: [Xen-devel] [PATCH v8 00/16] Enable Memory Bandwidth Allocation in Xen

[Yi Sun]

On 17-10-20 09:20:00, Yi Sun wrote:
> On 17-10-19 16:08:09, Konrad Rzeszutek Wilk wrote:
> > On Mon, Oct 16, 2017 at 11:04:05AM +0800, Yi Sun wrote:
> > > a - Acked-by
> > > r - Reviewed-by
> > > 
> > >   r  patch 1  - docs: create Memory Bandwidth Allocation (MBA) feature 
> > > document
> > >   ar patch 2  - Rename PSR sysctl/domctl interfaces and xsm policy to 
> > > make them be general
> > >   ar patch 3  - x86: rename 'cbm_type' to 'psr_type' to make it general
> > >   ar patch 4  - x86: a few optimizations to psr codes
> > >   r  patch 5  - x86: implement data structure and CPU init flow for MBA
> > >   ar patch 6  - x86: implement get hw info flow for MBA
> > >   ar patch 7  - x86: implement get value interface for MBA
> > 
> > So 8 is missing and Ack/Review-edyb?
> > 
> Jan provided Reviewed-by to patch 8 in this version.
> 
> > >   ar patch 9  - tools: create general interfaces to support psr 
> > > allocation features
> > >   ar patch 10 - tools: implement the new libxc get hw info interface
> > >   ar patch 11 - tools: implement the new libxl get hw info interface
> > >   ar patch 12 - tools: implement the new xl get hw info interface
> > >   ar patch 13 - tools: rename 'xc_psr_cat_type' to 'xc_psr_type'
> > >   ar patch 14 - tools: implement new generic get value interface and MBA 
> > > get value command
> > >   ar patch 15 - tools: implement new generic set value interface and MBA 
> > > set value command
> > >   ar patch 16 - docs: add MBA description in docs
> > 
> > 
> > Also I tried to merge this on 'staging' and had a bit of issues. By any 
> > chance
> > do you have an up-to-date branc?
> 
> My codes base on commit 572a78. Let me try to apply patches onto staging.
> Thanks for your attention to this series!
> 
Andrew's below patch in staging branch causes the conflict.

commit 5b42c82f5584ca8b0e169c6de1b6d81214ea07f2
Author: Andrew Cooper 
Date:   Fri Oct 6 20:00:00 2017 +0100

tools/libxc: Fix domid parameter types

I will rebase my patch onto it and submit version 9.

> BRs,
> Sun Yi
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH v5 09/13] xen/pvcalls: implement sendmsg

[Stefano Stabellini]

On Tue, 17 Oct 2017, Boris Ostrovsky wrote:
> > +static int __write_ring(struct pvcalls_data_intf *intf,
> > +   struct pvcalls_data *data,
> > +   struct iov_iter *msg_iter,
> > +   int len)
> > +{
> > +   RING_IDX cons, prod, size, masked_prod, masked_cons;
> > +   RING_IDX array_size = XEN_FLEX_RING_SIZE(PVCALLS_RING_ORDER);
> > +   int32_t error;
> > +
> > +   error = intf->out_error;
> > +   if (error < 0)
> > +   return error;
> > +   cons = intf->out_cons;
> > +   prod = intf->out_prod;
> > +   /* read indexes before continuing */
> > +   virt_mb();
> > +
> > +   size = pvcalls_queued(prod, cons, array_size);
> > +   if (size >= array_size)
> > +   return 0;
> 
> 
> I thought you were going to return an error here? If this can only be
> due to someone messing up indexes is there a reason to continue trying
> to write? What are the chances that the index will get corrected?

Sorry, I forgot. I'll change it to return an error, maybe EFAULT.


> > +   if (len > array_size - size)
> > +   len = array_size - size;
> > +
> > +   masked_prod = pvcalls_mask(prod, array_size);
> > +   masked_cons = pvcalls_mask(cons, array_size);
> > +
> > +   if (masked_prod < masked_cons) {
> > +   copy_from_iter(data->out + masked_prod, len, msg_iter);
> > +   } else {
> > +   if (len > array_size - masked_prod) {
> > +   copy_from_iter(data->out + masked_prod,
> > +  array_size - masked_prod, msg_iter);
> > +   copy_from_iter(data->out,
> > +  len - (array_size - masked_prod),
> > +  msg_iter);
> > +   } else {
> > +   copy_from_iter(data->out + masked_prod, len, msg_iter);
> > +   }
> > +   }
> > +   /* write to ring before updating pointer */
> > +   virt_wmb();
> > +   intf->out_prod += len;
> > +
> > +   return len;
> > +}
> 

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

Re: [Xen-devel] [PATCH v5 10/13] xen/pvcalls: implement recvmsg

[Stefano Stabellini]

On Tue, 17 Oct 2017, Boris Ostrovsky wrote:
> > +
> > +int pvcalls_front_recvmsg(struct socket *sock, struct msghdr *msg, size_t 
> > len,
> > +int flags)
> > +{
> > +   struct pvcalls_bedata *bedata;
> > +   int ret;
> > +   struct sock_mapping *map;
> > +
> > +   if (flags & (MSG_CMSG_CLOEXEC|MSG_ERRQUEUE|MSG_OOB|MSG_TRUNC))
> > +   return -EOPNOTSUPP;
> > +
> > +   pvcalls_enter();
> > +   if (!pvcalls_front_dev) {
> > +   pvcalls_exit();
> > +   return -ENOTCONN;
> > +   }
> > +   bedata = dev_get_drvdata(_front_dev->dev);
> > +
> > +   map = (struct sock_mapping *) sock->sk->sk_send_head;
> > +   if (!map) {
> > +   pvcalls_exit();
> > +   return -ENOTSOCK;
> > +   }
> > +
> > +   mutex_lock(>active.in_mutex);
> > +   if (len > XEN_FLEX_RING_SIZE(PVCALLS_RING_ORDER))
> > +   len = XEN_FLEX_RING_SIZE(PVCALLS_RING_ORDER);
> > +
> > +   while (!(flags & MSG_DONTWAIT) && !pvcalls_front_read_todo(map)) {
> > +   wait_event_interruptible(map->active.inflight_conn_req,
> > +pvcalls_front_read_todo(map));
> > +   }
> > +   ret = __read_ring(map->active.ring, >active.data,
> > + >msg_iter, len, flags);
> > +
> > +   if (ret > 0)
> > +   notify_remote_via_irq(map->active.irq);
> > +   if (ret == 0)
> > +   ret = -EAGAIN;
> 
> Why not 0? The manpage says:
> 
>EAGAIN or EWOULDBLOCK
>   The  socket  is  marked nonblocking and the receive
> operation would block, or a receive timeout
>   had been set and the timeout expired before data was
> received.  POSIX.1 allows either error  to
>   be  returned  for  this case, and does not require these
> constants to have the same value, so a
>   portable application should check for both possibilities.
> 
> 
> I don't think either of these conditions is true here.
> 
> (Again, should have noticed this earlier, sorry)

In case the socket is MSG_DONTWAIT, then we should return -EAGAIN here.
However, it is true that if the socket is not MSG_DONTWAIT, then
returning 0 would make more sense.

So I'll do:

if (ret == 0)
ret = (flags & MSG_DONTWAIT) ? -EAGAIN : 0;

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

Re: [Xen-devel] [PATCH v5 06/13] xen/pvcalls: implement bind command

[Stefano Stabellini]

On Tue, 17 Oct 2017, Boris Ostrovsky wrote:
> On 10/06/2017 08:30 PM, Stefano Stabellini wrote:
> > Send PVCALLS_BIND to the backend. Introduce a new structure, part of
> > struct sock_mapping, to store information specific to passive sockets.
> >
> > Introduce a status field to keep track of the status of the passive
> > socket.
> >
> > Signed-off-by: Stefano Stabellini 
> > CC: boris.ostrov...@oracle.com
> > CC: jgr...@suse.com
> > ---
> >  drivers/xen/pvcalls-front.c | 66 
> > +
> >  drivers/xen/pvcalls-front.h |  3 +++
> >  2 files changed, 69 insertions(+)
> >
> > diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
> > index 7c9261b..4cafd9b 100644
> > --- a/drivers/xen/pvcalls-front.c
> > +++ b/drivers/xen/pvcalls-front.c
> > @@ -71,6 +71,13 @@ struct sock_mapping {
> >  
> > wait_queue_head_t inflight_conn_req;
> > } active;
> > +   struct {
> > +   /* Socket status */
> > +#define PVCALLS_STATUS_UNINITALIZED  0
> > +#define PVCALLS_STATUS_BIND  1
> > +#define PVCALLS_STATUS_LISTEN2
> > +   uint8_t status;
> > +   } passive;
> > };
> >  };
> >  
> > @@ -347,6 +354,65 @@ int pvcalls_front_connect(struct socket *sock, struct 
> > sockaddr *addr,
> > return ret;
> >  }
> >  
> > +int pvcalls_front_bind(struct socket *sock, struct sockaddr *addr, int 
> > addr_len)
> > +{
> > +   struct pvcalls_bedata *bedata;
> > +   struct sock_mapping *map = NULL;
> > +   struct xen_pvcalls_request *req;
> > +   int notify, req_id, ret;
> > +
> > +   if (addr->sa_family != AF_INET || sock->type != SOCK_STREAM)
> > +   return -ENOTSUPP;
> > +
> > +   pvcalls_enter();
> > +   if (!pvcalls_front_dev) {
> > +   pvcalls_exit();
> > +   return -ENOTCONN;
> 
> The connect patch returns -ENETUNREACH here. Is there a deliberate
> distinction between these cases?

No, there isn't a deliberate distinction. Actually, all other commands
return ENOTCONN for this error, we might as well be consistent and
change ENETUNREACH to ENOTCONN for connect.

If you agree, I'll make the change to the connect patch, and add your
reviewed-by here.



> Other than that
> 
> Reviewed-by: Boris Ostrovsky 


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

Re: [Xen-devel] [PATCH v5 04/13] xen/pvcalls: implement socket command and handle events

[Stefano Stabellini]

On Tue, 17 Oct 2017, Boris Ostrovsky wrote:
> On 10/06/2017 08:30 PM, Stefano Stabellini wrote:
> > Send a PVCALLS_SOCKET command to the backend, use the masked
> > req_prod_pvt as req_id. This way, req_id is guaranteed to be between 0
> > and PVCALLS_NR_REQ_PER_RING. We already have a slot in the rsp array
> > ready for the response, and there cannot be two outstanding responses
> > with the same req_id.
> >
> > Wait for the response by waiting on the inflight_req waitqueue and
> > check for the req_id field in rsp[req_id]. Use atomic accesses and
> > barriers to read the field. Note that the barriers are simple smp
> > barriers (as opposed to virt barriers) because they are for internal
> > frontend synchronization, not frontend<->backend communication.
> >
> > Once a response is received, clear the corresponding rsp slot by setting
> > req_id to PVCALLS_INVALID_ID. Note that PVCALLS_INVALID_ID is invalid
> > only from the frontend point of view. It is not part of the PVCalls
> > protocol.
> >
> > pvcalls_front_event_handler is in charge of copying responses from the
> > ring to the appropriate rsp slot. It is done by copying the body of the
> > response first, then by copying req_id atomically. After the copies,
> > wake up anybody waiting on waitqueue.
> >
> > socket_lock protects accesses to the ring.
> >
> > Create a new struct sock_mapping and convert the pointer into an
> > uint64_t and use it as id for the new socket to pass to the backend. The
> > struct will be fully initialized later on connect or bind. In this patch
> > the struct sock_mapping is empty, the fields will be added by the next
> > patch.
> >
> > sock->sk->sk_send_head is not used for ip sockets: reuse the field to
> > store a pointer to the struct sock_mapping corresponding to the socket.
> > This way, we can easily get the struct sock_mapping from the struct
> > socket.
> >
> > Signed-off-by: Stefano Stabellini 
> 
> Reviewed-by: Boris Ostrovsky 
> 
> with one question:
> 
> > +   /*
> > +* PVCalls only supports domain AF_INET,
> > +* type SOCK_STREAM and protocol 0 sockets for now.
> > +*
> > +* Check socket type here, AF_INET and protocol checks are done
> > +* by the caller.
> > +*/
> > +   if (sock->type != SOCK_STREAM)
> > +   return -ENOTSUPP;
> > +
> 
> 
> Is this ENOTSUPP or EOPNOTSUPP? I didn't know the former even existed
> and include/linux/errno.h suggests that this is NFSv3-specific.

The PVCalls spec says that unimplemented commands return ENOTSUPP,
defined as -524. I guess that is why I used ENOTSUPP, but, actually,
this is the return value to the caller, which has nothing to do with the
PVCalls protocol return value. In fact, it could be something entirely
different.

In this case, I think you are correct, it is best to use EOPNOTSUPP.
I'll make the change and retain your Reviewed-by, if that's OK for you.

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

Re: [Xen-devel] [PATCH v8 00/16] Enable Memory Bandwidth Allocation in Xen

[Yi Sun]

On 17-10-19 16:08:09, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 16, 2017 at 11:04:05AM +0800, Yi Sun wrote:
> > Hi, all,
> > 
> > We plan to bring a new PSR (Platform Shared Resource) feature called
> > Intel Memory Bandwidth Allocation (MBA) to Xen.
> > 
> > Besides the MBA enabling, we change some interfaces to make them more
> > general but not only for CAT.
> > 
> > Any comments are welcome!
> > 
> > You can find this series at:
> > https://github.com/yisun-git/xen_mba mba_v8
> > 
> > This version bases on below pre-fix patch which has been merged into staging
> > branch:
> > "x86: psr: support co-exist features' values setting"
> > https://lists.xen.org/archives/html/xen-devel/2017-10/msg00866.html
> > 
> > CC: Jan Beulich 
> > CC: Andrew Cooper 
> > CC: Wei Liu 
> > CC: Ian Jackson 
> > CC: Daniel De Graaf 
> > CC: Roger Pau Monn? 
> > CC: Konrad Rzeszutek Wilk 
> > CC: Chao Peng 
> > CC: Julien Grall 
> > 
> > ---
> > Acked and Reviewed list before V8:
> > 
> > a - Acked-by
> > r - Reviewed-by
> > 
> >   r  patch 1  - docs: create Memory Bandwidth Allocation (MBA) feature 
> > document
> >   ar patch 2  - Rename PSR sysctl/domctl interfaces and xsm policy to make 
> > them be general
> >   ar patch 3  - x86: rename 'cbm_type' to 'psr_type' to make it general
> >   ar patch 4  - x86: a few optimizations to psr codes
> >   r  patch 5  - x86: implement data structure and CPU init flow for MBA
> >   ar patch 6  - x86: implement get hw info flow for MBA
> >   ar patch 7  - x86: implement get value interface for MBA
> 
> So 8 is missing and Ack/Review-edyb?
> 
Jan provided Reviewed-by to patch 8 in this version.

> >   ar patch 9  - tools: create general interfaces to support psr allocation 
> > features
> >   ar patch 10 - tools: implement the new libxc get hw info interface
> >   ar patch 11 - tools: implement the new libxl get hw info interface
> >   ar patch 12 - tools: implement the new xl get hw info interface
> >   ar patch 13 - tools: rename 'xc_psr_cat_type' to 'xc_psr_type'
> >   ar patch 14 - tools: implement new generic get value interface and MBA 
> > get value command
> >   ar patch 15 - tools: implement new generic set value interface and MBA 
> > set value command
> >   ar patch 16 - docs: add MBA description in docs
> 
> 
> Also I tried to merge this on 'staging' and had a bit of issues. By any chance
> do you have an up-to-date branc?

My codes base on commit 572a78. Let me try to apply patches onto staging.
Thanks for your attention to this series!

BRs,
Sun Yi

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

Re: [Xen-devel] [PATCH v3 2/7] xsm: flask: change the dummy xsm policy and flask hook for map_gmfn_foregin

[Zhongze Liu]

2017-10-20 8:34 GMT+08:00 Zhongze Liu :
> Hi Daniel,
>
> 2017-10-20 1:36 GMT+08:00 Daniel De Graaf :
>> On 10/18/2017 10:36 PM, Zhongze Liu wrote:
>>>
>>> The original dummy xsm_map_gmfn_foregin checks if source domain has the
>>> proper
>>> privileges over the target domain. Under this policy, it's not allowed if
>>> a Dom0
>>> wants to map pages from one DomU to another, which restricts some useful
>>> yet not
>>> dangerous use cases of the API, such as sharing pages among DomU's by
>>> calling
>>> XENMEM_add_to_physmap from Dom0.
>>>
>>> For the dummy xsm_map_gmfn_foregin, change to policy to: IFF the current
>>> domain
>>> has the proper privileges on (d) and (t), grant the access.
>>>
>>> For the flask side: 1) Introduce a new av permission MMU__SHARE_MEM to
>>> denote if
>>> two domains can share memory through map_gmfn_foregin. 2) Change to hook
>>> to
>>> grant the access IFF the current domain has proper MMU privileges on (d)
>>> and (t),
>>> and MMU__SHARE_MEM is allowed between (d) and (t). 3) Modify the default
>>> xen.te
>>> to allow MMU__SHARE_MEM for normal domains that allow grant mapping/event
>>> channels.
>>>
>>> This is for the proposal "Allow setting up shared memory areas between VMs
>>> from xl config file" (see [1]).
>>>
>>> [1] https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html
>>>
>>> Signed-off-by: Zhongze Liu 
>>>
>>> Cc: Daniel De Graaf 
>>> Cc: Ian Jackson 
>>> Cc: Wei Liu 
>>> Cc: Stefano Stabellini 
>>> Cc: Julien Grall 
>>> Cc: xen-devel@lists.xen.org
>>> ---
>>>V3:
>>>* Change several if statements to the GCC '... = a ?: b' extention.
>>>* lookup the current domain in the hooks instead of passing it as an
>>> arg
>>> ---
>>>   tools/flask/policy/modules/xen.if   | 2 ++
>>>   xen/include/xsm/dummy.h | 3 ++-
>>>   xen/xsm/flask/hooks.c   | 4 +++-
>>>   xen/xsm/flask/policy/access_vectors | 4 
>>>   4 files changed, 11 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/tools/flask/policy/modules/xen.if
>>> b/tools/flask/policy/modules/xen.if
>>> index 55437496f6..3ffd1c6239 100644
>>> --- a/tools/flask/policy/modules/xen.if
>>> +++ b/tools/flask/policy/modules/xen.if
>>> @@ -127,6 +127,8 @@ define(`domain_comms', `
>>> domain_event_comms($1, $2)
>>> allow $1 $2:grant { map_read map_write copy unmap };
>>> allow $2 $1:grant { map_read map_write copy unmap };
>>> +   allow $1 $2:mmu share_mem;
>>> +   allow $2 $1:mmu share_mem;
>>>   ')
>>> # domain_self_comms(domain)
>>> diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
>>> index b2cd56cdc5..65e7060ad5 100644
>>> --- a/xen/include/xsm/dummy.h
>>> +++ b/xen/include/xsm/dummy.h
>>> @@ -516,7 +516,8 @@ static XSM_INLINE int
>>> xsm_remove_from_physmap(XSM_DEFAULT_ARG struct domain *d1,
>>>   static XSM_INLINE int xsm_map_gmfn_foreign(XSM_DEFAULT_ARG struct domain
>>> *d, struct domain *t)
>>>   {
>>>   XSM_ASSERT_ACTION(XSM_TARGET);
>>> -return xsm_default_action(action, d, t);
>>> +return xsm_default_action(action, current->domain, d) ?:
>>> +xsm_default_action(action, current->domain, t);
>>>   }
>>
>>
>> Same comment as below, the check between (current->domain) and (d) should
>> be redundant with one higher up in the call stack.  The check between
>> (current->domain) and (t) should remain, although this *does* result in a
>> relaxing of the existing permission checks on the call as Jan noted.
>>
>>>   static XSM_INLINE int xsm_hvm_param(XSM_DEFAULT_ARG struct domain *d,
>>> unsigned long op)
>>> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
>>> index f01b4cfaaa..16103bafc9 100644
>>> --- a/xen/xsm/flask/hooks.c
>>> +++ b/xen/xsm/flask/hooks.c
>>> @@ -1199,7 +1199,9 @@ static int flask_remove_from_physmap(struct domain
>>> *d1, struct domain *d2)
>>> static int flask_map_gmfn_foreign(struct domain *d, struct domain *t)
>>>   {
>>> -return domain_has_perm(d, t, SECCLASS_MMU, MMU__MAP_READ |
>>> MMU__MAP_WRITE);
>>> +return domain_has_perm(current->domain, d, SECCLASS_MMU,
>>> MMU__MAP_READ | MMU__MAP_WRITE) ?:
>>> +domain_has_perm(current->domain, t, SECCLASS_MMU, MMU__MAP_READ |
>>> MMU__MAP_WRITE) ?:
>>> +domain_has_perm(d, t, SECCLASS_MMU, MMU__SHARE_MEM);
>>>   }
>>
>>
>> This is at least partially redundant with the higher-level permission checks
>> needed to get to the xenmem_add_* functions (xatp_permission_check call in
>> xen/common/memory.c, for example).  That check already verifies the
>> permission
>> for (current->domain) to modify (d)'s page tables.
>>
>> The other two checks here look correct.
>
> Do you mean that the checks that verify the permission for (current->domain) 
> to
> modify (d)'s page tables have already been done somewhere higher up in the
> call 

[Xen-devel] [linux-linus test] 114682: tolerable FAIL - PUSHED

[osstest service owner]

flight 114682 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114682/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-saverestore.2 fail in 114658 pass 
in 114682
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail in 114658 pass in 
114682
 test-armhf-armhf-examine  5 xen-installfail pass in 114658

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 114658 blocked 
in 114643
 test-amd64-amd64-xl-rtds 10 debian-install  fail in 114658 like 114643
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 114643
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114643
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 114643
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 114643
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114643
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114643
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 114643
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114643
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linuxebe6e90ccc6679cb01d2b280e4b61e6092d4bedb
baseline version:
 linux3728e6a255b50382591ee374c70e6f5276a47d0a

Last test of basis   114643  2017-10-17 10:48:18 Z2 days
Testing same since   114658  2017-10-17 20:18:45 Z2 days2 attempts


People who touched revisions under test:
  Don Brace 
  Hannes Reinecke 
  Hannes Reinecke 
  Himanshu Madhani 
  Johannes Thumshirn 
  Lee Duncan 
  Linus Torvalds 
  Martin K. Petersen 
  Quinn Tran 
  Satish Kharat 

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

Re: [Xen-devel] [PATCH v3 2/7] xsm: flask: change the dummy xsm policy and flask hook for map_gmfn_foregin

[Zhongze Liu]

Hi Daniel,

2017-10-20 1:36 GMT+08:00 Daniel De Graaf :
> On 10/18/2017 10:36 PM, Zhongze Liu wrote:
>>
>> The original dummy xsm_map_gmfn_foregin checks if source domain has the
>> proper
>> privileges over the target domain. Under this policy, it's not allowed if
>> a Dom0
>> wants to map pages from one DomU to another, which restricts some useful
>> yet not
>> dangerous use cases of the API, such as sharing pages among DomU's by
>> calling
>> XENMEM_add_to_physmap from Dom0.
>>
>> For the dummy xsm_map_gmfn_foregin, change to policy to: IFF the current
>> domain
>> has the proper privileges on (d) and (t), grant the access.
>>
>> For the flask side: 1) Introduce a new av permission MMU__SHARE_MEM to
>> denote if
>> two domains can share memory through map_gmfn_foregin. 2) Change to hook
>> to
>> grant the access IFF the current domain has proper MMU privileges on (d)
>> and (t),
>> and MMU__SHARE_MEM is allowed between (d) and (t). 3) Modify the default
>> xen.te
>> to allow MMU__SHARE_MEM for normal domains that allow grant mapping/event
>> channels.
>>
>> This is for the proposal "Allow setting up shared memory areas between VMs
>> from xl config file" (see [1]).
>>
>> [1] https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html
>>
>> Signed-off-by: Zhongze Liu 
>>
>> Cc: Daniel De Graaf 
>> Cc: Ian Jackson 
>> Cc: Wei Liu 
>> Cc: Stefano Stabellini 
>> Cc: Julien Grall 
>> Cc: xen-devel@lists.xen.org
>> ---
>>V3:
>>* Change several if statements to the GCC '... = a ?: b' extention.
>>* lookup the current domain in the hooks instead of passing it as an
>> arg
>> ---
>>   tools/flask/policy/modules/xen.if   | 2 ++
>>   xen/include/xsm/dummy.h | 3 ++-
>>   xen/xsm/flask/hooks.c   | 4 +++-
>>   xen/xsm/flask/policy/access_vectors | 4 
>>   4 files changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/flask/policy/modules/xen.if
>> b/tools/flask/policy/modules/xen.if
>> index 55437496f6..3ffd1c6239 100644
>> --- a/tools/flask/policy/modules/xen.if
>> +++ b/tools/flask/policy/modules/xen.if
>> @@ -127,6 +127,8 @@ define(`domain_comms', `
>> domain_event_comms($1, $2)
>> allow $1 $2:grant { map_read map_write copy unmap };
>> allow $2 $1:grant { map_read map_write copy unmap };
>> +   allow $1 $2:mmu share_mem;
>> +   allow $2 $1:mmu share_mem;
>>   ')
>> # domain_self_comms(domain)
>> diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
>> index b2cd56cdc5..65e7060ad5 100644
>> --- a/xen/include/xsm/dummy.h
>> +++ b/xen/include/xsm/dummy.h
>> @@ -516,7 +516,8 @@ static XSM_INLINE int
>> xsm_remove_from_physmap(XSM_DEFAULT_ARG struct domain *d1,
>>   static XSM_INLINE int xsm_map_gmfn_foreign(XSM_DEFAULT_ARG struct domain
>> *d, struct domain *t)
>>   {
>>   XSM_ASSERT_ACTION(XSM_TARGET);
>> -return xsm_default_action(action, d, t);
>> +return xsm_default_action(action, current->domain, d) ?:
>> +xsm_default_action(action, current->domain, t);
>>   }
>
>
> Same comment as below, the check between (current->domain) and (d) should
> be redundant with one higher up in the call stack.  The check between
> (current->domain) and (t) should remain, although this *does* result in a
> relaxing of the existing permission checks on the call as Jan noted.
>
>>   static XSM_INLINE int xsm_hvm_param(XSM_DEFAULT_ARG struct domain *d,
>> unsigned long op)
>> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
>> index f01b4cfaaa..16103bafc9 100644
>> --- a/xen/xsm/flask/hooks.c
>> +++ b/xen/xsm/flask/hooks.c
>> @@ -1199,7 +1199,9 @@ static int flask_remove_from_physmap(struct domain
>> *d1, struct domain *d2)
>> static int flask_map_gmfn_foreign(struct domain *d, struct domain *t)
>>   {
>> -return domain_has_perm(d, t, SECCLASS_MMU, MMU__MAP_READ |
>> MMU__MAP_WRITE);
>> +return domain_has_perm(current->domain, d, SECCLASS_MMU,
>> MMU__MAP_READ | MMU__MAP_WRITE) ?:
>> +domain_has_perm(current->domain, t, SECCLASS_MMU, MMU__MAP_READ |
>> MMU__MAP_WRITE) ?:
>> +domain_has_perm(d, t, SECCLASS_MMU, MMU__SHARE_MEM);
>>   }
>
>
> This is at least partially redundant with the higher-level permission checks
> needed to get to the xenmem_add_* functions (xatp_permission_check call in
> xen/common/memory.c, for example).  That check already verifies the
> permission
> for (current->domain) to modify (d)'s page tables.
>
> The other two checks here look correct.

Do you mean that the checks that verify the permission for (current->domain) to
modify (d)'s page tables have already been done somewhere higher up in the
call stack so that I can eliminate them in both hooks?


Cheers,

Zhongze Liu.

___
Xen-devel mailing list
Xen-devel@lists.xen.org

[Xen-devel] [linux-next test] 114679: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

flight 114679 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114679/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsmbroken
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 4 host-install(4) broken REGR. 
vs. 114541
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 114541
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 114541
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot  fail REGR. vs. 114541
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 114541
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 114541
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot  fail REGR. vs. 114541
 test-amd64-i386-rumprun-i386  7 xen-boot fail REGR. vs. 114541
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 114541
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 114541
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 114541
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
114541
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 114541
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 114541
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 114541
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot  fail REGR. vs. 114541
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot  fail REGR. vs. 114541
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 114541
 test-amd64-i386-examine   7 reboot   fail REGR. vs. 114541
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
114541
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot  fail REGR. vs. 114541
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 114541
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot fail REGR. vs. 114541
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot fail REGR. vs. 114541
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 114541
 test-amd64-i386-libvirt-qcow2  7 xen-bootfail REGR. vs. 114541
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 114541
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 114541
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 114541
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 114541
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot  fail REGR. vs. 114541
 build-amd64-pvops 6 kernel-build fail REGR. vs. 114541

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  0c8055c2f45f489aff67f4d362f3fdc192cc2d94
baseline version:
 xen  5dd3907a2af37060a675dd3bc5a02b7b38dac66c

Last test of basis   114756  2017-10-19 14:27:49 Z0 days
Testing same since   114776  2017-10-19 21:04:07 Z0 days1 attempts


People who touched revisions under test:
  Stefano Stabellini 

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=0c8055c2f45f489aff67f4d362f3fdc192cc2d94
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.
 PERLLIB=.:.
+++ 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 
0c8055c2f45f489aff67f4d362f3fdc192cc2d94
+ branch=xen-unstable-smoke
+ revision=0c8055c2f45f489aff67f4d362f3fdc192cc2d94
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.:.
 PERLLIB=.:.:.
+++ 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
+++ export PERLLIB=.:.:.:.
+++ PERLLIB=.:.:.:.
++ 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.9-testing
+ '[' x0c8055c2f45f489aff67f4d362f3fdc192cc2d94 = 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/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : 

Re: [Xen-devel] [PATCH for-4.10] xen/arm: gic-v3: Make sure ICC_SRE_EL1 is restored before ICH_VMCR_EL2

[Stefano Stabellini]

On Thu, 19 Oct 2017, Julien Grall wrote:
> Per 8.4.8 in ARM IHI 0069D, ICH_VMCR_EL2.VFIQEn is RES1 when
> ICC_SRE_EL1.SRE is 1. This causes a Group 0 interrupt (as generated in
> GICv2 mode) to be delivered as a FIQ to the guest, with potentially
> consequence. So we must make sure that ICC_SRE_EL1 has been actually
> programmed before at ICH_VMCR_EL2.
> 
> This was discovered when booting EFI in a GICv2 guest on a GICv3
> hardware.
> 
> Signed-off-by: Julien Grall 

Nice catch!

Signed-off-by: Stefano Stabellini 


> ---
> 
> This patch should be backported up to Xen 4.7.
> ---
>  xen/arch/arm/gic-v3.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index 74d00e0c54..b8aff77a6c 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -392,7 +392,16 @@ static void gicv3_restore_state(const struct vcpu *v)
>  val |= GICC_SRE_EL2_ENEL1;
>  WRITE_SYSREG32(val, ICC_SRE_EL2);
>  
> +/*
> + * VFIQEn is RES1 if ICC_SRE_EL1.SRE is 1. This causes a Group0
> + * interrupt (as generated in GICv2 mode) to be delivered as a FIQ
> + * to the guest, with potentially consequence. So we must make sure
> + * that ICC_SRE_EL1 has been actually programmed with the value we
> + * want before starting to mess with the rest of the GIC, and
> + * VMCR_EL1 in particular.
> + */
>  WRITE_SYSREG32(v->arch.gic.v3.sre_el1, ICC_SRE_EL1);
> +isb();
>  WRITE_SYSREG32(v->arch.gic.v3.vmcr, ICH_VMCR_EL2);
>  restore_aprn_regs(>arch.gic);
>  gicv3_restore_lrs(v);
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH for-4.10] xen/arm: gic-v3: Make sure ICC_SRE_EL1 is restored before ICH_VMCR_EL2

[Stefano Stabellini]

On Thu, 19 Oct 2017, Stefano Stabellini wrote:
> On Thu, 19 Oct 2017, Julien Grall wrote:
> > Per 8.4.8 in ARM IHI 0069D, ICH_VMCR_EL2.VFIQEn is RES1 when
> > ICC_SRE_EL1.SRE is 1. This causes a Group 0 interrupt (as generated in
> > GICv2 mode) to be delivered as a FIQ to the guest, with potentially
> > consequence. So we must make sure that ICC_SRE_EL1 has been actually
> > programmed before at ICH_VMCR_EL2.
> > 
> > This was discovered when booting EFI in a GICv2 guest on a GICv3
> > hardware.
> > 
> > Signed-off-by: Julien Grall 
> 
> Nice catch!
> 
> Signed-off-by: Stefano Stabellini 

Sorry wrong tag :)


> 
> > ---
> > 
> > This patch should be backported up to Xen 4.7.
> > ---
> >  xen/arch/arm/gic-v3.c | 9 +
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> > index 74d00e0c54..b8aff77a6c 100644
> > --- a/xen/arch/arm/gic-v3.c
> > +++ b/xen/arch/arm/gic-v3.c
> > @@ -392,7 +392,16 @@ static void gicv3_restore_state(const struct vcpu *v)
> >  val |= GICC_SRE_EL2_ENEL1;
> >  WRITE_SYSREG32(val, ICC_SRE_EL2);
> >  
> > +/*
> > + * VFIQEn is RES1 if ICC_SRE_EL1.SRE is 1. This causes a Group0
> > + * interrupt (as generated in GICv2 mode) to be delivered as a FIQ
> > + * to the guest, with potentially consequence. So we must make sure
> > + * that ICC_SRE_EL1 has been actually programmed with the value we
> > + * want before starting to mess with the rest of the GIC, and
> > + * VMCR_EL1 in particular.
> > + */
> >  WRITE_SYSREG32(v->arch.gic.v3.sre_el1, ICC_SRE_EL1);
> > +isb();
> >  WRITE_SYSREG32(v->arch.gic.v3.vmcr, ICH_VMCR_EL2);
> >  restore_aprn_regs(>arch.gic);
> >  gicv3_restore_lrs(v);
> > -- 
> > 2.11.0
> > 
> 

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

[Xen-devel] [linux-3.18 test] 114677: tolerable FAIL - PUSHED

[osstest service owner]

flight 114677 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114677/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 114446
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114446
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114446
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 114446
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114446
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 114446
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114446
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass

version targeted for testing:
 linux1e8e6b30d014eb77278edb4cd9bee72f0255996f
baseline version:
 linux3e2bb7d281edae5a0732023061402e4a7231dffc

Last test of basis   114446  2017-10-13 01:48:04 Z6 days
Testing same since   114677  2017-10-18 07:56:15 Z1 days1 attempts


People who touched revisions under test:
  Al Viro 
  Alan Stern 
  Andreas Engel 
  Andreas Gruenbacher 
  Andrew Gabbasov 
  Andrey Konovalov 
  Darrick J. Wong 
  Dmitry Vyukov 
  Felipe Balbi 
  Greg Kroah-Hartman 
  Greg Kroah-Hartman gre...@linuxfoundation.org
  Haozhong Zhang 
  Henryk Heisig 
  Herbert Xu 
  Jaejoong Kim 
  Jiri Kosina 
  Joerg Roedel 
  Johan Hovold 
  Kazuya Mizuguchi 

Re: [Xen-devel] [PATCH v8 00/16] Enable Memory Bandwidth Allocation in Xen

[Konrad Rzeszutek Wilk]

On Mon, Oct 16, 2017 at 11:04:05AM +0800, Yi Sun wrote:
> Hi, all,
> 
> We plan to bring a new PSR (Platform Shared Resource) feature called
> Intel Memory Bandwidth Allocation (MBA) to Xen.
> 
> Besides the MBA enabling, we change some interfaces to make them more
> general but not only for CAT.
> 
> Any comments are welcome!
> 
> You can find this series at:
> https://github.com/yisun-git/xen_mba mba_v8
> 
> This version bases on below pre-fix patch which has been merged into staging
> branch:
> "x86: psr: support co-exist features' values setting"
> https://lists.xen.org/archives/html/xen-devel/2017-10/msg00866.html
> 
> CC: Jan Beulich 
> CC: Andrew Cooper 
> CC: Wei Liu 
> CC: Ian Jackson 
> CC: Daniel De Graaf 
> CC: Roger Pau Monné 
> CC: Konrad Rzeszutek Wilk 
> CC: Chao Peng 
> CC: Julien Grall 
> 
> ---
> Acked and Reviewed list before V8:
> 
> a - Acked-by
> r - Reviewed-by
> 
>   r  patch 1  - docs: create Memory Bandwidth Allocation (MBA) feature 
> document
>   ar patch 2  - Rename PSR sysctl/domctl interfaces and xsm policy to make 
> them be general
>   ar patch 3  - x86: rename 'cbm_type' to 'psr_type' to make it general
>   ar patch 4  - x86: a few optimizations to psr codes
>   r  patch 5  - x86: implement data structure and CPU init flow for MBA
>   ar patch 6  - x86: implement get hw info flow for MBA
>   ar patch 7  - x86: implement get value interface for MBA

So 8 is missing and Ack/Review-edyb?

>   ar patch 9  - tools: create general interfaces to support psr allocation 
> features
>   ar patch 10 - tools: implement the new libxc get hw info interface
>   ar patch 11 - tools: implement the new libxl get hw info interface
>   ar patch 12 - tools: implement the new xl get hw info interface
>   ar patch 13 - tools: rename 'xc_psr_cat_type' to 'xc_psr_type'
>   ar patch 14 - tools: implement new generic get value interface and MBA get 
> value command
>   ar patch 15 - tools: implement new generic set value interface and MBA set 
> value command
>   ar patch 16 - docs: add MBA description in docs


Also I tried to merge this on 'staging' and had a bit of issues. By any chance
do you have an up-to-date branc?

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

Re: [Xen-devel] [PATCH v1 15/27] compiler: Option to default to hidden symbols

[Luis R. Rodriguez]

On Wed, Oct 18, 2017 at 04:15:10PM -0700, Thomas Garnier wrote:
> On Thu, Oct 12, 2017 at 1:02 PM, Luis R. Rodriguez  wrote:
> > On Wed, Oct 11, 2017 at 01:30:15PM -0700, Thomas Garnier wrote:
> >> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> >> index e95a2631e545..6997716f73bf 100644
> >> --- a/include/linux/compiler.h
> >> +++ b/include/linux/compiler.h
> >> @@ -78,6 +78,14 @@ extern void __chk_io_ptr(const volatile void __iomem *);
> >>  #include 
> >>  #endif
> >>
> >> +/* Useful for Position Independent Code to reduce global references */
> >> +#ifdef CONFIG_DEFAULT_HIDDEN
> >> +#pragma GCC visibility push(hidden)
> >> +#define __default_visibility  __attribute__((visibility ("default")))
> >
> > Does this still work with CONFIG_LD_DEAD_CODE_DATA_ELIMINATION ?
> 
> I cannot make it work with or without this change. How is it supposed
> to be used?

Sadly I don't think much documentation was really added as part of the Nick's
commits about feature, even though commit b67067f1176 ("kbuild: allow archs to
select link dead code/data elimination") *does* say this was documented.

Side rant: the whole CONFIG_LTO removal was merged in the same commit without
this having gone in as a separate atomic patch.

Nick can you provide a bit more guidance about how to get this feature going or
tested on an architecture? Or are you just sticking to assuming folks using the
linker / compiler flags will know what to do? *Some* guidance could help.

> For me with, it crashes with a bad consdev at:
> http://elixir.free-electrons.com/linux/latest/source/drivers/tty/tty_io.c#L3194

From my reading of the commit log he only had tested it with with powerpc64le,
each other architecture would have to do work to get as far as even booting.

It would require someone then testing Nick's patches against a working
powerpc setup to ensure we don't regress there.

> >> diff --git a/init/Kconfig b/init/Kconfig
> >> index ccb1d8daf241..b640201fcff7 100644
> >> --- a/init/Kconfig
> >> +++ b/init/Kconfig
> >> @@ -1649,6 +1649,13 @@ config PROFILING
> >>  config TRACEPOINTS
> >>   bool
> >>
> >> +#
> >> +# Default to hidden visibility for all symbols.
> >> +# Useful for Position Independent Code to reduce global references.
> >> +#
> >> +config DEFAULT_HIDDEN
> >> + bool
> >
> > Note it is default.
> >
> > Has 0-day ran through this git tree? It should be easy to get it added for
> > testing. Also, even though most changes are x86 based there are some generic
> > changes and I'd love a warm fuzzy this won't break odd / random builds.
> > Although 0-day does cover a lot of test cases, it only has limited run time
> > tests. There are some other test beds which also cover some more obscure
> > architectures. Having a test pass on Guenter's test bed would be nice to
> > see. For that please coordinate with Guenter if he's willing to run this
> > a test for you.
> 
> Not yet, plan to give a v1.5 to Kees Cook to keep in one of his tree
> for couple weeks. I expect it will identify interesting issues.

I bet :)

  Luis

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

Re: [Xen-devel] [dpdk-dev] Can xenvirt pmd work in xen guest (aka DomU) without xen-vhost in Dom0 ?

[Konrad Rzeszutek Wilk]

On Mon, Oct 09, 2017 at 12:13:47AM +0800, Tan, Jianfeng wrote:
> Hi,
> 
> 
> On 10/8/2017 12:54 PM, Bill Bonaparte wrote:
> > Thanks Jianfeng for taking time to reply.
> > 
> > please allow me to briefly explain why I want to run dpdk on xen.
> > our system is based on dpdk, which means we use dpdk as packet
> > receive/transmit engine,
> > and with integrated dpdk virtio/vmxnet3 driver, our system can run on
> > KVM/VMware platform .
> > this year, we have plan to run our system on AWS cloud, but I found that
> > AWS
> > uses xen as its virtualization platform, and the bus-info of nic is
> > vif-x (x could be 0,1,2...),
> > the driver used in kernel is vif. this should be para-virtualized nic
> > used on xen.
> 
> My guess is exactly as you describe. In AWS, we lack of a PMD for xen
> netfront (vif) nic. And even we got such a PMD, we still need a PMD for xen
> netback. Both are missing.
> 
> > 
> > I don't know which dpdk drvier can manage this pv nic. then I see
> > xenvirt, I think this driver can
> > did this job, like virtio can manage virtio nic which is used on kvm.
> > unfortunately, after some study work, I run testpmd successfully on xen,
> > but no packets received.
> > 
> > with the informain got from you, I know It's need to run vhost_xen at
> > dom0 so that xenvirt at domU can work.
> > but for my case, I have no change to run vhost_xen at dom0, because I
> > only can operate my own domU.
> > 
> > for this case, If I want to run system which is based on dpdk at domU,
> > what should I do?
> > appreciate any idea or suggestion from you.
> 
> What kind of performance are you seeking? Only accelerating the frontend by
> a new PMD, i.e. netfront, we can bypass the VM kernel (). But without
> accelerating the backend, it only brings limited improvement.
> 
> Not sure if anyone from Amazon or Oracle can comment?

Joao has been working on updates in the Xen PV network driver such
that there is a higher acceleration (aka recycle grants). See in xen.git
tree:
commit 30655e2bf0ce8ee50e61728e2558e0363f4af1c9
Author: Joao Martins 
Date:   Tue Oct 3 18:46:08 2017 +0100

public/io/netif.h: add gref mapping control messages



This combined with the drivers that Broadcom wrote (I think that is
the name of the company that posted them a year or so ago), should
provide awesome performance.

> 
> Thanks,
> Jianfeng

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

Re: [Xen-devel] [Qemu-devel] [PATCH v5 0/8] xen: xen-domid-restrict improvements

[no-reply]

Hi,

This series seems to have some coding style problems. See output below for
more information:

Type: series
Message-id: 1508431916-9412-1-git-send-email-ian.jack...@eu.citrix.com
Subject: [Qemu-devel] [PATCH v5 0/8] xen: xen-domid-restrict improvements

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

git config --local diff.renamelimit 0
git config --local diff.renames True

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
b9f9672c4d configure: do_compiler: Dump some extra info under bash
74f2dc4a81 os-posix: Provide new -runas . facility
34bf5bf2fa xen: destroy_hvm_domain: Try xendevicemodel_shutdown
baa9207819 xen: move xc_interface compatibility fallback further up the file
f3cb5e6890 xen: destroy_hvm_domain: Move reason into a variable
4d0d91ed91 xen: defer call to xen_restrict until just before os_setup_post
4deada5196 xen: restrict: use xentoolcore_restrict_all
13836ce7d9 xen: link against xentoolcore

=== OUTPUT BEGIN ===
Checking PATCH 1/8: xen: link against xentoolcore...
Checking PATCH 2/8: xen: restrict: use xentoolcore_restrict_all...
Checking PATCH 3/8: xen: defer call to xen_restrict until just before 
os_setup_post...
Checking PATCH 4/8: xen: destroy_hvm_domain: Move reason into a variable...
Checking PATCH 5/8: xen: move xc_interface compatibility fallback further up 
the file...
Checking PATCH 6/8: xen: destroy_hvm_domain: Try xendevicemodel_shutdown...
Checking PATCH 7/8: os-posix: Provide new -runas . facility...
ERROR: consider using qemu_strtoul in preference to strtoul
#45: FILE: os-posix.c:142:
+lv = strtoul(optarg, , 0); /* can't qemu_strtoul, want *ep=='.' */

total: 1 errors, 0 warnings, 100 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

Checking PATCH 8/8: configure: do_compiler: Dump some extra info under bash...
=== OUTPUT END ===

Test command exited with code: 1


---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@freelists.org
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] VPMU interrupt unreliability

[Andrew Cooper]

On 19/10/17 19:24, Kyle Huey wrote:
> On Thu, Oct 19, 2017 at 11:20 AM, Meng Xu  wrote:
>> On Thu, Oct 19, 2017 at 11:40 AM, Andrew Cooper
>>  wrote:
>>> On 19/10/17 16:09, Kyle Huey wrote:
 On Wed, Oct 11, 2017 at 7:09 AM, Boris Ostrovsky
  wrote:
> On 10/10/2017 12:54 PM, Kyle Huey wrote:
>> On Mon, Jul 24, 2017 at 9:54 AM, Kyle Huey  wrote:
>>> On Mon, Jul 24, 2017 at 8:07 AM, Boris Ostrovsky
>>>  wrote:
>> One thing I noticed is that the workaround doesn't appear to be
>> complete: it is only checking PMC0 status and not other counters 
>> (fixed
>> or architectural). Of course, without knowing what the actual problem
>> was it's hard to say whether this was intentional.
> handle_pmc_quirk appears to loop through all the counters ...
 Right, I didn't notice that it is shifting MSR_CORE_PERF_GLOBAL_STATUS
 value one by one and so it is looking at all bits.

>>> 2. Intercepting MSR loads for counters that have the workaround
>>> applied and giving the guest the correct counter value.
>> We'd have to keep track of whether the counter has been reset (by the
>> quirk) since the last MSR write.
> Yes.
>
>>> 3. Or perhaps even changing the workaround to disable the PMI on 
>>> that
>>> counter until the guest acks via GLOBAL_OVF_CTRL, assuming that 
>>> works
>>> on the relevant hardware.
>> MSR_CORE_PERF_GLOBAL_OVF_CTRL is written immediately after the quirk
>> runs (in core2_vpmu_do_interrupt()) so we already do this, don't we?
> I'm suggesting waiting until the *guest* writes to the (virtualized)
> GLOBAL_OVF_CTRL.
 Wouldn't it be better to wait until the counter is reloaded?
>>> Maybe!  I haven't thought through it a lot.  It's still not clear to
>>> me whether MSR_CORE_PERF_GLOBAL_OVF_CTRL actually controls the
>>> interrupt in any way or whether it just resets the bits in
>>> MSR_CORE_PERF_GLOBAL_STATUS and acking the interrupt on the APIC is
>>> all that's required to reenable it.
>>>
>>> - Kyle
>> I wonder if it would be reasonable to just remove the workaround
>> entirely at some point.  The set of people using 1) several year old
>> hardware, 2) an up to date Xen, and 3) the off-by-default performance
>> counters is probably rather small.
> We'd probably want to only enable this for affected processors, not
> remove it outright. But the problem is that we still don't know for sure
> whether this issue affects NHM only, do we?
>
> (https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg02242.html
> is the original message)
 Yes, the basic problem is that we don't know where to draw the line.
>>> vPMU is disabled by default for security reasons,
>>
>> Is there any document about the possible attack via the vPMU? The
>> document I found (such as [1] and XSA-163) just briefly say that the
>> vPMU should be disabled due to security concern.
>>
>>
>> [1] https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html
> Cross-guest information leaks, presumably.

Plenty of "not context switching things properly".

Off the top of my head, there was also a straight DoS by blindly passing
guest values into an unchecked wrmsr(), and privilege escalation via
letting the guest choose where ds_store dumped its data.

~Andrew

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

Re: [Xen-devel] [PATCH RFC 09/14] xen: vmx: Introduce a Hyper call to set subpage

[Tamas K Lengyel]

On Thu, Oct 19, 2017 at 2:13 AM, Zhang Yi  wrote:
> From: Zhang Yi Z 
>
> The Hypercall is defined as HVMOP_set_subpage

Are there any expected use-cases where a HVM guest would need access
to this hypercall? Is spp compatible with #VE? If not, I think it
would be better to integrate this with the existing xen_mem_access_op.

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

Re: [Xen-devel] [PATCH RFC 08/14] xen: vmx: Added setup spp page structure.

[Tamas K Lengyel]

On Thu, Oct 19, 2017 at 2:12 AM, Zhang Yi  wrote:
> From: Zhang Yi Z 
>
> The hardware uses the guest-physical address and bits 11:7 of the
> address accessed to lookup the SPPT to fetch a write permission bit for
> the 128 byte wide sub-page region being accessed within the 4K
> guest-physical page. If the sub-page region write permission bit is set,
> the write is allowed; otherwise the write is disallowed and results in
> an EPT violation.
>
> Guest-physical pages mapped via leaf EPT-paging-structures for which the
> accumulated write-access bit and the SPP bits are both clear (0)
> generate
> EPT violations on memory writes accesses. Guest-physical pages mapped
> via EPT-paging-structure for which the accumulated write-access bit is
> set (1) allow writes, effectively ignoring the SPP bit on the leaf
> EPT-paging structure.
>
> Software will setup the spp page table level4,3,2 as well as EPT page
> structure, and fill the level1 via the 32 bit bitmap per a single 4K
> page.
> Now it could be divided to 32 x 128 sub-pages.
>
> Signed-off-by: Zhang Yi Z 
> ---
>  xen/arch/x86/mm/mem_access.c  | 35 +++
>  xen/arch/x86/mm/p2m-ept.c | 94 
> +++
>  xen/include/asm-x86/hvm/vmx/vmx.h | 10 +
>  xen/include/asm-x86/p2m.h |  3 ++
>  4 files changed, 142 insertions(+)
>
> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
> index a471c74..1b97469 100644
> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access.c
> @@ -490,6 +490,41 @@ unlock_exit:
>  return rc;
>  }
>
> +static u64 format_spp_spte(u32 spp_wp_bitmap)
> +{
> +   u64 new_spte = 0;
> +   int i = 0;
> +
> +   /*
> +* One 4K page contains 32 sub-pages, in SPP table L4E, old bits
> +* are reserved, so we need to transfer u32 subpage write
> +* protect bitmap to u64 SPP L4E format.
> +*/
> +   while ( i < 32 ) {
> +   if ( spp_wp_bitmap & (1ULL << i) )
> +   new_spte |= 1ULL << (i * 2);
> +
> +   i++;
> +   }
> +
> +   return new_spte;
> +}
> +
> +int p2m_set_spp_page_st(struct domain *d, gfn_t gfn, uint32_t access_map)

So nothing in this patch makes use of this function. Could you please
re-organize the patchset so this is included with the patch that
starts using it?

> +{
> +struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +u64 access = format_spp_spte(access_map);
> +unsigned long gfn_l = gfn_x(gfn);
> +int ret = -1;
> +
> +p2m_lock(p2m);
> +if ( p2m->spp_set_entry )
> +ret = p2m->spp_set_entry(p2m, gfn_l, access);
> +p2m_unlock(p2m);
> +
> +return ret;
> +}
> +
>  /*
>   * Local variables:
>   * mode: C

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

Re: [Xen-devel] VPMU interrupt unreliability

[Kyle Huey]

On Thu, Oct 19, 2017 at 11:20 AM, Meng Xu  wrote:
> On Thu, Oct 19, 2017 at 11:40 AM, Andrew Cooper
>  wrote:
>>
>> On 19/10/17 16:09, Kyle Huey wrote:
>> > On Wed, Oct 11, 2017 at 7:09 AM, Boris Ostrovsky
>> >  wrote:
>> >> On 10/10/2017 12:54 PM, Kyle Huey wrote:
>> >>> On Mon, Jul 24, 2017 at 9:54 AM, Kyle Huey  wrote:
>>  On Mon, Jul 24, 2017 at 8:07 AM, Boris Ostrovsky
>>   wrote:
>> >>> One thing I noticed is that the workaround doesn't appear to be
>> >>> complete: it is only checking PMC0 status and not other counters 
>> >>> (fixed
>> >>> or architectural). Of course, without knowing what the actual problem
>> >>> was it's hard to say whether this was intentional.
>> >> handle_pmc_quirk appears to loop through all the counters ...
>> > Right, I didn't notice that it is shifting MSR_CORE_PERF_GLOBAL_STATUS
>> > value one by one and so it is looking at all bits.
>> >
>>  2. Intercepting MSR loads for counters that have the workaround
>>  applied and giving the guest the correct counter value.
>> >>> We'd have to keep track of whether the counter has been reset (by the
>> >>> quirk) since the last MSR write.
>> >> Yes.
>> >>
>>  3. Or perhaps even changing the workaround to disable the PMI on 
>>  that
>>  counter until the guest acks via GLOBAL_OVF_CTRL, assuming that 
>>  works
>>  on the relevant hardware.
>> >>> MSR_CORE_PERF_GLOBAL_OVF_CTRL is written immediately after the quirk
>> >>> runs (in core2_vpmu_do_interrupt()) so we already do this, don't we?
>> >> I'm suggesting waiting until the *guest* writes to the (virtualized)
>> >> GLOBAL_OVF_CTRL.
>> > Wouldn't it be better to wait until the counter is reloaded?
>>  Maybe!  I haven't thought through it a lot.  It's still not clear to
>>  me whether MSR_CORE_PERF_GLOBAL_OVF_CTRL actually controls the
>>  interrupt in any way or whether it just resets the bits in
>>  MSR_CORE_PERF_GLOBAL_STATUS and acking the interrupt on the APIC is
>>  all that's required to reenable it.
>> 
>>  - Kyle
>> >>> I wonder if it would be reasonable to just remove the workaround
>> >>> entirely at some point.  The set of people using 1) several year old
>> >>> hardware, 2) an up to date Xen, and 3) the off-by-default performance
>> >>> counters is probably rather small.
>> >> We'd probably want to only enable this for affected processors, not
>> >> remove it outright. But the problem is that we still don't know for sure
>> >> whether this issue affects NHM only, do we?
>> >>
>> >> (https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg02242.html
>> >> is the original message)
>> > Yes, the basic problem is that we don't know where to draw the line.
>>
>> vPMU is disabled by default for security reasons,
>
>
> Is there any document about the possible attack via the vPMU? The
> document I found (such as [1] and XSA-163) just briefly say that the
> vPMU should be disabled due to security concern.
>
>
> [1] https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html

Cross-guest information leaks, presumably.

>>
>> and also broken, in a
>> way which demonstrates that vPMU isn't getting much real-world use.
>
> I also noticed that AWS seems support part of the vPMU
> functionalities, which were used by Netflix to optimize their
> applications' performance, according to
> http://www.brendangregg.com/blog/2017-05-04/the-pmcs-of-ec2.html .
>
> I guess the security issue should be solved by AWS? However, without
> knowing how the attack could be conducted, I'm not sure how AWS avoids
> the attack concern for vPMU.

AWS only allows you to use the vPMU if you have the entire physical
machine your VM is running on dedicated to yourself.  Cross-guest
information leaks are not a big deal if the same tenant controls all
the guests.

>>
>> As far as I'm concerned, all options (including rm -rf and start from
>> scratch) are acceptable, especially if this ends up giving us a better
>> overall subsystem.
>>
>> Do we know how other hypervisors work around this issue?
>
> Maybe the solution of AWS is a choice? I'm not sure. I'm just thinking aloud. 
> :)
>
> Thanks,
>
> Meng
>
> --
> Meng Xu
> Ph.D. Candidate in Computer and Information Science
> University of Pennsylvania
> http://www.cis.upenn.edu/~mengxu/

- Kyle

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

Re: [Xen-devel] VPMU interrupt unreliability

[Meng Xu]

On Thu, Oct 19, 2017 at 11:40 AM, Andrew Cooper
 wrote:
>
> On 19/10/17 16:09, Kyle Huey wrote:
> > On Wed, Oct 11, 2017 at 7:09 AM, Boris Ostrovsky
> >  wrote:
> >> On 10/10/2017 12:54 PM, Kyle Huey wrote:
> >>> On Mon, Jul 24, 2017 at 9:54 AM, Kyle Huey  wrote:
>  On Mon, Jul 24, 2017 at 8:07 AM, Boris Ostrovsky
>   wrote:
> >>> One thing I noticed is that the workaround doesn't appear to be
> >>> complete: it is only checking PMC0 status and not other counters 
> >>> (fixed
> >>> or architectural). Of course, without knowing what the actual problem
> >>> was it's hard to say whether this was intentional.
> >> handle_pmc_quirk appears to loop through all the counters ...
> > Right, I didn't notice that it is shifting MSR_CORE_PERF_GLOBAL_STATUS
> > value one by one and so it is looking at all bits.
> >
>  2. Intercepting MSR loads for counters that have the workaround
>  applied and giving the guest the correct counter value.
> >>> We'd have to keep track of whether the counter has been reset (by the
> >>> quirk) since the last MSR write.
> >> Yes.
> >>
>  3. Or perhaps even changing the workaround to disable the PMI on that
>  counter until the guest acks via GLOBAL_OVF_CTRL, assuming that works
>  on the relevant hardware.
> >>> MSR_CORE_PERF_GLOBAL_OVF_CTRL is written immediately after the quirk
> >>> runs (in core2_vpmu_do_interrupt()) so we already do this, don't we?
> >> I'm suggesting waiting until the *guest* writes to the (virtualized)
> >> GLOBAL_OVF_CTRL.
> > Wouldn't it be better to wait until the counter is reloaded?
>  Maybe!  I haven't thought through it a lot.  It's still not clear to
>  me whether MSR_CORE_PERF_GLOBAL_OVF_CTRL actually controls the
>  interrupt in any way or whether it just resets the bits in
>  MSR_CORE_PERF_GLOBAL_STATUS and acking the interrupt on the APIC is
>  all that's required to reenable it.
> 
>  - Kyle
> >>> I wonder if it would be reasonable to just remove the workaround
> >>> entirely at some point.  The set of people using 1) several year old
> >>> hardware, 2) an up to date Xen, and 3) the off-by-default performance
> >>> counters is probably rather small.
> >> We'd probably want to only enable this for affected processors, not
> >> remove it outright. But the problem is that we still don't know for sure
> >> whether this issue affects NHM only, do we?
> >>
> >> (https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg02242.html
> >> is the original message)
> > Yes, the basic problem is that we don't know where to draw the line.
>
> vPMU is disabled by default for security reasons,


Is there any document about the possible attack via the vPMU? The
document I found (such as [1] and XSA-163) just briefly say that the
vPMU should be disabled due to security concern.


[1] https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html

>
> and also broken, in a
> way which demonstrates that vPMU isn't getting much real-world use.

I also noticed that AWS seems support part of the vPMU
functionalities, which were used by Netflix to optimize their
applications' performance, according to
http://www.brendangregg.com/blog/2017-05-04/the-pmcs-of-ec2.html .

I guess the security issue should be solved by AWS? However, without
knowing how the attack could be conducted, I'm not sure how AWS avoids
the attack concern for vPMU.

>
> As far as I'm concerned, all options (including rm -rf and start from
> scratch) are acceptable, especially if this ends up giving us a better
> overall subsystem.
>
> Do we know how other hypervisors work around this issue?

Maybe the solution of AWS is a choice? I'm not sure. I'm just thinking aloud. :)

Thanks,

Meng

-- 
Meng Xu
Ph.D. Candidate in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] [PATCH RFC 05/14] xen: vmx: Disable the 2M/1G superpage when SPP enabled

[Tamas K Lengyel]

On Thu, Oct 19, 2017 at 2:11 AM, Zhang Yi  wrote:
> From: Zhang Yi Z 
>
> Current we only support Sub-page Protection on the 4k
> page table.
>
> Signed-off-by: Zhang Yi Z 
> ---
>  xen/arch/x86/hvm/vmx/vmx.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 04ae0d6..a4c24bb 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2497,6 +2497,12 @@ const struct hvm_function_table * __init 
> start_vmx(void)
>  vmx_function_table.get_guest_bndcfgs = vmx_get_guest_bndcfgs;
>  }
>
> +if ( cpu_has_vmx_ept_spp )

I think this really only ought to happen if the command-line option
has also been enabled.

> +{
> +vmx_function_table.hap_capabilities &= ~HVM_HAP_SUPERPAGE_2MB;
> +vmx_function_table.hap_capabilities &= ~HVM_HAP_SUPERPAGE_1GB;
> +}
> +
>  setup_vmcs_dump();
>
>  lbr_tsx_fixup_check();
> --
> 2.7.4

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

Re: [Xen-devel] [PATCH] x86/xen: support priv-mapping in an HVM tools domain

[Boris Ostrovsky]

On 10/19/2017 11:26 AM, Paul Durrant wrote:
> If the domain has XENFEAT_auto_translated_physmap then use of the PV-
> specific HYPERVISOR_mmu_update hypercall is clearly incorrect.
>
> This patch adds checks in xen_remap_domain_gfn_array() and
> xen_unmap_domain_gfn_array() which call through to the approprate
> xlate_mmu function if the feature is present. A check is also added
> to xen_remap_domain_gfn_range() to fail with -EOPNOTSUPP since this
> should not be used in an HVM tools domain.
>
> Signed-off-by: Paul Durrant 
> ---
> Cc: Boris Ostrovsky 
> Cc: Juergen Gross 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> ---
>  arch/x86/xen/mmu.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 3e15345abfe7..d33e7dbe3129 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -172,6 +172,9 @@ int xen_remap_domain_gfn_range(struct vm_area_struct *vma,
>  pgprot_t prot, unsigned domid,
>  struct page **pages)
>  {
> + if (xen_feature(XENFEAT_auto_translated_physmap))
> + return -EOPNOTSUPP;
> +

This is never called on XENFEAT_auto_translated_physmap domains, there
is a check in privcmd_ioctl_mmap() for that.

>   return do_remap_gfn(vma, addr, , nr, NULL, prot, domid, pages);
>  }
>  EXPORT_SYMBOL_GPL(xen_remap_domain_gfn_range);
> @@ -182,6 +185,10 @@ int xen_remap_domain_gfn_array(struct vm_area_struct 
> *vma,
>  int *err_ptr, pgprot_t prot,
>  unsigned domid, struct page **pages)
>  {
> + if (xen_feature(XENFEAT_auto_translated_physmap))
> + return xen_xlate_remap_gfn_array(vma, addr, gfn, nr, err_ptr,
> +  prot, domid, pages);
> +

So how did this work before? In fact, I don't see any callers of
xen_xlate_{re|un}map_gfn_range().

-boris


>   /* We BUG_ON because it's a programmer error to pass a NULL err_ptr,
>* and the consequences later is quite hard to detect what the actual
>* cause of "wrong memory was mapped in".
> @@ -193,9 +200,12 @@ EXPORT_SYMBOL_GPL(xen_remap_domain_gfn_array);
>  
>  /* Returns: 0 success */
>  int xen_unmap_domain_gfn_range(struct vm_area_struct *vma,
> -int numpgs, struct page **pages)
> +int nr, struct page **pages)
>  {
> - if (!pages || !xen_feature(XENFEAT_auto_translated_physmap))
> + if (xen_feature(XENFEAT_auto_translated_physmap))
> + return xen_xlate_unmap_gfn_range(vma, nr, pages);
> +
> + if (!pages)
>   return 0;
>  
>   return -EINVAL;


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

Re: [Xen-devel] [PATCH v3 2/7] xsm: flask: change the dummy xsm policy and flask hook for map_gmfn_foregin

[Daniel De Graaf]

On 10/19/2017 07:58 AM, Jan Beulich wrote:

On 19.10.17 at 04:36,  wrote:

--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -516,7 +516,8 @@ static XSM_INLINE int 
xsm_remove_from_physmap(XSM_DEFAULT_ARG struct domain *d1,
  static XSM_INLINE int xsm_map_gmfn_foreign(XSM_DEFAULT_ARG struct domain *d, 
struct domain *t)
  {
  XSM_ASSERT_ACTION(XSM_TARGET);
-return xsm_default_action(action, d, t);
+return xsm_default_action(action, current->domain, d) ?:
+xsm_default_action(action, current->domain, t);
  }


When all three domains are different, how does the changed
policy reflect the original "d has privilege over t" requirement?
I understand you want to relax the current condition, but this
shouldn't come at the price of granting access when access
should be denied. Nor the inverse - the current domain not
having privilege over both does also not mean d doesn't have
the necessary privilege over t.

I continue to think that you can't validly retrofit the new
intended functionality onto the existing hypercall, even if
nothing except the permission check needs to be different.

Jan


If this operation is going to be allowed at all (and I agree it has
valid use cases), then there won't be a privilege relationship between
(d) and (t) to check - they'll both be (somewhat related) domUs as far
as Xen can tell.  If this hypercall isn't used, adding a new hypercall
(subop) is the only way I'd see to do it - and that seems very redundant
as it'd need to do all the same checks except for the one about the
relationship between (d) and (t).  I don't see the reason why the
existing hypercall should deny being used for that purpose once it's
possible using other means.

The only possible problem that springs to mind is a restricted kernel
interface (such as the one used by QEMU in dom0 that restricts to a
single target domain) that now doesn't realize it's relaying an
operation that also requires permission over (t) after only checking
that the origin is allowed to modify (d).

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

Re: [Xen-devel] [PATCH v3 2/7] xsm: flask: change the dummy xsm policy and flask hook for map_gmfn_foregin

[Daniel De Graaf]

On 10/18/2017 10:36 PM, Zhongze Liu wrote:

The original dummy xsm_map_gmfn_foregin checks if source domain has the proper
privileges over the target domain. Under this policy, it's not allowed if a Dom0
wants to map pages from one DomU to another, which restricts some useful yet not
dangerous use cases of the API, such as sharing pages among DomU's by calling
XENMEM_add_to_physmap from Dom0.

For the dummy xsm_map_gmfn_foregin, change to policy to: IFF the current domain
has the proper privileges on (d) and (t), grant the access.

For the flask side: 1) Introduce a new av permission MMU__SHARE_MEM to denote if
two domains can share memory through map_gmfn_foregin. 2) Change to hook to
grant the access IFF the current domain has proper MMU privileges on (d) and 
(t),
and MMU__SHARE_MEM is allowed between (d) and (t). 3) Modify the default xen.te
to allow MMU__SHARE_MEM for normal domains that allow grant mapping/event
channels.

This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file" (see [1]).

[1] https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html

Signed-off-by: Zhongze Liu 

Cc: Daniel De Graaf 
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: xen-devel@lists.xen.org
---
   V3:
   * Change several if statements to the GCC '... = a ?: b' extention.
   * lookup the current domain in the hooks instead of passing it as an arg
---
  tools/flask/policy/modules/xen.if   | 2 ++
  xen/include/xsm/dummy.h | 3 ++-
  xen/xsm/flask/hooks.c   | 4 +++-
  xen/xsm/flask/policy/access_vectors | 4 
  4 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/tools/flask/policy/modules/xen.if 
b/tools/flask/policy/modules/xen.if
index 55437496f6..3ffd1c6239 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -127,6 +127,8 @@ define(`domain_comms', `
domain_event_comms($1, $2)
allow $1 $2:grant { map_read map_write copy unmap };
allow $2 $1:grant { map_read map_write copy unmap };
+   allow $1 $2:mmu share_mem;
+   allow $2 $1:mmu share_mem;
  ')
  
  # domain_self_comms(domain)

diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index b2cd56cdc5..65e7060ad5 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -516,7 +516,8 @@ static XSM_INLINE int 
xsm_remove_from_physmap(XSM_DEFAULT_ARG struct domain *d1,
  static XSM_INLINE int xsm_map_gmfn_foreign(XSM_DEFAULT_ARG struct domain *d, 
struct domain *t)
  {
  XSM_ASSERT_ACTION(XSM_TARGET);
-return xsm_default_action(action, d, t);
+return xsm_default_action(action, current->domain, d) ?:
+xsm_default_action(action, current->domain, t);
  }


Same comment as below, the check between (current->domain) and (d) should
be redundant with one higher up in the call stack.  The check between
(current->domain) and (t) should remain, although this *does* result in a
relaxing of the existing permission checks on the call as Jan noted.


  static XSM_INLINE int xsm_hvm_param(XSM_DEFAULT_ARG struct domain *d, 
unsigned long op)
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index f01b4cfaaa..16103bafc9 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1199,7 +1199,9 @@ static int flask_remove_from_physmap(struct domain *d1, 
struct domain *d2)
  
  static int flask_map_gmfn_foreign(struct domain *d, struct domain *t)

  {
-return domain_has_perm(d, t, SECCLASS_MMU, MMU__MAP_READ | MMU__MAP_WRITE);
+return domain_has_perm(current->domain, d, SECCLASS_MMU, MMU__MAP_READ | 
MMU__MAP_WRITE) ?:
+domain_has_perm(current->domain, t, SECCLASS_MMU, MMU__MAP_READ | 
MMU__MAP_WRITE) ?:
+domain_has_perm(d, t, SECCLASS_MMU, MMU__SHARE_MEM);
  }


This is at least partially redundant with the higher-level permission checks
needed to get to the xenmem_add_* functions (xatp_permission_check call in
xen/common/memory.c, for example).  That check already verifies the permission
for (current->domain) to modify (d)'s page tables.

The other two checks here look correct.

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

Re: [Xen-devel] runstatedir matters when using debhelper tools in Artful

[Wei Liu]

CC Ian who know debhelper better.

On Thu, Oct 19, 2017 at 02:49:06PM +, Mark Pryor wrote:
> Hello,
> When finishing a debianised build of xen-4.10~rc1 in Artful I had no extra 
> patches, so I left outthis patch below that I used to build xen-4.9 in Artful:
> 
> https://lists.xen.org/archives/html/xen-devel/2017-09/msg01424.html
> When `dpkg -i xen_4.10~rc1-artful2_amd64.deb` is run, the systemd symlink 
> links should get written to /etc/systemd/system/multi*, but now this failed, 
> unlike the xen-4.9 equivalent package.
> When it works (patch is applied) it looks like below
> paste.debian.net/plain/991667
> When it fails there are no systemd symlinks written and the package install 
> is broken.
> Nobody might notice if the runstatedir variable is missing from 
> config/Paths.mk, but if you build Xen with a debian-delta and use debhelper 
> it matters (in Artful or Buster).
> PryMar56##xen-packaging

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

[Xen-devel] [PATCH for-4.10] xen/arm: gic-v3: Make sure ICC_SRE_EL1 is restored before ICH_VMCR_EL2

[Julien Grall]

Per 8.4.8 in ARM IHI 0069D, ICH_VMCR_EL2.VFIQEn is RES1 when
ICC_SRE_EL1.SRE is 1. This causes a Group 0 interrupt (as generated in
GICv2 mode) to be delivered as a FIQ to the guest, with potentially
consequence. So we must make sure that ICC_SRE_EL1 has been actually
programmed before at ICH_VMCR_EL2.

This was discovered when booting EFI in a GICv2 guest on a GICv3
hardware.

Signed-off-by: Julien Grall 

---

This patch should be backported up to Xen 4.7.
---
 xen/arch/arm/gic-v3.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 74d00e0c54..b8aff77a6c 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -392,7 +392,16 @@ static void gicv3_restore_state(const struct vcpu *v)
 val |= GICC_SRE_EL2_ENEL1;
 WRITE_SYSREG32(val, ICC_SRE_EL2);
 
+/*
+ * VFIQEn is RES1 if ICC_SRE_EL1.SRE is 1. This causes a Group0
+ * interrupt (as generated in GICv2 mode) to be delivered as a FIQ
+ * to the guest, with potentially consequence. So we must make sure
+ * that ICC_SRE_EL1 has been actually programmed with the value we
+ * want before starting to mess with the rest of the GIC, and
+ * VMCR_EL1 in particular.
+ */
 WRITE_SYSREG32(v->arch.gic.v3.sre_el1, ICC_SRE_EL1);
+isb();
 WRITE_SYSREG32(v->arch.gic.v3.vmcr, ICH_VMCR_EL2);
 restore_aprn_regs(>arch.gic);
 gicv3_restore_lrs(v);
-- 
2.11.0


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

Re: [Xen-devel] Block device hang after migration

[Wei Liu]

On Thu, Oct 19, 2017 at 03:30:28PM +0100, Roger Pau Monné wrote:
> On Thu, Oct 19, 2017 at 11:53:11AM +0100, Wei Liu wrote:
> > Hi
> > 
> > In the process of upgrading osstest to Stretch, I discovered an issue
> > with the block device. This happens after a local migration.
> > 
> > [  127.216232] Freezing user space processes ... (elapsed 0.005 seconds) 
> > done.
> > [  127.222143] Freezing remaining freezable tasks ... 
> > [  147.228913] Freezing of tasks failed after 20.006 seconds (1 tasks 
> > refusing to freeze, wq_busy=0):
> > [  147.228935] jbd2/xvda1-8D0   143  2 0x
> > [  147.228964]  880005109000  88000569e000 
> > 88001f918240
> > [  147.228984]  88001ea7a000 c9004029bb30 816038e3 
> > c9004029bbe8
> > [  147.229001]  00ff8800056d1500 88001f918240  
> > 88000569e000
> > [  147.229028] Call Trace:
> > [  147.229274]  [] ? __schedule+0x233/0x6d0
> > [  147.229297]  [] ? bit_wait+0x50/0x50
> > [  147.229307]  [] ? schedule+0x32/0x80
> > [  147.229318]  [] ? schedule_timeout+0x1de/0x350
> > [  147.229345]  [] ? xen_clocksource_get_cycles+0x11/0x20
> > [  147.229363]  [] ? ktime_get+0x3b/0xb0
> > [  147.229378]  [] ? bit_wait+0x50/0x50
> > [  147.229389]  [] ? io_schedule_timeout+0x9d/0x100
> > [  147.229401]  [] ? prepare_to_wait+0x57/0x80
> > [  147.229417]  [] ? bit_wait_io+0x17/0x60
> > [  147.229427]  [] ? __wait_on_bit+0x53/0x80
> > [  147.229442]  [] ? bit_wait+0x50/0x50
> > [  147.229457]  [] ? out_of_line_wait_on_bit+0x7e/0xa0
> > [  147.229469]  [] ? wake_atomic_t_function+0x60/0x60
> > [  147.229563]  [] ? 
> > jbd2_journal_commit_transaction+0xdd2/0x17a0 [jbd2]
> > [  147.229589]  [] ? finish_task_switch+0x7d/0x1f0
> > [  147.229612]  [] ? kjournald2+0xc2/0x260 [jbd2]
> > [  147.229624]  [] ? prepare_to_wait_event+0xf0/0xf0
> > [  147.229643]  [] ? commit_timeout+0x10/0x10 [jbd2]
> > [  147.229656]  [] ? kthread+0xd7/0xf0
> > [  147.229667]  [] ? kthread_park+0x60/0x60
> > [  147.229684]  [] ? ret_from_fork+0x25/0x30
> > [  147.229708] Restarting kernel threads ... done.
> > [  147.230496] xen:manage: do_suspend: freeze kernel threads failed -16
> > [  147.230508] Restarting tasks ... done.
> > [  238.484918] 
> > 
> > http://logs.test-lab.xenproject.org/osstest/logs/114709/test-amd64-amd64-xl-qcow2/fiano1---var-log-xen-console-guest-debian.stretch.guest.osstest--incoming.log
> > 
> > And this seems to be the same issue Olivier Bonvale reported in "[Xen-devel]
> > task btrfs-transacti:651 blocked for more than 120 seconds".
> 
> Not really I think, that didn't involve migration IIRC. Oliver was
> attaching 26 PV disks, which starved the grant table.
> 
> > The guest in osstest uses ext4, with only one or two vbds. Kernel is 
> > Debian's
> > stock kernel (4.9).
> 
> There's been a lot of patches from Juergen and others since 4.9.
> osstest is currently using 4.9 also and doesn't seem to complain.
> 
> Is there any newer kernel available from backports?
> 

There is no Debian backport kernel in the case -- it is going to be 4.9
all the time.

Assuming all patches required will be backported to 4.9.  We just need
to wait for the changes to trickle down to Debian.

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

Re: [Xen-devel] [RFC 4/4] arm: tee: add basic OP-TEE mediator

[Julien Grall]

Hi,

On 19/10/17 17:37, Volodymyr Babchuk wrote:

On Thu, Oct 19, 2017 at 05:12:17PM +0100, Julien Grall wrote:

Hi Julien,


+if ( rc < 0 )
+{
+gprintk(XENLOG_INFO, "OP-TEE: Can't map static shm for Dom0: %d", rc);


gprintk already dump the domid. So no need to say Dom0.

I just wanted to emphasis that we mappaed memory for Dom0. Will remove.


gprintk will printk d0. So there are no point to say it a second time...



+set_user_reg(regs, 0, OPTEE_SMC_RETURN_ENOTAVAIL);
+}
+
+return true;
+}
+
+static bool handle_exchange_capabilities(struct cpu_user_regs *regs)
+{
+forward_call(regs);
+
+printk("handle_exchange_capabilities\n");


Same here, no plain prink.

Sorry, this is another debug print. Missed it when formatted patches.


+/* Return error back to the guest */
+if ( get_user_reg(regs, 0) != OPTEE_SMC_RETURN_OK)
+return true;
+
+/* Don't allow guests to work without dynamic SHM */


Hmmm? But you don't support guests today. So why are you checking that?

This is a RFC. Will remove this parts of the code in a proper patch series.

I just wanted to ensure that community is okay with proposed approach and
to show how minimalistic mediator can look.

I don't think this is true. You only show how easy it is to let Dom0
accessing TEE. And as I said in the cover letter, this is not the
controversial part.

Actually I wanted to show approach when mediator resides right in xen.
I got valuable input from you. Now I see that I must completely rework the
first patch. And, probably, show more comprehensive support from OP-TEE side.


The more controversial one is the guest support that you completely left
aside. I believe this part will not be as minimalistic as you think because
you need to translate buffer address and prevent those buffers to disappear
under your feet.

Yes. I plan to copy all buffers where IPAs presented to another place,
so DomU will not be able to see PAs during translation. And I plan to
pin all DomU pages with a data. Also I'll read from guest pages only
once. I think, this will be enough.


There are probably other problem to fix...

Probably yes...

I think, I'll focus on OP-TEE side right now and come back when there will
be more more to show.


To clarify my view. I am not against a temporary support of OP-TEE for the
hardware domain in Xen. But it does not mean I would be ready to see  the a
full OP-TEE support for guests in Xen.

Hm. What did you mean in last sentence? Our (here, at EPAM) target is full
virtualization support for OP-TEE. If you don't want to see it in Xen,
then what another ways we have?


Sorry it was not clear enough. I meant that whilst I am happy to see OP-TEE
support for the hardware domain in the hypervisor, we still need to discuss
on the approach for guests.

Excuse me, I still didn't get it. You imply that we need some
completely different approach for guests? Or I can stick with current
approach, just add more restrictions?

Under "current approach" I mostly mean "handle SMCs to TEE at EL2" as
opposed to "handle them in stubdom". Half patches of this RFC should
be severely reworked anyways.


Let me answer on your cover letter. That would be easier to draw a 
decision with your last e-mail.


Cheers,

--
Julien Grall

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

[Xen-devel] [PATCH 3/8] xen: defer call to xen_restrict until just before os_setup_post

[Ian Jackson]

We need to restrict *all* the control fds that qemu opens.  Looking in
/proc/PID/fd shows there are many; their allocation seems scattered
throughout Xen support code in qemu.

We must postpone the restrict call until roughly the same time as qemu
changes its uid, chroots (if applicable), and so on.

There doesn't seem to be an appropriate hook already.  The RunState
change hook fires at different times depending on exactly what mode
qemu is operating in.

And it appears that no-one but the Xen code wants a hook at this phase
of execution.  So, introduce a bare call to a new function
xen_setup_post, just before os_setup_post.  Also provide the
appropriate stub for when Xen compilation is disabled.

We do the restriction before rather than after os_setup_post, because
xen_restrict may need to open /dev/null, and os_setup_post might have
called chroot.

Signed-off-by: Ian Jackson 
---
v3: Do xen_setup_post just before, not just after, os_setup_post,
to improve interaction with chroot.  Thanks to Ross Lagerwall.
---
 hw/i386/xen/xen-hvm.c   |  8 
 hw/xen/xen-common.c | 13 +
 include/sysemu/sysemu.h |  2 ++
 stubs/xen-hvm.c |  5 +
 vl.c|  1 +
 5 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index d9ccd5d..7b60ec6 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -1254,14 +1254,6 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion 
**ram_memory)
 goto err;
 }
 
-if (xen_domid_restrict) {
-rc = xen_restrict(xen_domid);
-if (rc < 0) {
-error_report("failed to restrict: error %d", errno);
-goto err;
-}
-}
-
 xen_create_ioreq_server(xen_domid, >ioservid);
 
 state->exit.notify = xen_exit_notifier;
diff --git a/hw/xen/xen-common.c b/hw/xen/xen-common.c
index 632a938..4056420 100644
--- a/hw/xen/xen-common.c
+++ b/hw/xen/xen-common.c
@@ -117,6 +117,19 @@ static void xen_change_state_handler(void *opaque, int 
running,
 }
 }
 
+void xen_setup_post(void)
+{
+int rc;
+
+if (xen_domid_restrict) {
+rc = xen_restrict(xen_domid);
+if (rc < 0) {
+perror("xen: failed to restrict");
+exit(1);
+}
+}
+}
+
 static int xen_init(MachineState *ms)
 {
 xen_xc = xc_interface_open(0, 0, 0);
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index b213696..b064a55 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -93,6 +93,8 @@ void qemu_remove_machine_init_done_notifier(Notifier *notify);
 
 void qemu_announce_self(void);
 
+void xen_setup_post(void);
+
 extern int autostart;
 
 typedef enum {
diff --git a/stubs/xen-hvm.c b/stubs/xen-hvm.c
index 3ca6c51..9701feb 100644
--- a/stubs/xen-hvm.c
+++ b/stubs/xen-hvm.c
@@ -13,6 +13,7 @@
 #include "hw/xen/xen.h"
 #include "exec/memory.h"
 #include "qmp-commands.h"
+#include "sysemu/sysemu.h"
 
 int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num)
 {
@@ -61,3 +62,7 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion 
**ram_memory)
 void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
 {
 }
+
+void xen_setup_post(void)
+{
+}
diff --git a/vl.c b/vl.c
index fb1f05b..ca06553 100644
--- a/vl.c
+++ b/vl.c
@@ -4792,6 +4792,7 @@ int main(int argc, char **argv, char **envp)
 vm_start();
 }
 
+xen_setup_post();
 os_setup_post();
 
 main_loop();
-- 
2.1.4


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

[Xen-devel] [PATCH 5/8] xen: move xc_interface compatibility fallback further up the file

[Ian Jackson]

We are going to want to use the dummy xendevicemodel_handle type in
new stub functions in the CONFIG_XEN_CTRL_INTERFACE_VERSION < 41000
section.  So we need to provide that definition, or (as applicable)
include the appropriate header, earlier in the file.

(Ideally the newer compatibility layers would be at the bottom of the
file, so that they can naturally benefit from the compatibility layers
for earlier version.  But that's rather too much for this series.)

No functional change.

Signed-off-by: Ian Jackson 
---
v2: New patch in v2 of the series
---
 include/hw/xen/xen_common.h | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 3f44a63..8efdb8a 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -78,6 +78,17 @@ static inline void *xenforeignmemory_map(xc_interface *h, 
uint32_t dom,
 
 extern xenforeignmemory_handle *xen_fmem;
 
+#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40900
+
+typedef xc_interface xendevicemodel_handle;
+
+#else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 40900 */
+
+#undef XC_WANT_COMPAT_DEVICEMODEL_API
+#include 
+
+#endif
+
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 41000
 
 #define XEN_COMPAT_PHYSMAP
@@ -105,8 +116,6 @@ static inline int xentoolcore_restrict_all(domid_t domid)
 
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40900
 
-typedef xc_interface xendevicemodel_handle;
-
 static inline xendevicemodel_handle *xendevicemodel_open(
 struct xentoollog_logger *logger, unsigned int open_flags)
 {
@@ -228,11 +237,6 @@ static inline int xendevicemodel_set_mem_type(
 return xc_hvm_set_mem_type(dmod, domid, mem_type, first_pfn, nr);
 }
 
-#else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 40900 */
-
-#undef XC_WANT_COMPAT_DEVICEMODEL_API
-#include 
-
 #endif
 
 extern xendevicemodel_handle *xen_dmod;
-- 
2.1.4


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

[Xen-devel] [PATCH 1/8] xen: link against xentoolcore

[Ian Jackson]

From: Anthony PERARD 

Xen libraries 4.10 will include a new xentoolcore library, without
which xendevicemodel et al will not work.

Signed-off-by: Ian Jackson 
---
 configure | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/configure b/configure
index fd7e3a5..6f691df 100755
--- a/configure
+++ b/configure
@@ -2072,7 +2072,7 @@ if test "$xen" != "no" ; then
   $($pkg_config --modversion xencontrol | sed 's/\./ /g') )"
 xen=yes
 xen_pc="xencontrol xenstore xenguest xenforeignmemory xengnttab"
-xen_pc="$xen_pc xenevtchn xendevicemodel"
+xen_pc="$xen_pc xenevtchn xendevicemodel xentoolcore"
 QEMU_CFLAGS="$QEMU_CFLAGS $($pkg_config --cflags $xen_pc)"
 libs_softmmu="$($pkg_config --libs $xen_pc) $libs_softmmu"
 LDFLAGS="$($pkg_config --libs $xen_pc) $LDFLAGS"
@@ -2104,18 +2104,20 @@ EOF
 cat > $TMPC <
+#include 
 int main(void) {
   xenforeignmemory_handle *xfmem;
 
   xfmem = xenforeignmemory_open(0, 0);
   xenforeignmemory_map2(xfmem, 0, 0, 0, 0, 0, 0, 0);
+  xentoolcore_restrict_all(0);
 
   return 0;
 }
 EOF
-compile_prog "" "$xen_libs -lxendevicemodel $xen_stable_libs"
+compile_prog "" "$xen_libs -lxendevicemodel $xen_stable_libs 
-lxentoolcore"
   then
-  xen_stable_libs="-lxendevicemodel $xen_stable_libs"
+  xen_stable_libs="-lxendevicemodel $xen_stable_libs -lxentoolcore"
   xen_ctrl_version=41000
   xen=yes
 elif
-- 
2.1.4


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

[Xen-devel] [PATCH 2/8] xen: restrict: use xentoolcore_restrict_all

[Ian Jackson]

And insist that it works.

Drop individual use of xendevicemodel_restrict and
xenforeignmemory_restrict.  These are not actually effective in this
version of qemu, because qemu has a large number of fds open onto
various Xen control devices.

The restriction arrangements are still not right, because the
restriction needs to be done very late - after qemu has opened all of
its control fds.

xentoolcore_restrict_all and xentoolcore.h are available in Xen 4.10
and later, only.  Provide a compatibility stub.  And drop the
compatibility stubs for the old functions.

Signed-off-by: Ian Jackson 
---
v2: Modify the compatibility code, too.
Bump this patch ahead of "defer call to xen_restrict until running"
Retain call to xentoolcore_restrict_all

Signed-off-by: Ian Jackson 
---
 include/hw/xen/xen_common.h | 46 +++--
 1 file changed, 11 insertions(+), 35 deletions(-)

diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 86c7f26..3f44a63 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -91,6 +91,16 @@ static inline void 
*xenforeignmemory_map2(xenforeignmemory_handle *h,
 return xenforeignmemory_map(h, dom, prot, pages, arr, err);
 }
 
+static inline int xentoolcore_restrict_all(domid_t domid)
+{
+errno = ENOTTY;
+return -1;
+}
+
+#else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 41000 */
+
+#include 
+
 #endif
 
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40900
@@ -218,20 +228,6 @@ static inline int xendevicemodel_set_mem_type(
 return xc_hvm_set_mem_type(dmod, domid, mem_type, first_pfn, nr);
 }
 
-static inline int xendevicemodel_restrict(
-xendevicemodel_handle *dmod, domid_t domid)
-{
-errno = ENOTTY;
-return -1;
-}
-
-static inline int xenforeignmemory_restrict(
-xenforeignmemory_handle *fmem, domid_t domid)
-{
-errno = ENOTTY;
-return -1;
-}
-
 #else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 40900 */
 
 #undef XC_WANT_COMPAT_DEVICEMODEL_API
@@ -290,28 +286,8 @@ static inline int xen_modified_memory(domid_t domid, 
uint64_t first_pfn,
 static inline int xen_restrict(domid_t domid)
 {
 int rc;
-
-/* Attempt to restrict devicemodel operations */
-rc = xendevicemodel_restrict(xen_dmod, domid);
+rc = xentoolcore_restrict_all(domid);
 trace_xen_domid_restrict(rc ? errno : 0);
-
-if (rc < 0) {
-/*
- * If errno is ENOTTY then restriction is not implemented so
- * there's no point in trying to restrict other types of
- * operation, but it should not be treated as a failure.
- */
-if (errno == ENOTTY) {
-return 0;
-}
-
-return rc;
-}
-
-/* Restrict foreignmemory operations */
-rc = xenforeignmemory_restrict(xen_fmem, domid);
-trace_xen_domid_restrict(rc ? errno : 0);
-
 return rc;
 }
 
-- 
2.1.4


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

[Xen-devel] [PATCH 7/8] os-posix: Provide new -runas . facility

[Ian Jackson]

This allows the caller to specify a uid and gid to use, even if there
is no corresponding password entry.  This will be useful in certain
Xen configurations.

We don't support just -runas  because: (i) deprivileging without
calling setgroups would be ineffective (ii) given only a uid we don't
know what gid we ought to use (since uids may eppear in multiple
passwd file entries with different gids).

Signed-off-by: Ian Jackson 
---
v4: Changed to reuse option -runas
v3: Error messages fixed.  Thanks to Peter Maydell and Ross Lagerwall.
v2: Coding style fixes.
---
 os-posix.c  | 64 +++--
 qemu-options.hx |  3 ++-
 2 files changed, 55 insertions(+), 12 deletions(-)

diff --git a/os-posix.c b/os-posix.c
index 92e9d85..9418bd4 100644
--- a/os-posix.c
+++ b/os-posix.c
@@ -43,6 +43,8 @@
 #endif
 
 static struct passwd *user_pwd;
+static uid_t user_uid = (uid_t)-1;
+static gid_t user_gid = (gid_t)-1;
 static const char *chroot_dir;
 static int daemonize;
 static int daemon_pipe;
@@ -128,6 +130,34 @@ void os_set_proc_name(const char *s)
 #endif
 }
 
+
+static bool os_parse_runas_uid_gid(const char *optarg)
+{
+unsigned long lv;
+char *ep;
+uid_t got_uid;
+gid_t got_gid;
+int rc;
+
+errno = 0;
+lv = strtoul(optarg, , 0); /* can't qemu_strtoul, want *ep=='.' */
+got_uid = lv; /* overflow here is ID in C99 */
+if (errno || *ep != '.' || got_uid != lv || got_uid == (uid_t)-1) {
+return false;
+}
+
+lv = 0;
+rc = qemu_strtoul(ep + 1, 0, 0, );
+got_gid = lv; /* overflow here is ID in C99 */
+if (rc || got_gid != lv || got_gid == (gid_t)-1) {
+return false;
+}
+
+user_uid = got_uid;
+user_gid = got_gid;
+return true;
+}
+
 /*
  * Parse OS specific command line options.
  * return 0 if option handled, -1 otherwise
@@ -145,8 +175,10 @@ void os_parse_cmd_args(int index, const char *optarg)
 #endif
 case QEMU_OPTION_runas:
 user_pwd = getpwnam(optarg);
-if (!user_pwd) {
-fprintf(stderr, "User \"%s\" doesn't exist\n", optarg);
+if (!user_pwd && !os_parse_runas_uid_gid(optarg)) {
+fprintf(stderr,
+"User \"%s\" doesn't exist (and is not .)\n",
+optarg);
 exit(1);
 }
 break;
@@ -166,18 +198,28 @@ void os_parse_cmd_args(int index, const char *optarg)
 
 static void change_process_uid(void)
 {
-if (user_pwd) {
-if (setgid(user_pwd->pw_gid) < 0) {
-fprintf(stderr, "Failed to setgid(%d)\n", user_pwd->pw_gid);
+if (user_pwd || user_uid != (uid_t)-1) {
+gid_t intended_gid = user_pwd ? user_pwd->pw_gid : user_gid;
+uid_t intended_uid = user_pwd ? user_pwd->pw_uid : user_uid;
+if (setgid(intended_gid) < 0) {
+fprintf(stderr, "Failed to setgid(%d)\n", intended_gid);
 exit(1);
 }
-if (initgroups(user_pwd->pw_name, user_pwd->pw_gid) < 0) {
-fprintf(stderr, "Failed to initgroups(\"%s\", %d)\n",
-user_pwd->pw_name, user_pwd->pw_gid);
-exit(1);
+if (user_pwd) {
+if (initgroups(user_pwd->pw_name, user_pwd->pw_gid) < 0) {
+fprintf(stderr, "Failed to initgroups(\"%s\", %d)\n",
+user_pwd->pw_name, user_pwd->pw_gid);
+exit(1);
+}
+} else {
+if (setgroups(1, _gid) < 0) {
+fprintf(stderr, "Failed to setgroups(1, [%d])",
+user_gid);
+exit(1);
+}
 }
-if (setuid(user_pwd->pw_uid) < 0) {
-fprintf(stderr, "Failed to setuid(%d)\n", user_pwd->pw_uid);
+if (setuid(intended_uid) < 0) {
+fprintf(stderr, "Failed to setuid(%d)\n", intended_uid);
 exit(1);
 }
 if (setuid(0) != -1) {
diff --git a/qemu-options.hx b/qemu-options.hx
index 9f6e2ad..bdff99f 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -3958,7 +3958,8 @@ ETEXI
 
 #ifndef _WIN32
 DEF("runas", HAS_ARG, QEMU_OPTION_runas, \
-"-runas user change to user id user just before starting the VM\n",
+"-runas user change to user id user just before starting the VM\n" \
+"user can be numeric uid.gid instead\n",
 QEMU_ARCH_ALL)
 #endif
 STEXI
-- 
2.1.4


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

[Xen-devel] [PATCH 8/8] configure: do_compiler: Dump some extra info under bash

[Ian Jackson]

This makes it much easier to find a particular thing in config.log.

The information may be lacking in other shells, resulting in harmless
empty output.  (This is why we don't use the proper ${FUNCNAME[*]}
array syntax - other shells will choke on that.)

The extra output is only printed if configure is run with bash.  The
something), it is necessary to say   bash ./configure  to get the extra
debug info in the log.

Signed-off-by: Ian Jackson 
---
v4: No longer tag this patch RFC.
---
 configure | 4 
 1 file changed, 4 insertions(+)

diff --git a/configure b/configure
index 6f691df..21a2b15 100755
--- a/configure
+++ b/configure
@@ -60,6 +60,10 @@ do_compiler() {
 # is compiler binary to execute.
 local compiler="$1"
 shift
+echo >>config.log "
+funcs: ${FUNCNAME}
+lines: ${BASH_LINENO}
+files: ${BASH_SOURCE}"
 echo $compiler "$@" >> config.log
 $compiler "$@" >> config.log 2>&1 || return $?
 # Test passed. If this is an --enable-werror build, rerun
-- 
2.1.4


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

[Xen-devel] [PATCH 4/8] xen: destroy_hvm_domain: Move reason into a variable

[Ian Jackson]

We are going to want to reuse this.

No functional change.

Signed-off-by: Ian Jackson 
Reviewed-by: Anthony PERARD 
---
 hw/i386/xen/xen-hvm.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index 7b60ec6..83420cd 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -1387,12 +1387,13 @@ void destroy_hvm_domain(bool reboot)
 xc_interface *xc_handle;
 int sts;
 
+unsigned int reason = reboot ? SHUTDOWN_reboot : SHUTDOWN_poweroff;
+
 xc_handle = xc_interface_open(0, 0, 0);
 if (xc_handle == NULL) {
 fprintf(stderr, "Cannot acquire xenctrl handle\n");
 } else {
-sts = xc_domain_shutdown(xc_handle, xen_domid,
- reboot ? SHUTDOWN_reboot : SHUTDOWN_poweroff);
+sts = xc_domain_shutdown(xc_handle, xen_domid, reason);
 if (sts != 0) {
 fprintf(stderr, "xc_domain_shutdown failed to issue %s, "
 "sts %d, %s\n", reboot ? "reboot" : "poweroff",
-- 
2.1.4


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

[Xen-devel] [PATCH 6/8] xen: destroy_hvm_domain: Try xendevicemodel_shutdown

[Ian Jackson]

xc_interface_open etc. is not going to work if we have dropped
privilege, but xendevicemodel_shutdown will if everything is new
enough.

xendevicemodel_shutdown is only availabe in Xen 4.10 and later, so
provide a stub for earlier versions.

Signed-off-by: Ian Jackson 
---
v2: Add compatibility stub for Xen < 4.10.
Fix coding style.

Signed-off-by: Ian Jackson 
---
 hw/i386/xen/xen-hvm.c   | 10 ++
 include/hw/xen/xen_common.h |  7 +++
 2 files changed, 17 insertions(+)

diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index 83420cd..25b8b14 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -1386,9 +1386,19 @@ void destroy_hvm_domain(bool reboot)
 {
 xc_interface *xc_handle;
 int sts;
+int rc;
 
 unsigned int reason = reboot ? SHUTDOWN_reboot : SHUTDOWN_poweroff;
 
+if (xen_dmod) {
+rc = xendevicemodel_shutdown(xen_dmod, xen_domid, reason);
+if (!rc) {
+return;
+}
+perror("xendevicemodel_shutdown failed");
+/* well, try the old thing then */
+}
+
 xc_handle = xc_interface_open(0, 0, 0);
 if (xc_handle == NULL) {
 fprintf(stderr, "Cannot acquire xenctrl handle\n");
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 8efdb8a..1d6fb57 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -108,6 +108,13 @@ static inline int xentoolcore_restrict_all(domid_t domid)
 return -1;
 }
 
+static inline int xendevicemodel_shutdown(xendevicemodel_handle *dmod,
+  domid_t domid, unsigned int reason)
+{
+errno = ENOTTY;
+return -1;
+}
+
 #else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 41000 */
 
 #include 
-- 
2.1.4


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

[Xen-devel] [PATCH v5 0/8] xen: xen-domid-restrict improvements

[Ian Jackson]

I have been working on trying to get qemu, when running as a Xen
device model, to _actually_ not have power equivalent to root.

I think I have achieved this, with some limitations (which are
discussed in my series against xen.git.

However, there are changes to qemu needed.  In particular

 * The -xen-domid-restrict option does not work properly right now.
   It only restricts a small subset of the descriptors qemu has open.
   I am introducing a new library call in the Xen libraries for this,
   xentoolcore_restrict_all.

 * We need to call a different function on domain shutdown.

 * The restriction operation needs to be done at a slightly different
   time, necessitating a new hook.

 * Additionally, we want to be able to set aside a uid range for these
   qemus to run in, and that involves being able to tell qemu to drop
   privilege by numeric uid and gid.

Thanks to Anthony Perard, Ross Lagerwall, Peter Maydell, Markus
Armbruster and Daniel P. Berrange for assistance, review and testing.

  m 1/8  xen: link against xentoolcore
 r  2/8  xen: restrict: use xentoolcore_restrict_all
 rm 3/8  xen: defer call to xen_restrict until just before
 r  4/8  xen: destroy_hvm_domain: Move reason into a variable
 a  5/8  xen: move xc_interface compatibility fallback further up
 r  6/8  xen: destroy_hvm_domain: Try xendevicemodel_shutdown
  * 7/8  os-posix: Provide new -runas . facility
8/8  configure: do_compiler: Dump some extra info under bash

 m = commit message (only) changed in v5 of the series
 * = patch changed in v5 of the series
 r = reviewed
 a = acked

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH 1/8] xen: link against xentoolcore

[Anthony PERARD]

On Thu, Oct 19, 2017 at 05:38:10PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("Re: [PATCH 1/8] xen: link against xentoolcore"):
> > I don't think it is necessary to do anything in qemu. The linker should
> > find on its own the new libxentoolcore as long as an option
> > -Wl,-rpath-link= provide the right path to xentoolcore when building
> > qemu from xen.git.  In other cases, the pkg-config files should be
> > enough (configure doesn't need to known about a new xentoolcore.pc
> > file).
> 
> It seems that the build still works, without this patch but without
> the rest of my series too, because we end up passing
>   -L/u/iwj/work/xen.git/tools/../tools/libs/toolcore
>   -Wl,-rpath-link=/u/iwj/work/xen.git/tools/../tools/libs/toolcore
> (or similar) on the qemu link line.  So when ld links against
> libxenstore (say) it finds that xenstore needs toolcore and finds
> toolcore in the relevant paths.
> 
> We still need this patch for the rest of the series, though.

Of course, I was only arguing that this patch on its own is not usefull.

Do you need a signed-off-by or review-by from me? Since it looks like
I'm the author.

-- 
Anthony PERARD

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  5dd3907a2af37060a675dd3bc5a02b7b38dac66c
baseline version:
 xen  8d7b633adab76a778ccf3e3417e903b35333c528

Last test of basis   114696  2017-10-18 13:01:59 Z1 days
Testing same since   114756  2017-10-19 14:27:49 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

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=5dd3907a2af37060a675dd3bc5a02b7b38dac66c
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.
 PERLLIB=.:.
+++ 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 
5dd3907a2af37060a675dd3bc5a02b7b38dac66c
+ branch=xen-unstable-smoke
+ revision=5dd3907a2af37060a675dd3bc5a02b7b38dac66c
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.:.
 PERLLIB=.:.:.
+++ 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
+++ export PERLLIB=.:.:.:.
+++ PERLLIB=.:.:.:.
++ 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.9-testing
+ '[' x5dd3907a2af37060a675dd3bc5a02b7b38dac66c = 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/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : 

Re: [Xen-devel] [RFC 4/4] arm: tee: add basic OP-TEE mediator

[Volodymyr Babchuk]

On Thu, Oct 19, 2017 at 05:12:17PM +0100, Julien Grall wrote:

Hi Julien,

> >>>+if ( rc < 0 )
> >>>+{
> >>>+gprintk(XENLOG_INFO, "OP-TEE: Can't map static shm for Dom0: 
> >>>%d", rc);
> >>
> >>gprintk already dump the domid. So no need to say Dom0.
> >I just wanted to emphasis that we mappaed memory for Dom0. Will remove.
> 
> gprintk will printk d0. So there are no point to say it a second time...
> >
> >>>+set_user_reg(regs, 0, OPTEE_SMC_RETURN_ENOTAVAIL);
> >>>+}
> >>>+
> >>>+return true;
> >>>+}
> >>>+
> >>>+static bool handle_exchange_capabilities(struct cpu_user_regs *regs)
> >>>+{
> >>>+forward_call(regs);
> >>>+
> >>>+printk("handle_exchange_capabilities\n");
> >>
> >>Same here, no plain prink.
> >Sorry, this is another debug print. Missed it when formatted patches.
> >
> >>>+/* Return error back to the guest */
> >>>+if ( get_user_reg(regs, 0) != OPTEE_SMC_RETURN_OK)
> >>>+return true;
> >>>+
> >>>+/* Don't allow guests to work without dynamic SHM */
> >>
> >>Hmmm? But you don't support guests today. So why are you checking that?
> >This is a RFC. Will remove this parts of the code in a proper patch 
> >series.
> >
> >I just wanted to ensure that community is okay with proposed approach and
> >to show how minimalistic mediator can look.
> I don't think this is true. You only show how easy it is to let Dom0
> accessing TEE. And as I said in the cover letter, this is not the
> controversial part.
> >>>Actually I wanted to show approach when mediator resides right in xen.
> >>>I got valuable input from you. Now I see that I must completely rework the
> >>>first patch. And, probably, show more comprehensive support from OP-TEE 
> >>>side.
> >>>
> The more controversial one is the guest support that you completely left
> aside. I believe this part will not be as minimalistic as you think 
> because
> you need to translate buffer address and prevent those buffers to 
> disappear
> under your feet.
> >>>Yes. I plan to copy all buffers where IPAs presented to another place,
> >>>so DomU will not be able to see PAs during translation. And I plan to
> >>>pin all DomU pages with a data. Also I'll read from guest pages only
> >>>once. I think, this will be enough.
> >>>
> There are probably other problem to fix...
> >>>Probably yes...
> >>>
> >>>I think, I'll focus on OP-TEE side right now and come back when there will
> >>>be more more to show.
> >>
> >>To clarify my view. I am not against a temporary support of OP-TEE for the
> >>hardware domain in Xen. But it does not mean I would be ready to see  the a
> >>full OP-TEE support for guests in Xen.
> >Hm. What did you mean in last sentence? Our (here, at EPAM) target is full
> >virtualization support for OP-TEE. If you don't want to see it in Xen,
> >then what another ways we have?
> 
> Sorry it was not clear enough. I meant that whilst I am happy to see OP-TEE
> support for the hardware domain in the hypervisor, we still need to discuss
> on the approach for guests.
Excuse me, I still didn't get it. You imply that we need some
completely different approach for guests? Or I can stick with current
approach, just add more restrictions?

Under "current approach" I mostly mean "handle SMCs to TEE at EL2" as
opposed to "handle them in stubdom". Half patches of this RFC should
be severely reworked anyways.

WBR, Volodymyr

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

Re: [Xen-devel] [PATCH 1/8] xen: link against xentoolcore

[Ian Jackson]

Anthony PERARD writes ("Re: [PATCH 1/8] xen: link against xentoolcore"):
> I don't think it is necessary to do anything in qemu. The linker should
> find on its own the new libxentoolcore as long as an option
> -Wl,-rpath-link= provide the right path to xentoolcore when building
> qemu from xen.git.  In other cases, the pkg-config files should be
> enough (configure doesn't need to known about a new xentoolcore.pc
> file).

It seems that the build still works, without this patch but without
the rest of my series too, because we end up passing
  -L/u/iwj/work/xen.git/tools/../tools/libs/toolcore
  -Wl,-rpath-link=/u/iwj/work/xen.git/tools/../tools/libs/toolcore
(or similar) on the qemu link line.  So when ld links against
libxenstore (say) it finds that xenstore needs toolcore and finds
toolcore in the relevant paths.

We still need this patch for the rest of the series, though.

Ian.

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

Re: [Xen-devel] [PATCH V3 26/29] x86/vvtd: Handle interrupt translation faults

[Roger Pau Monné]

On Thu, Sep 21, 2017 at 11:02:07PM -0400, Lan Tianyu wrote:
> From: Chao Gao 
> 
> Interrupt translation faults are non-recoverable fault. When faults
> are triggered, it needs to populate fault info to Fault Recording
> Registers and inject vIOMMU msi interrupt to notify guest IOMMU driver
> to deal with faults.
> 
> This patch emulates hardware's handling interrupt translation
> faults (more information about the process can be found in VT-d spec,
> chipter "Translation Faults", section "Non-Recoverable Fault
> Reporting" and section "Non-Recoverable Logging").
> Specifically, viommu_record_fault() records the fault information and
> viommu_report_non_recoverable_fault() reports faults to software.
> Currently, only Primary Fault Logging is supported and the Number of
> Fault-recording Registers is 1.
> 
> Signed-off-by: Chao Gao 
> Signed-off-by: Lan Tianyu 
> ---
>  xen/drivers/passthrough/vtd/iommu.h |  60 +++--
>  xen/drivers/passthrough/vtd/vvtd.c  | 252 
> +++-
>  2 files changed, 301 insertions(+), 11 deletions(-)
> 
> diff --git a/xen/drivers/passthrough/vtd/iommu.h 
> b/xen/drivers/passthrough/vtd/iommu.h
> index 790384f..e19b045 100644
> --- a/xen/drivers/passthrough/vtd/iommu.h
> +++ b/xen/drivers/passthrough/vtd/iommu.h
> @@ -198,26 +198,66 @@
>  #define DMA_CCMD_CAIG_MASK(x) (((u64)x) & ((u64) 0x3 << 59))
>  
>  /* FECTL_REG */
> -#define DMA_FECTL_IM (((u64)1) << 31)
> +#define DMA_FECTL_IM_SHIFT 31
> +#define DMA_FECTL_IM (1U << DMA_FECTL_IM_SHIFT)
> +#define DMA_FECTL_IP_SHIFT 30
> +#define DMA_FECTL_IP (1U << DMA_FECTL_IP_SHIFT)

Is it fine to change those from uint64_t to unsigned int?

>  
>  /* FSTS_REG */
> -#define DMA_FSTS_PFO ((u64)1 << 0)
> -#define DMA_FSTS_PPF ((u64)1 << 1)
> -#define DMA_FSTS_AFO ((u64)1 << 2)
> -#define DMA_FSTS_APF ((u64)1 << 3)
> -#define DMA_FSTS_IQE ((u64)1 << 4)
> -#define DMA_FSTS_ICE ((u64)1 << 5)
> -#define DMA_FSTS_ITE ((u64)1 << 6)
> -#define DMA_FSTS_FAULTSDMA_FSTS_PFO | DMA_FSTS_PPF | DMA_FSTS_AFO | 
> DMA_FSTS_APF | DMA_FSTS_IQE | DMA_FSTS_ICE | DMA_FSTS_ITE
> +#define DMA_FSTS_PFO_SHIFT 0
> +#define DMA_FSTS_PFO (1U << DMA_FSTS_PFO_SHIFT)
> +#define DMA_FSTS_PPF_SHIFT 1
> +#define DMA_FSTS_PPF (1U << DMA_FSTS_PPF_SHIFT)
> +#define DMA_FSTS_AFO (1U << 2)
> +#define DMA_FSTS_APF (1U << 3)
> +#define DMA_FSTS_IQE (1U << 4)
> +#define DMA_FSTS_ICE (1U << 5)
> +#define DMA_FSTS_ITE (1U << 6)

This seemingly non-functional changes should be done in a separate
patch.

> +#define DMA_FSTS_PRO_SHIFT 7
> +#define DMA_FSTS_PRO (1U << DMA_FSTS_PRO_SHIFT)
> +#define DMA_FSTS_FAULTS(DMA_FSTS_PFO | DMA_FSTS_PPF | DMA_FSTS_AFO | \
> +DMA_FSTS_APF | DMA_FSTS_IQE | DMA_FSTS_ICE | \
> +DMA_FSTS_ITE | DMA_FSTS_PRO)
> +#define DMA_FSTS_RW1CS (DMA_FSTS_PFO | DMA_FSTS_AFO | DMA_FSTS_APF | \
> +DMA_FSTS_IQE | DMA_FSTS_ICE | DMA_FSTS_ITE | \
> +DMA_FSTS_PRO)
>  #define dma_fsts_fault_record_index(s) (((s) >> 8) & 0xff)
>  
>  /* FRCD_REG, 32 bits access */
> -#define DMA_FRCD_F (((u64)1) << 31)
> +#define DMA_FRCD_LEN0x10
> +#define DMA_FRCD2_OFFSET0x8
> +#define DMA_FRCD3_OFFSET0xc
> +#define DMA_FRCD_F_SHIFT31
> +#define DMA_FRCD_F ((u64)1 << DMA_FRCD_F_SHIFT)
>  #define dma_frcd_type(d) ((d >> 30) & 1)
>  #define dma_frcd_fault_reason(c) (c & 0xff)
>  #define dma_frcd_source_id(c) (c & 0x)
>  #define dma_frcd_page_addr(d) (d & (((u64)-1) << 12)) /* low 64 bit */
>  
> +struct vtd_fault_record_register
> +{
> +union {
> +struct {
> +uint64_t lo;
> +uint64_t hi;
> +} bits;
> +struct {
> +uint64_t rsvd0  :12,
> + fault_info :52;
> +uint64_t source_id  :16,
> + rsvd1  :9,
> + pmr:1,  /* Privilege Mode Requested */
> + exe:1,  /* Execute Permission Requested */
> + pasid_p:1,  /* PASID Present */
> + fault_reason   :8,  /* Fault Reason */
> + pasid_val  :20, /* PASID Value */
> + addr_type  :2,  /* Address Type */
> + type   :1,  /* Type. (0) Write (1) 
> Read/AtomicOp */
> + fault  :1;  /* Fault */
> +} fields;
> +};
> +};
> +
>  enum VTD_FAULT_TYPE
>  {
>  /* Interrupt remapping transition faults */
> diff --git a/xen/drivers/passthrough/vtd/vvtd.c 
> b/xen/drivers/passthrough/vtd/vvtd.c
> index bd1cadd..745941c 100644
> --- a/xen/drivers/passthrough/vtd/vvtd.c
> +++ b/xen/drivers/passthrough/vtd/vvtd.c
> @@ -19,6 +19,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -41,6 +42,7 @@ unsigned int vvtd_caps = 

[Xen-devel] [PATCH for-4.10 v2] passthrough/vtd: Don't DMA to the stack in queue_invalidate_wait()

[Andrew Cooper]

DMA-ing to the stack is generally considered bad practice.  In this case, if a
timeout occurs because of a sluggish device which is processing the request,
the completion notification will corrupt the stack of a subsequent deeper call
tree.

Place the poll_slot in a percpu area and DMA to that instead.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Kevin Tian 
CC: Julien Grall 

Julien: This wants backporting to all releases, and therefore should be
considered for 4.10 at this point.

v2:
 * Retain volatile declaration for poll_slot.
 * Initialise poll_slot to QINVAL_STAT_INIT on each call.
---
 xen/drivers/passthrough/vtd/qinval.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/qinval.c 
b/xen/drivers/passthrough/vtd/qinval.c
index e95dc54..51aef37 100644
--- a/xen/drivers/passthrough/vtd/qinval.c
+++ b/xen/drivers/passthrough/vtd/qinval.c
@@ -147,13 +147,15 @@ static int __must_check queue_invalidate_wait(struct 
iommu *iommu,
   u8 iflag, u8 sw, u8 fn,
   bool_t flush_dev_iotlb)
 {
-volatile u32 poll_slot = QINVAL_STAT_INIT;
+static DEFINE_PER_CPU(volatile u32, poll_slot);
 unsigned int index;
 unsigned long flags;
 u64 entry_base;
 struct qinval_entry *qinval_entry, *qinval_entries;
+volatile u32 *this_poll_slot = _cpu(poll_slot);
 
 spin_lock_irqsave(>register_lock, flags);
+*this_poll_slot = QINVAL_STAT_INIT;
 index = qinval_next_index(iommu);
 entry_base = iommu_qi_ctrl(iommu)->qinval_maddr +
  ((index >> QINVAL_ENTRY_ORDER) << PAGE_SHIFT);
@@ -167,7 +169,7 @@ static int __must_check queue_invalidate_wait(struct iommu 
*iommu,
 qinval_entry->q.inv_wait_dsc.lo.res_1 = 0;
 qinval_entry->q.inv_wait_dsc.lo.sdata = QINVAL_STAT_DONE;
 qinval_entry->q.inv_wait_dsc.hi.res_1 = 0;
-qinval_entry->q.inv_wait_dsc.hi.saddr = virt_to_maddr(_slot) >> 2;
+qinval_entry->q.inv_wait_dsc.hi.saddr = virt_to_maddr(this_poll_slot) >> 2;
 
 unmap_vtd_domain_page(qinval_entries);
 qinval_update_qtail(iommu, index);
@@ -182,7 +184,7 @@ static int __must_check queue_invalidate_wait(struct iommu 
*iommu,
 timeout = NOW() + MILLISECS(flush_dev_iotlb ?
 iommu_dev_iotlb_timeout : VTD_QI_TIMEOUT);
 
-while ( poll_slot != QINVAL_STAT_DONE )
+while ( *this_poll_slot != QINVAL_STAT_DONE )
 {
 if ( NOW() > timeout )
 {
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v12 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

[Julien Grall]

Hi,

On 19/10/17 17:06, Julien Grall wrote:

On 19/10/17 16:47, Jan Beulich wrote:

On 19.10.17 at 17:37,  wrote:

Hi,

On 19/10/17 16:11, Jan Beulich wrote:

On 19.10.17 at 16:49,  wrote:
I'd prefer to make the whole thing x86-only since that's the only 
platform

on which I can test it, and indeed the code used to be x86-only. Jan

objected
to this so all I'm trying to achieve is that it builds for ARM. 
Please can

you and
Jan reach agreement on where the code should live and how, if at 
all, it

should be #ifdef-ed?

I am quite surprised of "it is tools-only" so it is fine to not 
protect
it even if it is x86 only. That's probably going to bite us in the 
future.




So, this appears to have reached an impasse. I don't know how to 
proceed
without having to also fix priv mapping for x86, which is a yak far 
too

large

for me to shave at the moment.


Julien,

why is it that you are making refcounting on p2m insertion / removal
a requirement for this series? We all know it's not there right now
(and similarly also not for the IOMMU, which might affect ARM as well
unless you always use shared page tables), and it's - as Paul validly
says - unrelated to his series.


Well, we do at least have refcounting for foreign mapping on Arm. So if
a foreign domain remove the mapping, the page will stay allocated until
the last mapping is removed. For IOMMU, page tables are for the moment
always shared.

If you don't want to fix x86 now, then it is fine. But I would
appreciate if you don't spread that on Arm.

To give you a bit more context, I was ready to implement the Arm version
of set_foreign_p2m_entry (it is quite trivial) to append at the end of
this series. But given that refcounting is not done, I am more reluctant
to do that.


I don't understand: The refcounting is to be done by ARM-specific
code anyway, i.e. by the implementation of set_foreign_p2m_entry(),
not its caller. At least that's what I would have expected.


I thought I said it before, but it looks like not. Assuming the MFN is 
always baked by a domain, the prototype would likely need to be extended 
and take the foreign domain.


If it is not the case, we would need to find another way to do refcounting.


Looking a bit more at the resource you can acquire from this hypercall. 
Some of them are allocated using alloc_xenheap_page() so not assigned to 
a domain.


So I am not sure how you can expect a function set_foreign_p2m_entry to 
take reference in that case.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC 4/4] arm: tee: add basic OP-TEE mediator

[Julien Grall]

Hi Volodymyr,

On 19/10/17 16:33, Volodymyr Babchuk wrote:

On Thu, Oct 19, 2017 at 03:01:28PM +0100, Julien Grall wrote:

My request is to move the set_user_reg(...) calls outside of call_forward.
So this would make clear the mediator needs to examine the result values.

Ah, I see. You suggest to rename forward_call() to something like execute_call()
and make it return result in some other way.


To give you an example:

call_forward()
/* No need to sanitize value because... */
set_user_reg(...)
set_user_reg(...)

The caller may not need to examine the results. But at least it is clear
compare to an helper hiding that.

Note that the set_user_reg(...) calls could in a another helper.

Yep. So new executute_call() call does actuall SMC and returns result in
some structure. If I need to return result as is back to VM, I call another
helper. Right?


That's right.








+
+return true;
+}
+
+static bool handle_get_shm_config(struct cpu_user_regs *regs)
+{
+paddr_t shm_start;
+size_t shm_size;
+int rc;
+
+printk("handle_get_shm_config\n");


No plain printk in code accessible by the guest. You should use gprintk or
ratelimit it.

Sorry, this is a debug print. I'll remove it at all.


+/* Give all static SHM region to the Dom0 */


s/Dom0/Hardware Domain/

Hm, looks like Dom0 != hardware domain. At least I see code that replaces
contents of hardware_domain variable. If it is possible, then there will
be a problem with static SHM buffer.


On Arm Dom0 == Hardware Domain. If Hardware Domain were introduced, then I
would expect OP-TEE to be handled by the it and not Dom0.

Oh, I see. Thank you for explanation.



Looks like it is better to check for is_domain_direct_mapped(d), as you
mentioned below.


is_domain_direct_mapped(d) != hwdom. Please don't mix the both. The former
is here to proctect you gfn == mfn. The latter is here to make sure no other
domain than the hardware domain is going to use the shared memory.

Yes, I see. As I said earlier, only 1:1 mapped domain can use static SHM
mechanism. So I think I need to use is_domain_direct_mapped(d).


But if you use is_domain_direct_mapped(d) here, what will happen if two
guests asked for shared memory?

Is is possible that there will be two 1:1 mapped domains in XEN? If yes,
then I need to employ both checks: is_domain_direct_mapped(d) &&
is_hardware_domain(d).


At the moment only the hardware domain is mapped 1:1. But I don't want 
to make that assumption in the code. For instance, I know that one of 
your colleagues was looking at guest mapped 1:1.









But I am not sure what's the point of this check given OP-TEE is only
supported for the Hardware Domain and you already have a check for that.

Because I will remove outer check. But this check will remain. In this way
older OP-TEEs (without virtualization support) will still be accessible

>from Dom0/HWDom.



+if ( current->domain->domain_id != 0 )


Please use is_hardware_domain(current->domain) and not open-code the check.


+return false;
+
+forward_call(regs);
+
+/* Return error back to the guest */
+if ( get_user_reg(regs, 0) != OPTEE_SMC_RETURN_OK)
+return true;


This is quite confusing to read, I think it would make sense that
forward_call return the error.

Good idea, thanks.


+
+shm_start = get_user_reg(regs, 1);
+shm_size = get_user_reg(regs, 2);
+
+/* Dom0 is mapped 1:1 */


Please don't make this assumption or at least add
ASSERT(is_domain_direct_mapped(d));

Thanks. I'll check this in runtime, as I mentioned above.


+rc = map_regions_p2mt(current->domain, gaddr_to_gfn(shm_start),


Rather than using current->domain everywhere, I would prefer if you
introduce a temporary variable for the domain.

Okay.


+  shm_size / PAGE_SIZE,


Please PFN_DOWN(...).


+  maddr_to_mfn(shm_start),
+  p2m_ram_rw);


What is this shared memory for? I know this is the hardware domain, so using
p2m_ram_rw would be ok. But I don't think this would be safe unless TEE do
proper safety check.

Linux kernel driver does memremap() in such place. OP-TEE maps it as non-secure
RAM. This shared memory is used to pass information between OP-TEE OS
and OP-TEE client. About which safety check you are talking?


Well, does OP-TEE validate the data read from that shared region? But it
seems that you don't plan to give part of the SHM to a guest, so it might be
ok.

OP-TEE surely validate all data from NW. Also OP-TEE is written in such way,
that it reads from shared memory only once, to ensure that NW will not change
data after validation. Mediator will do the same.


What do you mean by the last bit?

Let me cite TEE Internal Core API Specification (Public Release v1.1.1):

"
The fact that Memory References may use memory directly shared with
the client implies that the Trusted Application needs to be especially
careful when handling such data: Even if the client is not 

Re: [Xen-devel] [PATCH V3 25/29] x86/vmsi: Hook delivering remapping format msi to guest

[Roger Pau Monné]

On Thu, Sep 21, 2017 at 11:02:06PM -0400, Lan Tianyu wrote:
> diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
> index 6196334..349a8cf 100644
> --- a/xen/drivers/passthrough/io.c
> +++ b/xen/drivers/passthrough/io.c
> @@ -942,21 +942,20 @@ static void __msi_pirq_eoi(struct hvm_pirq_dpci 
> *pirq_dpci)
>  static int _hvm_dpci_msi_eoi(struct domain *d,
>   struct hvm_pirq_dpci *pirq_dpci, void *arg)
>  {
> -int vector = (long)arg;
> +uint8_t vector, dlm, vector_target = (long)arg;

Since you are changing this, please cast to (uint8_t) instead.

> +uint32_t dest;
> +bool dm;

Why are you moving dest, dm, dlm and vector here?

>  
> -if ( (pirq_dpci->flags & HVM_IRQ_DPCI_MACH_MSI) &&
> - (pirq_dpci->gmsi.legacy.gvec == vector) )
> +if ( pirq_dpci->flags & HVM_IRQ_DPCI_MACH_MSI )
>  {
> -unsigned int dest = MASK_EXTR(pirq_dpci->gmsi.legacy.gflags,
> -  XEN_DOMCTL_VMSI_X86_DEST_ID_MASK);
> -bool dest_mode = pirq_dpci->gmsi.legacy.gflags &
> - XEN_DOMCTL_VMSI_X86_DM_MASK;

AFAICT their scope is limited to this if.

> +if ( pirq_dpci_2_msi_attr(d, pirq_dpci, , , , ) )
> +return 0;
>  
> -if ( vlapic_match_dest(vcpu_vlapic(current), NULL, 0, dest,
> -   dest_mode) )
> +if ( vector == vector_target &&
> + vlapic_match_dest(vcpu_vlapic(current), NULL, 0, dest, dm) )
>  {
> -__msi_pirq_eoi(pirq_dpci);
> -return 1;
> +__msi_pirq_eoi(pirq_dpci);
> +return 1;
>  }
>  }
>  
> -- 
> 1.8.3.1
> 

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

Re: [Xen-devel] [PATCH v12 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

[Julien Grall]

Hi,

On 19/10/17 16:47, Jan Beulich wrote:

On 19.10.17 at 17:37,  wrote:

Hi,

On 19/10/17 16:11, Jan Beulich wrote:

On 19.10.17 at 16:49,  wrote:
I'd prefer to make the whole thing x86-only since that's the only platform

on which I can test it, and indeed the code used to be x86-only. Jan

objected

to this so all I'm trying to achieve is that it builds for ARM. Please can

you and

Jan reach agreement on where the code should live and how, if at all, it
should be #ifdef-ed?

I am quite surprised of "it is tools-only" so it is fine to not protect
it even if it is x86 only. That's probably going to bite us in the future.



So, this appears to have reached an impasse. I don't know how to proceed
without having to also fix priv mapping for x86, which is a yak far too

large

for me to shave at the moment.


Julien,

why is it that you are making refcounting on p2m insertion / removal
a requirement for this series? We all know it's not there right now
(and similarly also not for the IOMMU, which might affect ARM as well
unless you always use shared page tables), and it's - as Paul validly
says - unrelated to his series.


Well, we do at least have refcounting for foreign mapping on Arm. So if
a foreign domain remove the mapping, the page will stay allocated until
the last mapping is removed. For IOMMU, page tables are for the moment
always shared.

If you don't want to fix x86 now, then it is fine. But I would
appreciate if you don't spread that on Arm.

To give you a bit more context, I was ready to implement the Arm version
of set_foreign_p2m_entry (it is quite trivial) to append at the end of
this series. But given that refcounting is not done, I am more reluctant
to do that.


I don't understand: The refcounting is to be done by ARM-specific
code anyway, i.e. by the implementation of set_foreign_p2m_entry(),
not its caller. At least that's what I would have expected.


I thought I said it before, but it looks like not. Assuming the MFN is 
always baked by a domain, the prototype would likely need to be extended 
and take the foreign domain.


If it is not the case, we would need to find another way to do refcounting.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH V3 24/29] tools/libxc: Add a new interface to bind remapping format msi with pirq

[Roger Pau Monné]

On Thu, Sep 21, 2017 at 11:02:05PM -0400, Lan Tianyu wrote:
> From: Chao Gao 

The title for this patch it's wrong, it modifies both the hypervisor
and libxc. Please fix it.

> When exposing vIOMMU (vvtd) to guest, guest can configure the msi to
> remapping format. For pass-through device, the physical interrupt now
> can be bound with remapping format msi. This patch introduce a flag,
> HVM_IRQ_DPCI_GUEST_REMAPPED, which indicate a physical interrupt is
> bound with remapping format guest interrupt. Thus, we can use
> (HVM_IRQ_DPCI_GUEST_REMAPPED | HVM_IRQ_DPCI_GUEST_MSI) to show the new
> binding type. Also provide an new interface to manage the new binding.
> 
> Signed-off-by: Chao Gao 
> Signed-off-by: Lan Tianyu 
> 
> ---
> diff --git a/xen/include/asm-x86/hvm/irq.h b/xen/include/asm-x86/hvm/irq.h
> index bd8a918..4f5d37b 100644
> --- a/xen/include/asm-x86/hvm/irq.h
> +++ b/xen/include/asm-x86/hvm/irq.h
> @@ -121,6 +121,7 @@ struct dev_intx_gsi_link {
>  #define _HVM_IRQ_DPCI_GUEST_PCI_SHIFT   4
>  #define _HVM_IRQ_DPCI_GUEST_MSI_SHIFT   5
>  #define _HVM_IRQ_DPCI_IDENTITY_GSI_SHIFT6
> +#define _HVM_IRQ_DPCI_GUEST_REMAPPED_SHIFT  7
>  #define _HVM_IRQ_DPCI_TRANSLATE_SHIFT  15
>  #define HVM_IRQ_DPCI_MACH_PCI(1u << _HVM_IRQ_DPCI_MACH_PCI_SHIFT)
>  #define HVM_IRQ_DPCI_MACH_MSI(1u << _HVM_IRQ_DPCI_MACH_MSI_SHIFT)
> @@ -128,6 +129,7 @@ struct dev_intx_gsi_link {
>  #define HVM_IRQ_DPCI_EOI_LATCH   (1u << _HVM_IRQ_DPCI_EOI_LATCH_SHIFT)
>  #define HVM_IRQ_DPCI_GUEST_PCI   (1u << _HVM_IRQ_DPCI_GUEST_PCI_SHIFT)
>  #define HVM_IRQ_DPCI_GUEST_MSI   (1u << _HVM_IRQ_DPCI_GUEST_MSI_SHIFT)
> +#define HVM_IRQ_DPCI_GUEST_REMAPPED  (1u << 
> _HVM_IRQ_DPCI_GUEST_REMAPPED_SHIFT)
>  #define HVM_IRQ_DPCI_IDENTITY_GSI(1u << _HVM_IRQ_DPCI_IDENTITY_GSI_SHIFT)
>  #define HVM_IRQ_DPCI_TRANSLATE   (1u << _HVM_IRQ_DPCI_TRANSLATE_SHIFT)

Please keep this sorted. It should go after the _GSI one.

>  
> @@ -137,6 +139,11 @@ struct hvm_gmsi_info {
>  uint32_t gvec;
>  uint32_t gflags;
>  } legacy;
> +struct {
> +uint32_t source_id;
> +uint32_t data;
> +uint64_t addr;
> +} intremap;
>  };
>  int dest_vcpu_id; /* -1 :multi-dest, non-negative: dest_vcpu_id */
>  bool posted; /* directly deliver to guest via VT-d PI? */
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index 68854b6..8c59cfc 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -559,6 +559,7 @@ typedef enum pt_irq_type_e {
>  PT_IRQ_TYPE_MSI,
>  PT_IRQ_TYPE_MSI_TRANSLATE,
>  PT_IRQ_TYPE_SPI,/* ARM: valid range 32-1019 */
> +PT_IRQ_TYPE_MSI_IR,

Introducing a new irq type seems dubious, at the end this is still a
MSI interrupt.

>  } pt_irq_type_t;
>  struct xen_domctl_bind_pt_irq {
>  uint32_t machine_irq;
> @@ -586,6 +587,12 @@ struct xen_domctl_bind_pt_irq {
>  uint64_aligned_t gtable;
>  } msi;
>  struct {
> +uint32_t source_id;
> +uint32_t data;
> +uint64_t addr;
> +uint64_t gtable;
> +} msi_ir;

Have you tried to expand gflags somehow so that you don't need a new
type together with a new structure?

It seems quite cumbersome and also involves adding more handlers to
libxc.

At the end this is a domctl interface, so you should be able to modify
it at will.

Roger.

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

Re: [Xen-devel] [PATCH V3 22/29] x86/vioapic: extend vioapic_get_vector() to support remapping format RTE

[Jan Beulich]

>>> On 19.10.17 at 17:49,  wrote:
> On Thu, Sep 21, 2017 at 11:02:03PM -0400, Lan Tianyu wrote:
>> --- a/xen/arch/x86/hvm/vioapic.c
>> +++ b/xen/arch/x86/hvm/vioapic.c
>> @@ -561,11 +561,25 @@ int vioapic_get_vector(const struct domain *d, 
>> unsigned int gsi)
>>  {
>>  unsigned int pin;
>>  const struct hvm_vioapic *vioapic = gsi_vioapic(d, gsi, );
>> +struct arch_irq_remapping_request request;
>>  
>>  if ( !vioapic )
>>  return -EINVAL;
>>  
>> -return vioapic->redirtbl[pin].fields.vector;
>> +irq_request_ioapic_fill(, vioapic->id, 
>> vioapic->redirtbl[pin].bits);
>> +if ( viommu_check_irq_remapping(vioapic->domain, ) )
>> +{
>> +int err;
>> +struct arch_irq_remapping_info info;
>> +
>> +err = viommu_get_irq_info(vioapic->domain, , );
>> +return !err ? info.vector : err;
> 
> You can simplify this as return err :? info.vector;

At which point the local variable becomes pretty pointless.

Jan


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

Re: [Xen-devel] [PATCH] watchdog: xen: use time64_t for timeouts

[Guenter Roeck]

On Thu, Oct 19, 2017 at 05:05:48PM +0200, Arnd Bergmann wrote:
> The Xen watchdog driver uses __kernel_time_t and ktime_to_timespec()
> internally for managing its timeouts. Both are deprecated because of
> y2038 problems. The driver itself is fine, since it only uses monotonic
> times, but converting it to use ktime_get_seconds() avoids the deprecated
> interfaces and is slightly simpler.
> 
> Signed-off-by: Arnd Bergmann 

Reviewed-by: Guenter Roeck 

> ---
>  drivers/watchdog/xen_wdt.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/watchdog/xen_wdt.c b/drivers/watchdog/xen_wdt.c
> index cf0e650c2015..5dd5c3494d55 100644
> --- a/drivers/watchdog/xen_wdt.c
> +++ b/drivers/watchdog/xen_wdt.c
> @@ -35,7 +35,7 @@
>  static struct platform_device *platform_device;
>  static DEFINE_SPINLOCK(wdt_lock);
>  static struct sched_watchdog wdt;
> -static __kernel_time_t wdt_expires;
> +static time64_t wdt_expires;
>  static bool is_active, expect_release;
>  
>  #define WATCHDOG_TIMEOUT 60 /* in seconds */
> @@ -49,15 +49,15 @@ module_param(nowayout, bool, S_IRUGO);
>  MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started "
>   "(default=" __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
>  
> -static inline __kernel_time_t set_timeout(void)
> +static inline time64_t set_timeout(void)
>  {
>   wdt.timeout = timeout;
> - return ktime_to_timespec(ktime_get()).tv_sec + timeout;
> + return ktime_get_seconds() + timeout;
>  }
>  
>  static int xen_wdt_start(void)
>  {
> - __kernel_time_t expires;
> + time64_t expires;
>   int err;
>  
>   spin_lock(_lock);
> @@ -98,7 +98,7 @@ static int xen_wdt_stop(void)
>  
>  static int xen_wdt_kick(void)
>  {
> - __kernel_time_t expires;
> + time64_t expires;
>   int err;
>  
>   spin_lock(_lock);
> @@ -222,7 +222,7 @@ static long xen_wdt_ioctl(struct file *file, unsigned int 
> cmd,
>   return put_user(timeout, argp);
>  
>   case WDIOC_GETTIMELEFT:
> - retval = wdt_expires - ktime_to_timespec(ktime_get()).tv_sec;
> + retval = wdt_expires - ktime_get_seconds();
>   return put_user(retval, argp);
>   }
>  
> -- 
> 2.9.0
> 

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

Re: [Xen-devel] [PATCH V3 22/29] x86/vioapic: extend vioapic_get_vector() to support remapping format RTE

[Roger Pau Monné]

On Thu, Sep 21, 2017 at 11:02:03PM -0400, Lan Tianyu wrote:
> From: Chao Gao 
> 
> When IOAPIC RTE is in remapping format, it doesn't contain the vector of
> interrupt. For this case, the RTE contains an index of interrupt remapping
> table where the vector of interrupt is stored. This patchs gets the vector
> through a vIOMMU interface.
> 
> Signed-off-by: Chao Gao 
> Signed-off-by: Lan Tianyu 
> ---
>  xen/arch/x86/hvm/vioapic.c | 16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/x86/hvm/vioapic.c b/xen/arch/x86/hvm/vioapic.c
> index 5d0d1cd..9e47ef4 100644
> --- a/xen/arch/x86/hvm/vioapic.c
> +++ b/xen/arch/x86/hvm/vioapic.c
> @@ -561,11 +561,25 @@ int vioapic_get_vector(const struct domain *d, unsigned 
> int gsi)
>  {
>  unsigned int pin;
>  const struct hvm_vioapic *vioapic = gsi_vioapic(d, gsi, );
> +struct arch_irq_remapping_request request;
>  
>  if ( !vioapic )
>  return -EINVAL;
>  
> -return vioapic->redirtbl[pin].fields.vector;
> +irq_request_ioapic_fill(, vioapic->id, 
> vioapic->redirtbl[pin].bits);
> +if ( viommu_check_irq_remapping(vioapic->domain, ) )
> +{
> +int err;
> +struct arch_irq_remapping_info info;
> +
> +err = viommu_get_irq_info(vioapic->domain, , );
> +return !err ? info.vector : err;

You can simplify this as return err :? info.vector;

Roger.

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

[Xen-devel] [PATCH for-next 2/3] x86/pv: Use DIV_ROUND_UP() when converting between GDT entries and frames

[Andrew Cooper]

Also consistently use use nr_frames, rather than mixing nr_pages with a
frames[] array.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
---
 xen/arch/x86/domain.c   |  8 +---
 xen/arch/x86/pv/descriptor-tables.c | 17 -
 2 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index c28ac38..98bfb35 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1017,12 +1017,14 @@ int arch_set_info_guest(
 else
 {
 unsigned long gdt_frames[ARRAY_SIZE(v->arch.pv_vcpu.gdt_frames)];
-unsigned int n = (c.cmp->gdt_ents + 511) / 512;
+unsigned int nr_frames = DIV_ROUND_UP(c.cmp->gdt_ents, 512);
 
-if ( n > ARRAY_SIZE(v->arch.pv_vcpu.gdt_frames) )
+if ( nr_frames > ARRAY_SIZE(v->arch.pv_vcpu.gdt_frames) )
 return -EINVAL;
-for ( i = 0; i < n; ++i )
+
+for ( i = 0; i < nr_frames; ++i )
 gdt_frames[i] = c.cmp->gdt_frames[i];
+
 rc = (int)pv_set_gdt(v, gdt_frames, c.cmp->gdt_ents);
 }
 if ( rc != 0 )
diff --git a/xen/arch/x86/pv/descriptor-tables.c 
b/xen/arch/x86/pv/descriptor-tables.c
index 9c8de1d..e31c97e 100644
--- a/xen/arch/x86/pv/descriptor-tables.c
+++ b/xen/arch/x86/pv/descriptor-tables.c
@@ -57,14 +57,13 @@ long pv_set_gdt(struct vcpu *v, unsigned long *frames, 
unsigned int entries)
 {
 struct domain *d = v->domain;
 l1_pgentry_t *pl1e;
-/* NB. There are 512 8-byte entries per GDT page. */
-unsigned int i, nr_pages = (entries + 511) / 512;
+unsigned int i, nr_frames = DIV_ROUND_UP(entries, 512);
 
 if ( entries > FIRST_RESERVED_GDT_ENTRY )
 return -EINVAL;
 
 /* Check the pages in the new GDT. */
-for ( i = 0; i < nr_pages; i++ )
+for ( i = 0; i < nr_frames; i++ )
 {
 struct page_info *page;
 
@@ -85,7 +84,7 @@ long pv_set_gdt(struct vcpu *v, unsigned long *frames, 
unsigned int entries)
 /* Install the new GDT. */
 v->arch.pv_vcpu.gdt_ents = entries;
 pl1e = pv_gdt_ptes(v);
-for ( i = 0; i < nr_pages; i++ )
+for ( i = 0; i < nr_frames; i++ )
 {
 v->arch.pv_vcpu.gdt_frames[i] = frames[i];
 l1e_write([i], l1e_from_pfn(frames[i], __PAGE_HYPERVISOR_RW));
@@ -104,7 +103,7 @@ long pv_set_gdt(struct vcpu *v, unsigned long *frames, 
unsigned int entries)
 long do_set_gdt(XEN_GUEST_HANDLE_PARAM(xen_ulong_t) frame_list,
 unsigned int entries)
 {
-int nr_pages = (entries + 511) / 512;
+unsigned int nr_frames = DIV_ROUND_UP(entries, 512);
 unsigned long frames[16];
 struct vcpu *curr = current;
 long ret;
@@ -113,7 +112,7 @@ long do_set_gdt(XEN_GUEST_HANDLE_PARAM(xen_ulong_t) 
frame_list,
 if ( entries > FIRST_RESERVED_GDT_ENTRY )
 return -EINVAL;
 
-if ( copy_from_guest(frames, frame_list, nr_pages) )
+if ( copy_from_guest(frames, frame_list, nr_frames) )
 return -EFAULT;
 
 domain_lock(curr->domain);
@@ -130,7 +129,7 @@ int compat_set_gdt(XEN_GUEST_HANDLE_PARAM(uint) frame_list,
unsigned int entries)
 {
 struct vcpu *curr = current;
-unsigned int i, nr_pages = (entries + 511) / 512;
+unsigned int i, nr_frames = DIV_ROUND_UP(entries, 512);
 unsigned long frames[16];
 int ret;
 
@@ -138,10 +137,10 @@ int compat_set_gdt(XEN_GUEST_HANDLE_PARAM(uint) 
frame_list,
 if ( entries > FIRST_RESERVED_GDT_ENTRY )
 return -EINVAL;
 
-if ( !guest_handle_okay(frame_list, nr_pages) )
+if ( !guest_handle_okay(frame_list, nr_frames) )
 return -EFAULT;
 
-for ( i = 0; i < nr_pages; ++i )
+for ( i = 0; i < nr_frames; ++i )
 {
 unsigned int frame;
 
-- 
2.1.4


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

[Xen-devel] [PATCH for-next 1/3] x86/pv: Move compat_set_gdt() to be beside do_set_gdt()

[Andrew Cooper]

This also makes the do_update_descriptor() pair of functions adjacent.

Purely code motion; no functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
---
 xen/arch/x86/pv/descriptor-tables.c | 69 +++--
 1 file changed, 36 insertions(+), 33 deletions(-)

diff --git a/xen/arch/x86/pv/descriptor-tables.c 
b/xen/arch/x86/pv/descriptor-tables.c
index 81973af..9c8de1d 100644
--- a/xen/arch/x86/pv/descriptor-tables.c
+++ b/xen/arch/x86/pv/descriptor-tables.c
@@ -126,6 +126,42 @@ long do_set_gdt(XEN_GUEST_HANDLE_PARAM(xen_ulong_t) 
frame_list,
 return ret;
 }
 
+int compat_set_gdt(XEN_GUEST_HANDLE_PARAM(uint) frame_list,
+   unsigned int entries)
+{
+struct vcpu *curr = current;
+unsigned int i, nr_pages = (entries + 511) / 512;
+unsigned long frames[16];
+int ret;
+
+/* Rechecked in set_gdt, but ensures a sane limit for copy_from_user(). */
+if ( entries > FIRST_RESERVED_GDT_ENTRY )
+return -EINVAL;
+
+if ( !guest_handle_okay(frame_list, nr_pages) )
+return -EFAULT;
+
+for ( i = 0; i < nr_pages; ++i )
+{
+unsigned int frame;
+
+if ( __copy_from_guest(, frame_list, 1) )
+return -EFAULT;
+
+frames[i] = frame;
+guest_handle_add_offset(frame_list, 1);
+}
+
+domain_lock(curr->domain);
+
+if ( (ret = pv_set_gdt(curr, frames, entries)) == 0 )
+flush_tlb_local();
+
+domain_unlock(curr->domain);
+
+return ret;
+}
+
 long do_update_descriptor(uint64_t pa, uint64_t desc)
 {
 struct domain *currd = current->domain;
@@ -181,39 +217,6 @@ long do_update_descriptor(uint64_t pa, uint64_t desc)
 return ret;
 }
 
-int compat_set_gdt(XEN_GUEST_HANDLE_PARAM(uint) frame_list, unsigned int 
entries)
-{
-unsigned int i, nr_pages = (entries + 511) / 512;
-unsigned long frames[16];
-int ret;
-
-/* Rechecked in set_gdt, but ensures a sane limit for copy_from_user(). */
-if ( entries > FIRST_RESERVED_GDT_ENTRY )
-return -EINVAL;
-
-if ( !guest_handle_okay(frame_list, nr_pages) )
-return -EFAULT;
-
-for ( i = 0; i < nr_pages; ++i )
-{
-unsigned int frame;
-
-if ( __copy_from_guest(, frame_list, 1) )
-return -EFAULT;
-frames[i] = frame;
-guest_handle_add_offset(frame_list, 1);
-}
-
-domain_lock(current->domain);
-
-if ( (ret = pv_set_gdt(current, frames, entries)) == 0 )
-flush_tlb_local();
-
-domain_unlock(current->domain);
-
-return ret;
-}
-
 int compat_update_descriptor(uint32_t pa_lo, uint32_t pa_hi,
  uint32_t desc_lo, uint32_t desc_hi)
 {
-- 
2.1.4


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

[Xen-devel] [PATCH for-next 3/3] x86/pv: Misc improvements to pv_destroy_gdt()

[Andrew Cooper]

Hoist the l1e_from_pfn(zero_pfn, __PAGE_HYPERVISOR_RO) calculation out of the
loop, and switch the code over to using mfn_t.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
---
 xen/arch/x86/pv/descriptor-tables.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/pv/descriptor-tables.c 
b/xen/arch/x86/pv/descriptor-tables.c
index e31c97e..d1c4296 100644
--- a/xen/arch/x86/pv/descriptor-tables.c
+++ b/xen/arch/x86/pv/descriptor-tables.c
@@ -37,18 +37,21 @@
 
 void pv_destroy_gdt(struct vcpu *v)
 {
-l1_pgentry_t *pl1e;
+l1_pgentry_t *pl1e = pv_gdt_ptes(v);
+mfn_t zero_mfn = _mfn(virt_to_mfn(zero_page));
+l1_pgentry_t zero_l1e = l1e_from_mfn(zero_mfn, __PAGE_HYPERVISOR_RO);
 unsigned int i;
-unsigned long pfn, zero_pfn = PFN_DOWN(__pa(zero_page));
 
 v->arch.pv_vcpu.gdt_ents = 0;
-pl1e = pv_gdt_ptes(v);
 for ( i = 0; i < FIRST_RESERVED_GDT_PAGE; i++ )
 {
-pfn = l1e_get_pfn(pl1e[i]);
-if ( (l1e_get_flags(pl1e[i]) & _PAGE_PRESENT) && pfn != zero_pfn )
-put_page_and_type(mfn_to_page(_mfn(pfn)));
-l1e_write([i], l1e_from_pfn(zero_pfn, __PAGE_HYPERVISOR_RO));
+mfn_t mfn = l1e_get_mfn(pl1e[i]);
+
+if ( (l1e_get_flags(pl1e[i]) & _PAGE_PRESENT) &&
+ !mfn_eq(mfn, zero_mfn) )
+put_page_and_type(mfn_to_page(mfn));
+
+l1e_write([i], zero_l1e);
 v->arch.pv_vcpu.gdt_frames[i] = 0;
 }
 }
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v12 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

[Jan Beulich]

>>> On 19.10.17 at 17:37,  wrote:
> Hi,
> 
> On 19/10/17 16:11, Jan Beulich wrote:
> On 19.10.17 at 16:49,  wrote:
> I'd prefer to make the whole thing x86-only since that's the only platform
 on which I can test it, and indeed the code used to be x86-only. Jan 
> objected
 to this so all I'm trying to achieve is that it builds for ARM. Please can 
> you and
 Jan reach agreement on where the code should live and how, if at all, it
 should be #ifdef-ed?

 I am quite surprised of "it is tools-only" so it is fine to not protect
 it even if it is x86 only. That's probably going to bite us in the future.

>>>
>>> So, this appears to have reached an impasse. I don't know how to proceed
>>> without having to also fix priv mapping for x86, which is a yak far too 
> large
>>> for me to shave at the moment.
>> 
>> Julien,
>> 
>> why is it that you are making refcounting on p2m insertion / removal
>> a requirement for this series? We all know it's not there right now
>> (and similarly also not for the IOMMU, which might affect ARM as well
>> unless you always use shared page tables), and it's - as Paul validly
>> says - unrelated to his series.
> 
> Well, we do at least have refcounting for foreign mapping on Arm. So if 
> a foreign domain remove the mapping, the page will stay allocated until 
> the last mapping is removed. For IOMMU, page tables are for the moment 
> always shared.
> 
> If you don't want to fix x86 now, then it is fine. But I would 
> appreciate if you don't spread that on Arm.
> 
> To give you a bit more context, I was ready to implement the Arm version 
> of set_foreign_p2m_entry (it is quite trivial) to append at the end of 
> this series. But given that refcounting is not done, I am more reluctant 
> to do that.

I don't understand: The refcounting is to be done by ARM-specific
code anyway, i.e. by the implementation of set_foreign_p2m_entry(),
not its caller. At least that's what I would have expected.

Jan


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

Re: [Xen-devel] [PATCH V3 21/29] VIOMMU: Introduce callback of checking irq remapping mode

[Roger Pau Monné]

On Thu, Sep 21, 2017 at 11:02:02PM -0400, Lan Tianyu wrote:
> This patch is to add callback for vIOAPIC and vMSI to check whether interrupt
> remapping is enabled.
> 
> Signed-off-by: Lan Tianyu 
> ---
>  xen/common/viommu.c  | 15 +++
>  xen/include/xen/viommu.h | 10 ++
>  2 files changed, 25 insertions(+)
> 
> diff --git a/xen/common/viommu.c b/xen/common/viommu.c
> index 0708e43..ff95465 100644
> --- a/xen/common/viommu.c
> +++ b/xen/common/viommu.c
> @@ -194,6 +194,21 @@ int viommu_get_irq_info(struct domain *d,
>  return viommu->ops->get_irq_info(d, request, irq_info);
>  }
>  
> +bool viommu_check_irq_remapping(struct domain *d,
> +struct arch_irq_remapping_request *request)

Both should be constified.

> +{
> +struct viommu *viommu = d->viommu;
> +
> +if ( !viommu )
> +return false;
> +
> +ASSERT(viommu->ops);
> +if ( !viommu->ops->check_irq_remapping )
> +return false;
> +
> +return viommu->ops->check_irq_remapping(d, request);

IMHO this helper should be introduced together with the vvtd
implementation of check_irq_remapping.

Roger.

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

Re: [Xen-devel] [PATCH V3 20/29] VIOMMU: Add get irq info callback to convert irq remapping request

[Roger Pau Monné]

On Thu, Sep 21, 2017 at 11:02:01PM -0400, Lan Tianyu wrote:
> This patch is to add get_irq_info callback for platform implementation
> to convert irq remapping request to irq info (E,G vector, dest, dest_mode
> and so on).
> 
> Signed-off-by: Lan Tianyu 
> ---
>  xen/common/viommu.c  | 16 
>  xen/include/asm-x86/viommu.h |  8 
>  xen/include/xen/viommu.h | 14 ++
>  3 files changed, 38 insertions(+)
> 
> diff --git a/xen/common/viommu.c b/xen/common/viommu.c
> index b517158..0708e43 100644
> --- a/xen/common/viommu.c
> +++ b/xen/common/viommu.c
> @@ -178,6 +178,22 @@ int viommu_handle_irq_request(struct domain *d,
>  return viommu->ops->handle_irq_request(d, request);
>  }
>  
> +int viommu_get_irq_info(struct domain *d,
> +struct arch_irq_remapping_request *request,
> +struct arch_irq_remapping_info *irq_info)
> +{
> +struct viommu *viommu = d->viommu;
> +
> +if ( !viommu )
> +return -EINVAL;

OK, here there's a check for !viommu. Can we please have this written
down in the header? (ie: which functions are safe/expected to be
called without a viommu)

> +
> +ASSERT(viommu->ops);
> +if ( !viommu->ops->get_irq_info )
> +return -EINVAL;
> +
> +return viommu->ops->get_irq_info(d, request, irq_info);
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/include/asm-x86/viommu.h b/xen/include/asm-x86/viommu.h
> index 366fbb6..586b6bd 100644
> --- a/xen/include/asm-x86/viommu.h
> +++ b/xen/include/asm-x86/viommu.h
> @@ -24,6 +24,14 @@
>  #define VIOMMU_REQUEST_IRQ_MSI  0
>  #define VIOMMU_REQUEST_IRQ_APIC 1
>  
> +struct arch_irq_remapping_info
> +{
> +uint8_t  vector;
> +uint32_t dest;
> +uint32_t dest_mode:1;
> +uint32_t delivery_mode:3;

Why uint32_t for this two last fields? Also please sort them so that
the padding is limited at the end of the structure.

> +};
> +
>  struct arch_irq_remapping_request
>  {
>  union {
> diff --git a/xen/include/xen/viommu.h b/xen/include/xen/viommu.h
> index 230f6b1..beb40cd 100644
> --- a/xen/include/xen/viommu.h
> +++ b/xen/include/xen/viommu.h
> @@ -21,6 +21,7 @@
>  #define __XEN_VIOMMU_H__
>  
>  struct viommu;
> +struct arch_irq_remapping_info;
>  struct arch_irq_remapping_request;

If you include asm/viommu.h in viommu.h you don't need to forward
declarations.

>  
>  struct viommu_ops {
> @@ -28,6 +29,9 @@ struct viommu_ops {
>  int (*destroy)(struct viommu *viommu);
>  int (*handle_irq_request)(struct domain *d,
>struct arch_irq_remapping_request *request);
> +int (*get_irq_info)(struct domain *d,
> +struct arch_irq_remapping_request *request,

AFAICT d and request should be constified.

Roger.

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

Re: [Xen-devel] VPMU interrupt unreliability

[Andrew Cooper]

On 19/10/17 16:09, Kyle Huey wrote:
> On Wed, Oct 11, 2017 at 7:09 AM, Boris Ostrovsky
>  wrote:
>> On 10/10/2017 12:54 PM, Kyle Huey wrote:
>>> On Mon, Jul 24, 2017 at 9:54 AM, Kyle Huey  wrote:
 On Mon, Jul 24, 2017 at 8:07 AM, Boris Ostrovsky
  wrote:
>>> One thing I noticed is that the workaround doesn't appear to be
>>> complete: it is only checking PMC0 status and not other counters (fixed
>>> or architectural). Of course, without knowing what the actual problem
>>> was it's hard to say whether this was intentional.
>> handle_pmc_quirk appears to loop through all the counters ...
> Right, I didn't notice that it is shifting MSR_CORE_PERF_GLOBAL_STATUS
> value one by one and so it is looking at all bits.
>
 2. Intercepting MSR loads for counters that have the workaround
 applied and giving the guest the correct counter value.
>>> We'd have to keep track of whether the counter has been reset (by the
>>> quirk) since the last MSR write.
>> Yes.
>>
 3. Or perhaps even changing the workaround to disable the PMI on that
 counter until the guest acks via GLOBAL_OVF_CTRL, assuming that works
 on the relevant hardware.
>>> MSR_CORE_PERF_GLOBAL_OVF_CTRL is written immediately after the quirk
>>> runs (in core2_vpmu_do_interrupt()) so we already do this, don't we?
>> I'm suggesting waiting until the *guest* writes to the (virtualized)
>> GLOBAL_OVF_CTRL.
> Wouldn't it be better to wait until the counter is reloaded?
 Maybe!  I haven't thought through it a lot.  It's still not clear to
 me whether MSR_CORE_PERF_GLOBAL_OVF_CTRL actually controls the
 interrupt in any way or whether it just resets the bits in
 MSR_CORE_PERF_GLOBAL_STATUS and acking the interrupt on the APIC is
 all that's required to reenable it.

 - Kyle
>>> I wonder if it would be reasonable to just remove the workaround
>>> entirely at some point.  The set of people using 1) several year old
>>> hardware, 2) an up to date Xen, and 3) the off-by-default performance
>>> counters is probably rather small.
>> We'd probably want to only enable this for affected processors, not
>> remove it outright. But the problem is that we still don't know for sure
>> whether this issue affects NHM only, do we?
>>
>> (https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg02242.html
>> is the original message)
> Yes, the basic problem is that we don't know where to draw the line.

vPMU is disabled by default for security reasons, and also broken, in a
way which demonstrates that vPMU isn't getting much real-world use.

As far as I'm concerned, all options (including rm -rf and start from
scratch) are acceptable, especially if this ends up giving us a better
overall subsystem.

Do we know how other hypervisors work around this issue?

I'm tempted to suggest just ripping it straight out.  NHM is ancient
these days, and if someone does manage to get a repro, we stand a better
chance of being able to debug it properly.

~Andrew

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

Re: [Xen-devel] [PATCH 00/12] ARM: VGIC/GIC separation cleanups

[Andre Przywara]

Hi,

On 19/10/17 13:48, Andre Przywara wrote:
> By the original VGIC design, Xen differentiates between the actual VGIC
> emulation on one hand and the GIC hardware accesses on the other.
> It seems there were some deviations from that scheme (over time?), so at
> the moment we end up happily accessing VGIC specific data structures
> like struct pending_irq and struct vgic_irq_rank from pure GIC files
> like gic.c or even irq.c (try: git grep -l struct\ pending_irq xen/arch/arm).
> But any future VGIC rework will depend on a clean separation, so this
> series tries to clean this up.
> It starts with some rather innocent patches, reaches its peak with the
> ugly patch 5/12 and the heavy 6/12, and calms down in the rest of the
> series again.
> After this series there are no more references to VGIC structures from
> GIC files, at least for non-ITS code. The ITS is a beast own its own
> (blame the author) and will be addressed later.
> 
> This is a first shot, any ideas on improvements are welcome.

Forgot to mention: This is of course not 4.10 material.

And I tested this is on Midway and Juno, with two guests migrating
interrupts like crazy over night:
   CPU0   CPU1
 18:88925198892530 GIC-0  27 Level arch_timer
 19:  193048966  192887534 GIC-0  31 Level events
 20:366  0   xen-dyn Edge-event xenbus
 21: 180335 183325   xen-dyn Edge-event hvc_console
 22:  112174867   81289537   xen-dyn Edge-event blkif
 23:   80768079  111489990   xen-dyn Edge-event blkif

But please give it a good shake on your setup to spot any regressions.

Cheers,
Andre.

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

Re: [Xen-devel] [PATCH v12 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

[Julien Grall]

Hi,

On 19/10/17 16:11, Jan Beulich wrote:

On 19.10.17 at 16:49,  wrote:
I'd prefer to make the whole thing x86-only since that's the only platform

on which I can test it, and indeed the code used to be x86-only. Jan objected
to this so all I'm trying to achieve is that it builds for ARM. Please can you 
and
Jan reach agreement on where the code should live and how, if at all, it
should be #ifdef-ed?

I am quite surprised of "it is tools-only" so it is fine to not protect
it even if it is x86 only. That's probably going to bite us in the future.



So, this appears to have reached an impasse. I don't know how to proceed
without having to also fix priv mapping for x86, which is a yak far too large
for me to shave at the moment.


Julien,

why is it that you are making refcounting on p2m insertion / removal
a requirement for this series? We all know it's not there right now
(and similarly also not for the IOMMU, which might affect ARM as well
unless you always use shared page tables), and it's - as Paul validly
says - unrelated to his series.


Well, we do at least have refcounting for foreign mapping on Arm. So if 
a foreign domain remove the mapping, the page will stay allocated until 
the last mapping is removed. For IOMMU, page tables are for the moment 
always shared.


If you don't want to fix x86 now, then it is fine. But I would 
appreciate if you don't spread that on Arm.


To give you a bit more context, I was ready to implement the Arm version 
of set_foreign_p2m_entry (it is quite trivial) to append at the end of 
this series. But given that refcounting is not done, I am more reluctant 
to do that.


Anyway, I don't plan to block common code. But I will block any 
implementation of set_foreign_p2m_entry (other than returning not 
implemented) on Arm until someone step up and fix the refcounting.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH V3 19/29] x86/vioapic: Hook interrupt delivery of vIOAPIC

[Roger Pau Monné]

On Thu, Sep 21, 2017 at 11:02:00PM -0400, Lan Tianyu wrote:
> From: Chao Gao 
> 
> When irq remapping is enabled, IOAPIC Redirection Entry may be in remapping
> format. If that, generate an irq_remapping_request and call the common
> VIOMMU abstraction's callback to handle this interrupt request. Device
> model is responsible for checking the request's validity.
> 
> Signed-off-by: Chao Gao 
> Signed-off-by: Lan Tianyu 
> 
> ---
> v3:
>  - use the new interface to check remapping format.
> ---
>  xen/arch/x86/hvm/vioapic.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/xen/arch/x86/hvm/vioapic.c b/xen/arch/x86/hvm/vioapic.c
> index 72cae93..5d0d1cd 100644
> --- a/xen/arch/x86/hvm/vioapic.c
> +++ b/xen/arch/x86/hvm/vioapic.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -38,6 +39,7 @@
>  #include 
>  #include 
>  #include 
> +#include 

I think asm/viommu should be included by viommu.h.

>  
>  /* HACK: Route IRQ0 only to VCPU0 to prevent time jumps. */
>  #define IRQ0_SPECIAL_ROUTING 1
> @@ -387,9 +389,17 @@ static void vioapic_deliver(struct hvm_vioapic *vioapic, 
> unsigned int pin)
>  struct vlapic *target;
>  struct vcpu *v;
>  unsigned int irq = vioapic->base_gsi + pin;
> +struct arch_irq_remapping_request request;
>  
>  ASSERT(spin_is_locked(>arch.hvm_domain.irq_lock));
>  
> +irq_request_ioapic_fill(, vioapic->id, 
> vioapic->redirtbl[pin].bits);

So the macro introduced in the previous patch should instead be
introduced here.

Roger.

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

Re: [Xen-devel] [RFC 4/4] arm: tee: add basic OP-TEE mediator

[Volodymyr Babchuk]

On Thu, Oct 19, 2017 at 03:01:28PM +0100, Julien Grall wrote:

> Hi Volodymyr,
Hi Julien,

[...]
>>+}
>>+
>>+static bool forward_call(struct cpu_user_regs *regs)
>>+{
>>+register_t resp[4];
>>+
>>+call_smccc_smc(get_user_reg(regs, 0),
>>+   get_user_reg(regs, 1),
>>+   get_user_reg(regs, 2),
>>+   get_user_reg(regs, 3),
>>+   get_user_reg(regs, 4),
>>+   get_user_reg(regs, 5),
>>+   get_user_reg(regs, 6),
>>+   /* VM id 0 is reserved for hypervisor itself */
>
>s/VM/client/. Also, on your design document you mentioned that you did
>modify OP-TEE to support multiple client ID. So how do you know whether the
>TEE supports client ID?
Hm, as I remember, I never mentioned that I modified OP-TEE to support
multiple client IDs. This is my current task.
>>>
>>>"On OP-TEE side:
>>>1. Shared memory redesign which is almost complete.
>>>2. Implement new SMCs  from hypervsiror to TEE to track VM lifecycle.
>>>3. Track VM IDs to isolated VM data.
>>>4. RPCs to sleeping guests."
>>Yes, this are my plans. First item is done. I'm currently working on
>>others. Sorry, looks like I didn't clearly showed, that this is what should
>>be done. It is not done yet.
>>
>>>I was kind of expecting that was done given you put a client ID here. If it
>>>is not done, then why are you passing a ID that we are not even sure OP-TEE
>>>will be able to understand?
>>OP-TEE has very rudimentary support of client ID [2]. So it will understand 
>>it.
>>It uses client ID to ensure, that right VM does return from a RPC. There are
>>no other uses for it right now.
> 
> I am not sure to understand what you mean here. Do you expect OP-TEE to
> block? Or send an interrupt later on to say the work is finish?
No, OP-TEE will never block in Secure World. Roughty mechanism of RPCs is
described on page 19 of SMCCC. It is called "yielding service call" in SMCCC.
OP-TEE uses client id ensure that resume_call() from one VM does not mimick
resume_call() from other VM. There are more checks, obvioulsy. This is one
of them.

> [...]
> 

>>+   current->domain->domain_id +1,
>>+   resp);
>>+
>>+set_user_reg(regs, 0, resp[0]);
>>+set_user_reg(regs, 1, resp[1]);
>>+set_user_reg(regs, 2, resp[2]);
>>+set_user_reg(regs, 3, resp[3]);
>
>Who will do the sanity check of the return values? Each callers? If so, I
>would prefer that the results are stored in a temporary array and a 
>separate
>helpers will write them into the domain once the sanity is done.
Maybe there will be cases when call will be forwarded straight to OP-TEE and
nobody in hypervisor will examine returned result. At least, at this moment
there are such cases. Probably, in full-scalle mediator this will no longer
be true.

>This would avoid to mistakenly expose unwanted data to a domain.
Correct me, but set_user_reg() modifies data that will be stored in general
purpose registers during return from trap handler. This can't expose any
additional data to a domain.
>>>
>>>Which set_user_reg()? The helper does not do any modification... If you
>>>speak about the code below, then it is very confusing and error-prone.
>>No, I was speaking about code above. The one that calls set_user_reg().
>>You leave your comment there, so I assumed you are talking about that part.
>>
>>>If you separate the call from setting the guest registers then the you give
>>>a hint to the caller that maybe something has to be down and he can't
>>>blindly trust the result...
>>Let me describe how this works right now. XEN traps SMC to OP-TEE and forwards
>>it to the mediator. Mediator examines registers to determine type of the call.
>>Then it either:
>>
>>  * Forwards it to OP-TEE as is. This does forward_call(). forward_call()
>>executes real SMC and then writes return data to guest registers
>>
>>  * Forwards it to OP-TEE and then examines result. Again, it uses
>>forward_call() to execute SMC and then it checks returned values.
>>
>>For example, if guest wanted to exchange capabilities with OP-TEE,
>>mediator checks if OP-TEE support dynamic SHM. If it is not supported
>>and guest is not hwdom, then mediator injects an error to guest.
>>This prevents further initialization of OP-TEE driver in client.
>>
>>Another example is static SHM configuration. If this request was sent
>>from hwdom, then upon return from OP-TEE, mediator maps static
>>shm into hwdom address space. Else it returns an error. DomU sees
>>that static SHM is not available and relies only on dynamic SHM.
>>
>>Idea is to make this transparent for OP-TEE client driver. It does not
>>need to know that it is running in virtualized environment (one
>>backward-compatible change will be needed anyways, 

[Xen-devel] [PATCH] x86/xen: support priv-mapping in an HVM tools domain

[Paul Durrant]

If the domain has XENFEAT_auto_translated_physmap then use of the PV-
specific HYPERVISOR_mmu_update hypercall is clearly incorrect.

This patch adds checks in xen_remap_domain_gfn_array() and
xen_unmap_domain_gfn_array() which call through to the approprate
xlate_mmu function if the feature is present. A check is also added
to xen_remap_domain_gfn_range() to fail with -EOPNOTSUPP since this
should not be used in an HVM tools domain.

Signed-off-by: Paul Durrant 
---
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
---
 arch/x86/xen/mmu.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 3e15345abfe7..d33e7dbe3129 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -172,6 +172,9 @@ int xen_remap_domain_gfn_range(struct vm_area_struct *vma,
   pgprot_t prot, unsigned domid,
   struct page **pages)
 {
+   if (xen_feature(XENFEAT_auto_translated_physmap))
+   return -EOPNOTSUPP;
+
return do_remap_gfn(vma, addr, , nr, NULL, prot, domid, pages);
 }
 EXPORT_SYMBOL_GPL(xen_remap_domain_gfn_range);
@@ -182,6 +185,10 @@ int xen_remap_domain_gfn_array(struct vm_area_struct *vma,
   int *err_ptr, pgprot_t prot,
   unsigned domid, struct page **pages)
 {
+   if (xen_feature(XENFEAT_auto_translated_physmap))
+   return xen_xlate_remap_gfn_array(vma, addr, gfn, nr, err_ptr,
+prot, domid, pages);
+
/* We BUG_ON because it's a programmer error to pass a NULL err_ptr,
 * and the consequences later is quite hard to detect what the actual
 * cause of "wrong memory was mapped in".
@@ -193,9 +200,12 @@ EXPORT_SYMBOL_GPL(xen_remap_domain_gfn_array);
 
 /* Returns: 0 success */
 int xen_unmap_domain_gfn_range(struct vm_area_struct *vma,
-  int numpgs, struct page **pages)
+  int nr, struct page **pages)
 {
-   if (!pages || !xen_feature(XENFEAT_auto_translated_physmap))
+   if (xen_feature(XENFEAT_auto_translated_physmap))
+   return xen_xlate_unmap_gfn_range(vma, nr, pages);
+
+   if (!pages)
return 0;
 
return -EINVAL;
-- 
2.11.0


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

[Xen-devel] [PATCH] x86/xen: support priv-mapping in an HVM tools domain

[Paul Durrant]

If the domain has XENFEAT_auto_translated_physmap then use of the PV-
specific HYPERVISOR_mmu_update hypercall is clearly incorrect.

This patch adds checks in xen_remap_domain_gfn_array() and
xen_unmap_domain_gfn_array() which call through to the approprate
xlate_mmu function if the feature is present. A check is also added
to xen_remap_domain_gfn_range() to fail with -EOPNOTSUPP since this
should not be used in an HVM tools domain.

Signed-off-by: Paul Durrant 
---
Boris Ostrovsky 
Juergen Gross 
Thomas Gleixner 
Ingo Molnar 
"H. Peter Anvin" 
---
 arch/x86/xen/mmu.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 3e15345abfe7..d33e7dbe3129 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -172,6 +172,9 @@ int xen_remap_domain_gfn_range(struct vm_area_struct *vma,
   pgprot_t prot, unsigned domid,
   struct page **pages)
 {
+   if (xen_feature(XENFEAT_auto_translated_physmap))
+   return -EOPNOTSUPP;
+
return do_remap_gfn(vma, addr, , nr, NULL, prot, domid, pages);
 }
 EXPORT_SYMBOL_GPL(xen_remap_domain_gfn_range);
@@ -182,6 +185,10 @@ int xen_remap_domain_gfn_array(struct vm_area_struct *vma,
   int *err_ptr, pgprot_t prot,
   unsigned domid, struct page **pages)
 {
+   if (xen_feature(XENFEAT_auto_translated_physmap))
+   return xen_xlate_remap_gfn_array(vma, addr, gfn, nr, err_ptr,
+prot, domid, pages);
+
/* We BUG_ON because it's a programmer error to pass a NULL err_ptr,
 * and the consequences later is quite hard to detect what the actual
 * cause of "wrong memory was mapped in".
@@ -193,9 +200,12 @@ EXPORT_SYMBOL_GPL(xen_remap_domain_gfn_array);
 
 /* Returns: 0 success */
 int xen_unmap_domain_gfn_range(struct vm_area_struct *vma,
-  int numpgs, struct page **pages)
+  int nr, struct page **pages)
 {
-   if (!pages || !xen_feature(XENFEAT_auto_translated_physmap))
+   if (xen_feature(XENFEAT_auto_translated_physmap))
+   return xen_xlate_unmap_gfn_range(vma, nr, pages);
+
+   if (!pages)
return 0;
 
return -EINVAL;
-- 
2.11.0


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

Re: [Xen-devel] [PATCH] x86/xen: support priv-mapping in an HVM tools domain

[Paul Durrant]

Apologies... I misformatted this. I will re-send.

  Paul
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 19 October 2017 16:24
> To: x...@kernel.org; xen-de...@lists.xenproject.org; linux-
> ker...@vger.kernel.org
> Cc: Paul Durrant 
> Subject: [PATCH] x86/xen: support priv-mapping in an HVM tools domain
> 
> If the domain has XENFEAT_auto_translated_physmap then use of the PV-
> specific HYPERVISOR_mmu_update hypercall is clearly incorrect.
> 
> This patch adds checks in xen_remap_domain_gfn_array() and
> xen_unmap_domain_gfn_array() which call through to the approprate
> xlate_mmu function if the feature is present. A check is also added
> to xen_remap_domain_gfn_range() to fail with -EOPNOTSUPP since this
> should not be used in an HVM tools domain.
> 
> Signed-off-by: Paul Durrant 
> ---
> Boris Ostrovsky 
> Juergen Gross 
> Thomas Gleixner 
> Ingo Molnar 
> "H. Peter Anvin" 
> ---
>  arch/x86/xen/mmu.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 3e15345abfe7..d33e7dbe3129 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -172,6 +172,9 @@ int xen_remap_domain_gfn_range(struct
> vm_area_struct *vma,
>  pgprot_t prot, unsigned domid,
>  struct page **pages)
>  {
> + if (xen_feature(XENFEAT_auto_translated_physmap))
> + return -EOPNOTSUPP;
> +
>   return do_remap_gfn(vma, addr, , nr, NULL, prot, domid,
> pages);
>  }
>  EXPORT_SYMBOL_GPL(xen_remap_domain_gfn_range);
> @@ -182,6 +185,10 @@ int xen_remap_domain_gfn_array(struct
> vm_area_struct *vma,
>  int *err_ptr, pgprot_t prot,
>  unsigned domid, struct page **pages)
>  {
> + if (xen_feature(XENFEAT_auto_translated_physmap))
> + return xen_xlate_remap_gfn_array(vma, addr, gfn, nr,
> err_ptr,
> +  prot, domid, pages);
> +
>   /* We BUG_ON because it's a programmer error to pass a NULL
> err_ptr,
>* and the consequences later is quite hard to detect what the actual
>* cause of "wrong memory was mapped in".
> @@ -193,9 +200,12 @@
> EXPORT_SYMBOL_GPL(xen_remap_domain_gfn_array);
> 
>  /* Returns: 0 success */
>  int xen_unmap_domain_gfn_range(struct vm_area_struct *vma,
> -int numpgs, struct page **pages)
> +int nr, struct page **pages)
>  {
> - if (!pages || !xen_feature(XENFEAT_auto_translated_physmap))
> + if (xen_feature(XENFEAT_auto_translated_physmap))
> + return xen_xlate_unmap_gfn_range(vma, nr, pages);
> +
> + if (!pages)
>   return 0;
> 
>   return -EINVAL;
> --
> 2.11.0


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

Re: [Xen-devel] [PATCH] tools/Makefile: unset MAKELEVEL before building QEMU

[Ian Jackson]

Anthony PERARD writes ("[PATCH] tools/Makefile: unset MAKELEVEL before building 
QEMU"):
> Since QEMU commits aef45d51d1204f3335fb99de6658e0c5612c2b67
> "build: automatically handle GIT submodule checkout for dtc"
> the QEMU makefiles rely on the variable MAKELEVEL to make a decision on
> whether to update some git submodules or not. Since we call QEMU build
> from within the Xen one, MAKELEVEL would already be greater than 0 and
> the git submodules would not be updated and QEMU would fail to build.
> 
> Fix this by removing MAKELEVEL from the environment before trying to
> build QEMU.

Urgh.

I think this is a bug in the qemu makefiles.  But also, use of git
submodules is a bug in itself.  None of that is likely to be fixed.

Acked-by: Ian Jackson 

Ian.

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

Re: [Xen-devel] [RFC v2 5/7] acpi:arm64: Add support for parsing IORT table

[Goel, Sameer]

On 10/12/2017 8:06 AM, Julien Grall wrote:
> Hi Sameer,
> 
> On 21/09/17 01:37, Sameer Goel wrote:
>> Add support for parsing IORT table to initialize SMMU devices.
>> * The code for creating an SMMU device has been modified, so that the SMMU
>> device can be initialized.
>> * The NAMED NODE code has been commented out as this will need DOM0 kernel
>> support.
>> * ITS code has been included but it has not been tested.
>>
>> Signed-off-by: Sameer Goel 
>> ---
>>   xen/arch/arm/setup.c   |   3 +
>>   xen/drivers/acpi/Makefile  |   1 +
>>   xen/drivers/acpi/arm/Makefile  |   1 +
>>   xen/drivers/acpi/arm/iort.c    | 173 
>> +
>>   xen/drivers/passthrough/arm/smmu.c |   1 +
>>   xen/include/acpi/acpi_iort.h   |  17 ++--
>>   xen/include/asm-arm/device.h   |   2 +
>>   xen/include/xen/acpi.h |  21 +
>>   xen/include/xen/pci.h  |   8 ++
>>   9 files changed, 146 insertions(+), 81 deletions(-)
>>   create mode 100644 xen/drivers/acpi/arm/Makefile
>>
>> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
>> index 92f173b..4ba09b2 100644
>> --- a/xen/arch/arm/setup.c
>> +++ b/xen/arch/arm/setup.c
>> @@ -49,6 +49,7 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>     struct bootinfo __initdata bootinfo;
>>   @@ -796,6 +797,8 @@ void __init start_xen(unsigned long boot_phys_offset,
>>     tasklet_subsys_init();
>>   +    /* Parse the ACPI iort data */
>> +    acpi_iort_init();
>>     xsm_dt_init();
>>   diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile
>> index 444b11d..e7ffd82 100644
>> --- a/xen/drivers/acpi/Makefile
>> +++ b/xen/drivers/acpi/Makefile
>> @@ -1,5 +1,6 @@
>>   subdir-y += tables
>>   subdir-y += utilities
>> +subdir-$(CONFIG_ARM) += arm
>>   subdir-$(CONFIG_X86) += apei
>>     obj-bin-y += tables.init.o
>> diff --git a/xen/drivers/acpi/arm/Makefile b/xen/drivers/acpi/arm/Makefile
>> new file mode 100644
>> index 000..7c039bb
>> --- /dev/null
>> +++ b/xen/drivers/acpi/arm/Makefile
>> @@ -0,0 +1 @@
>> +obj-y += iort.o
>> diff --git a/xen/drivers/acpi/arm/iort.c b/xen/drivers/acpi/arm/iort.c
>> index 2e368a6..7f54062 100644
>> --- a/xen/drivers/acpi/arm/iort.c
>> +++ b/xen/drivers/acpi/arm/iort.c
>> @@ -14,17 +14,47 @@
>>    * This file implements early detection/parsing of I/O mapping
>>    * reported to OS through firmware via I/O Remapping Table (IORT)
>>    * IORT document number: ARM DEN 0049A
>> + *
>> + * Based on Linux drivers/acpi/arm64/iort.c
>> + * => commit ca78d3173cff3503bcd15723b049757f75762d15
>> + *
>> + * Xen modification:
>> + * Sameer Goel 
>> + * Copyright (C) 2017, The Linux Foundation, All rights reserved.
>> + *
>>    */
>>   -#define pr_fmt(fmt)    "ACPI: IORT: " fmt
>> -
>> -#include 
>> -#include 
>> -#include 
>> -#include 
>> -#include 
>> -#include 
>> -#include 
>> +#include 
>> +#include 
> 
> Why do you need to include there? Can't this be done after all the  ?
I was just clubbing the acpi includes. I can move this after all xen/
> 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
>> +/* Xen: Define compatibility functions */
>> +#define FW_BUG    "[Firmware Bug]: "
>> +#define pr_err(fmt, ...) printk(XENLOG_ERR fmt, ## __VA_ARGS__)
>> +#define pr_warn(fmt, ...) printk(XENLOG_WARNING fmt, ## __VA_ARGS__)
>> +
>> +/* Alias to Xen allocation helpers */
>> +#define kfree xfree
>> +#define kmalloc(size, flags)    _xmalloc(size, sizeof(void *))
>> +#define kzalloc(size, flags)    _xzalloc(size, sizeof(void *))
> 
> Likely you would need the same macros in the SMMUv3 driver. Could we think of 
> a common headers implementing the Linux compat layer?
I agree that this will be a very useful. i'll try to propose something.
> 
>> +
>> +/* Redefine WARN macros */
>> +#undef WARN
>> +#undef WARN_ON
>> +#define WARN(condition, format...) ({    \
>> +    int __ret_warn_on = !!(condition);    \
>> +    if (unlikely(__ret_warn_on))    \
>> +    printk(format);    \
>> +    unlikely(__ret_warn_on);    \
>> +})
> 
> Again, you should at least try to modify the common code version before 
> deciding to redefine it here.
The xen macro seems such that it explicitly tries to block a return by wrapping 
this macro in a loop. I had changed the common function in the last iteration 
and there seemed to be a pushback. 
> 
>> +#define WARN_TAINT(cond, taint, format...) WARN(cond, format)
>> +#define WARN_ON(cond)  (!!cond)
>>     #define IORT_TYPE_MASK(type)    (1 << (type))
>>   #define IORT_MSI_TYPE    (1 << ACPI_IORT_NODE_ITS_GROUP)
>> @@ -256,6 +286,13 @@ static acpi_status iort_match_node_callback(struct 
>> acpi_iort_node *node,
>>   acpi_status status;
>>     if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT) {
>> +  

Re: [Xen-devel] [PATCH for-4.10 1/2] tools/libxc: Fix precopy_policy() to not pass a structure by value

[Ian Jackson]

Andrew Cooper writes ("Re: [PATCH for-4.10 1/2] tools/libxc: Fix 
precopy_policy() to not pass a structure by value"):
> On 16/10/17 16:07, Ian Jackson wrote:
> > This statement is true only if you think "the precopy callback" refers
> > to the stub generated by libxl_save_msgs_gen.
> 
> The commit is about save_callbacks.precopy_policy() specifically (and
> IMO, obviously).
> 
> Given this, the statement is true.

I don't agree.

> >   But a more natural
> > reading is that "the precopy callback" refers to the actual code which
> > implements whatever logic is required.
> >
> > In a system using libxl, that code definitely _is_ executing in a
> > separate address space.  And passing the stats by value rather than
> > reference does make it marginally easier.
> 
> There is no libxl code for any of this.

That is of course a deficiency which we hope will be remedied,
surely.  We should expect there to be libxl code.

> >> Switch the callback to passing by pointer which is far more efficient, and
> >> drop the typedef (because none of the other callback have this oddity).
> > I would like you to expand on this efficiency argument.
> 
> The two most common mechanisms are either to pass the object split
> across pre-agreed registers, or the compiler rearranges things to have a
> local stack object, pass by pointer, and have the prologue memcpy() it
> into local scope.
> 
> The resulting change in calling convention is implementation defined,
> and subject to several different code-gen options in GCC or Clang.
> 
> Therefore it is inappropriate for such an interface to exist in the
> libxenguest ABI.

I asked you to expand on an efficiency argument and instead you have
provided an argument based on calling convention.

Furthermore, the argument you are now presenting is simply wrong.

Yes, there are options in compilers which can change the calling
conventions in incompatible ways (for structs passed as arguments, as
for various other things).  But one must not pass those arguments when
expecting to link against nonconsenting libraries.

The C standard has permitted passing structs by value for a long time
now, and all the (CPU architecture, operating system) combinations we
support have a well-defined ABI doing so.  Passing structs by value is
far from unusual.

Ian.

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

Re: [Xen-devel] [PATCH v12 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

[Jan Beulich]

>>> On 19.10.17 at 16:49,  wrote:
>> > I'd prefer to make the whole thing x86-only since that's the only platform
>> on which I can test it, and indeed the code used to be x86-only. Jan objected
>> to this so all I'm trying to achieve is that it builds for ARM. Please can 
>> you and
>> Jan reach agreement on where the code should live and how, if at all, it
>> should be #ifdef-ed?
>> 
>> I am quite surprised of "it is tools-only" so it is fine to not protect
>> it even if it is x86 only. That's probably going to bite us in the future.
>> 
> 
> So, this appears to have reached an impasse. I don't know how to proceed 
> without having to also fix priv mapping for x86, which is a yak far too large 
> for me to shave at the moment.

Julien,

why is it that you are making refcounting on p2m insertion / removal
a requirement for this series? We all know it's not there right now
(and similarly also not for the IOMMU, which might affect ARM as well
unless you always use shared page tables), and it's - as Paul validly
says - unrelated to his series.

Jan


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

Re: [Xen-devel] VPMU interrupt unreliability

[Kyle Huey]

On Wed, Oct 11, 2017 at 7:09 AM, Boris Ostrovsky
 wrote:
> On 10/10/2017 12:54 PM, Kyle Huey wrote:
>> On Mon, Jul 24, 2017 at 9:54 AM, Kyle Huey  wrote:
>>> On Mon, Jul 24, 2017 at 8:07 AM, Boris Ostrovsky
>>>  wrote:
>> One thing I noticed is that the workaround doesn't appear to be
>> complete: it is only checking PMC0 status and not other counters (fixed
>> or architectural). Of course, without knowing what the actual problem
>> was it's hard to say whether this was intentional.
> handle_pmc_quirk appears to loop through all the counters ...
 Right, I didn't notice that it is shifting MSR_CORE_PERF_GLOBAL_STATUS
 value one by one and so it is looking at all bits.

>>> 2. Intercepting MSR loads for counters that have the workaround
>>> applied and giving the guest the correct counter value.
>> We'd have to keep track of whether the counter has been reset (by the
>> quirk) since the last MSR write.
> Yes.
>
>>> 3. Or perhaps even changing the workaround to disable the PMI on that
>>> counter until the guest acks via GLOBAL_OVF_CTRL, assuming that works
>>> on the relevant hardware.
>> MSR_CORE_PERF_GLOBAL_OVF_CTRL is written immediately after the quirk
>> runs (in core2_vpmu_do_interrupt()) so we already do this, don't we?
> I'm suggesting waiting until the *guest* writes to the (virtualized)
> GLOBAL_OVF_CTRL.
 Wouldn't it be better to wait until the counter is reloaded?
>>> Maybe!  I haven't thought through it a lot.  It's still not clear to
>>> me whether MSR_CORE_PERF_GLOBAL_OVF_CTRL actually controls the
>>> interrupt in any way or whether it just resets the bits in
>>> MSR_CORE_PERF_GLOBAL_STATUS and acking the interrupt on the APIC is
>>> all that's required to reenable it.
>>>
>>> - Kyle
>> I wonder if it would be reasonable to just remove the workaround
>> entirely at some point.  The set of people using 1) several year old
>> hardware, 2) an up to date Xen, and 3) the off-by-default performance
>> counters is probably rather small.
>
> We'd probably want to only enable this for affected processors, not
> remove it outright. But the problem is that we still don't know for sure
> whether this issue affects NHM only, do we?
>
> (https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg02242.html
> is the original message)

Yes, the basic problem is that we don't know where to draw the line.

- Kyle

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

Re: [Xen-devel] [PATCH 1/1] xen/time: do not decrease steal time after live migration on xen

[Boris Ostrovsky]

On 10/19/2017 04:02 AM, Dongli Zhang wrote:
> After guest live migration on xen, steal time in /proc/stat
> (cpustat[CPUTIME_STEAL]) might decrease because steal returned by
> xen_steal_lock() might be less than this_rq()->prev_steal_time which is
> derived from previous return value of xen_steal_clock().
>
> For instance, steal time of each vcpu is 335 before live migration.
>
> cpu  198 0 368 200064 1962 0 0 1340 0 0
> cpu0 38 0 81 50063 492 0 0 335 0 0
> cpu1 65 0 97 49763 634 0 0 335 0 0
> cpu2 38 0 81 50098 462 0 0 335 0 0
> cpu3 56 0 107 50138 374 0 0 335 0 0
>
> After live migration, steal time is reduced to 312.
>
> cpu  200 0 370 200330 1971 0 0 1248 0 0
> cpu0 38 0 82 50123 500 0 0 312 0 0
> cpu1 65 0 97 49832 634 0 0 312 0 0
> cpu2 39 0 82 50167 462 0 0 312 0 0
> cpu3 56 0 107 50207 374 0 0 312 0 0
>
> The code in this patch is borrowed from do_stolen_accounting() which has
> already been removed from linux source code since commit ecb23dc6f2ef
> ("xen: add steal_clock support on x86"). The core idea of both
> do_stolen_accounting() and this patch is to avoid accounting new steal
> clock if it is smaller than previous old steal clock.
>
> Similar and more severe issue would impact prior linux 4.8-4.10 as
> discussed by Michael Las at
> https://0xstubs.org/debugging-a-flaky-cpu-steal-time-counter-on-a-paravirtualized-xen-guest,
> which would overflow steal time and lead to 100% st usage in top command
> for linux 4.8-4.10. A backport of this patch would fix that issue.
>
> References: 
> https://0xstubs.org/debugging-a-flaky-cpu-steal-time-counter-on-a-paravirtualized-xen-guest
> Signed-off-by: Dongli Zhang 
> ---
>  drivers/xen/time.c | 15 ++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/xen/time.c b/drivers/xen/time.c
> index ac5f23f..2b3a996 100644
> --- a/drivers/xen/time.c
> +++ b/drivers/xen/time.c
> @@ -19,6 +19,8 @@
>  /* runstate info updated by Xen */
>  static DEFINE_PER_CPU(struct vcpu_runstate_info, xen_runstate);
>  
> +static DEFINE_PER_CPU(u64, xen_old_steal);
> +
>  /* return an consistent snapshot of 64-bit time/counter value */
>  static u64 get64(const u64 *p)
>  {
> @@ -83,9 +85,20 @@ bool xen_vcpu_stolen(int vcpu)
>  u64 xen_steal_clock(int cpu)
>  {
>   struct vcpu_runstate_info state;
> + u64 xen_new_steal;
> + s64 steal_delta;
>  
>   xen_get_runstate_snapshot_cpu(, cpu);
> - return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline];
> + xen_new_steal = state.time[RUNSTATE_runnable]
> + + state.time[RUNSTATE_offline];
> + steal_delta = xen_new_steal - per_cpu(xen_old_steal, cpu);
> +
> + if (steal_delta < 0)
> + xen_new_steal = per_cpu(xen_old_steal, cpu);
> + else
> + per_cpu(xen_old_steal, cpu) = xen_new_steal;
> +
> + return xen_new_steal;
>  }
>  
>  void xen_setup_runstate_info(int cpu)

Can we stash state.time[] during suspend and then add stashed values
inside xen_get_runstate_snapshot_cpu()?

This will make xen_steal_clock() simpler.

-boris


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

Re: [Xen-devel] [PATCH] libxc: don't fail domain creation when unpacking initrd fails

[Ian Jackson]

Jan:
> [...] As quite often when changing code I'm not very
> familiar with, I had tried to minimize the amount of changes needed. E.g.
> I did consider dropping xc_dom_ramdisk_check_size() altogether in favor
> of some other function (or even doing what is needed in its only caller),
> but that would have been a larger (both textual and factual) change than
> keeping the function and adding another parameter.

I can see why this seema an attractive approach to unfamiliar code.
But at least in this case I think the results are unsatisfactory.

Jan Beulich writes ("Re: [PATCH] libxc: don't fail domain creation when 
unpacking initrd fails"):
> On 16.10.17 at 18:43,  wrote:
> > I'm afraid I still find the patch less clear than it could be.
> > The new semantics of xc_dom_ramdisk_check_size are awkward.  And
> > looking at it briefly, I think it might be possible to try the unzip
> > even if the size is too large.
> 
> I don't think so - xc_dom_ramdisk_check_size() returns 1
> whenever decompressed size is above the limit. What I do
> admit is that in the case compressed size is larger than
> uncompressed size, with the boundary being in between, and
> with decompression failing, we may accept something that's
> above the limit. Not sure how bad that is though, as the limit
> is pretty arbitrary anyway.

Conceptually what you are trying to do is have two alternative
strategies.  Those two strategies have different limits.  So "the
limit" is not a meaningful concept.

> > What you are really trying to do here is to pursue two strategies in
> > parallel.  And ideally they would not be entangled.
> 
> I would have wanted to do things in sequence rather than in
> parallel. I can't see how that could work though, in particular
> when considering the case mentioned above (uncompressed size
> smaller than compressed) - as the space allocation in the guest
> can't be reverted, I need to allocate the larger of the two sizes
> anyway.

I don't think it can work.  I think you uneed to pursue them in
parallel and keep separate records, for each one, of whether we are
still pursuing it or whether it has failed (and of course its
necessary locals).

> > Each of the strategies must rely only on
> > functions which don't bomb out, to achieve that.
> 
> I'm not sure I understand what "bomb out" is supposed to
> mean here. I first thought you meant calls to xc_dom_panic(),
> but now I don't think that's what you would mean here (the
> more that I'm not introducing that behavior of the function).
> 
> So what about Andrew's suggestion of leaving the initrd alone
> unconditionally?

That would be a backward incompatible change.  We'd need some kind of
justification to explain why no-one cares about it any more.

Ian.

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

Re: [Xen-devel] [PATCH] MAINTAINERS: Make Christian Lindig maintainer for ocaml tools

[Christian Lindig]

Thanks for the trust. I’d be happy to do it in the formal role of maintainer 
but would also be happy to help maintaining ocaml tools otherwise.

— Christian



> On 17. Oct 2017, at 17:44, Ian Jackson  wrote:
> 
> oxenstored is our default implementation of xenstore, for platforms
> that have ocaml support.  We need it to be maintained.  Dave Scott,
> the only existing maintainer, has had limited availability.
> 
> Christian has been reveiwing patches and offering opinions where
> necessary, although activity in this area has been quiet and there has
> not been a great deal of new development.
> 
> Christian's contributions have been sensible and I think it would be a
> good idea now to formally make him a maintainer.
> 
> CC: Christian Lindig 
> CC: David Scott 
> Signed-off-by: Ian Jackson 
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4d70923..e30cb70 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -283,6 +283,7 @@ T:git git://xenbits.xen.org/mini-os.git
> F:config/MiniOS.mk
> 
> OCAML TOOLS
> +M:   Christian Lindig 
> M:David Scott 
> S:Supported
> F:tools/ocaml/
> -- 
> 2.1.4
> 

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

[Xen-devel] [PATCH] watchdog: xen: use time64_t for timeouts

[Arnd Bergmann]

The Xen watchdog driver uses __kernel_time_t and ktime_to_timespec()
internally for managing its timeouts. Both are deprecated because of
y2038 problems. The driver itself is fine, since it only uses monotonic
times, but converting it to use ktime_get_seconds() avoids the deprecated
interfaces and is slightly simpler.

Signed-off-by: Arnd Bergmann 
---
 drivers/watchdog/xen_wdt.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/watchdog/xen_wdt.c b/drivers/watchdog/xen_wdt.c
index cf0e650c2015..5dd5c3494d55 100644
--- a/drivers/watchdog/xen_wdt.c
+++ b/drivers/watchdog/xen_wdt.c
@@ -35,7 +35,7 @@
 static struct platform_device *platform_device;
 static DEFINE_SPINLOCK(wdt_lock);
 static struct sched_watchdog wdt;
-static __kernel_time_t wdt_expires;
+static time64_t wdt_expires;
 static bool is_active, expect_release;
 
 #define WATCHDOG_TIMEOUT 60 /* in seconds */
@@ -49,15 +49,15 @@ module_param(nowayout, bool, S_IRUGO);
 MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started "
"(default=" __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
 
-static inline __kernel_time_t set_timeout(void)
+static inline time64_t set_timeout(void)
 {
wdt.timeout = timeout;
-   return ktime_to_timespec(ktime_get()).tv_sec + timeout;
+   return ktime_get_seconds() + timeout;
 }
 
 static int xen_wdt_start(void)
 {
-   __kernel_time_t expires;
+   time64_t expires;
int err;
 
spin_lock(_lock);
@@ -98,7 +98,7 @@ static int xen_wdt_stop(void)
 
 static int xen_wdt_kick(void)
 {
-   __kernel_time_t expires;
+   time64_t expires;
int err;
 
spin_lock(_lock);
@@ -222,7 +222,7 @@ static long xen_wdt_ioctl(struct file *file, unsigned int 
cmd,
return put_user(timeout, argp);
 
case WDIOC_GETTIMELEFT:
-   retval = wdt_expires - ktime_to_timespec(ktime_get()).tv_sec;
+   retval = wdt_expires - ktime_get_seconds();
return put_user(retval, argp);
}
 
-- 
2.9.0


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

Re: [Xen-devel] [PATCH v1 5/5] tools: libxendevicemodel: Provide xendevicemodel_pin_memory_cacheattr

[Ian Jackson]

Ross Lagerwall writes ("[PATCH v1 5/5] tools: libxendevicemodel: Provide 
xendevicemodel_pin_memory_cacheattr"):
> Signed-off-by: Ross Lagerwall 

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH v1 4/5] tools: libxendevicemodel: Provide xendevicemodel_add_to_physmap

[Ian Jackson]

Ross Lagerwall writes ("[PATCH v1 4/5] tools: libxendevicemodel: Provide 
xendevicemodel_add_to_physmap"):
> Signed-off-by: Ross Lagerwall 

Acked-by: Ian Jackson 

I have looked at the hypervisor patches but I am not qualified to
assess the security properties of the new DMOPs.

Ian.

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

Re: [Xen-devel] [RFC v2 5/7] acpi:arm64: Add support for parsing IORT table

[Goel, Sameer]

On 10/10/2017 6:36 AM, Manish Jaggi wrote:
> Hi Sameer,
> On 9/21/2017 6:07 AM, Sameer Goel wrote:
>> Add support for parsing IORT table to initialize SMMU devices.
>> * The code for creating an SMMU device has been modified, so that the SMMU
>> device can be initialized.
>> * The NAMED NODE code has been commented out as this will need DOM0 kernel
>> support.
>> * ITS code has been included but it has not been tested.
> Could you please refactor this patch into another set of two patches.
> I am planning to rebase my IORT for Dom0 Hiding patch rework on this patch.

I will try to break this up. Lets discuss this a bit more next week.
> Thanks,
> Manish
>> Signed-off-by: Sameer Goel 
>> ---
>>   xen/arch/arm/setup.c   |   3 +
>>   xen/drivers/acpi/Makefile  |   1 +
>>   xen/drivers/acpi/arm/Makefile  |   1 +
>>   xen/drivers/acpi/arm/iort.c    | 173 
>> +
>>   xen/drivers/passthrough/arm/smmu.c |   1 +
>>   xen/include/acpi/acpi_iort.h   |  17 ++--
>>   xen/include/asm-arm/device.h   |   2 +
>>   xen/include/xen/acpi.h |  21 +
>>   xen/include/xen/pci.h  |   8 ++
>>   9 files changed, 146 insertions(+), 81 deletions(-)
>>   create mode 100644 xen/drivers/acpi/arm/Makefile
>>
>> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
>> index 92f173b..4ba09b2 100644
>> --- a/xen/arch/arm/setup.c
>> +++ b/xen/arch/arm/setup.c
>> @@ -49,6 +49,7 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>     struct bootinfo __initdata bootinfo;
>>   @@ -796,6 +797,8 @@ void __init start_xen(unsigned long boot_phys_offset,
>>     tasklet_subsys_init();
>>   +    /* Parse the ACPI iort data */
>> +    acpi_iort_init();
>>     xsm_dt_init();
>>   diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile
>> index 444b11d..e7ffd82 100644
>> --- a/xen/drivers/acpi/Makefile
>> +++ b/xen/drivers/acpi/Makefile
>> @@ -1,5 +1,6 @@
>>   subdir-y += tables
>>   subdir-y += utilities
>> +subdir-$(CONFIG_ARM) += arm
>>   subdir-$(CONFIG_X86) += apei
>>     obj-bin-y += tables.init.o
>> diff --git a/xen/drivers/acpi/arm/Makefile b/xen/drivers/acpi/arm/Makefile
>> new file mode 100644
>> index 000..7c039bb
>> --- /dev/null
>> +++ b/xen/drivers/acpi/arm/Makefile
>> @@ -0,0 +1 @@
>> +obj-y += iort.o
>> diff --git a/xen/drivers/acpi/arm/iort.c b/xen/drivers/acpi/arm/iort.c
>> index 2e368a6..7f54062 100644
>> --- a/xen/drivers/acpi/arm/iort.c
>> +++ b/xen/drivers/acpi/arm/iort.c
>> @@ -14,17 +14,47 @@
>>    * This file implements early detection/parsing of I/O mapping
>>    * reported to OS through firmware via I/O Remapping Table (IORT)
>>    * IORT document number: ARM DEN 0049A
>> + *
>> + * Based on Linux drivers/acpi/arm64/iort.c
>> + * => commit ca78d3173cff3503bcd15723b049757f75762d15
>> + *
>> + * Xen modification:
>> + * Sameer Goel 
>> + * Copyright (C) 2017, The Linux Foundation, All rights reserved.
>> + *
>>    */
>>   -#define pr_fmt(fmt)    "ACPI: IORT: " fmt
>> -
>> -#include 
>> -#include 
>> -#include 
>> -#include 
>> -#include 
>> -#include 
>> -#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
>> +/* Xen: Define compatibility functions */
>> +#define FW_BUG    "[Firmware Bug]: "
>> +#define pr_err(fmt, ...) printk(XENLOG_ERR fmt, ## __VA_ARGS__)
>> +#define pr_warn(fmt, ...) printk(XENLOG_WARNING fmt, ## __VA_ARGS__)
>> +
>> +/* Alias to Xen allocation helpers */
>> +#define kfree xfree
>> +#define kmalloc(size, flags)    _xmalloc(size, sizeof(void *))
>> +#define kzalloc(size, flags)    _xzalloc(size, sizeof(void *))
>> +
>> +/* Redefine WARN macros */
>> +#undef WARN
>> +#undef WARN_ON
>> +#define WARN(condition, format...) ({    \
>> +    int __ret_warn_on = !!(condition);    \
>> +    if (unlikely(__ret_warn_on))    \
>> +    printk(format);    \
>> +    unlikely(__ret_warn_on);    \
>> +})
>> +#define WARN_TAINT(cond, taint, format...) WARN(cond, format)
>> +#define WARN_ON(cond)  (!!cond)
>>     #define IORT_TYPE_MASK(type)    (1 << (type))
>>   #define IORT_MSI_TYPE    (1 << ACPI_IORT_NODE_ITS_GROUP)
>> @@ -256,6 +286,13 @@ static acpi_status iort_match_node_callback(struct 
>> acpi_iort_node *node,
>>   acpi_status status;
>>     if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT) {
>> +    status = AE_NOT_IMPLEMENTED;
>> +/*
>> + * We need the namespace object name from dsdt to match the iort node, this
>> + * will need additions to the kernel xen bus notifiers.
>> + * So, disabling the named node code till a proposal is approved.
>> + */
>> +#if 0
>>   struct acpi_buffer buf = { ACPI_ALLOCATE_BUFFER, NULL };
>>   struct acpi_device *adev = to_acpi_device_node(dev->fwnode);
>>   struct 

Re: [Xen-devel] [PATCH V3 18/29] VIOMMU: Add irq request callback to deal with irq remapping

[Roger Pau Monné]

On Thu, Sep 21, 2017 at 11:01:59PM -0400, Lan Tianyu wrote:
> This patch is to add irq request callback for platform implementation
> to deal with irq remapping request.
> 
> Signed-off-by: Lan Tianyu 
> ---
>  xen/common/viommu.c  | 15 +
>  xen/include/asm-x86/viommu.h | 72 
> 
>  xen/include/xen/viommu.h | 11 +++
>  3 files changed, 98 insertions(+)
>  create mode 100644 xen/include/asm-x86/viommu.h
> 
> diff --git a/xen/common/viommu.c b/xen/common/viommu.c
> index 55feb5d..b517158 100644
> --- a/xen/common/viommu.c
> +++ b/xen/common/viommu.c
> @@ -163,6 +163,21 @@ int viommu_domctl(struct domain *d, struct 
> xen_domctl_viommu_op *op,
>  return rc;
>  }
>  
> +int viommu_handle_irq_request(struct domain *d,
> +  struct arch_irq_remapping_request *request)
> +{
> +struct viommu *viommu = d->viommu;
> +
> +if ( !viommu )
> +return -EINVAL;

ENODEV

> +
> +ASSERT(viommu->ops);
> +if ( !viommu->ops->handle_irq_request )
> +return -EINVAL;
> +
> +return viommu->ops->handle_irq_request(d, request);
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/include/asm-x86/viommu.h b/xen/include/asm-x86/viommu.h
> new file mode 100644
> index 000..366fbb6
> --- /dev/null
> +++ b/xen/include/asm-x86/viommu.h
> @@ -0,0 +1,72 @@
> +/*
> + * include/asm-x86/viommu.h
> + *
> + * Copyright (c) 2017 Intel Corporation.
> + * Author: Lan Tianyu 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program; If not, see .
> + *
> + */
> +#ifndef __ARCH_X86_VIOMMU_H__
> +#define __ARCH_X86_VIOMMU_H__
> +
> +/* IRQ request type */
> +#define VIOMMU_REQUEST_IRQ_MSI  0
> +#define VIOMMU_REQUEST_IRQ_APIC 1
> +
> +struct arch_irq_remapping_request

Oh, so you have been using arch_irq_remapping_request in previous
patches without it being introduced. This is becoming more and more
hard to review. I will try to finish reviewing the whole series but
please, in the future make sure that each patch compiles on it's
own.

It's impossible to properly review a series when you use a structure
that has not yet been introduced.

> +{
> +union {
> +/* MSI */
> +struct {
> +uint64_t addr;
> +uint32_t data;
> +} msi;
> +/* Redirection Entry in IOAPIC */
> +uint64_t rte;
> +} msg;
> +uint16_t source_id;
> +uint8_t type;

Why don't you make this an enum?

> +};
> +
> +static inline void irq_request_ioapic_fill(struct arch_irq_remapping_request 
> *req,
> +   uint32_t ioapic_id, uint64_t rte)
> +{
> +ASSERT(req);
> +req->type = VIOMMU_REQUEST_IRQ_APIC;
> +req->source_id = ioapic_id;
> +req->msg.rte = rte;
> +}
> +
> +static inline void irq_request_msi_fill(struct arch_irq_remapping_request 
> *req,
> +uint32_t source_id, uint64_t addr,
> +uint32_t data)
> +{
> +ASSERT(req);
> +req->type = VIOMMU_REQUEST_IRQ_MSI;
> +req->source_id = source_id;
> +req->msg.msi.addr = addr;
> +req->msg.msi.data = data;
> +}

You are introducing two functions here that are not used in this
patch. They should be added when they are used, or else it's very hard
to review.

Thanks, Roger.

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

Re: [Xen-devel] [RFC v2 3/7] xen/passthrough/arm: Introduce iommu_fwspec

[Goel, Sameer]

On 10/12/2017 7:05 AM, Julien Grall wrote:
> Hi,
> 
> On 21/09/17 01:37, Sameer Goel wrote:
>> Introduce a common structure to hold the fw (ACPI or DT) defined
>> configuration for SMMU hw. The current use case is for arm SMMUs. So,
>> making this architecture specific.
>>
>> Based on Linux kernel commit 57f98d2f61e1: iommu: Introduce iommu_fwspec
>> Signed-off-by: Sameer Goel 
>> ---
>>   xen/drivers/passthrough/arm/iommu.c | 66 
>> +
>>   xen/include/asm-arm/device.h    |  1 +
>>   xen/include/xen/iommu.h | 29 
>>   3 files changed, 96 insertions(+)
>>
>> diff --git a/xen/drivers/passthrough/arm/iommu.c 
>> b/xen/drivers/passthrough/arm/iommu.c
>> index 95b1abb..41c6497 100644
>> --- a/xen/drivers/passthrough/arm/iommu.c
>> +++ b/xen/drivers/passthrough/arm/iommu.c
>> @@ -73,3 +73,69 @@ int arch_iommu_populate_page_table(struct domain *d)
>>   /* The IOMMU shares the p2m with the CPU */
>>   return -ENOSYS;
>>   }
>> +
>> +const struct iommu_ops *iommu_ops_from_fwnode(struct fwnode_handle *fwnode)
>> +{
>> +    return iommu_get_ops();
> 
> Can you please add a comment explain why you always return iommu_get_ops()?
> 
> Would it be possible that the device is not behind an IOMMU?
That is true. I will fix this.
> 
>> +}
>> +
>> +int iommu_fwspec_init(struct device *dev, struct fwnode_handle 
>> *iommu_fwnode,
>> +    const struct iommu_ops *ops)
>> +{
>> +    struct iommu_fwspec *fwspec = dev->iommu_fwspec;
>> +
>> +    if ( fwspec )
>> +    return ops == fwspec->ops ? 0 : -EINVAL;
>> +
>> +    fwspec = _xzalloc(sizeof(struct iommu_fwspec), sizeof(void *));
> 
> On the previous version this was xzalloc(struct iommu_fwspec), why?
> 
> I also don't understand the align on sizeof(void *).
Forgot why I did this. I will change it back. I just copied the alignment value 
from xzalloc.
> 
>> +    if ( !fwspec )
>> +    return -ENOMEM;
>> +
>> +    fwspec->iommu_fwnode = iommu_fwnode;
>> +    fwspec->ops = ops;
>> +    dev->iommu_fwspec = fwspec;
>> +
>> +    return 0;
>> +}
>> +
>> +void iommu_fwspec_free(struct device *dev)
>> +{
>> +    struct iommu_fwspec *fwspec = dev->iommu_fwspec;
>> +
>> +    if ( fwspec )
>> +    {
> 
> Linux is dropping the reference on the iommu_fwnode. Are we never expecting 
> to take reference on the it in Xen?
I will fix this.
> 
>> +    xfree(fwspec);
>> +    dev->iommu_fwspec = NULL;
>> +    }
>> +}
>> +
>> +int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids)
>> +{
>> +    struct iommu_fwspec *fwspec = dev->iommu_fwspec;
>> +    struct iommu_fwspec *fwspec_n = NULL;
>> +    size_t size, size_n;
>> +    int i;
>> +
>> +    if ( !fwspec )
>> +    return -EINVAL;
>> +
>> +    size = offsetof(struct iommu_fwspec, ids[fwspec->num_ids]);
>> +    size_n = offsetof(struct iommu_fwspec, ids[fwspec->num_ids + num_ids]);
>> +    if ( size_n > size )
>> +    { > +    fwspec_n = _xzalloc(size_n, sizeof(void *));
> 
> Same question about _xzalloc() here.
> 
See above.
>> +    if ( !fwspec_n )
>> +    return -ENOMEM;
>> +
>> +    memcpy(fwspec_n, fwspec, size);
>> +    xfree(fwspec);
>> +    }
>> +
>> +    for (i = 0; i < num_ids; i++)
>> +    fwspec_n->ids[fwspec_n->num_ids + i] = ids[i];
>> +
>> +    fwspec_n->num_ids += num_ids;
>> +    dev->iommu_fwspec = fwspec_n;
>> +
>> +    return 0;
>> +}
>> diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
>> index 78c38fe..5027c87 100644
>> --- a/xen/include/asm-arm/device.h
>> +++ b/xen/include/asm-arm/device.h
>> @@ -21,6 +21,7 @@ struct device
>>   struct dt_device_node *of_node; /* Used by drivers imported from Linux 
>> */
>>   #endif
>>   struct fwnode_handle *fwnode; /*fw device node identifier */
>> +    struct iommu_fwspec *iommu_fwspec;
>>   struct dev_archdata archdata;
>>   };
>>   diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
>> index 0dac4f3..34e8d68 100644
>> --- a/xen/include/xen/iommu.h
>> +++ b/xen/include/xen/iommu.h
>> @@ -208,4 +208,33 @@ DECLARE_PER_CPU(bool_t, iommu_dont_flush_iotlb);
>>   extern struct spinlock iommu_pt_cleanup_lock;
>>   extern struct page_list_head iommu_pt_cleanup_list;
>>   +/**
>> + * Following block was ported from Linux to help with the implementation of
>> + * arm64 iommu devices. Hence the architecture specific compile
>> + */
>> +
>> +#if defined(CONFIG_ARM)
> 
> If it is Arm only, then it should be moved in asm-arm/iommu.h.
Will do.
> 
>> +/**
>> + * struct iommu_fwspec - per-device IOMMU instance data
>> + * @ops: ops for this device's IOMMU
>> + * @iommu_fwnode: firmware handle for this device's IOMMU
>> + * @iommu_priv: IOMMU driver private data for this device
>> + * @num_ids: number of associated device IDs
>> + * @ids: IDs which this device may present to the IOMMU
>> + */
>> +struct iommu_fwspec {
>> +    const struct iommu_ops *ops;
>> +    struct fwnode_handle   

[Xen-devel] [linux-4.9 test] 114676: trouble: blocked/broken/fail/pass

[osstest service owner]

flight 114676 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114676/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvopsbroken
 build-armhf-pvops 4 host-install(4)broken REGR. vs. 114469

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-examine  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114469
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114469
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114469
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linux5d7a76acad403638f635c918cc63d1d44ffa4065
baseline version:
 linux9d36d3eff2f85efad0a3b0c6031081654ae33928

Last test of basis   114469  2017-10-13 12:50:00 Z6 days
Testing same since   114676  2017-10-18 07:55:57 Z1 days1 attempts


People who touched revisions under test:
  Al Viro 
  Alan Stern 
  Andreas Engel 
  Andreas Gruenbacher 
  Andrew Gabbasov 
  Andrew Morton 
  Andrey Konovalov 
  Darrick J. Wong 
  Felipe Balbi 
  Greg Kroah-Hartman 
  Haozhong Zhang 
  Henryk Heisig 
  Herbert Xu 
  Jaejoong Kim 
  Jani Nikula 
  Jarkko Nikula 
  Jeffrey Chu 
  Jiri Kosina 
  Joerg Roedel 
  Johan Hovold 
  Johannes Berg 
  Johannes Thumshirn 
  Jouni Malinen 
  Kazuya Mizuguchi 
  Ladi Prosek 
  Linus Torvalds 
  Linus Walleij 
  Manasi Navare 
  Mathias Krause 
  Matthew Wilcox 
  Matthew Wilcox 
  Paolo Bonzini 
  Paul Burton 
  Paul E. McKenney 
  Pavel Shilovsky 
  Peng Xu 
  Peter Ujfalusi 
  Petr Mladek 
  

Re: [Xen-devel] [PATCH v2 for-4.10 2/2] xentoolcore_restrict_all: Implement for libxenevtchn

[Ian Jackson]

Ross Lagerwall writes ("[PATCH v2 for-4.10 2/2] xentoolcore_restrict_all: 
Implement for libxenevtchn"):
> Signed-off-by: Ross Lagerwall 
> ---
> Changed in v2:
> * Keep warning about DoS and resource exhaustion being a possibility.

Acked-by: Ian Jackson 

Julien, I think you intended your release-ack to apply to both these
patches.  Unless you object I will put your release-ack on this patch
too, therefore, and commit both of them.

Ian.

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

Re: [Xen-devel] [RFC v2 2/7] arm64: Add definitions for fwnode_handle

[Goel, Sameer]

On 10/12/2017 6:45 AM, Julien Grall wrote:
> Hi,
> 
> On 21/09/17 01:37, Sameer Goel wrote:
>> This will be used as a device property to match the DMA capable devices
>> with the associated SMMU. The header file is a port from linux. The code
>> was changed to remove the types that were not needed for Xen.
> 
> I think you probably want a bit more context in the commit message about 
> implement fwnode.h in common code.
> 
> Within this series, fwnode seems to only be used by Arm. So what would be the 
> advantage to get that in xen/? Is it going to be used by x86 or taken 
> advantage in common code?
> 
>>
>> Linux ChangeId:ce793486e23e: driver core / ACPI: Represent ACPI
>> companions using fwnode_handle
>>
>> Signed-off-by: Sameer Goel 
>> ---
>>   xen/include/asm-arm/device.h |  2 ++
>>   xen/include/xen/fwnode.h | 33 +
>>   2 files changed, 35 insertions(+)
>>   create mode 100644 xen/include/xen/fwnode.h
>>
>> diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
>> index 6734ae8..78c38fe 100644
>> --- a/xen/include/asm-arm/device.h
>> +++ b/xen/include/asm-arm/device.h
>> @@ -2,6 +2,7 @@
>>   #define __ASM_ARM_DEVICE_H
>>     #include 
>> +#include 
>>     enum device_type
>>   {
>> @@ -19,6 +20,7 @@ struct device
>>   #ifdef CONFIG_HAS_DEVICE_TREE
>>   struct dt_device_node *of_node; /* Used by drivers imported from Linux 
>> */
> 
> I was expecting a todo in the code after the discussion about leave of_node 
> here.
> 
>>   #endif
>> +    struct fwnode_handle *fwnode; /*fw device node identifier */
The fwnode handle was provide a match cookie for the SMMUs and not much else. 
Even with this around we will need the 
dt info in the device node. I agree that this rolls up into fw spec and I can 
look at the code cleanup for the next patch.
> 
> Space missing before "fw".
> 
>>   struct dev_archdata archdata;
>>   };
>>   diff --git a/xen/include/xen/fwnode.h b/xen/include/xen/fwnode.h
>> new file mode 100644
>> index 000..0fed958
>> --- /dev/null
>> +++ b/xen/include/xen/fwnode.h
>> @@ -0,0 +1,33 @@
>> +/*
>> + * fwnode.h - Firmware device node object handle type definition.
>> + *
>> + * Copyright (C) 2015, Intel Corporation
>> + * Author: Rafael J. Wysocki 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * Ported from Linux include/linux/fwnode.h
>> + *  => commit ce793486e23e0162a732c605189c8028e0910e86
>> + *
>> + * No functional Xen modifications.
>> + */
>> +
>> +#ifndef __XEN_FWNODE_H_
>> +#define __XEN_FWNODE_H_
>> +
>> +enum fwnode_type {
>> +    FWNODE_INVALID = 0,
>> +    FWNODE_OF,
>> +    FWNODE_ACPI,
>> +    FWNODE_ACPI_STATIC,
>> +    FWNODE_IRQCHIP
>> +};
>> +
> 
> Looking at Linux code, the fwnode_type already disappeared from Linux (see 
> commit db3e50f3234b "device property: Get rid of struct fwnode_handle type 
> field").
> 
> I understand the goal on using fwnode is to help porting drivers from Linux. 
> So how much this has changed now?
This was not very useful in any case. So, I will move over to the new version.

> 
> Cheers,
> 
>> +struct fwnode_handle {
>> +    enum fwnode_type type;
>> +    struct fwnode_handle *secondary;
>> +};
>> +
>> +#endif
>>
> 

-- 
 Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, 
Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

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

Re: [Xen-devel] [PATCH v12 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

[Paul Durrant]

> -Original Message-
[snip]
> >
> > I'd prefer to make the whole thing x86-only since that's the only platform
> on which I can test it, and indeed the code used to be x86-only. Jan objected
> to this so all I'm trying to achieve is that it builds for ARM. Please can 
> you and
> Jan reach agreement on where the code should live and how, if at all, it
> should be #ifdef-ed?
> 
> I am quite surprised of "it is tools-only" so it is fine to not protect
> it even if it is x86 only. That's probably going to bite us in the future.
> 

So, this appears to have reached an impasse. I don't know how to proceed 
without having to also fix priv mapping for x86, which is a yak far too large 
for me to shave at the moment.

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

Re: [Xen-devel] [PATCH] aarch64: advertise the GIC system register interface

[Peter Maydell]

On 18 October 2017 at 01:10, Stefano Stabellini  wrote:
> Advertise the presence of the GIC system register interface (1<<24)
> according to H9.248 of the ARM ARM.
>
> This patch allows Xen to boot on QEMU aarch64.
>
> Signed-off-by: Stefano Stabellini 
>
> diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
> index 670c07a..a451763 100644
> --- a/target/arm/cpu64.c
> +++ b/target/arm/cpu64.c
> @@ -136,7 +136,7 @@ static void aarch64_a57_initfn(Object *obj)
>  cpu->id_isar3 = 0x01112131;
>  cpu->id_isar4 = 0x00011142;
>  cpu->id_isar5 = 0x00011121;
> -cpu->id_aa64pfr0 = 0x;
> +cpu->id_aa64pfr0 = 0x0100;
>  cpu->id_aa64dfr0 = 0x10305106;
>  cpu->pmceid0 = 0x;
>  cpu->pmceid1 = 0x;
> @@ -196,7 +196,7 @@ static void aarch64_a53_initfn(Object *obj)
>  cpu->id_isar3 = 0x01112131;
>  cpu->id_isar4 = 0x00011142;
>  cpu->id_isar5 = 0x00011121;
> -cpu->id_aa64pfr0 = 0x;
> +cpu->id_aa64pfr0 = 0x0100;
>  cpu->id_aa64dfr0 = 0x10305106;
>  cpu->id_aa64isar0 = 0x00011120;
>  cpu->id_aa64mmfr0 = 0x1122; /* 40 bit physical addr */

Whoops -- we missed this when we added the GICv3 support, because
Linux doesn't check it.

Applied to target-arm.next, thanks.

-- PMM

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

Re: [Xen-devel] [PATCH V3 17/29] x86/vvtd: add a helper function to decide the interrupt format

[Roger Pau Monné]

On Thu, Sep 21, 2017 at 11:01:58PM -0400, Lan Tianyu wrote:
> From: Chao Gao 
> 
> Different platform may use different method to distinguish
> remapping format interrupt and normal format interrupt.
> 
> Intel uses one bit in IOAPIC RTE or MSI address register to
> indicate the interrupt is remapping format. vvtd will handle
> all the interrupts when .check_irq_remapping() return true.
> 
> Signed-off-by: Chao Gao 
> Signed-off-by: Lan Tianyu 
> ---
>  xen/drivers/passthrough/vtd/vvtd.c | 25 -
>  1 file changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/drivers/passthrough/vtd/vvtd.c 
> b/xen/drivers/passthrough/vtd/vvtd.c
> index 5e22ace..bd1cadd 100644
> --- a/xen/drivers/passthrough/vtd/vvtd.c
> +++ b/xen/drivers/passthrough/vtd/vvtd.c
> @@ -536,6 +536,28 @@ static int vvtd_get_irq_info(struct domain *d,
>  return 0;
>  }
>  
> +/* Probe whether the interrupt request is an remapping format */
> +static bool vvtd_is_remapping(struct domain *d,
> +  struct arch_irq_remapping_request *irq)
> +{
> +if ( irq->type == VIOMMU_REQUEST_IRQ_APIC )
> +{
> +struct IO_APIC_route_remap_entry rte = { .val = irq->msg.rte };
> +
> +return rte.format;
> +}
> +else if ( irq->type == VIOMMU_REQUEST_IRQ_MSI )
> +{
> +struct msi_msg_remap_entry msi_msg =
> +{ .address_lo = { .val = irq->msg.msi.addr } };
> +
> +return msi_msg.address_lo.format;
> +}
> +ASSERT_UNREACHABLE();

Switch please.

Also there's a bunch of temporary IO_APIC_route_remap_entry and
msi_msg_remap_entry local structures. Why don't you just create some
kind of union in arch_irq_remapping_request so that you don't need to
do this each time?

Thanks, Roger.

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