Re: [Xen-devel] [PATCH] x86: enable RCU based table free when PARAVIRT

[Linus Torvalds]

On Wed, Aug 23, 2017 at 6:45 AM, Vitaly Kuznetsov  wrote:
>
> Solve the issue by enabling RCU-based table free mechanism when PARAVIRT
> is selected in config. Testing with kernbench doesn't show any notable
> performance impact:

I wonder if we should just make it unconditional if it doesn't really
show any performance difference. One less config complexity to worry
about (and in this case I'm not so much worried about Kconfig itself,
as just "oh, you have totally different paths in the core VM depending
on PARAVIRT".

That said, the thing to test for these kinds of things is often
heavily scripted loads that just run thousands and thousands of really
small processes, and build up and tear down page tables all the time
because of fork/exit.

The load I've used occasionally is just "make test" in the git source
tree. Tons and tons of trivial fork/exec/exit things for all those
small tests and shell scripts.

I think 'kernbench' just does kernel compiles. Which is not very
kernel or VM intensive at all. It's mostly just user mode compilers in
parallel.

   Linus

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

Re: [Xen-devel] [PATCH 18/27] xen/arm: page: Prefix memory types with MT_

[Julien Grall]

On 08/23/2017 12:41 PM, Andre Przywara wrote:

Hi,


Hi Andre,


On 14/08/17 15:24, Julien Grall wrote: >> diff --git 
a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h

index 660e1779c5..d7a048b64d 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -25,17 +25,17 @@
   * LPAE Memory region attributes. Indexed by the AttrIndex bits of a
   * LPAE entry; the 8-bit fields are packed little-endian into MAIR0 and MAIR1.
   *
- * aiencoding
- *   UNCACHED  000      -- Strongly Ordered
- *   BUFFERABLE001   0100 0100  -- Non-Cacheable
- *   WRITETHROUGH  010   1010 1010  -- Write-through
- *   WRITEBACK 011   1110 1110  -- Write-back
- *   DEV_SHARED100    0100  -- Device
- *   ??101
- *   reserved  110
- *   WRITEALLOC111      -- Write-back write-allocate
+ *aiencoding
+ *   MT_UNCACHED  000      -- Strongly Ordered
+ *   MT_BUFFERABLE001   0100 0100  -- Non-Cacheable
+ *   MT_WRITETHROUGH  010   1010 1010  -- Write-through
+ *   MT_WRITEBACK 011   1110 1110  -- Write-back
+ *   MT_DEV_SHARED100    0100  -- Device
+ *   ??   101
+ *   reserved 110
+ *   MT_WRITEALLOC111      -- Write-back write-allocate
   *
- *   DEV_WC001   (== BUFFERABLE)
+ *   MT_DEV_WC001   (== BUFFERABLE)


It's just a comment, but for consistency this should be MT_BUFFERABLE
here as well, I guess.

Apart from that nit the rest looks correct.


Hmm, I dropped DEV_WC in patch #17 but forgot to remove it from the 
comment. I will drop it in that patch and ...




Reviewed-by: Andre Przywara 


... keep you reviewed-by here and the #17 if you are happy with it.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 19/27] xen/arm: page: Clean-up the definition of MAIRVAL

[Julien Grall]

On 08/23/2017 12:42 PM, Andre Przywara wrote:

Hi,


Hi Andre,


On 14/08/17 15:24, Julien Grall wrote:

Currently MAIRVAL is defined in term of MAIR0VAL and MAIR1VAL which are
both hardcoded value. This makes quite difficult to understand the value
written in both registers.

Rework the definition by using value of each attribute shifted by their
associated index.

Signed-off-by: Julien Grall 


I checked all the bits and encoding against the ARMv8 ARM, they look
correct to me.
However I feel that the attribute renaming patch (20/27) should come
before this one.


I can invert the two patches. I don't plan to keep your tags in both 
patches as this would sensibly change some bits.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 25/27] xen/arm: mm: Embed permission in the flags

[Julien Grall]

On 08/23/2017 03:37 PM, Andre Przywara wrote:

Hi,

Hi Andre,


On 23/08/17 15:26, Julien Grall wrote:

On 08/23/2017 03:08 PM, Andre Przywara wrote:

Hi,


Hi,


On 14/08/17 15:24, Julien Grall wrote:

Currently, it is not possible to specify the permission of a new
mapping. It would be necessary to use the function modify_xen_mappings
with a different set of flags.



Just saw that I forgot the typos here:


Add introduce a couple of new flags for the permissions (Non-eXecutable,


Either "add" or "introduce", I guess.


I guess my mind disagree with my hands :). I will use "introduce" here.




Read-Only) and also provides define that combine the memory attribute
and permission for common combination.


Somehow the plural/singular is messed up here, I needed to read that
sentence multiple times.



If I haven't been lost in the definitions, this now adds "not
executable" to the existing definitions, which seems to make sense, but
is a change that might trigger regressions (especially for
PAGE_HYPERVISOR). So I wonder if that should be mentioned in the commit
message then?


It will not trigger regression because mfn_to_xen_entry is setting xn to
1 by default. So all the mapping will be execute never when using
PAGE_HYPERVISOR.


Ah right, I missed that. Might still be worth to mention in the commit
message, as this isn't obvious from just that patch.


I can do that. Below the suggested commit message:

"Currently, it is not possible to specify the permission of a new
mapping. It would be necessary to use the function modify_xen_mappings
with a different set of flags.

Introduce a couple of new flags for the permissions (Non-eXecutable,
Read-Only) and also provides define that combine the memory attribute
and permission for common combination.

PAGE_HYPERVISOR is now an alias to PAGE_HYPERVISOR_RW (read-write 
non-executable mappings). This does not affect the current mapping using 
PAGE_HYPERVISOR because this


A follow-up patch will change modify_xen_mappings to use the new flags."

Can I keep your reviewed-by?

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 09/27] xen/arm: traps: Don't define FAR_EL2 for ARM32

[Julien Grall]

On 08/22/2017 03:12 PM, Andre Przywara wrote:

Hi,


Hi Andre,


On 14/08/17 15:24, Julien Grall wrote:

Aliasing FAR_EL2 to HIFAR makes the code confusing because on ARMv8
FAR_EL2[31:0] is architecturally mapped to HDFAR and FAR_EL2[63:32] to
FAR_EL2.

   ^^^
I guess you mean HIFAR here.
Otherwise the patch makes sense.

Whoops yes. I will fix it in the next version.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 10/27] xen/arm: arm32: Don't define FAR_EL1

[Julien Grall]

On 08/22/2017 03:37 PM, Andre Przywara wrote:

Hi,


Hi Andre,


On 14/08/17 15:24, Julien Grall wrote:

Aliasing FAR_EL1 to IFAR is wrong because on ARMv8 FAR_EL1[31:0] is
architecturally mapped to DFAR and FAR_EL1[63:32] to DFAR.


Should be IFAR, I guess?


Yep. I will fix it.


Please put a quid into the copy-and-paste piggy bank ;-)


2 quite with the copy-paste in patch #9 :).

Cheers,

--
Julien Grall

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

[Xen-devel] [PATCH] x86/pv: Minor improvements to guest_get_eff_{, kern}_l1e()

[Andrew Cooper]

 * These functions work in terms of linear addresses, not virtual addresses.
   Update the comments and parameter names.
 * Drop unnecessary inlines.
 * Drop vcpu parameter from guest_get_eff_kern_l1e().  Its sole caller passes
   current, and its callee strictly operates on current.
 * Switch guest_get_eff_kern_l1e()'s parameter from void * to l1_pgentry_t *.
   Both its caller and callee already use the correct type already.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
---
 xen/arch/x86/mm.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 3262499..8993e6d 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -561,15 +561,15 @@ static inline void guest_unmap_l1e(void *p)
 unmap_domain_page(p);
 }
 
-/* Read a PV guest's l1e that maps this virtual address. */
-static inline void guest_get_eff_l1e(unsigned long addr, l1_pgentry_t *eff_l1e)
+/* Read a PV guest's l1e that maps this linear address. */
+static void guest_get_eff_l1e(unsigned long linear, l1_pgentry_t *eff_l1e)
 {
 ASSERT(!paging_mode_translate(current->domain));
 ASSERT(!paging_mode_external(current->domain));
 
-if ( unlikely(!__addr_ok(addr)) ||
+if ( unlikely(!__addr_ok(linear)) ||
  __copy_from_user(eff_l1e,
-  &__linear_l1_table[l1_linear_offset(addr)],
+  &__linear_l1_table[l1_linear_offset(linear)],
   sizeof(l1_pgentry_t)) )
 *eff_l1e = l1e_empty();
 }
@@ -578,18 +578,18 @@ static inline void guest_get_eff_l1e(unsigned long addr, 
l1_pgentry_t *eff_l1e)
  * Read the guest's l1e that maps this address, from the kernel-mode
  * page tables.
  */
-static inline void guest_get_eff_kern_l1e(struct vcpu *v, unsigned long addr,
-  void *eff_l1e)
+static void guest_get_eff_kern_l1e(unsigned long linear, l1_pgentry_t *eff_l1e)
 {
-const bool user_mode = !(v->arch.flags & TF_kernel_mode);
+struct vcpu *curr = current;
+const bool user_mode = !(curr->arch.flags & TF_kernel_mode);
 
 if ( user_mode )
-toggle_guest_mode(v);
+toggle_guest_mode(curr);
 
-guest_get_eff_l1e(addr, eff_l1e);
+guest_get_eff_l1e(linear, eff_l1e);
 
 if ( user_mode )
-toggle_guest_mode(v);
+toggle_guest_mode(curr);
 }
 
 static inline void page_set_tlbflush_timestamp(struct page_info *page)
@@ -676,7 +676,7 @@ int map_ldt_shadow_page(unsigned int off)
 
 if ( is_pv_32bit_domain(d) )
 gva = (u32)gva;
-guest_get_eff_kern_l1e(v, gva, &l1e);
+guest_get_eff_kern_l1e(gva, &l1e);
 if ( unlikely(!(l1e_get_flags(l1e) & _PAGE_PRESENT)) )
 return 0;
 
-- 
2.1.4


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

Re: [Xen-devel] [PATCH 11/27] xen/arm: Add FnV field in hsr_*abt

[Julien Grall]

On 08/22/2017 05:07 PM, Andre Przywara wrote:

Hi,


Hi Andre,


On 14/08/17 15:24, Julien Grall wrote:

FnV (FAR not Valid) bit was introduced by ARMv8 in both AArch32 and
AArch64 (See D7-2275, D7-2277, G6-4958, G6-4962 in ARM DDI 0487B.a).


I understand that this just prepares the data structures for patch #14,
but I was wondering if we should update the other fields on the way as
well, for instance there is now "ar" in Aarch32 also.


I didn't want to do it because hsr_dabt will get a bit messy for 
AArch32. For instance bit[10] has a different meaning depending on the 
value of DFSC.


So if you don't mind, I would stick on FnV for now and will add the 
others when we really need them :).


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 14/27] xen/arm: traps: Improve logging for data/prefetch abort fault

[Julien Grall]

On 08/22/2017 06:20 PM, Andre Przywara wrote:

Hi,


Hi Andre,



On 14/08/17 15:24, Julien Grall wrote:

Walk the hypervisor page table for data/prefetch abort fault to help
diagnostics error in the page tables.

Signed-off-by: Julien Grall 
---
  xen/arch/arm/traps.c | 19 +++
  1 file changed, 19 insertions(+)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 819bdbc69e..dac4e54fa7 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2967,7 +2967,26 @@ asmlinkage void do_trap_hyp_sync(struct cpu_user_regs 
*regs)
  do_trap_brk(regs, hsr);
  break;
  #endif
+case HSR_EC_DATA_ABORT_CURR_EL:
+case HSR_EC_INSTR_ABORT_CURR_EL:
+{
+bool is_data = (hsr.ec == HSR_EC_DATA_ABORT_CURR_EL);
+const char *fault = (is_data) ? "Data Abort" : "Instruction Abort";
+
+printk("%s Trap. Syndrome=%#x\n", fault, hsr.iss);
+/*
+ * FAR may not be valid for a Synchronous External abort other
+ * than translation table walk.
+ */
+if ( hsr.xabt.fsc != FSC_SEA || !hsr.xabt.fnv )


This is quite hard to read. Would the DeMorgan'ed version be better?
   if ( hsr.xabt.fsc == FSC_SEA && hsr.xabt.fnv )
   printk 
else
   dump_hyp_walk ...


Indeed it is better. I will use that.

Cheers,




+dump_hyp_walk(get_hfar(is_data));
+else
+printk("Invalid FAR, don't walk the hypervisor tables\n");


Nit: "not walking" sounds less ambiguous.


+do_unexpected_trap(fault, regs);
  
+break;

+}
  default:
  printk("Hypervisor Trap. HSR=0x%x EC=0x%x IL=%x 
Syndrome=0x%"PRIx32"\n",
 hsr.bits, hsr.ec, hsr.len, hsr.iss);


Ignoring the nits above:


I will fix both and keep the reviewed-by if you don't mind.


Reviewed-by: Andre Przywara 


Cheers,

--
Julien Grall

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

[Xen-devel] [xen-4.9-testing baseline-only test] 72007: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 72007 xen-4.9-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72007/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair 11 xen-boot/dst_host fail REGR. vs. 71979
 test-amd64-amd64-migrupgrade 10 xen-boot/src_host fail REGR. vs. 71979
 test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail REGR. vs. 
71979
 test-amd64-i386-xl-qemut-ws16-amd64 10 windows-installfail REGR. vs. 71979
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 
71979
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail REGR. vs. 
71979

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-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   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop   fail blocked in 71979
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail like 71979
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail like 71979
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail never pass
 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  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-xl-midway   13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   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-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  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-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-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 13 migrate-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-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-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

version targeted for testing:
 xen  9bf14bbf990843bfec16a5d69d36cf46c7593d88
baseline version:
 xen  0e186e33c0487a81c48dccdede206e63db22dd7d

Last test of basis71979  2017-08-16 03:50:15 Z7 days
Testing same since72007  2017-08-23 12:22:55 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 

jo

Re: [Xen-devel] [PATCH] x86: enable RCU based table free when PARAVIRT

[Kirill A. Shutemov]

On Wed, Aug 23, 2017 at 11:26:46AM -0700, Linus Torvalds wrote:
> On Wed, Aug 23, 2017 at 6:45 AM, Vitaly Kuznetsov  wrote:
> >
> > Solve the issue by enabling RCU-based table free mechanism when PARAVIRT
> > is selected in config. Testing with kernbench doesn't show any notable
> > performance impact:
> 
> I wonder if we should just make it unconditional if it doesn't really
> show any performance difference. One less config complexity to worry
> about (and in this case I'm not so much worried about Kconfig itself,
> as just "oh, you have totally different paths in the core VM depending
> on PARAVIRT".

In this case we need performance numbers for !PARAVIRT kernel.

> That said, the thing to test for these kinds of things is often
> heavily scripted loads that just run thousands and thousands of really
> small processes, and build up and tear down page tables all the time
> because of fork/exit.
> 
> The load I've used occasionally is just "make test" in the git source
> tree. Tons and tons of trivial fork/exec/exit things for all those
> small tests and shell scripts.

Numbers for tight loop of "mmap(MAP_POPULATE); munmap()" might be
interesting too for worst case scenario.

-- 
 Kirill A. Shutemov

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

[Xen-devel] [libvirt test] 112840: tolerable trouble: blocked/broken/pass - PUSHED

[osstest service owner]

flight 112840 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112840/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 build-arm64-xsm   2 hosts-allocate  broken like 112808
 build-arm64-pvops 2 hosts-allocate  broken like 112808
 build-arm64-xsm   3 capture-logsbroken like 112808
 build-arm64   2 hosts-allocate  broken like 112808
 build-arm64-pvops 3 capture-logsbroken like 112808
 build-arm64   3 capture-logsbroken like 112808
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112808
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112808
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112808
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-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-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  a530078cd2d7d9a47a6e96a64f70497fb7b2ff10
baseline version:
 libvirt  0f1993aa15f281b3812806e29df729149a5b64c6

Last test of basis   112808  2017-08-22 04:24:14 Z1 days
Testing same since   112840  2017-08-23 04:21:20 Z0 days1 attempts


People who touched revisions under test:
  Ján Tomko 
  Pavel Hrdina 

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



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

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

Explanation of these reports, and of osstest in general, is 

Re: [Xen-devel] [PATCH] x86: enable RCU based table free when PARAVIRT

[Linus Torvalds]

On Wed, Aug 23, 2017 at 12:59 PM, Kirill A. Shutemov
 wrote:
>
> In this case we need performance numbers for !PARAVIRT kernel.

Yes.

> Numbers for tight loop of "mmap(MAP_POPULATE); munmap()" might be
> interesting too for worst case scenario.

Actually, I don't think you want to populate all the pages. You just
want to populate *one* page, in order to build up the page directory
structure, not allocate all the final points.

And we only free the actual page tables when there is nothing around,
so it should be at least a 2MB-aligned region etc.

So you should do a *big* allocation, and then touch a single page in
the middle, and then minmap it - that should give you maximal page
table activity. Otherwise the page tables will generally just stay
around.

Realistically, it's mainly exit() that frees page tables. Yes, you may
have a few page tables free'd by a normal munmap(), but it's usually
very limited. Which is why I suggested that script-heavy thing with
lots of small executables. That tends to be the main realistic load
that really causes a ton of page directory activity.

  Linus

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

Re: [Xen-devel] [PATCH 1/1] xen-blkback: stop blkback thread of every queue in xen_blkif_disconnect

[Konrad Rzeszutek Wilk]

.snip..
> > 
> > Acked-by: Roger Pau Monné 
> 
> Forgot to add, this needs to be backported to stable branches, so:

Annie, could you resend the patch with the tags and an update
to the description to me please?
> 
> Cc: sta...@vger.kernel.org
> 
> Roger.
> 
> ___
> 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

[Xen-devel] [PATCH] xen: Don't try to call xen_alloc_p2m_entry() on autotranslating guests

[Boris Ostrovsky]

Commit aba831a69632 ("xen: remove tests for pvh mode in pure pv paths")
removed XENFEAT_auto_translated_physmap test in xen_alloc_p2m_entry()
since it is assumed that the routine is never called by non-PV guests.

However, alloc_xenballooned_pages() may make this call on a PVH guest.
Prevent this from happening by adding XENFEAT_auto_translated_physmap
check there.

Signed-off-by: Boris Ostrovsky 
Fixes: aba831a69632 ("xen: remove tests for pvh mode in pure pv paths")
---
 drivers/xen/balloon.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index ab60925..f77e499 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -664,9 +664,11 @@ int alloc_xenballooned_pages(int nr_pages, struct page 
**pages)
 */
BUILD_BUG_ON(XEN_PAGE_SIZE != PAGE_SIZE);
 
-   ret = xen_alloc_p2m_entry(page_to_pfn(page));
-   if (ret < 0)
-   goto out_undo;
+   if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+   ret = xen_alloc_p2m_entry(page_to_pfn(page));
+   if (ret < 0)
+   goto out_undo;
+   }
 #endif
} else {
ret = add_ballooned_pages(nr_pages - pgno);
-- 
1.8.3.1


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

Re: [Xen-devel] [PATCH] x86: enable RCU based table free when PARAVIRT

[Linus Torvalds]

On Wed, Aug 23, 2017 at 3:36 PM, Kirill A. Shutemov
 wrote:
>
> Below is test cases that allocates a lot of page tables and measuare
> fork/exit time. (I'm not entirely sure it's the best way to stress the
> codepath.)

Looks ok to me. Doing a profile (without the RCU freeing, obviously) gives me

   0.77%  a.out[kernel.vmlinux]  [k] free_pgd_range


  ▒

so it does seem to spend time in the page directory code.

> Unpatched:  average 4.8322s, stddev 0.114s
> Patched:average 4.8362s, stddev 0.111s

Ok, I vote for avoiding the complexity of two different behaviors, and
just making the page table freeing use RCU unconditionally.

If actively trying to trigger that code doesn't show a real measurable
difference, I don't think it matters, and the fewer different code
paths we have, the better.

  Linus

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

Re: [Xen-devel] [stage1-xen (RFC) PATCH 00/10] Add Fedora support

[Stefano Stabellini]

On Mon, 21 Aug 2017, Rajiv Ranganath wrote:
> Hi Stefanao,
> 
> Following series adds documentation on how to use stage1-xen on Fedora.
> It also adds continuous build support using CircleCI.
> 
> Xen, Qemu, rkt and stage1 ACI image are built using a Fedora based
> container. This setup allows for a reproducible build environment that
> we can use locally and also within a CI system.
> 
> Below is an overview of the series -
> 
> build/fedora: Add `buildroot-README.md`
> build/fedora: Add `buildroot-Dockerfile`
> build/fedora: Add `run`
> 
> `build/fedora` directory is introduced. In this directory we can
> maintain documentation, scripts and patches relating to Fedora support
> for stage1-xen.
> 
> `buildroot-README.md` describes a two stage container build process.
> This is modeled on how we do builds for distro packages, but using
> containers instead of a mock/chroot environment. The build artifact
> produced by `run` script is a tarball, instead of a rpm or deb file.
> 
> build/fedora: Add `source_path.sh`
> build/fedora: Add `xen-unstable-runit/*` scripts
> 
> Scripts used within build artifact tarball.
> 
> .circleci/config.yml: Add
> README.md: Add CircleCI badge
> 
> Adds CircleCI support. Here [1][2] is a temporary repo with Circle CI
> support enabled.
> 
> build/fedora: Add `RUNNING_STAGE1_XEN.md`
> BUILDING.md: Add Fedora instructions
> 
> Update docs.
> 
> Please let me know your comments. Thank you!
> 
> Best,
> Rajiv
> 
> [1]: https://github.com/lambda-linux-fedora/stage1-xen/tree/wip
> [2]: https://circleci.com/gh/lambda-linux-fedora/stage1-xen/tree/wip


Hi Rajiv,

Thank you very much for your work on this! From an high level, I think
it is very good.

One thing I would like to ask is that you make it just a bit more
modular. I think it is OK to use a Docker container for the build, but I
would like to support users that prefer to build on their own system by
calling build/fedora/run manually, the same script used by the Docker
container.

I don't think it would be a lot of effort to change the docs and the
script to allow that but it would be of great benefit.

I'll add more comments on the patches.

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

Re: [Xen-devel] [stage1-xen (RFC) PATCH 04/10] build/fedora: Add `run`

[Stefano Stabellini]

On Mon, 21 Aug 2017, Rajiv Ranganath wrote:
> From: Rajiv M Ranganath 

This is great, just a couple of comments. Please split it into two
scripts: one to build the dependecies (xen, qemu, etc.), and the other
to build stage1-xen. Of course, you could have one `run' script that
calls both scripts for convenience.

That way, a user could call the dependency builder once on her system,
then call the stage1-xen builder as many times as needed. The script
will be more reusable.

You won't like this final suggestion, but I'll try anyway :-) I would
prefer if this script was in bash. I have nothing against python (in
fact I know python better than other scripting languages) but I try to
minimize the number of languages required to contribute to stage1-xen.
But if it is python or nothing, I'll take python.


>  build/fedora/run |   87 
> ++
>  1 file changed, 87 insertions(+)
>  create mode 100755 build/fedora/run
> 
> diff --git a/build/fedora/run b/build/fedora/run
> new file mode 100755
> index 000..37e1dac
> --- /dev/null
> +++ b/build/fedora/run
> @@ -0,0 +1,87 @@
> +#!/usr/bin/python2
> +
> +import shlex
> +import subprocess
> +import sys
> +import os
> +
> +
> +# helper function to capture stdout from a long running process
> +def subprocess_stdout(cmd, cwd, env):
> +p = subprocess.Popen(
> +shlex.split(cmd), cwd=cwd, env=env, stdout=subprocess.PIPE)
> +while p.poll() is None:
> +l = p.stdout.readline()
> +sys.stdout.write(l)
> +
> +
> +env = os.environ.copy()
> +
> +# build and install xen-unstable
> +print "Cloning xen-unstable..."
> +cmd = 'git clone git://xenbits.xen.org/xen.git'
> +subprocess.check_output(shlex.split(cmd), cwd='/root')
> +
> +steps = [
> +'./configure --prefix=/opt/xen-unstable 
> --with-system-qemu=/opt/xen-unstable/lib/xen/bin/qemu-system-i386 
> --disable-stubdom --disable-qemu-traditional --disable-rombios 
> --sysconfdir=/opt/xen-unstable/etc --enable-rpath --disable-systemd',

I think it is fine to install things under /opt by default, but I would
like it to be configurable. A global variable at the top of the script
to set the destination directory is good enough.


> +'make',
> +'make install BOOT_DIR=/opt/xen-unstable/boot 
> DEBUG_DIR=/opt/xen-unstable/lib/debug 
> EFI_DIR=/opt/xen-unstable/boot/efi/EFI/xen'
> +]
> +for cmd in steps:
> +cwd = '/root/xen'
> +subprocess_stdout(cmd, cwd, env)
> +
> +# build and install qemu-unstable
> +print "Cloning qemu-unstable..."
> +cmd = 'git clone git://git.qemu.org/qemu.git'
> +subprocess.check_output(shlex.split(cmd), cwd='/root')
> +
> +steps = [
> +'./configure --prefix=/opt/qemu-unstable --enable-xen 
> --target-list=i386-softmmu --extra-cflags="-I/opt/xen-unstable/include" 
> --extra-ldflags="-L/opt/xen-unstable/lib -Wl,-rpath,/opt/xen-unstable/lib" 
> --disable-kvm --enable-virtfs --enable-linux-aio',
> +'make', 'make install'

Same here about the destination directory


> +]
> +for cmd in steps:
> +cwd = '/root/qemu'
> +subprocess_stdout(cmd, cwd, env)
> +
> +cmd = 'cp i386-softmmu/qemu-system-i386 
> /opt/xen-unstable/lib/xen/bin/qemu-system-i386'
> +subprocess.check_output(shlex.split(cmd), cwd='/root/qemu')
> +
> +# build rkt
> +print "Cloning rkt..."
> +cmd = 'git clone https://github.com/rkt/rkt.git'
> +subprocess.check_output(shlex.split(cmd), cwd='/root')
> +
> +steps = [
> +'./autogen.sh', './configure --disable-tpm --with-stage1-flavors=coreos',
> +'make'
> +]
> +for cmd in steps:
> +cwd = '/root/rkt'
> +subprocess_stdout(cmd, cwd, env)
> +
> +# build stage1-xen
> +env['GOPATH'] = '/root/gopath'
> +cwd = '/root/gopath/src/github.com/rkt/stage1-xen'
> +cmd = 'bash build.sh'
> +subprocess_stdout(cmd, cwd, env)
> +
> +# install build artifacts to `/opt/`
> +steps = [
> +'mkdir -p /opt/stage1-xen/bin', 'mkdir -p /opt/stage1-xen/aci',
> +'cp /root/rkt/build-rkt-1.28.1+git/target/bin/rkt 
> /opt/stage1-xen/bin/rkt',
> +'cp /root/gopath/src/github.com/rkt/stage1-xen/stage1-xen.aci 
> /opt/stage1-xen/aci/stage1-xen.aci',
> +'cp 
> /root/gopath/src/github.com/rkt/stage1-xen/build/fedora/source_path.sh 
> /opt/stage1-xen/bin/source_path.sh',
> +'cp -r 
> /root/gopath/src/github.com/rkt/stage1-xen/build/fedora/xen-unstable-runit 
> /opt/xen-unstable-runit'
> +]
> +for cmd in steps:
> +cwd = '/root'
> +subprocess_stdout(cmd, cwd, env)
> +
> +cwd = '/opt'
> +cmd = 'tar zcvf /root/stage1-xen-build.tar.gz qemu-unstable/ stage1-xen/ 
> xen-unstable/ xen-unstable-runit/'
> +subprocess_stdout(cmd, cwd, env)
> +
> +cwd = '/root'
> +cmd = 'mv /root/stage1-xen-build.tar.gz /tmp'
> +subprocess_stdout(cmd, cwd, env)
> 

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

Re: [Xen-devel] [stage1-xen (RFC) PATCH 02/10] build/fedora: Add `buildroot-README.md`

[Stefano Stabellini]

On Mon, 21 Aug 2017, Rajiv Ranganath wrote:
> From: Rajiv M Ranganath 

In addition to the instructions below, please mention how to build
stage1-xen manually by installing the dependencies listed in
buildroot-Dockerfile and executing build/fedora/run by hand.


>  build/fedora/buildroot-README.md |   50 
> ++
>  1 file changed, 50 insertions(+)
>  create mode 100644 build/fedora/buildroot-README.md
> 
> diff --git a/build/fedora/buildroot-README.md 
> b/build/fedora/buildroot-README.md
> new file mode 100644
> index 000..0efb150
> --- /dev/null
> +++ b/build/fedora/buildroot-README.md
> @@ -0,0 +1,50 @@
> +## stage1-xen Fedora Buildroot
> +
> +stage1-xen build artifacts for Fedora is built in two phases. In the first 
> phase
> +a docker container is prepared with all the build dependencies. We refer to 
> it
> +as `stage1-xen-fedora-buildroot`. In the next phase we execute the `run` 
> script
> +that uses `stage1-xen-fedora-buildroot` and to produce the build artifacts.
> +
> +### Building `stage1-xen-fedora-buildroot`
> +
> +`stage1-xen-fedora-buildroot` has a external dependency
> +on [`binutils`](https://github.com/lambda-linux-fedora/binutils) package 
> that is
> +compiled with `i386pe` support. You can download the pre-built RPMs
> +from [here](https://drive.google.com/open?id=0B_tTbuxmuRzIR05wQ3E1eWVyaGs).
> +Please download `binutils-2.26.1-1.1.fc25.tar`.
> +
> +To build docker image
> +
> +```
> +cd stage1-xen/build/fedora
> +
> +docker build -f buildroot-Dockerfile -t stage1-xen-fedora-buildroot .
> +```
> +
> +### Running `stage1-xen-fedora-buildroot`
> +
> +```
> +cd stage1-xen
> +
> +docker run --rm \
> +  -v `pwd`:/root/gopath/src/github.com/rkt/stage1-xen \
> +  -v /tmp:/tmp \
> +  -t -i stage1-xen-fedora-buildroot \
> +  /sbin/my_init -- /root/bin/run
> +```
> +
> +The generated build artifacts are in `/tmp` directory.
> +
> +To debug build issues -
> +
> +```
> +cd stage1-xen
> +
> +docker run --rm \
> +  -v `pwd`:/root/gopath/src/github.com/rkt/stage1-xen \
> +  -v /tmp:/tmp \
> +  -t -i stage1-xen-fedora-buildroot \
> +  /sbin/my_init -- /bin/bash
> +```
> +
> +Also see section on `ipdb` in `buildroot-Dockerfile`.
> 

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

Re: [Xen-devel] [stage1-xen (RFC) PATCH 07/10] .circleci/config.yml: Add

[Stefano Stabellini]

On Mon, 21 Aug 2017, Rajiv Ranganath wrote:
> From: Rajiv M Ranganath 

Does .circleci need to be in the top directory or could it be under
fedora? If possible, I think it would make more sense to introduce it
there.

> 
> ---
>  .circleci/config.yml |   21 +
>  1 file changed, 21 insertions(+)
>  create mode 100644 .circleci/config.yml
> 
> diff --git a/.circleci/config.yml b/.circleci/config.yml
> new file mode 100644
> index 000..67ac964
> --- /dev/null
> +++ b/.circleci/config.yml
> @@ -0,0 +1,21 @@
> +version: 2
> +jobs:
> +  build:
> +working_directory: /root
> +docker:
> +  - image: lambdalinuxfedora/stage1-xen-fedora-buildroot:1708171409
> +command: /sbin/my_init
> +steps:
> +  - run:
> +  # We create `stage1-xen` directory in Dockerfile for local dev
> +  # environment. Removing it here so CircleCI checkout step can work
> +  # correctly
> +  name: Removing stage1-xen directory from GOPATH...
> +  command: |
> +rm -rf /root/gopath/src/github.com/rkt/stage1-xen
> +  - checkout:
> +  path: /root/gopath/src/github.com/rkt/stage1-xen
> +  - run:
> +  name: Starting run...
> +  command: |
> +/root/bin/run
> 

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

Re: [Xen-devel] [stage1-xen (RFC) PATCH 08/10] README.md: Add CircleCI badge

[Stefano Stabellini]

On Mon, 21 Aug 2017, Rajiv Ranganath wrote:
> From: Rajiv M Ranganath 

Reviewed-by: Stefano Stabellini 

 
> ---
>  README.md |2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/README.md b/README.md
> index 9ea6adf..e1cd40c 100644
> --- a/README.md
> +++ b/README.md
> @@ -1,5 +1,7 @@
>  # stage1-xen - A Xen based stage1 for CoreOS rkt
>  
> +[![Build 
> Status](https://circleci.com/gh/rkt/stage1-xen/tree/master.svg?style=shield&circle-token=:circle-token)](https://circleci.com/gh/rkt/stage1-xen/tree/master)
> +
>  ## Goal
>  
>  CoreOS rkt is a modular container engine with [three stages of 
> execution](https://coreos.com/rkt/docs/latest/devel/stage1-implementors-guide.html).
>  Stage1 is responsible for creating the execution environment for the 
> contained applications.
> 

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

Re: [Xen-devel] [stage1-xen (RFC) PATCH 09/10] build/fedora: Add `RUNNING_STAGE1_XEN.md`

[Stefano Stabellini]

On Mon, 21 Aug 2017, Rajiv Ranganath wrote:

This is a great and well detailed document. I have a few suggestions
below to provide some info for people that wants to do it manually.


> ---
>  build/fedora/RUNNING_STAGE1_XEN.md |  383 
> 
>  1 file changed, 383 insertions(+)
>  create mode 100644 build/fedora/RUNNING_STAGE1_XEN.md
> 
> diff --git a/build/fedora/RUNNING_STAGE1_XEN.md 
> b/build/fedora/RUNNING_STAGE1_XEN.md
> new file mode 100644
> index 000..705e7e4
> --- /dev/null
> +++ b/build/fedora/RUNNING_STAGE1_XEN.md
> @@ -0,0 +1,383 @@
> +# Running Stage1 Xen on Fedora
> +
> +This document outlines the steps to get started with stage1-xen on Fedora. 
> They are –
> +
> + * [Preparing your machine and installing minimal 
> Fedora](#preparing_your_machine_and_installing_minimal_fedora)
> + * [Booting into Xen](#booting_into_xen)
> + * [Launching Xen services](#launching_xen_services)
> + * [Setting up Xen networking](#setting_up_xen_networking)
> + * [Running stage1-xen](#running_stage1-xen)
> +
> +
> +## Preparing your machine and installing minimal Fedora
> +
> +On x86 platform there are two ways to start an operating system or a 
> hypervisor. They are –
> +
> + * Legacy BIOS Mode
> + * EFI Mode
> +
> +Latest operating systems and hypervisors including Fedora and Xen has 
> support for EFI mode. If you are unfamiliar with EFI we recommend checking 
> out this [article](http://www.rodsbooks.com/efi-bootloaders/principles.html).
> +
> +By default, most BIOS now boot using EFI Mode. In your BIOS menu, there 
> might be an option to toggle _Legacy BIOS Mode_. Do not toggle that option.
> +
> +### Enable VT-x and VT-d
> +
> +Please ensure that you have enabled VT-x and if available VT-d.
> +
> +### Disable Secure Boot
> +
> +As we will be booting a custom build of Xen, we need to disable secure boot. 
> You will find an option in your BIOS menu to disable secure boot.
> +
> +### Installing minimal Fedora
> +
> +The default Fedora installation installs packages that we do not require 
> when running Xen. We recommend doing a minimal Fedora as follows.
> +
> + 1. Download Net Install image
> +
> + 2. Prepare a USB drive
> +
> + 3. Do a minimal Fedora Install
> +
> +You can download the Fedora net install image 
> [here](https://alt.fedoraproject.org/). You can select either the Fedora 
> Server or Fedora Workstation image, it doesn't really matter.
> +
> +After downloading the net install images, please copy the raw image onto a 
> USB drive. Please see 
> [this](https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Installation_Guide/sect-making-usb-media.html)
>  link on how to prepare USB drive.
> +
> +EFI BIOS comes with a _BIOS Boot Menu_ using which you can select the device 
> to boot from. Insert the USB drive, then go into your BIOS Boot Menu and boot 
> using the USB drive. This should start the Fedora Network Installer.
> +
> +In the Fedora Installer, there is a section for under _SOFTWARE_ called 
> _SOFTWARE SELECTION_. In this section please **select** either _Minimal 
> Install_ or _Basic Desktop_, **without** any add-ons. 
> +
> +**Note:** If there is existing data on the hard disk, please ensure that 
> _INSTALLATION DESTINATION_ under _SYSTEM_ section is appropriately 
> configured. 
> +
> +Then click on _Begin Installation_ to complete the installation.
> +
> +Once the installation is complete, please disable SELinux by editing 
> `/etc/selinux/config`.
> +
> +You now have a minimal Fedora Installation, which is good for working with 
> Xen.
> +
> +
> +## Booting into Xen
> +
> +Log into Fedora as root and copy over `stage1-xen-build.tar.gz`. Extract 
> `stage1-xen-build.tar.gz` into `/opt` directory.

The doc is good. As for other patches in this series, I spend a couple
of words on the build without a Docker container. In this case, I would
say:

  "Build and Install Xen and stage1-xen. Please see buildroot-README.md on
  how to do it. If you follow the automatic build with Docker, then copy
  over `stage1-xen-build.tar.gz`. Extract `stage1-xen-build.tar.gz` into
  `/opt` directory."


> +```shell
> +[root@localhost ~]# tar zxvf stage1-xen-build.tar.gz -C /opt
> +
> +[root@localhost ~]# ls /opt
> +qemu-unstable  stage1-xen  xen-unstable  xen-unstable-runit
> +```
> +
> +This will extract all the build artifacts into `/opt` directory.
> +
> +Next we will create a BIOS Boot Menu entry to boot `xen-4.10-unstable.efi`. 
> This will start Xen hypervisor. Xen will then start Fedora as Dom-0 guest.
> +
> +On Fedora, EFI system partition (ESP) is usually mounted at `/boot/efi`. 
> This is a `vfat` partition. You can check if EFI system partition is mounted 
> as follows –
> +
> +```shell
> +[root@localhost ~]# mount | grep '\/boot\/efi'
> +/dev/sda1 on /boot/efi type vfat 
> (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro)
> +```
> +
> +Create a directory for Xen under `/boot/efi/

Re: [Xen-devel] [stage1-xen (RFC) PATCH 10/10] BUILDING.md: Add Fedora instructions

[Stefano Stabellini]

On Mon, 21 Aug 2017, Rajiv Ranganath wrote:
> ---
>  BUILDING.md |   35 ++-
>  1 file changed, 30 insertions(+), 5 deletions(-)
> 
> diff --git a/BUILDING.md b/BUILDING.md
> index 3ef5311..b9ca404 100644
> --- a/BUILDING.md
> +++ b/BUILDING.md
> @@ -1,7 +1,13 @@
>  # Build
> -stage1-xen requires new Xen and QEMU versions at the time of writing. You 
> are unlikely to find them already packaged with your distro. This document 
> describes how to build and install the latest Xen and QEMU from scratch. In 
> addition, given that CoreOS rkt is also missing from reasonably new distros 
> such as Ubuntu Xenial Xerus, I added instructions on how to build that too. 
> The document includes the dependencies needed for the build based on Ubuntu 
> Xenial Xerus.
> +stage1-xen requires new Xen and QEMU versions at the time of writing. You 
> are unlikely to find them already packaged with your distro. This document 
> describes how to build and install the latest Xen, QEMU and rkt from scratch 
> for Ubuntu Xenial Xerus and Fedora.

I would clarify that the build and installation method for Ubuntu and
the one for Fedora use very different approaches. I would add:

  ... "for Ubuntu Xenial Xerus and Fedora. Differently from the
  documentation for Ubuntu, the documentation for Fedora uses a separate
  Docker container for the build."


> -## Building Xen
> + * [Ubuntu Xenial Xerus](#build_ubuntu)
> + * [Fedora](#build_fedora)

  [Fedora via container]



> +
> +## Ubuntu Xenial Xerus
> +
> +### Building Xen
>  ```
>  apt-get install git build-essential python-dev gettext uuid-dev 
> libncurses5-dev libyajl-dev libaio-dev pkg-config libglib2.0-dev libssl-dev 
> libpixman-1-dev bridge-utils wget libfdt-dev bin86 bcc liblzma-dev iasl 
> libc6-dev-i386
>  
> @@ -17,7 +23,7 @@ reboot
>  Make sure to select Xen at boot, or edit /boot/grub/grub.cfg to make it the 
> default, changing "set default="0" to point to the appropriate entry below 
> (the one booting xen.gz), which could be entry number "4" for example.
>  
>  
> -## Building QEMU
> +### Building QEMU
>  ```
>  apt-get install libglib2.0-dev libpixman-1-dev libcap-dev libattr1-dev
>  
> @@ -54,7 +60,7 @@ make install
>  cp i386-softmmu/qemu-system-i386 /usr/lib/xen/bin/
>  ```
>  
> -## Building CoreOS rkt
> +### Building CoreOS rkt
>  ```
>  apt-get install golang automake libacl1-dev libsystemd-dev
>  ./configure --disable-tpm --with-stage1-flavors=coreos
> @@ -62,7 +68,7 @@ make
>  cp build-rkt-1.26.0+git/target/bin/rkt /usr/sbin
>  ```
>  
> -## Building stage1-xen
> +### Building stage1-xen
>  ```
>  apt-get install busybox-static jq
>  
> @@ -72,3 +78,22 @@ export GOPATH=/path/to/gopath
>  bash build.sh
>  cp stage1-xen.aci /home/username
>  ```
> +
> +
> +## Fedora
> +
> +On Fedora we build stage1-xen artifacts (Xen, QEMU and rkt) in a docker 
> container as follows –
> +
> +```
> +cd stage1-xen
> +
> +docker pull lambdalinuxfedora/stage1-xen-fedora-buildroot
> +
> +docker run --rm \
> +  -v `pwd`:/root/gopath/src/github.com/rkt/stage1-xen \
> +  -v /tmp:/tmp \
> +  -t -i lambdalinuxfedora/stage1-xen-fedora-buildroot \
> +  /sbin/my_init -- /root/bin/run
> +```
> +
> +Once `docker run` completes, the build artifact `stage1-xen-build.tar.gz` is 
> generated in `/tmp` directory. Please see 
> [RUNNING_STAGE1_XEN.md](build/fedora/RUNNING_STAGE1_XEN.md) for details on 
> how to setup Fedora for running stage1-xen.

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

Re: [Xen-devel] [stage1-xen (RFC) PATCH 06/10] build/fedora: Add `xen-unstable-runit/*` scripts

[Stefano Stabellini]

On Mon, 21 Aug 2017, Rajiv Ranganath wrote:
> From: Rajiv M Ranganath 
> 
> 
> ---
>  build/fedora/xen-unstable-runit/setup.sh   |   21 
> 
>  build/fedora/xen-unstable-runit/teardown.sh|   21 
> 
>  .../xen-init-dom0-disk-backend/run |8 
>  build/fedora/xen-unstable-runit/xen-init-dom0/run  |6 ++
>  build/fedora/xen-unstable-runit/xenconsoled/run|   10 ++
>  build/fedora/xen-unstable-runit/xenstored/run  |   20 +++
>  6 files changed, 86 insertions(+)
>  create mode 100755 build/fedora/xen-unstable-runit/setup.sh
>  create mode 100755 build/fedora/xen-unstable-runit/teardown.sh
>  create mode 100755 
> build/fedora/xen-unstable-runit/xen-init-dom0-disk-backend/run
>  create mode 100755 build/fedora/xen-unstable-runit/xen-init-dom0/run
>  create mode 100755 build/fedora/xen-unstable-runit/xenconsoled/run
>  create mode 100755 build/fedora/xen-unstable-runit/xenstored/run
> 
> diff --git a/build/fedora/xen-unstable-runit/setup.sh 
> b/build/fedora/xen-unstable-runit/setup.sh
> new file mode 100755
> index 000..16699be
> --- /dev/null
> +++ b/build/fedora/xen-unstable-runit/setup.sh
> @@ -0,0 +1,21 @@
> +#!/bin/bash
> +
> +set -e
> +set -o pipefail

In most of my script I tend not to use pipefail because if I use a pipe
is exactly because one of the commands might fail. I do it on purpose.
This script doesn't even have any pipes, I would drop it.


> +# runit RPM creates `/etc/service` directory
> +if [ ! -d "/etc/service" ]; then
> +echo "/etc/service directory not found. Please install runit RPM."
> +exit 1
> +fi
> +
> +runit_services="xenconsoled xen-init-dom0 xen-init-dom0-disk-backend 
> xenstored"
> +
> +pushd /etc/service > /dev/null
> +for service in $runit_services; do
> +ln -sf /opt/xen-unstable-runit/$service $service
> +done
> +popd > /dev/null

pushd and popd are not useful in this script, I would remove them


> +echo "Successfully created symlinks in /etc/service directory."
> +exit 0
> diff --git a/build/fedora/xen-unstable-runit/teardown.sh 
> b/build/fedora/xen-unstable-runit/teardown.sh
> new file mode 100755
> index 000..c0895f4
> --- /dev/null
> +++ b/build/fedora/xen-unstable-runit/teardown.sh
> @@ -0,0 +1,21 @@
> +#!/bin/bash
> +
> +set -e
> +set -o pipefail

same comment on pipefail


> +# runit RPM creates `/etc/service` directory
> +if [ ! -d "/etc/service" ]; then
> +echo "/etc/service directory not found."
> +exit 1
> +fi
> +
> +runit_services="xenconsoled xen-init-dom0 xen-init-dom0-disk-backend 
> xenstored"
> +
> +pushd /etc/service > /dev/null
> +for service in $runit_services; do
> +rm -f $service
> +done
> +popd > /dev/null

same comment on pushd and popd


> +echo "Successfully deleted symlinks in /etc/service directory."
> +exit 0
> diff --git a/build/fedora/xen-unstable-runit/xen-init-dom0-disk-backend/run 
> b/build/fedora/xen-unstable-runit/xen-init-dom0-disk-backend/run
> new file mode 100755
> index 000..a952890
> --- /dev/null
> +++ b/build/fedora/xen-unstable-runit/xen-init-dom0-disk-backend/run
> @@ -0,0 +1,8 @@
> +#!/bin/sh

Why /bin/sh instead of bash? The container should have bash installed,
right?

If we are using bash, I would consider adding a set -e, also in the
other sh scripts below.


> +sv check xenstored >/dev/null || exit 1
> +sv check xenconsoled >/dev/null || exit 1
> +
> +# In case of failure, allow user to run teardown script
> +sleep 5s
> +
> +exec /opt/xen-unstable/lib/xen/bin/qemu-system-i386 -xen-domid 0 -xen-attach 
> -name dom0 -nographic -M xenpv -monitor /dev/null -serial /dev/null -parallel 
> /dev/null -nodefaults -no-user-config
> diff --git a/build/fedora/xen-unstable-runit/xen-init-dom0/run 
> b/build/fedora/xen-unstable-runit/xen-init-dom0/run
> new file mode 100755
> index 000..f7f56ed
> --- /dev/null
> +++ b/build/fedora/xen-unstable-runit/xen-init-dom0/run
> @@ -0,0 +1,6 @@
> +#!/bin/sh
> +sv check xenstored >/dev/null || exit 1
> +
> +/opt/xen-unstable/lib/xen/bin/xen-init-dom0
> +
> +exec chpst -b xen-init-dom0 runit-pause
> diff --git a/build/fedora/xen-unstable-runit/xenconsoled/run 
> b/build/fedora/xen-unstable-runit/xenconsoled/run
> new file mode 100755
> index 000..7a3ab4e
> --- /dev/null
> +++ b/build/fedora/xen-unstable-runit/xenconsoled/run
> @@ -0,0 +1,10 @@
> +#!/bin/sh
> +sv check xen-init-dom0 >/dev/null || exit 1
> +
> +[ ! -d /var/log/xen/console ] && mkdir -p /var/log/xen/console
> +
> +# In case of failure, allow user to run teardown script
> +sleep 5s
> +
> +# --log=[none|guest|hv|all]
> +exec /opt/xen-unstable/sbin/xenconsoled -i --log=none
> diff --git a/build/fedora/xen-unstable-runit/xenstored/run 
> b/build/fedora/xen-unstable-runit/xenstored/run
> new file mode 100755
> index 000..42e5e41
> --- /dev/null
> +++ b/build/fedora/xen-unstable-runit/xenstored/run
> @@ -0,0 +1,20 @@
> +#!/bin/sh
> +[ ! -d /var/run/xen ] && mkdir -p /var/run/x

Re: [Xen-devel] [PATCH 4/6] xsm: flask: change the interface and default policy for xsm_map_gmfn_foregin

[Zhongze Liu]

Hi Jan,

Thanks for reviewing my patch.

2017-08-23 17:55 GMT+08:00 Jan Beulich :
 On 22.08.17 at 20:08,  wrote:
>> The original xsm_map_gmfn_foregin policy 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, this restricts some useful yet 
>> not
>> dangerous usages of the API, such as sharing pages among DomU's by calling
>> XENMEM_add_to_physmap from Dom0.
>>
>> Change the policy to: IIF current domain has the proper privilege on the
>> target domain and source domain, grant the access.
>
> You say "and here", yet ...
>
>> --- a/xen/include/xsm/dummy.h
>> +++ b/xen/include/xsm/dummy.h
>> @@ -525,10 +525,12 @@ static XSM_INLINE int 
>> xsm_remove_from_physmap(XSM_DEFAULT_ARG struct domain *d1,
>>  return xsm_default_action(action, d1, d2);
>>  }
>>
>> -static XSM_INLINE int xsm_map_gmfn_foreign(XSM_DEFAULT_ARG struct domain 
>> *d, struct domain *t)
>> +static XSM_INLINE int xsm_map_gmfn_foreign(XSM_DEFAULT_ARG struct domain 
>> *cd,
>> +   struct domain *d, struct domain 
>> *t)
>>  {
>>  XSM_ASSERT_ACTION(XSM_TARGET);
>> -return xsm_default_action(action, d, t);
>> +return xsm_default_action(action, cd, d) ||
>> +xsm_default_action(action, cd, t);
>>  }
>
> ... you use "or" here and ...

This might be confusing. But think of returning 0 as "allowed", the
only condition where this
statement returns a 0 is when both calls return 0 -- so it's actually
an "and". (Think of de-morgan's law.)

But as Stefano has pointed out, I should preserve the error code.
And as Daniel has pointed out, I should also check if d and t can share memory.

>
>> --- a/xen/xsm/flask/hooks.c
>> +++ b/xen/xsm/flask/hooks.c
>> @@ -1165,9 +1165,11 @@ static int flask_remove_from_physmap(struct domain 
>> *d1, struct domain *d2)
>>  return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
>>  }
>>
>> -static int flask_map_gmfn_foreign(struct domain *d, struct domain *t)
>> +static int flask_map_gmfn_foreign(struct domain *cd,
>> +  struct domain *d, struct domain *t)
>>  {
>> -return domain_has_perm(d, t, SECCLASS_MMU, MMU__MAP_READ | 
>> MMU__MAP_WRITE);
>> +return domain_has_perm(cd, d, SECCLASS_MMU, MMU__MAP_READ | 
>> MMU__MAP_WRITE) ||
>> +domain_has_perm(cd, t, SECCLASS_MMU, MMU__MAP_READ | 
>> MMU__MAP_WRITE);
>>  }
>
> ... here. A domain can't have XSM_TARGET permission over two
> other domains, so what you want to do here can't work at all,
> afaict.

I agree with what Stefano has said below.

Cheers,

Zhongze Liu.

>
> Jan
>

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

[Xen-devel] [ovmf baseline-only test] 72009: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 72009 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72009/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 27ee96701a9495644aefae3690ca6849a79f7631
baseline version:
 ovmf bb3d1a6198cc5a8f2672927295c9f8d5ede9187c

Last test of basis72003  2017-08-22 08:20:08 Z1 days
Testing same since72009  2017-08-23 16:28:34 Z0 days1 attempts


People who touched revisions under test:
  Jiaxin Wu 
  Wu Jiaxin 

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



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

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


Push not applicable.


commit 27ee96701a9495644aefae3690ca6849a79f7631
Author: Jiaxin Wu 
Date:   Fri Aug 18 10:50:59 2017 +0800

MdeModulePkg/Library: Remove the self-reference in UdpIoLib/TcpIoLib/IpIoLib

Cc: Ye Ting 
Cc: Fu Siyuan 
Cc: Shao Ming 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
Reviewed-by: Fu Siyuan 

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

[Xen-devel] [linux-linus test] 112834: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-examine  7 reboot   fail REGR. vs. 110515
 test-amd64-amd64-i386-pvgrub  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-libvirt  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-qemuu-nested-intel  7 xen-boot  fail REGR. vs. 110515
 test-amd64-amd64-amd64-pvgrub  7 xen-bootfail REGR. vs. 110515
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
110515
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. 
vs. 110515
 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host   fail REGR. vs. 110515
 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host   fail REGR. vs. 110515
 test-amd64-amd64-libvirt-vhd  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-libvirt-xsm  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-qemut-debianhvm-amd64  7 xen-bootfail REGR. vs. 110515
 test-amd64-amd64-xl-xsm   7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-pvh-intel  7 xen-bootfail REGR. vs. 110515
 test-amd64-amd64-rumprun-amd64  7 xen-boot   fail REGR. vs. 110515
 test-amd64-amd64-pygrub   7 xen-boot fail REGR. vs. 110515
 test-amd64-i386-libvirt  10 debian-install   fail REGR. vs. 110515
 test-amd64-i386-pair 16 debian-install/dst_host  fail REGR. vs. 110515
 test-amd64-amd64-xl-multivcpu 10 debian-install  fail REGR. vs. 110515
 test-amd64-amd64-xl-credit2  10 debian-install   fail REGR. vs. 110515
 test-amd64-i386-xl   10 debian-install   fail REGR. vs. 110515
 test-amd64-i386-libvirt-xsm  10 debian-install   fail REGR. vs. 110515
 test-amd64-i386-libvirt-pair 16 debian-install/dst_host  fail REGR. vs. 110515
 test-amd64-i386-xl-xsm   10 debian-install   fail REGR. vs. 110515
 test-amd64-amd64-xl-pvh-amd  10 debian-install   fail REGR. vs. 110515
 test-armhf-armhf-libvirt-xsm 10 debian-install   fail REGR. vs. 110515
 test-armhf-armhf-libvirt 10 debian-install   fail REGR. vs. 110515
 test-armhf-armhf-xl-cubietruck 10 debian-install fail REGR. vs. 110515
 test-armhf-armhf-xl-multivcpu 10 debian-install  fail REGR. vs. 110515
 test-armhf-armhf-xl-xsm  10 debian-install   fail REGR. vs. 110515
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
110515
 test-amd64-amd64-xl   7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 110515
 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 110515
 test-armhf-armhf-xl  10 debian-install   fail REGR. vs. 110515
 test-armhf-armhf-xl-arndale  10 debian-install   fail REGR. vs. 110515
 test-armhf-armhf-xl-credit2  10 debian-install   fail REGR. vs. 110515

Regressions which are regarded as allowable (not blocking):
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 110515
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 110515
 build-arm64   2 hosts-allocate broken REGR. vs. 110515
 test-armhf-armhf-xl-rtds 10 debian-install   fail REGR. vs. 110515

Tests which did not succeed, but are not blocking:
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   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-pvops 3 capture-logs  broken blocked in 110515
 build-arm64-xsm   3 capture-logs  broken blocked in 110515
 build-arm64   3 capture-logs  broken blocked in 110515
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail blocked in 
110515
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 110515
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 110515
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 110515
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd

[Xen-devel] [xen-4.6-testing baseline-only test] 72008: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 72008 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72008/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install 
fail REGR. vs. 71984
 test-armhf-armhf-xl-midway   12 guest-start   fail REGR. vs. 71984
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. 
vs. 71984
 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-installfail REGR. vs. 71984
 test-amd64-i386-qemut-rhel6hvm-intel 15 leak-check/check  fail REGR. vs. 71984
 test-amd64-amd64-libvirt-xsm 18 guest-start/debian.repeat fail REGR. vs. 71984
 test-amd64-i386-xl-qemut-ws16-amd64 10 windows-installfail REGR. vs. 71984
 test-amd64-amd64-xl-qemuu-win10-i386 16 guest-localmigrate/x10 fail REGR. vs. 
71984
 test-amd64-i386-xl-raw   10 debian-di-install fail REGR. vs. 71984
 test-amd64-i386-xl-qemuu-debianhvm-amd64 19 guest-start.2 fail REGR. vs. 71984
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-installfail REGR. vs. 71984

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-ovmf-amd64 14 guest-localmigrate fail REGR. vs. 71984

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-1   21 xtf/test-hvm32-invlpg~shadow fail   like 71984
 test-xtf-amd64-amd64-1  35 xtf/test-hvm32pae-invlpg~shadow fail like 71984
 test-xtf-amd64-amd64-3   21 xtf/test-hvm32-invlpg~shadow fail   like 71984
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   like 71984
 test-xtf-amd64-amd64-1   47 xtf/test-hvm64-invlpg~shadow fail   like 71984
 test-xtf-amd64-amd64-3  35 xtf/test-hvm32pae-invlpg~shadow fail like 71984
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   like 71984
 test-xtf-amd64-amd64-3   47 xtf/test-hvm64-invlpg~shadow fail   like 71984
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   like 71984
 test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail like 71984
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 71984
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 71984
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 71984
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-xtf-amd64-amd64-5   70 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-xtf-amd64-amd64-4   70 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-pvh-intel 15 guest-saverestorefail  never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-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-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-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-2   70 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-1   70 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-3   70 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-amd64-xl-pvh-amd  12 guest-start  fail   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 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-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-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd

[Xen-devel] [PATCH v2 05/15] x86: implement get hw info flow for MBA

[Yi Sun]

This patch implements get HW info flow for MBA including its callback
function and sysctl interface.

Signed-off-by: Yi Sun 
---
v2:
- use 'XEN_SYSCTL_PSR_MBA_LINEAR' to set MBA feature HW info.
  (suggested by Chao Peng)
v1:
- sort 'PSR_INFO_IDX_' macros as feature.
  (suggested by Chao Peng)
- rename 'PSR_INFO_IDX_MBA_LINEAR' to 'PSR_INFO_IDX_MBA_FLAG'.
- rename 'linear' in 'struct mba_info' to 'flags' for future extension.
  (suggested by Chao Peng)
---
 xen/arch/x86/psr.c  | 17 -
 xen/arch/x86/sysctl.c   | 19 +++
 xen/include/asm-x86/psr.h   |  2 ++
 xen/include/public/sysctl.h |  8 
 4 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index f5e99ce..4a0c982 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -264,6 +264,10 @@ static enum psr_feat_type psr_val_type_to_feat_type(enum 
psr_val_type type)
 feat_type = FEAT_TYPE_L2_CAT;
 break;
 
+case PSR_VAL_TYPE_MBA:
+feat_type = FEAT_TYPE_MBA;
+break;
+
 default:
 ASSERT_UNREACHABLE();
 }
@@ -493,7 +497,18 @@ static const struct feat_props l2_cat_props = {
 static bool mba_get_feat_info(const struct feat_node *feat,
   uint32_t data[], unsigned int array_len)
 {
-return false;
+if ( array_len != PSR_INFO_ARRAY_SIZE )
+return false;
+
+data[PSR_INFO_IDX_COS_MAX] = feat->cos_max;
+data[PSR_INFO_IDX_MBA_THRTL_MAX] = feat->mba_info.thrtl_max;
+
+if ( feat->mba_info.linear )
+data[PSR_INFO_IDX_MBA_FLAG] |= XEN_SYSCTL_PSR_MBA_LINEAR;
+else
+data[PSR_INFO_IDX_MBA_FLAG] &= ~XEN_SYSCTL_PSR_MBA_LINEAR;
+
+return true;
 }
 
 static void mba_write_msr(unsigned int cos, uint32_t val,
diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
index df54d38..cbab85a 100644
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -214,6 +214,25 @@ long arch_do_sysctl(
 break;
 }
 
+case XEN_SYSCTL_PSR_MBA_get_info:
+{
+ret = psr_get_info(sysctl->u.psr_alloc_op.target,
+   PSR_VAL_TYPE_MBA, data, ARRAY_SIZE(data));
+if ( ret )
+break;
+
+sysctl->u.psr_alloc_op.u.mba_info.cos_max =
+  data[PSR_INFO_IDX_COS_MAX];
+sysctl->u.psr_alloc_op.u.mba_info.thrtl_max =
+  data[PSR_INFO_IDX_MBA_THRTL_MAX];
+sysctl->u.psr_alloc_op.u.mba_info.flags =
+  data[PSR_INFO_IDX_MBA_FLAG];
+
+if ( !ret && __copy_field_to_guest(u_sysctl, sysctl, 
u.psr_alloc_op) )
+ret = -EFAULT;
+break;
+}
+
 default:
 ret = -EOPNOTSUPP;
 break;
diff --git a/xen/include/asm-x86/psr.h b/xen/include/asm-x86/psr.h
index 10043ac..a7fb625 100644
--- a/xen/include/asm-x86/psr.h
+++ b/xen/include/asm-x86/psr.h
@@ -39,6 +39,8 @@
 #define PSR_INFO_IDX_COS_MAX0
 #define PSR_INFO_IDX_CAT_CBM_LEN1
 #define PSR_INFO_IDX_CAT_FLAG   2
+#define PSR_INFO_IDX_MBA_THRTL_MAX  1
+#define PSR_INFO_IDX_MBA_FLAG   2
 #define PSR_INFO_ARRAY_SIZE 3
 
 struct psr_cmt_l3 {
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index fcebab1..169e7e6 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -745,6 +745,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_sysctl_pcitopoinfo_t);
 
 #define XEN_SYSCTL_PSR_CAT_get_l3_info   0
 #define XEN_SYSCTL_PSR_CAT_get_l2_info   1
+#define XEN_SYSCTL_PSR_MBA_get_info  2
 struct xen_sysctl_psr_alloc_op {
 uint32_t cmd;   /* IN: XEN_SYSCTL_PSR_CAT_* */
 uint32_t target;/* IN */
@@ -755,6 +756,13 @@ struct xen_sysctl_psr_alloc_op {
 #define XEN_SYSCTL_PSR_CAT_L3_CDP   (1u << 0)
 uint32_t flags; /* OUT: CAT flags */
 } cat_info;
+
+struct {
+uint32_t thrtl_max; /* OUT: Maximum throttle */
+uint32_t cos_max;   /* OUT: Maximum COS */
+#define XEN_SYSCTL_PSR_MBA_LINEAR  (1u << 0)
+uint32_t flags; /* OUT: MBA flags */
+} mba_info;
 } u;
 };
 typedef struct xen_sysctl_psr_alloc_op xen_sysctl_psr_alloc_op_t;
-- 
1.9.1


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

[Xen-devel] [PATCH v2 09/15] tools: implement the new libxc get hw info interface

[Yi Sun]

This patch implements a new libxc get hw info interface and corresponding
data structures. It also changes libxl_psr.c to call this new interface.

Signed-off-by: Yi Sun 
---
v2:
- split this patch out from a big patch in v1.
  (suggested by Wei Liu)
- change 'CAT_INFO' and 'MBA_INFO' to 'CAT' and 'MBA'.
  (suggested by Chao Peng)
---
 tools/libxc/include/xenctrl.h | 30 +---
 tools/libxc/xc_psr.c  | 46 ---
 tools/libxl/libxl_psr.c   | 34 ++--
 3 files changed, 93 insertions(+), 17 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index c7710b8..81a6f48 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2458,6 +2458,31 @@ enum xc_psr_cat_type {
 };
 typedef enum xc_psr_cat_type xc_psr_cat_type;
 
+enum xc_psr_feat_type {
+XC_PSR_FEAT_UNKNOWN,
+XC_PSR_FEAT_CAT_L3,
+XC_PSR_FEAT_CAT_L2,
+XC_PSR_FEAT_MBA,
+};
+typedef enum xc_psr_feat_type xc_psr_feat_type;
+
+struct xc_psr_hw_info {
+union {
+struct {
+uint32_t cos_max;
+uint32_t cbm_len;
+bool cdp_enabled;
+} xc_cat_info;
+
+struct {
+uint32_t cos_max;
+uint32_t thrtl_max;
+bool linear;
+} xc_mba_info;
+} u;
+};
+typedef struct xc_psr_hw_info xc_psr_hw_info;
+
 int xc_psr_cmt_attach(xc_interface *xch, uint32_t domid);
 int xc_psr_cmt_detach(xc_interface *xch, uint32_t domid);
 int xc_psr_cmt_get_domain_rmid(xc_interface *xch, uint32_t domid,
@@ -2479,9 +2504,8 @@ int xc_psr_cat_set_domain_data(xc_interface *xch, 
uint32_t domid,
 int xc_psr_cat_get_domain_data(xc_interface *xch, uint32_t domid,
xc_psr_cat_type type, uint32_t target,
uint64_t *data);
-int xc_psr_cat_get_info(xc_interface *xch, uint32_t socket, unsigned int lvl,
-uint32_t *cos_max, uint32_t *cbm_len,
-bool *cdp_enabled);
+int xc_psr_get_hw_info(xc_interface *xch, uint32_t socket,
+   xc_psr_feat_type type, xc_psr_hw_info *hw_info);
 
 int xc_get_cpu_levelling_caps(xc_interface *xch, uint32_t *caps);
 int xc_get_cpu_featureset(xc_interface *xch, uint32_t index,
diff --git a/tools/libxc/xc_psr.c b/tools/libxc/xc_psr.c
index 73d05f2..ba412e4 100644
--- a/tools/libxc/xc_psr.c
+++ b/tools/libxc/xc_psr.c
@@ -323,36 +323,58 @@ int xc_psr_cat_get_domain_data(xc_interface *xch, 
uint32_t domid,
 return rc;
 }
 
-int xc_psr_cat_get_info(xc_interface *xch, uint32_t socket, unsigned int lvl,
-uint32_t *cos_max, uint32_t *cbm_len, bool 
*cdp_enabled)
+int xc_psr_get_hw_info(xc_interface *xch, uint32_t socket,
+   xc_psr_feat_type type, xc_psr_hw_info *hw_info)
 {
 int rc = -1;
 DECLARE_SYSCTL;
 
+if ( !hw_info )
+return rc;
+
 sysctl.cmd = XEN_SYSCTL_psr_alloc_op;
 sysctl.u.psr_alloc_op.target = socket;
 
-switch ( lvl )
+switch ( type )
 {
-case 2:
+case XC_PSR_FEAT_CAT_L2:
 sysctl.u.psr_alloc_op.cmd = XEN_SYSCTL_PSR_CAT_get_l2_info;
 rc = xc_sysctl(xch, &sysctl);
 if ( !rc )
 {
-*cos_max = sysctl.u.psr_alloc_op.u.cat_info.cos_max;
-*cbm_len = sysctl.u.psr_alloc_op.u.cat_info.cbm_len;
-*cdp_enabled = false;
+hw_info->u.xc_cat_info.cos_max =
+sysctl.u.psr_alloc_op.u.cat_info.cos_max;
+hw_info->u.xc_cat_info.cbm_len =
+sysctl.u.psr_alloc_op.u.cat_info.cbm_len;
+hw_info->u.xc_cat_info.cdp_enabled = false;
 }
 break;
-case 3:
+case XC_PSR_FEAT_CAT_L3:
 sysctl.u.psr_alloc_op.cmd = XEN_SYSCTL_PSR_CAT_get_l3_info;
 rc = xc_sysctl(xch, &sysctl);
 if ( !rc )
 {
-*cos_max = sysctl.u.psr_alloc_op.u.cat_info.cos_max;
-*cbm_len = sysctl.u.psr_alloc_op.u.cat_info.cbm_len;
-*cdp_enabled = sysctl.u.psr_alloc_op.u.cat_info.flags &
-   XEN_SYSCTL_PSR_CAT_L3_CDP;
+hw_info->u.xc_cat_info.cos_max =
+sysctl.u.psr_alloc_op.u.cat_info.cos_max;
+hw_info->u.xc_cat_info.cbm_len =
+sysctl.u.psr_alloc_op.u.cat_info.cbm_len;
+hw_info->u.xc_cat_info.cdp_enabled =
+sysctl.u.psr_alloc_op.u.cat_info.flags &
+XEN_SYSCTL_PSR_CAT_L3_CDP;
+}
+break;
+case XC_PSR_FEAT_MBA:
+sysctl.u.psr_alloc_op.cmd = XEN_SYSCTL_PSR_MBA_get_info;
+rc = xc_sysctl(xch, &sysctl);
+if ( !rc )
+{
+hw_info->u.xc_mba_info.cos_max =
+sysctl.u.psr_alloc_op.u.mba_info.cos_max;
+hw_info->u.xc_mba_info.thrtl_max =
+   

[Xen-devel] [PATCH v2 06/15] x86: implement get value interface for MBA

[Yi Sun]

This patch implements get value domctl interface for MBA.

Signed-off-by: Yi Sun 
---
 xen/arch/x86/domctl.c   | 7 +++
 xen/include/public/domctl.h | 1 +
 2 files changed, 8 insertions(+)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index e1c7c70..4936bcb 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1496,6 +1496,13 @@ long arch_do_domctl(
 copyback = true;
 break;
 
+case XEN_DOMCTL_PSR_MBA_OP_GET_THRTL:
+ret = psr_get_val(d, domctl->u.psr_alloc_op.target,
+  &val32, PSR_VAL_TYPE_MBA);
+domctl->u.psr_alloc_op.data = val32;
+copyback = true;
+break;
+
 default:
 ret = -EOPNOTSUPP;
 break;
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 4bb4399..a577a3e 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -1144,6 +1144,7 @@ struct xen_domctl_psr_alloc_op {
 #define XEN_DOMCTL_PSR_CAT_OP_GET_L3_DATA5
 #define XEN_DOMCTL_PSR_CAT_OP_SET_L2_CBM 6
 #define XEN_DOMCTL_PSR_CAT_OP_GET_L2_CBM 7
+#define XEN_DOMCTL_PSR_MBA_OP_GET_THRTL  9
 uint32_t cmd;   /* IN: XEN_DOMCTL_PSR_CAT_OP_* */
 uint32_t target;/* IN */
 uint64_t data;  /* IN/OUT */
-- 
1.9.1


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

[Xen-devel] [PATCH v2 08/15] tools: create general interfaces to support psr allocation features

[Yi Sun]

This patch creates general interfaces in libxl to support all psr
allocation features.

Add 'LIBXL_HAVE_PSR_MBA' to indicate interface change.

Please note, the functionality cannot work until later patches
are applied.

Signed-off-by: Yi Sun 
---
v2:
- remove '_INFO' in 'libxl_psr_feat_type' and make corresponding
  changes in 'libxl_psr_hw_info'.
  (suggested by Chao Peng)
---
 tools/libxl/libxl.h | 35 ++-
 tools/libxl/libxl_psr.c | 25 +
 tools/libxl/libxl_types.idl | 22 ++
 3 files changed, 81 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 229e289..c1d804c 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -931,6 +931,13 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst, const 
libxl_mac *src);
 #define LIBXL_HAVE_PSR_L2_CAT 1
 
 /*
+ * LIBXL_HAVE_PSR_MBA
+ *
+ * If this is defined, the Memory Bandwidth Allocation feature is supported.
+ */
+#define LIBXL_HAVE_PSR_MBA 1
+
+/*
  * LIBXL_HAVE_MCA_CAPS
  *
  * If this is defined, setting MCA capabilities for HVM domain is supported.
@@ -2219,7 +2226,33 @@ int libxl_psr_cat_get_info(libxl_ctx *ctx, 
libxl_psr_cat_info **info,
 int libxl_psr_cat_get_l3_info(libxl_ctx *ctx, libxl_psr_cat_info **info,
   int *nr);
 void libxl_psr_cat_info_list_free(libxl_psr_cat_info *list, int nr);
-#endif
+
+#ifdef LIBXL_HAVE_PSR_MBA
+/*
+ * Function to set a domain's value. It operates on a single or multiple
+ * target(s) defined in 'target_map'. 'target_map' specifies all the sockets
+ * to be operated on.
+ */
+int libxl_psr_set_val(libxl_ctx *ctx, uint32_t domid,
+  libxl_psr_cbm_type type, libxl_bitmap *target_map,
+  uint64_t val);
+/*
+ * Function to get a domain's cbm. It operates on a single 'target'.
+ * 'target' specifies which socket to be operated on.
+ */
+int libxl_psr_get_val(libxl_ctx *ctx, uint32_t domid,
+  libxl_psr_cbm_type type, unsigned int target,
+  uint64_t *val);
+/*
+ * On success, the function returns an array of elements in 'info',
+ * and the length in 'nr'.
+ */
+int libxl_psr_get_hw_info(libxl_ctx *ctx, libxl_psr_hw_info **info,
+  unsigned int *nr, libxl_psr_feat_type type,
+  unsigned int lvl);
+void libxl_psr_hw_info_list_free(libxl_psr_hw_info *list, unsigned int nr);
+#endif /* LIBXL_HAVE_PSR_MBA */
+#endif /* LIBXL_HAVE_PSR_CAT */
 
 /* misc */
 
diff --git a/tools/libxl/libxl_psr.c b/tools/libxl/libxl_psr.c
index f55ba1e..cf368ba 100644
--- a/tools/libxl/libxl_psr.c
+++ b/tools/libxl/libxl_psr.c
@@ -425,6 +425,31 @@ void libxl_psr_cat_info_list_free(libxl_psr_cat_info 
*list, int nr)
 free(list);
 }
 
+int libxl_psr_set_val(libxl_ctx *ctx, uint32_t domid,
+  libxl_psr_cbm_type type, libxl_bitmap *target_map,
+  uint64_t val)
+{
+return ERROR_FAIL;
+}
+
+int libxl_psr_get_val(libxl_ctx *ctx, uint32_t domid,
+  libxl_psr_cbm_type type, unsigned int target,
+  uint64_t *val)
+{
+return ERROR_FAIL;
+}
+
+int libxl_psr_get_hw_info(libxl_ctx *ctx, libxl_psr_hw_info **info,
+  unsigned int *nr, libxl_psr_feat_type type,
+  unsigned int lvl)
+{
+return ERROR_FAIL;
+}
+
+void libxl_psr_hw_info_list_free(libxl_psr_hw_info *list, unsigned int nr)
+{
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 6e80d36..ab847f8 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -977,6 +977,7 @@ libxl_psr_cbm_type = Enumeration("psr_cbm_type", [
 (2, "L3_CBM_CODE"),
 (3, "L3_CBM_DATA"),
 (4, "L2_CBM"),
+(5, "MBA_THRTL"),
 ])
 
 libxl_psr_cat_info = Struct("psr_cat_info", [
@@ -985,3 +986,24 @@ libxl_psr_cat_info = Struct("psr_cat_info", [
 ("cbm_len", uint32),
 ("cdp_enabled", bool),
 ])
+
+libxl_psr_feat_type = Enumeration("psr_feat_type", [
+(1, "CAT"),
+(2, "MBA"),
+])
+
+libxl_psr_hw_info = Struct("psr_hw_info", [
+("id", uint32),
+("u", KeyedUnion(None, libxl_psr_feat_type, "type",
+  [("cat", Struct(None, [
+("cos_max", uint32),
+("cbm_len", uint32),
+("cdp_enabled", bool),
+   ])),
+   ("mba", Struct(None, [
+("cos_max", uint32),
+("thrtl_max",   uint32),
+("linear",  bool),
+   ])),
+  ]))
+], dir=DIR_OUT)
-- 
1.9.1


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

[Xen-devel] [PATCH v2 01/15] docs: create Memory Bandwidth Allocation (MBA) feature document

[Yi Sun]

This patch creates MBA feature document in doc/features/. It describes
key points to implement MBA which is described in details in Intel SDM
"Introduction to Memory Bandwidth Allocation".

Signed-off-by: Yi Sun 
---
v2:
- declare 'HW' in Terminology.
  (suggested by Chao Peng)
- replace 'COS ID of VCPU' to 'COS ID of domain'.
  (suggested by Chao Peng)
- replace 'COS register' to 'Thrtl MSR'.
  (suggested by Chao Peng)
- add description for 'psr-mba-show' to state that the decimal value is
  shown for linear mode but hexadecimal value is shown for non-linear mode.
  (suggested by Chao Peng)
- remove content in 'Areas for improvement'.
  (suggested by Chao Peng)
- use '<>' to specify mandatory argument to a command.
  (suggested by Wei Liu)
v1:
- remove a special character to avoid the error when building pandoc.
---
 docs/features/intel_psr_mba.pandoc | 256 +
 1 file changed, 256 insertions(+)
 create mode 100644 docs/features/intel_psr_mba.pandoc

diff --git a/docs/features/intel_psr_mba.pandoc 
b/docs/features/intel_psr_mba.pandoc
new file mode 100644
index 000..21592e8
--- /dev/null
+++ b/docs/features/intel_psr_mba.pandoc
@@ -0,0 +1,256 @@
+% Intel Memory Bandwidth Allocation (MBA) Feature
+% Revision 1.4
+
+\clearpage
+
+# Basics
+
+ 
+ Status: **Tech Preview**
+
+Architecture(s): Intel x86
+
+   Component(s): Hypervisor, toolstack
+
+   Hardware: MBA is supported on Skylake Server and beyond
+ 
+
+# Terminology
+
+* CAT Cache Allocation Technology
+* CBM Capacity BitMasks
+* CDP Code and Data Prioritization
+* COS/CLOSClass of Service
+* HW  Hardware
+* MBA Memory Bandwidth Allocation
+* MSRsMachine Specific Registers
+* PSR Intel Platform Shared Resource
+* THRTL   Throttle value or delay value
+
+# Overview
+
+The Memory Bandwidth Allocation (MBA) feature provides indirect and approximate
+control over memory bandwidth available per-core. This feature provides OS/
+hypervisor the ability to slow misbehaving apps/domains or create advanced
+closed-loop control system via exposing control over a credit-based throttling
+mechanism.
+
+# User details
+
+* Feature Enabling:
+
+  Add "psr=mba" to boot line parameter to enable MBA feature.
+
+* xl interfaces:
+
+  1. `psr-mba-show [domain-id]`:
+
+ Show memory bandwidth throttling for domain. For linear mode, it shows the
+ decimal value. For non-linear mode, it shows hexadecimal value.
+
+  2. `psr-mba-set [OPTIONS]  `:
+
+ Set memory bandwidth throttling for domain.
+
+ Options:
+ '-s': Specify the socket to process, otherwise all sockets are processed.
+
+ Throttling value set in register implies memory bandwidth blocked, i.e.
+ higher throttling value results in lower bandwidth. The max throttling
+ value can be got through CPUID.
+
+ The response of the throttling value could be linear mode or non-linear
+ mode.
+
+ Linear mode: the input precision is defined as 100-(MBA_MAX). For 
instance,
+ if the MBA_MAX value is 90, the input precision is 10%. Values not an even
+ multiple of the precision (e.g., 12%) will be rounded down (e.g., to 10%
+ delay applied) by HW automatically.
+
+ Non-linear mode: input delay values are powers-of-two from zero to the
+ MBA_MAX value from CPUID. In this case any values not a power of two will
+ be rounded down the next nearest power of two by HW automatically.
+
+# Technical details
+
+MBA is a member of Intel PSR features, it shares the base PSR infrastructure
+in Xen.
+
+## Hardware perspective
+
+  MBA defines a range of MSRs to support specifying a delay value (Thrtl) per
+  COS, with details below.
+
+  ```
+   +++
+   | MSR (per socket)   |Address |
+   +++
+   | IA32_L2_QOS_Ext_BW_Thrtl_0 | 0xD50  |
+   +++
+   | ...|  ...   |
+   +++
+   | IA32_L2_QOS_Ext_BW_Thrtl_n | 0xD50+n (n<64) |
+   +++
+  ```
+
+  When context switch happens, the COS ID of domain is written to per-thread 
MSR
+  `IA32_PQR_ASSOC`, and then hardware enforces bandwidth allocation according
+  to the throttling value stored in the Thrtl MSR register.
+
+## The relationship between MBA and CAT/CDP
+
+  Generally speaking, MBA is completely independent of CAT/CDP, and any
+  combination may be applied at any time, e.g. enabling MBA with CAT
+  disabled.
+
+  But it needs to be noticed that MBA shares COS infrastructure with CAT,
+  although MBA is enumerated by different CPUID leaf from CAT (which
+  

[Xen-devel] [PATCH v2 04/15] x86: implement data structure and CPU init flow for MBA

[Yi Sun]

This patch implements main data structures of MBA.

Like CAT features, MBA HW info has cos_max which means the max thrtl
register number, and thrtl_max which means the max throttle value
(delay value). It also has a flag to represent if the throttle
value is linear or not.

One thrtl register of MBA stores a throttle value for one or more
domains. The throttle value means the transaction time between L2
cache and next level memory to be delayed.

This patch also implements init flow for MBA and register stub
callback functions.

Signed-off-by: Yi Sun 
---
v2:
- modify commit message to replace 'cos register' to 'thrtl register' to
  make it accurate.
  (suggested by Chao Peng)
- restore the place of the sentence to assign value to 'feat->cbm_len'
  because the MBA init flow is splitted out as a separate function in v1.
  (suggested by Chao Peng)
- add comment to explain what the MBA thrtl defaul value '0' stands for.
  (suggested by Chao Peng)
- check 'thrtl_max' under linear mode. It could not be euqal or larger than
  100.
  (suggested by Chao Peng)
v1:
- rebase codes onto L2 CAT v15.
- move comment to appropriate place.
  (suggested by Chao Peng)
- implement 'mba_init_feature' and keep 'cat_init_feature'.
  (suggested by Chao Peng)
- keep 'regs.b' into a local variable to avoid reading CPUID every time.
  (suggested by Chao Peng)
---
 xen/arch/x86/psr.c  | 141 +++-
 xen/include/asm-x86/msr-index.h |   1 +
 xen/include/asm-x86/psr.h   |   2 +
 3 files changed, 126 insertions(+), 18 deletions(-)

diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index da62f81..f5e99ce 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -27,13 +27,16 @@
  * - CMT Cache Monitoring Technology
  * - COS/CLOSClass of Service. Also mean COS registers.
  * - COS_MAX Max number of COS for the feature (minus 1)
+ * - MBA Memory Bandwidth Allocation
  * - MSRsMachine Specific Registers
  * - PSR Intel Platform Shared Resource
+ * - THRTL_MAX   Max throttle value (delay value) of MBA
  */
 
 #define PSR_CMT(1u << 0)
 #define PSR_CAT(1u << 1)
 #define PSR_CDP(1u << 2)
+#define PSR_MBA(1u << 3)
 
 #define CAT_CBM_LEN_MASK 0x1f
 #define CAT_COS_MAX_MASK 0x
@@ -60,10 +63,14 @@
  */
 #define MAX_COS_NUM 2
 
+#define MBA_LINEAR (1u << 2)
+#define MBA_THRTL_MAX_MASK 0xfff
+
 enum psr_feat_type {
 FEAT_TYPE_L3_CAT,
 FEAT_TYPE_L3_CDP,
 FEAT_TYPE_L2_CAT,
+FEAT_TYPE_MBA,
 FEAT_TYPE_NUM,
 FEAT_TYPE_UNKNOWN,
 };
@@ -71,7 +78,6 @@ enum psr_feat_type {
 /*
  * This structure represents one feature.
  * cos_max - The max COS registers number got through CPUID.
- * cbm_len - The length of CBM got through CPUID.
  * cos_reg_val - Array to store the values of COS registers. One entry stores
  *   the value of one COS register.
  *   For L3 CAT and L2 CAT, one entry corresponds to one COS_ID.
@@ -80,9 +86,23 @@ enum psr_feat_type {
  *   cos_reg_val[1] (Code).
  */
 struct feat_node {
-/* cos_max and cbm_len are common values for all features so far. */
+/* cos_max is common values for all features so far. */
 unsigned int cos_max;
-unsigned int cbm_len;
+
+/* Feature specific HW info. */
+union {
+struct {
+/* The length of CBM got through CPUID. */
+unsigned int cbm_len;
+} cat_info;
+
+struct {
+/* The max throttling value got through CPUID. */
+unsigned int thrtl_max;
+unsigned int linear;
+} mba_info;
+};
+
 uint32_t cos_reg_val[MAX_COS_REG_CNT];
 };
 
@@ -161,6 +181,7 @@ static DEFINE_PER_CPU(struct psr_assoc, psr_assoc);
  */
 static struct feat_node *feat_l3;
 static struct feat_node *feat_l2_cat;
+static struct feat_node *feat_mba;
 
 /* Common functions */
 #define cat_default_val(len) (0x >> (32 - (len)))
@@ -273,7 +294,7 @@ static bool psr_check_cbm(unsigned int cbm_len, unsigned 
long cbm)
 return true;
 }
 
-/* CAT common functions implementation. */
+/* Implementation of allocation features' functions. */
 static int cat_init_feature(const struct cpuid_leaf *regs,
 struct feat_node *feat,
 struct psr_socket_info *info,
@@ -289,8 +310,8 @@ static int cat_init_feature(const struct cpuid_leaf *regs,
 if ( !regs->a || !regs->d )
 return -ENOENT;
 
-feat->cbm_len = (regs->a & CAT_CBM_LEN_MASK) + 1;
 feat->cos_max = min(opt_cos_max, regs->d & CAT_COS_MAX_MASK);
+feat->cat_info.cbm_len = (regs->a & CAT_CBM_LEN_MASK) + 1;
 
 switch ( type )
 {
@@ -300,12 +321,12 @@ static int cat_init_feature(const struct cpuid_leaf *regs,
 return -ENOENT;
 
 /* We reserve cos=0 as default cbm (all bits within cbm_len are 1). */
-fea

[Xen-devel] [PATCH v2 12/15] tools: rename 'xc_psr_cat_type' to 'xc_psr_val_type'

[Yi Sun]

This patch renames 'xc_psr_cat_type' to 'xc_psr_val_type' so that
the structure name is common for all allocation features.

Signed-off-by: Yi Sun 
Acked-by: Wei Liu 
Reviewed-by: Chao Peng 
---
 tools/libxc/include/xenctrl.h |  8 
 tools/libxc/xc_psr.c  |  4 ++--
 tools/libxl/libxl_psr.c   | 12 ++--
 3 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 81a6f48..f1c629e 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2450,13 +2450,13 @@ enum xc_psr_cmt_type {
 };
 typedef enum xc_psr_cmt_type xc_psr_cmt_type;
 
-enum xc_psr_cat_type {
+enum xc_psr_val_type {
 XC_PSR_CAT_L3_CBM  = 1,
 XC_PSR_CAT_L3_CBM_CODE = 2,
 XC_PSR_CAT_L3_CBM_DATA = 3,
 XC_PSR_CAT_L2_CBM  = 4,
 };
-typedef enum xc_psr_cat_type xc_psr_cat_type;
+typedef enum xc_psr_val_type xc_psr_val_type;
 
 enum xc_psr_feat_type {
 XC_PSR_FEAT_UNKNOWN,
@@ -2499,10 +2499,10 @@ int xc_psr_cmt_get_data(xc_interface *xch, uint32_t 
rmid, uint32_t cpu,
 int xc_psr_cmt_enabled(xc_interface *xch);
 
 int xc_psr_cat_set_domain_data(xc_interface *xch, uint32_t domid,
-   xc_psr_cat_type type, uint32_t target,
+   xc_psr_val_type type, uint32_t target,
uint64_t data);
 int xc_psr_cat_get_domain_data(xc_interface *xch, uint32_t domid,
-   xc_psr_cat_type type, uint32_t target,
+   xc_psr_val_type type, uint32_t target,
uint64_t *data);
 int xc_psr_get_hw_info(xc_interface *xch, uint32_t socket,
xc_psr_feat_type type, xc_psr_hw_info *hw_info);
diff --git a/tools/libxc/xc_psr.c b/tools/libxc/xc_psr.c
index ba412e4..c69e943 100644
--- a/tools/libxc/xc_psr.c
+++ b/tools/libxc/xc_psr.c
@@ -249,7 +249,7 @@ int xc_psr_cmt_enabled(xc_interface *xch)
 return 0;
 }
 int xc_psr_cat_set_domain_data(xc_interface *xch, uint32_t domid,
-   xc_psr_cat_type type, uint32_t target,
+   xc_psr_val_type type, uint32_t target,
uint64_t data)
 {
 DECLARE_DOMCTL;
@@ -284,7 +284,7 @@ int xc_psr_cat_set_domain_data(xc_interface *xch, uint32_t 
domid,
 }
 
 int xc_psr_cat_get_domain_data(xc_interface *xch, uint32_t domid,
-   xc_psr_cat_type type, uint32_t target,
+   xc_psr_val_type type, uint32_t target,
uint64_t *data)
 {
 int rc;
diff --git a/tools/libxl/libxl_psr.c b/tools/libxl/libxl_psr.c
index d7da7d7..c97dca4 100644
--- a/tools/libxl/libxl_psr.c
+++ b/tools/libxl/libxl_psr.c
@@ -303,11 +303,11 @@ out:
 return rc;
 }
 
-static inline xc_psr_cat_type libxl__psr_cbm_type_to_libxc_psr_cat_type(
+static inline xc_psr_val_type libxl__psr_cbm_type_to_libxc_psr_val_type(
 libxl_psr_cbm_type type)
 {
-BUILD_BUG_ON(sizeof(libxl_psr_cbm_type) != sizeof(xc_psr_cat_type));
-return (xc_psr_cat_type)type;
+BUILD_BUG_ON(sizeof(libxl_psr_cbm_type) != sizeof(xc_psr_val_type));
+return (xc_psr_val_type)type;
 }
 
 int libxl_psr_cat_set_cbm(libxl_ctx *ctx, uint32_t domid,
@@ -325,12 +325,12 @@ int libxl_psr_cat_set_cbm(libxl_ctx *ctx, uint32_t domid,
 }
 
 libxl_for_each_set_bit(socketid, *target_map) {
-xc_psr_cat_type xc_type;
+xc_psr_val_type xc_type;
 
 if (socketid >= nr_sockets)
 break;
 
-xc_type = libxl__psr_cbm_type_to_libxc_psr_cat_type(type);
+xc_type = libxl__psr_cbm_type_to_libxc_psr_val_type(type);
 if (xc_psr_cat_set_domain_data(ctx->xch, domid, xc_type,
socketid, cbm)) {
 libxl__psr_cat_log_err_msg(gc, errno);
@@ -349,7 +349,7 @@ int libxl_psr_cat_get_cbm(libxl_ctx *ctx, uint32_t domid,
 {
 GC_INIT(ctx);
 int rc = 0;
-xc_psr_cat_type xc_type = libxl__psr_cbm_type_to_libxc_psr_cat_type(type);
+xc_psr_val_type xc_type = libxl__psr_cbm_type_to_libxc_psr_val_type(type);
 
 if (xc_psr_cat_get_domain_data(ctx->xch, domid, xc_type,
target, cbm_r)) {
-- 
1.9.1


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

[Xen-devel] [PATCH v2 02/15] Rename PSR sysctl/domctl interfaces and xsm policy to make them be general

[Yi Sun]

This patch renames PSR sysctl/domctl interfaces and related xsm policy to
make them be general for all resource allocation features but not only
for CAT. Then, we can resuse the interfaces for all allocation features.

Basically, it changes 'cat' to 'alloc'. E.g.:
1. psr_cat_op -> psr_alloc_op
2. XEN_DOMCTL_psr_cat_op -> XEN_DOMCTL_psr_alloc_op
3. XEN_SYSCTL_psr_cat_op -> XEN_SYSCTL_psr_alloc_op

The sysctl/domctl version numbers are bumped.

Signed-off-by: Yi Sun 
Reviewed-by: Wei Liu 
Acked-by: Daniel De Graaf 
---
v1:
- add description about what to be changed in commit message.
  (suggested by Wei Liu)
- bump sysctl/domctl version numbers.
  (suggested by Wei Liu)
---
 tools/flask/policy/modules/dom0.te  |  4 ++--
 tools/libxc/xc_psr.c| 34 +-
 xen/arch/x86/domctl.c   | 36 ++--
 xen/arch/x86/sysctl.c   | 24 
 xen/include/public/domctl.h | 12 ++--
 xen/include/public/sysctl.h | 12 ++--
 xen/xsm/flask/hooks.c   |  8 
 xen/xsm/flask/policy/access_vectors |  8 
 8 files changed, 69 insertions(+), 69 deletions(-)

diff --git a/tools/flask/policy/modules/dom0.te 
b/tools/flask/policy/modules/dom0.te
index d0a4d91..1a376ac 100644
--- a/tools/flask/policy/modules/dom0.te
+++ b/tools/flask/policy/modules/dom0.te
@@ -14,7 +14,7 @@ allow dom0_t xen_t:xen {
tmem_control getscheduler setscheduler
 };
 allow dom0_t xen_t:xen2 {
-   resource_op psr_cmt_op psr_cat_op pmu_ctrl get_symbol
+   resource_op psr_cmt_op psr_alloc_op pmu_ctrl get_symbol
get_cpu_levelling_caps get_cpu_featureset livepatch_op
gcov_op
 };
@@ -39,7 +39,7 @@ allow dom0_t dom0_t:domain {
 };
 allow dom0_t dom0_t:domain2 {
set_cpuid gettsc settsc setscheduler set_max_evtchn set_vnumainfo
-   get_vnumainfo psr_cmt_op psr_cat_op
+   get_vnumainfo psr_cmt_op psr_alloc_op
 };
 allow dom0_t dom0_t:resource { add remove };
 
diff --git a/tools/libxc/xc_psr.c b/tools/libxc/xc_psr.c
index 039b920..73d05f2 100644
--- a/tools/libxc/xc_psr.c
+++ b/tools/libxc/xc_psr.c
@@ -274,11 +274,11 @@ int xc_psr_cat_set_domain_data(xc_interface *xch, 
uint32_t domid,
 return -1;
 }
 
-domctl.cmd = XEN_DOMCTL_psr_cat_op;
+domctl.cmd = XEN_DOMCTL_psr_alloc_op;
 domctl.domain = (domid_t)domid;
-domctl.u.psr_cat_op.cmd = cmd;
-domctl.u.psr_cat_op.target = target;
-domctl.u.psr_cat_op.data = data;
+domctl.u.psr_alloc_op.cmd = cmd;
+domctl.u.psr_alloc_op.target = target;
+domctl.u.psr_alloc_op.data = data;
 
 return do_domctl(xch, &domctl);
 }
@@ -310,15 +310,15 @@ int xc_psr_cat_get_domain_data(xc_interface *xch, 
uint32_t domid,
 return -1;
 }
 
-domctl.cmd = XEN_DOMCTL_psr_cat_op;
+domctl.cmd = XEN_DOMCTL_psr_alloc_op;
 domctl.domain = (domid_t)domid;
-domctl.u.psr_cat_op.cmd = cmd;
-domctl.u.psr_cat_op.target = target;
+domctl.u.psr_alloc_op.cmd = cmd;
+domctl.u.psr_alloc_op.target = target;
 
 rc = do_domctl(xch, &domctl);
 
 if ( !rc )
-*data = domctl.u.psr_cat_op.data;
+*data = domctl.u.psr_alloc_op.data;
 
 return rc;
 }
@@ -329,29 +329,29 @@ int xc_psr_cat_get_info(xc_interface *xch, uint32_t 
socket, unsigned int lvl,
 int rc = -1;
 DECLARE_SYSCTL;
 
-sysctl.cmd = XEN_SYSCTL_psr_cat_op;
-sysctl.u.psr_cat_op.target = socket;
+sysctl.cmd = XEN_SYSCTL_psr_alloc_op;
+sysctl.u.psr_alloc_op.target = socket;
 
 switch ( lvl )
 {
 case 2:
-sysctl.u.psr_cat_op.cmd = XEN_SYSCTL_PSR_CAT_get_l2_info;
+sysctl.u.psr_alloc_op.cmd = XEN_SYSCTL_PSR_CAT_get_l2_info;
 rc = xc_sysctl(xch, &sysctl);
 if ( !rc )
 {
-*cos_max = sysctl.u.psr_cat_op.u.cat_info.cos_max;
-*cbm_len = sysctl.u.psr_cat_op.u.cat_info.cbm_len;
+*cos_max = sysctl.u.psr_alloc_op.u.cat_info.cos_max;
+*cbm_len = sysctl.u.psr_alloc_op.u.cat_info.cbm_len;
 *cdp_enabled = false;
 }
 break;
 case 3:
-sysctl.u.psr_cat_op.cmd = XEN_SYSCTL_PSR_CAT_get_l3_info;
+sysctl.u.psr_alloc_op.cmd = XEN_SYSCTL_PSR_CAT_get_l3_info;
 rc = xc_sysctl(xch, &sysctl);
 if ( !rc )
 {
-*cos_max = sysctl.u.psr_cat_op.u.cat_info.cos_max;
-*cbm_len = sysctl.u.psr_cat_op.u.cat_info.cbm_len;
-*cdp_enabled = sysctl.u.psr_cat_op.u.cat_info.flags &
+*cos_max = sysctl.u.psr_alloc_op.u.cat_info.cos_max;
+*cbm_len = sysctl.u.psr_alloc_op.u.cat_info.cbm_len;
+*cdp_enabled = sysctl.u.psr_alloc_op.u.cat_info.flags &
XEN_SYSCTL_PSR_CAT_L3_CDP;
 }
 break;
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 127c84e..24b998b 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/dom

[Xen-devel] [PATCH v2 07/15] x86: implement set value flow for MBA

[Yi Sun]

This patch implements set value flow for MBA including its callback
function and domctl interface.

It also changes the memebers in 'cos_write_info' to transfer the
feature array, feature properties array and value array. Then, we
can write all features values on the cos id into MSRs.

Because multiple features may co-exist, we need handle all features to write
values of them into a COS register with new COS ID. E.g:
1. L3 CAT and MBA co-exist.
2. Dom1 and Dom2 share a same COS ID (2). The L3 CAT CBM of Dom1 is 0x1ff,
   the MBA Thrtle of Dom1 is 0xa.
3. User wants to change MBA Thrtl of Dom1 to be 0x14. Because COS ID 2 is
   used by Dom2 too, we have to pick a new COS ID 3. The original values of
   Dom1 on COS ID 3 may be below:
   -
   | COS 3 |
   -
   L3 CAT  | 0x7ff |
   -
   MBA | 0x0   |
   -
4. After setting, the L3 CAT CBM value of Dom1 should be kept and the new MBA
   Thrtl is set. So, the values on COS ID 3 should be below.
   -
   | COS 3 |
   -
   L3 CAT  | 0x1ff |
   -
   MBA | 0x14  |
   -

So, we should write all features values into their MSRs. That requires the
feature array, feature properties array and value array are input.

Signed-off-by: Yi Sun 
---
v2:
- remove linear mode 'thrtl_max' check in 'mba_check_thrtl' because it has
  been checked in 'mba_init_feature'.
  (suggested by Chao Peng)
- for non-linear mode, check if '*thrtl' is not 0 in 'mba_check_thrtl'. If
  it is 0, we do not need to change it.
  (suggested by Chao Peng)
- move comments to explain changes of 'cos_write_info' from psr.c to commit
  message.
  (suggested by Chao Peng)
---
 xen/arch/x86/domctl.c   |   6 ++
 xen/arch/x86/psr.c  | 150 ++--
 xen/include/public/domctl.h |   1 +
 3 files changed, 109 insertions(+), 48 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 4936bcb..0ae4799 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1468,6 +1468,12 @@ long arch_do_domctl(
   PSR_VAL_TYPE_L2_CBM);
 break;
 
+case XEN_DOMCTL_PSR_MBA_OP_SET_THRTL:
+ret = psr_set_val(d, domctl->u.psr_alloc_op.target,
+  domctl->u.psr_alloc_op.data,
+  PSR_VAL_TYPE_MBA);
+break;
+
 case XEN_DOMCTL_PSR_CAT_OP_GET_L3_CBM:
 ret = psr_get_val(d, domctl->u.psr_alloc_op.target,
   &val32, PSR_VAL_TYPE_L3_CBM);
diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index 4a0c982..ce82975 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -138,6 +138,12 @@ static const struct feat_props {
 
 /* write_msr is used to write out feature MSR register. */
 void (*write_msr)(unsigned int cos, uint32_t val, enum psr_val_type type);
+
+/*
+ * check_val is used to check if input val fulfills SDM requirement.
+ * Change it to valid value if SDM allows.
+ */
+bool (*check_val)(const struct feat_node *feat, unsigned long *val);
 } *feat_props[FEAT_TYPE_NUM];
 
 /*
@@ -275,29 +281,6 @@ static enum psr_feat_type psr_val_type_to_feat_type(enum 
psr_val_type type)
 return feat_type;
 }
 
-static bool psr_check_cbm(unsigned int cbm_len, unsigned long cbm)
-{
-unsigned int first_bit, zero_bit;
-
-/* Set bits should only in the range of [0, cbm_len]. */
-if ( cbm & (~0ul << cbm_len) )
-return false;
-
-/* At least one bit need to be set. */
-if ( cbm == 0 )
-return false;
-
-first_bit = find_first_bit(&cbm, cbm_len);
-zero_bit = find_next_zero_bit(&cbm, cbm_len, first_bit);
-
-/* Set bits should be contiguous. */
-if ( zero_bit < cbm_len &&
- find_next_bit(&cbm, cbm_len, zero_bit) < cbm_len )
-return false;
-
-return true;
-}
-
 /* Implementation of allocation features' functions. */
 static int cat_init_feature(const struct cpuid_leaf *regs,
 struct feat_node *feat,
@@ -433,6 +416,30 @@ static bool cat_get_feat_info(const struct feat_node *feat,
 return true;
 }
 
+static bool cat_check_cbm(const struct feat_node *feat, unsigned long *cbm)
+{
+unsigned int first_bit, zero_bit;
+unsigned int cbm_len = feat->cat_info.cbm_len;
+
+/* Set bits should only in the range of [0, cbm_len]. */
+if ( *cbm & (~0ul << cbm_len) )
+return false;
+
+/* At least one bit need to be set. */
+if ( *cbm == 0 )
+return false;
+
+first_bit = find_first_bit(cbm, cbm_len);
+zero_bit = find_next_zero_bit(cbm, cbm_len, first_bit);
+
+/* Set bits should be contiguous. */
+if ( zero_bit < cbm_len &&
+ find_next_bit(cbm, cbm_len, zero_bit) < cbm_len )
+return false;
+
+return true;
+}
+
 /* L3 CAT props */
 static void l3_c

[Xen-devel] [PATCH v2 10/15] tools: implement the new libxl get hw info interface

[Yi Sun]

This patch implements the new libxl get hw info interface,
'libxl_psr_get_hw_info', which is suitable to all psr allocation
features. It also implements corresponding list free function,
'libxl_psr_hw_info_list_free' and make 'libxl_psr_cat_get_info' to call
'libxl_psr_get_hw_info' to avoid redundant codes in libxl_psr.c.

Signed-off-by: Yi Sun 
---
v2:
- split this patch out from a big patch in v1.
  (suggested by Wei Liu)
- change 'CAT_INFO'/'MBA_INFO' to 'CAT' and 'MBA. Also the libxl structure
  name 'cat_info'/'mba_info' is changed to 'cat'/'mba'.
  (suggested by Chao Peng)
- call 'libxl_psr_hw_info_list_free' in 'libxl_psr_cat_get_info' to free
  allocated resources.
  (suggested by Chao Peng)
---
 tools/libxl/libxl_psr.c | 145 +---
 1 file changed, 112 insertions(+), 33 deletions(-)

diff --git a/tools/libxl/libxl_psr.c b/tools/libxl/libxl_psr.c
index b183305..d7da7d7 100644
--- a/tools/libxl/libxl_psr.c
+++ b/tools/libxl/libxl_psr.c
@@ -382,56 +382,51 @@ static inline xc_psr_feat_type 
libxl__psr_feat_type_to_libxc_psr_feat_type(
 return xc_type;
 }
 
+static inline int libxl__psr_hw_info_to_libxl_psr_cat_info(
+  libxl_psr_feat_type type, libxl_psr_hw_info *hw_info,
+  libxl_psr_cat_info *cat_info)
+{
+if (type != LIBXL_PSR_FEAT_TYPE_CAT)
+return ERROR_INVAL;
+
+cat_info->id = hw_info->id;
+cat_info->cos_max = hw_info->u.cat.cos_max;
+cat_info->cbm_len = hw_info->u.cat.cbm_len;
+cat_info->cdp_enabled = hw_info->u.cat.cdp_enabled;
+
+return 0;
+}
+
 int libxl_psr_cat_get_info(libxl_ctx *ctx, libxl_psr_cat_info **info,
int *nr, unsigned int lvl)
 {
 GC_INIT(ctx);
 int rc;
-int i = 0, socketid, nr_sockets;
-libxl_bitmap socketmap;
+unsigned int i;
+libxl_psr_hw_info *hw_info;
 libxl_psr_cat_info *ptr;
-xc_psr_hw_info hw_info;
-xc_psr_feat_type xc_type;
-
-libxl_bitmap_init(&socketmap);
-
-rc = libxl__count_physical_sockets(gc, &nr_sockets);
-if (rc) {
-LOGE(ERROR, "failed to get system socket count");
-goto out;
-}
 
-libxl_socket_bitmap_alloc(ctx, &socketmap, nr_sockets);
-rc = libxl_get_online_socketmap(ctx, &socketmap);
-if (rc < 0) {
-LOGE(ERROR, "failed to get available sockets");
+rc = libxl_psr_get_hw_info(ctx, &hw_info, (unsigned int *)nr,
+   LIBXL_PSR_FEAT_TYPE_CAT, lvl);
+if (rc)
 goto out;
-}
 
-xc_type = libxl__psr_feat_type_to_libxc_psr_feat_type(
-  LIBXL_PSR_FEAT_TYPE_CAT, lvl);
+ptr = libxl__malloc(NOGC, *nr * sizeof(libxl_psr_cat_info));
 
-ptr = libxl__malloc(NOGC, nr_sockets * sizeof(libxl_psr_cat_info));
-
-libxl_for_each_set_bit(socketid, socketmap) {
-ptr[i].id = socketid;
-if (xc_psr_get_hw_info(ctx->xch, socketid, xc_type, &hw_info)) {
+for (i = 0; i < *nr; i++) {
+if (libxl__psr_hw_info_to_libxl_psr_cat_info(
+LIBXL_PSR_FEAT_TYPE_CAT,
+&hw_info[i], &ptr[i])) {
+libxl_psr_hw_info_list_free(hw_info, (unsigned int)*nr);
 rc = ERROR_FAIL;
 free(ptr);
 goto out;
 }
-
-ptr[i].cos_max = hw_info.u.xc_cat_info.cos_max;
-ptr[i].cbm_len = hw_info.u.xc_cat_info.cbm_len;
-ptr[i].cdp_enabled = hw_info.u.xc_cat_info.cdp_enabled;
-
-i++;
 }
 
 *info = ptr;
-*nr = i;
+libxl_psr_hw_info_list_free(hw_info, (unsigned int)*nr);
 out:
-libxl_bitmap_dispose(&socketmap);
 GC_FREE;
 return rc;
 }
@@ -469,15 +464,99 @@ int libxl_psr_get_val(libxl_ctx *ctx, uint32_t domid,
 return ERROR_FAIL;
 }
 
+static inline int libxc__psr_hw_info_to_libxl_psr_hw_info(
+  libxl_psr_feat_type type, xc_psr_hw_info *xc_hw_info,
+  libxl_psr_hw_info *xl_hw_info)
+{
+switch (type) {
+case LIBXL_PSR_FEAT_TYPE_CAT:
+xl_hw_info->u.cat.cos_max = xc_hw_info->u.xc_cat_info.cos_max;
+xl_hw_info->u.cat.cbm_len = xc_hw_info->u.xc_cat_info.cbm_len;
+xl_hw_info->u.cat.cdp_enabled =
+xc_hw_info->u.xc_cat_info.cdp_enabled;
+break;
+case LIBXL_PSR_FEAT_TYPE_MBA:
+xl_hw_info->u.mba.cos_max = xc_hw_info->u.xc_mba_info.cos_max;
+xl_hw_info->u.mba.thrtl_max = xc_hw_info->u.xc_mba_info.thrtl_max;
+xl_hw_info->u.mba.linear = xc_hw_info->u.xc_mba_info.linear;
+break;
+default:
+return ERROR_INVAL;
+}
+
+return 0;
+}
+
 int libxl_psr_get_hw_info(libxl_ctx *ctx, libxl_psr_hw_info **info,
   unsigned int *nr, libxl_psr_feat_type type,
   unsigned int lvl)
 {
-return ERROR_FAIL;
+GC_INIT(ctx);
+int rc, nr_sockets;
+unsigned int i = 0, socketid;
+libxl_bitmap socketmap;
+libxl_ps

[Xen-devel] [PATCH v2 11/15] tools: implement the new xl get hw info interface

[Yi Sun]

This patch implements a new xl get HW info interface. A new argument
is added for psr-hwinfo command to get and show MBA HW info.

Signed-off-by: Yi Sun 
---
v2:
- split out this patch from a big patch in v1.
  (suggested by Wei Liu)
- change 'MBA_INFO' to 'MBA'. Also, change 'mba_info' to 'mba'.
  (suggested by Chao Peng)
---
 tools/xl/xl_cmdtable.c |  1 +
 tools/xl/xl_psr.c  | 39 +--
 2 files changed, 38 insertions(+), 2 deletions(-)

diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c
index 2c71a9f..5ac8a7e 100644
--- a/tools/xl/xl_cmdtable.c
+++ b/tools/xl/xl_cmdtable.c
@@ -524,6 +524,7 @@ struct cmd_spec cmd_table[] = {
   "[options]",
   "-m, --cmt   Show Cache Monitoring Technology (CMT) hardware info\n"
   "-a, --cat   Show Cache Allocation Technology (CAT) hardware info\n"
+  "-b, --mba   Show Memory Bandwidth Allocation (MBA) hardware info\n"
 },
 { "psr-cmt-attach",
   &main_psr_cmt_attach, 0, 1,
diff --git a/tools/xl/xl_psr.c b/tools/xl/xl_psr.c
index 7309d4f..ea37967 100644
--- a/tools/xl/xl_psr.c
+++ b/tools/xl/xl_psr.c
@@ -479,6 +479,33 @@ static int psr_l2_cat_hwinfo(void)
 return rc;
 }
 
+static int psr_mba_hwinfo(void)
+{
+int rc;
+unsigned int i, nr;
+libxl_psr_hw_info *info;
+
+rc = libxl_psr_get_hw_info(ctx, &info, &nr,
+   LIBXL_PSR_FEAT_TYPE_MBA, 0);
+if (rc)
+return rc;
+
+printf("Memory Bandwidth Allocation (MBA):\n");
+
+for (i = 0; i < nr; i++) {
+printf("%-16s: %u\n", "Socket ID", info[i].id);
+printf("%-16s: %s\n", "Linear Mode",
+   info[i].u.mba.linear ? "Enabled" : "Disabled");
+printf("%-16s: %u\n", "Maximum COS", info[i].u.mba.cos_max);
+printf("%-16s: %u\n", "Maximum Throttling Value",
+   info[i].u.mba.thrtl_max);
+printf("%-16s: %u\n", "Default Throttling Value", 0);
+}
+
+libxl_psr_hw_info_list_free(info, nr);
+return rc;
+}
+
 int main_psr_cat_cbm_set(int argc, char **argv)
 {
 uint32_t domid;
@@ -597,20 +624,24 @@ int main_psr_cat_show(int argc, char **argv)
 int main_psr_hwinfo(int argc, char **argv)
 {
 int opt, ret = 0;
-bool all = true, cmt = false, cat = false;
+bool all = true, cmt = false, cat = false, mba = false;
 static struct option opts[] = {
 {"cmt", 0, 0, 'm'},
 {"cat", 0, 0, 'a'},
+{"mba", 0, 0, 'b'},
 COMMON_LONG_OPTS
 };
 
-SWITCH_FOREACH_OPT(opt, "ma", opts, "psr-hwinfo", 0) {
+SWITCH_FOREACH_OPT(opt, "mab", opts, "psr-hwinfo", 0) {
 case 'm':
 all = false; cmt = true;
 break;
 case 'a':
 all = false; cat = true;
 break;
+case 'b':
+all = false; mba = true;
+break;
 }
 
 if (!ret && (all || cmt))
@@ -623,6 +654,10 @@ int main_psr_hwinfo(int argc, char **argv)
 if (all || cat)
 ret = psr_l2_cat_hwinfo();
 
+/* MBA is independent of CMT and CAT */
+if (all || mba)
+ret = psr_mba_hwinfo();
+
 return ret;
 }
 
-- 
1.9.1


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

[Xen-devel] [PATCH v2 03/15] x86: rename 'cbm_type' to 'psr_val_type' to make it general

[Yi Sun]

This patch renames 'cbm_type' to 'psr_val_type' to make it be general.
Then, we can reuse this for all psr allocation features.

Signed-off-by: Yi Sun 
Reviewed-by: Wei Liu 
---
v2:
- replace 'PSR_VAL_TYPE_{L3, L2}' to 'PSR_VAL_TYPE_{L3, L2}_CBM'.
  (suggested by Chao Peng)
---
 xen/arch/x86/domctl.c | 16 ++--
 xen/arch/x86/psr.c| 62 +--
 xen/arch/x86/sysctl.c |  4 +--
 xen/include/asm-x86/psr.h | 18 +++---
 4 files changed, 52 insertions(+), 48 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 24b998b..e1c7c70 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1447,51 +1447,51 @@ long arch_do_domctl(
 case XEN_DOMCTL_PSR_CAT_OP_SET_L3_CBM:
 ret = psr_set_val(d, domctl->u.psr_alloc_op.target,
   domctl->u.psr_alloc_op.data,
-  PSR_CBM_TYPE_L3);
+  PSR_VAL_TYPE_L3_CBM);
 break;
 
 case XEN_DOMCTL_PSR_CAT_OP_SET_L3_CODE:
 ret = psr_set_val(d, domctl->u.psr_alloc_op.target,
   domctl->u.psr_alloc_op.data,
-  PSR_CBM_TYPE_L3_CODE);
+  PSR_VAL_TYPE_L3_CODE);
 break;
 
 case XEN_DOMCTL_PSR_CAT_OP_SET_L3_DATA:
 ret = psr_set_val(d, domctl->u.psr_alloc_op.target,
   domctl->u.psr_alloc_op.data,
-  PSR_CBM_TYPE_L3_DATA);
+  PSR_VAL_TYPE_L3_DATA);
 break;
 
 case XEN_DOMCTL_PSR_CAT_OP_SET_L2_CBM:
 ret = psr_set_val(d, domctl->u.psr_alloc_op.target,
   domctl->u.psr_alloc_op.data,
-  PSR_CBM_TYPE_L2);
+  PSR_VAL_TYPE_L2_CBM);
 break;
 
 case XEN_DOMCTL_PSR_CAT_OP_GET_L3_CBM:
 ret = psr_get_val(d, domctl->u.psr_alloc_op.target,
-  &val32, PSR_CBM_TYPE_L3);
+  &val32, PSR_VAL_TYPE_L3_CBM);
 domctl->u.psr_alloc_op.data = val32;
 copyback = true;
 break;
 
 case XEN_DOMCTL_PSR_CAT_OP_GET_L3_CODE:
 ret = psr_get_val(d, domctl->u.psr_alloc_op.target,
-  &val32, PSR_CBM_TYPE_L3_CODE);
+  &val32, PSR_VAL_TYPE_L3_CODE);
 domctl->u.psr_alloc_op.data = val32;
 copyback = true;
 break;
 
 case XEN_DOMCTL_PSR_CAT_OP_GET_L3_DATA:
 ret = psr_get_val(d, domctl->u.psr_alloc_op.target,
-  &val32, PSR_CBM_TYPE_L3_DATA);
+  &val32, PSR_VAL_TYPE_L3_DATA);
 domctl->u.psr_alloc_op.data = val32;
 copyback = true;
 break;
 
 case XEN_DOMCTL_PSR_CAT_OP_GET_L2_CBM:
 ret = psr_get_val(d, domctl->u.psr_alloc_op.target,
-  &val32, PSR_CBM_TYPE_L2);
+  &val32, PSR_VAL_TYPE_L2_CBM);
 domctl->u.psr_alloc_op.data = val32;
 copyback = true;
 break;
diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index 3622de0..da62f81 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -100,24 +100,24 @@ static const struct feat_props {
 unsigned int cos_num;
 
 /*
- * An array to save all 'enum cbm_type' values of the feature. It is
+ * An array to save all 'enum psr_val_type' values of the feature. It is
  * used with cos_num together to get/write a feature's COS registers
  * values one by one.
  */
-enum cbm_type type[MAX_COS_NUM];
+enum psr_val_type type[MAX_COS_NUM];
 
 /*
  * alt_type is 'alternative type'. When this 'alt_type' is input, the
  * feature does some special operations.
  */
-enum cbm_type alt_type;
+enum psr_val_type alt_type;
 
 /* get_feat_info is used to return feature HW info through sysctl. */
 bool (*get_feat_info)(const struct feat_node *feat,
   uint32_t data[], unsigned int array_len);
 
 /* write_msr is used to write out feature MSR register. */
-void (*write_msr)(unsigned int cos, uint32_t val, enum cbm_type type);
+void (*write_msr)(unsigned int cos, uint32_t val, enum psr_val_type type);
 } *feat_props[FEAT_TYPE_NUM];
 
 /*
@@ -216,13 +216,13 @@ static void free_socket_resources(unsigned int socket)
 bitmap_zero(info->dom_set, DOMID_IDLE + 1);
 }
 
-static enum psr_feat_type psr_cbm_type_to_feat_type(enum cbm_type type)
+static enum psr_feat_type psr_val_type_to_feat_type(enum psr_val_type type)
 {
 enum psr_feat_type feat_type = FEAT_TYPE_UNKNOWN;
 
 switch ( type )
 {
-case PSR_CBM_TYPE_L3:
+case PSR_VAL_TYPE_L3_CBM:
 feat_type = FEAT_TYPE_L3_CAT;
 
 /*
@@ -

[Xen-devel] [PATCH v2 00/15] Enable Memory Bandwidth Allocation in Xen

[Yi Sun]

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 patch set at:
https://github.com/yisun-git/xen_mba mba_v2-2

---
Acked and Reviewed list before V2:

a - Acked-by
r - Reviewed-by

  ar patch 2  - Rename PSR sysctl/domctl interfaces and xsm policy to make them 
be general
  r  patch 3  - x86: rename 'cbm_type' to 'psr_val_type' to make it general
  ar patch 12 - tools: rename 'xc_psr_cat_type' to 'xc_psr_val_type'
  a  patch 13 - tools: implement new generic get value interface and MBA get 
value command
  a  patch 15 - docs: add MBA description in docs

---
V2 change list:

Patch 1:
- declare 'HW' in Terminology.
  (suggested by Chao Peng)
- replace 'COS ID of VCPU' to 'COS ID of domain'.
  (suggested by Chao Peng)
- replace 'COS register' to 'Thrtl MSR'.
  (suggested by Chao Peng)
- add description for 'psr-mba-show' to state that the decimal value is
  shown for linear mode but hexadecimal value is shown for non-linear mode.
  (suggested by Chao Peng)
- remove content in 'Areas for improvement'.
  (suggested by Chao Peng)
- use '<>' to specify mandatory argument to a command.
  (suggested by Wei Liu)
Patch3:
- replace 'PSR_VAL_TYPE_{L3, L2}' to 'PSR_VAL_TYPE_{L3, L2}_CBM'.
  (suggested by Chao Peng)
Patch 4:
- modify commit message to replace 'cos register' to 'thrtl register' to
  make it accurate.
  (suggested by Chao Peng)
- restore the place of the sentence to assign value to 'feat->cbm_len'
  because the MBA init flow is splitted out as a separate function in v1.
  (suggested by Chao Peng)
- add comment to explain what the MBA thrtl defaul value '0' stands for.
  (suggested by Chao Peng)
- check 'thrtl_max' under linear mode. It could not be euqal or larger than
  100.
  (suggested by Chao Peng)
Patch 5:
- use 'XEN_SYSCTL_PSR_MBA_LINEAR' to set MBA feature HW info.
  (suggested by Chao Peng)
Patch 7:
- remove linear mode 'thrtl_max' check in 'mba_check_thrtl' because it has
  been checked in 'mba_init_feature'.
  (suggested by Chao Peng)
- for non-linear mode, check if '*thrtl' is not 0 in 'mba_check_thrtl'. If
  it is 0, we do not need to change it.
  (suggested by Chao Peng)
- move comments to explain changes of 'cos_write_info' from psr.c to commit
  message.
  (suggested by Chao Peng)
Patch 8:
- remove '_INFO' in 'libxl_psr_feat_type' and make corresponding
  changes in 'libxl_psr_hw_info'.
  (suggested by Chao Peng)
Patch 9:
- split this patch out from a big patch in v1.
  (suggested by Wei Liu)
- change 'CAT_INFO' and 'MBA_INFO' to 'CAT' and 'MBA'.
  (suggested by Chao Peng)
Patch 10:
- split this patch out from a big patch in v1.
  (suggested by Wei Liu)
- change 'CAT_INFO'/'MBA_INFO' to 'CAT' and 'MBA. Also the libxl structure
  name 'cat_info'/'mba_info' is changed to 'cat'/'mba'.
  (suggested by Chao Peng)
- call 'libxl_psr_hw_info_list_free' in 'libxl_psr_cat_get_info' to free
  allocated resources.
  (suggested by Chao Peng)
Patch 11:
- split out this patch from a big patch in v1.
  (suggested by Wei Liu)
- change 'MBA_INFO' to 'MBA'. Also, change 'mba_info' to 'mba'.
  (suggested by Chao Peng)
Patch 13:
- change 'CAT_INFO'/'MBA_INFO' to 'CAT'/'MBA'. The related structure names
  are changed too.
  (suggested by Chao Peng)
Patch 15:
- state the value type shown by 'psr-mba-show'. For linear mode,
  it shows decimal value. For non-linear mode, it shows hexadecimal
  value.
  (suggested by Chao Peng)

Yi Sun (15):
  docs: create Memory Bandwidth Allocation (MBA) feature document
  Rename PSR sysctl/domctl interfaces and xsm policy to make them be
general
  x86: rename 'cbm_type' to 'psr_val_type' to make it general
  x86: implement data structure and CPU init flow for MBA
  x86: implement get hw info flow for MBA
  x86: implement get value interface for MBA
  x86: implement set value flow for MBA
  tools: create general interfaces to support psr allocation features
  tools: implement the new libxc get hw info interface
  tools: implement the new libxl get hw info interface
  tools: implement the new xl get hw info interface
  tools: rename 'xc_psr_cat_type' to 'xc_psr_val_type'
  tools: implement new generic get value interface and MBA get value
command
  tools: implement new generic set value interface and MBA set value
command
  docs: add MBA description in docs

 docs/features/intel_psr_mba.pandoc  | 256 +
 docs/man/xl.pod.1.in|  34 
 docs/misc/xl-psr.markdown   |  63 +++
 tools/flask/policy/modules/dom0.te  |   4 +-
 tools/libxc/include/xenctrl.h 

[Xen-devel] [PATCH v2 13/15] tools: implement new generic get value interface and MBA get value command

[Yi Sun]

This patch implements generic get value interfaces in libxc and libxl.
It also refactors the get value flow in xl to make it be suitable for all
allocation features. Based on that, a new MBA get value command is added in xl.

Signed-off-by: Yi Sun 
Acked-by: Wei Liu 
---
v2:
- change 'CAT_INFO'/'MBA_INFO' to 'CAT'/'MBA'. The related structure names
  are changed too.
  (suggested by Chao Peng)
---
 tools/libxc/include/xenctrl.h |   7 +-
 tools/libxc/xc_psr.c  |   9 +-
 tools/libxl/libxl_psr.c   |  51 
 tools/xl/xl.h |   1 +
 tools/xl/xl_cmdtable.c|   5 ++
 tools/xl/xl_psr.c | 185 +-
 6 files changed, 179 insertions(+), 79 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index f1c629e..d7eabfb 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2455,6 +2455,7 @@ enum xc_psr_val_type {
 XC_PSR_CAT_L3_CBM_CODE = 2,
 XC_PSR_CAT_L3_CBM_DATA = 3,
 XC_PSR_CAT_L2_CBM  = 4,
+XC_PSR_MBA_THRTL   = 5,
 };
 typedef enum xc_psr_val_type xc_psr_val_type;
 
@@ -2501,9 +2502,9 @@ int xc_psr_cmt_enabled(xc_interface *xch);
 int xc_psr_cat_set_domain_data(xc_interface *xch, uint32_t domid,
xc_psr_val_type type, uint32_t target,
uint64_t data);
-int xc_psr_cat_get_domain_data(xc_interface *xch, uint32_t domid,
-   xc_psr_val_type type, uint32_t target,
-   uint64_t *data);
+int xc_psr_get_domain_data(xc_interface *xch, uint32_t domid,
+   xc_psr_val_type type, uint32_t target,
+   uint64_t *data);
 int xc_psr_get_hw_info(xc_interface *xch, uint32_t socket,
xc_psr_feat_type type, xc_psr_hw_info *hw_info);
 
diff --git a/tools/libxc/xc_psr.c b/tools/libxc/xc_psr.c
index c69e943..de501b0 100644
--- a/tools/libxc/xc_psr.c
+++ b/tools/libxc/xc_psr.c
@@ -283,9 +283,9 @@ int xc_psr_cat_set_domain_data(xc_interface *xch, uint32_t 
domid,
 return do_domctl(xch, &domctl);
 }
 
-int xc_psr_cat_get_domain_data(xc_interface *xch, uint32_t domid,
-   xc_psr_val_type type, uint32_t target,
-   uint64_t *data)
+int xc_psr_get_domain_data(xc_interface *xch, uint32_t domid,
+   xc_psr_val_type type, uint32_t target,
+   uint64_t *data)
 {
 int rc;
 DECLARE_DOMCTL;
@@ -305,6 +305,9 @@ int xc_psr_cat_get_domain_data(xc_interface *xch, uint32_t 
domid,
 case XC_PSR_CAT_L2_CBM:
 cmd = XEN_DOMCTL_PSR_CAT_OP_GET_L2_CBM;
 break;
+case XC_PSR_MBA_THRTL:
+cmd = XEN_DOMCTL_PSR_MBA_OP_GET_THRTL;
+break;
 default:
 errno = EINVAL;
 return -1;
diff --git a/tools/libxl/libxl_psr.c b/tools/libxl/libxl_psr.c
index c97dca4..1f2eee2 100644
--- a/tools/libxl/libxl_psr.c
+++ b/tools/libxl/libxl_psr.c
@@ -71,16 +71,30 @@ static void libxl__psr_cmt_log_err_msg(libxl__gc *gc, int 
err)
 LOGE(ERROR, "%s", msg);
 }
 
-static void libxl__psr_cat_log_err_msg(libxl__gc *gc, int err)
+static void libxl__psr_alloc_log_err_msg(libxl__gc *gc,
+ int err,
+ libxl_psr_cbm_type type)
 {
+/*
+ * Index is 'libxl_psr_cbm_type' so we set two 'CDP' to correspond to
+ * DATA and CODE.
+ */
+const char * const feat_name[6] = {
+"UNKNOWN",
+"L3 CAT",
+"CDP",
+"CDP",
+"L2 CAT",
+"MBA",
+};
 char *msg;
 
 switch (err) {
 case ENODEV:
-msg = "CAT is not supported in this system";
+msg = "is not supported in this system";
 break;
 case ENOENT:
-msg = "CAT is not enabled on the socket";
+msg = "is not enabled on the socket";
 break;
 case EOVERFLOW:
 msg = "no free COS available";
@@ -106,7 +120,7 @@ static void libxl__psr_cat_log_err_msg(libxl__gc *gc, int 
err)
 return;
 }
 
-LOGE(ERROR, "%s", msg);
+LOGE(ERROR, "%s: %s", feat_name[type], msg);
 }
 
 static int libxl__pick_socket_cpu(libxl__gc *gc, uint32_t socketid)
@@ -333,7 +347,7 @@ int libxl_psr_cat_set_cbm(libxl_ctx *ctx, uint32_t domid,
 xc_type = libxl__psr_cbm_type_to_libxc_psr_val_type(type);
 if (xc_psr_cat_set_domain_data(ctx->xch, domid, xc_type,
socketid, cbm)) {
-libxl__psr_cat_log_err_msg(gc, errno);
+libxl__psr_alloc_log_err_msg(gc, errno, type);
 rc = ERROR_FAIL;
 }
 }
@@ -347,18 +361,7 @@ int libxl_psr_cat_get_cbm(libxl_ctx *ctx, uint32_t domid,
   libxl_psr_cbm_type type, uint32_t target,
   uint64_t *cbm_r)
 {
-GC_INIT(ctx);
-int rc = 0;
-xc_psr_v

[Xen-devel] [PATCH v2 15/15] docs: add MBA description in docs

[Yi Sun]

This patch adds MBA description in related documents.

Signed-off-by: Yi Sun 
Acked-by: Wei Liu 
---
v2:
- state the value type shown by 'psr-mba-show'. For linear mode,
  it shows decimal value. For non-linear mode, it shows hexadecimal
  value.
  (suggested by Chao Peng)
---
 docs/man/xl.pod.1.in  | 34 +
 docs/misc/xl-psr.markdown | 63 +++
 2 files changed, 97 insertions(+)

diff --git a/docs/man/xl.pod.1.in b/docs/man/xl.pod.1.in
index 16c8306..e644b19 100644
--- a/docs/man/xl.pod.1.in
+++ b/docs/man/xl.pod.1.in
@@ -1798,6 +1798,40 @@ processed.
 
 =back
 
+=head2 Memory Bandwidth Allocation
+
+Intel Skylake and later server platforms offer capabilities to configure and
+make use of the Memory Bandwidth Allocation (MBA) mechanisms, which provides
+OS/VMMs the ability to slow misbehaving apps/VMs or create advanced closed-loop
+control system via exposing control over a credit-based throttling mechanism.
+In the Xen implementation, MBA is used to control memory bandwidth on VM basis.
+To enforce bandwidth on a specific domain, just set throttling value (THRTL)
+for the domain.
+
+=over 4
+
+=item B [I] I I
+
+Set throttling value (THRTL) for a domain. For how to specify I
+please refer to L.
+
+B
+
+=over 4
+
+=item B<-s SOCKET>, B<--socket=SOCKET>
+
+Specify the socket to process, otherwise all sockets are processed.
+
+=back
+
+=item B [I]
+
+Show MBA settings for a certain domain or all domains. For linear mode, it
+shows the decimal value. For non-linear mode, it shows hexadecimal value.
+
+=back
+
 =head1 IGNORED FOR COMPATIBILITY WITH XM
 
 xl is mostly command-line compatible with the old xm utility used with
diff --git a/docs/misc/xl-psr.markdown b/docs/misc/xl-psr.markdown
index 04dd957..39fc801 100644
--- a/docs/misc/xl-psr.markdown
+++ b/docs/misc/xl-psr.markdown
@@ -186,6 +186,69 @@ Setting data CBM for a domain:
 Setting the same code and data CBM for a domain:
 `xl psr-cat-set  `
 
+## Memory Bandwidth Allocation (MBA)
+
+Memory Bandwidth Allocation (MBA) is a new feature available on Intel
+Skylake and later server platforms that allows an OS or Hypervisor/VMM to
+slow misbehaving apps/VMs or create advanced closed-loop control system via
+exposing control over a credit-based throttling mechanism. To enforce bandwidth
+on a specific domain, just set throttling value (THRTL) into Class of Service
+(COS). MBA provides two THRTL mode. One is linear mode and the other is
+non-linear mode.
+
+In the linear mode the input precision is defined as 100-(THRTL_MAX). Values
+not an even multiple of the precision (e.g., 12%) will be rounded down (e.g.,
+to 10% delay applied).
+
+If linear values are not supported then input delay values are powers-of-two
+from zero to the THRTL_MAX value from CPUID. In this case any values not a 
power
+of two will be rounded down the next nearest power of two.
+
+For example, assuming a system with 2 domains:
+
+ * A THRTL of 0x0 for every domain means each domain can access the whole cache
+   without any delay. This is the default.
+
+ * Linear mode: Giving one domain a THRTL of 0xC and the other domain's 0 means
+   that the first domain gets 10% delay to access the cache and the other one
+   without any delay.
+
+ * Non-linear mode: Giving one domain a THRTL of 0xC and the other domain's 0
+   means that the first domain gets 8% delay to access the cache and the other
+   one without any delay.
+
+For more detailed information please refer to Intel SDM chapter
+"Introduction to Memory Bandwidth Allocation".
+
+In Xen's implementation, THRTL can be configured with libxl/xl interfaces but
+COS is maintained in hypervisor only. The cache partition granularity is per
+domain, each domain has COS=0 assigned by default, the corresponding THRTL is
+0, which means all the cache resource can be accessed without delay.
+
+### xl interfaces
+
+System MBA information such as maximum COS and maximum THRTL can be obtained 
by:
+
+`xl psr-hwinfo --mba`
+
+The simplest way to change a domain's THRTL from its default is running:
+
+`xl psr-mba-set  [OPTIONS]  `
+
+In a multi-socket system, the same thrtl will be set on each socket by default.
+Per socket thrtl can be specified with the `--socket SOCKET` option.
+
+Setting the THRTL may not be successful if insufficient COS is available. In
+such case unused COS(es) may be freed by setting THRTL of all related domains 
to
+its default value(0).
+
+Per domain THRTL settings can be shown by:
+
+`xl psr-mba-show [OPTIONS] `
+
+For linear mode, it shows the decimal value. For non-linear mode, it shows
+hexadecimal value.
+
 ## Reference
 
 [1] Intel SDM
-- 
1.9.1


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

[Xen-devel] [PATCH v2 14/15] tools: implement new generic set value interface and MBA set value command

[Yi Sun]

This patch implements new generic set value interfaces in libxc and libxl.
These interfaces are suitable for all allocation features. It also adds a
new MBA set value command in xl.

Signed-off-by: Yi Sun 
---
 tools/libxc/include/xenctrl.h |  6 ++---
 tools/libxc/xc_psr.c  |  9 ---
 tools/libxl/libxl_psr.c   | 56 +--
 tools/xl/xl.h |  1 +
 tools/xl/xl_cmdtable.c|  6 +
 tools/xl/xl_psr.c | 55 ++
 6 files changed, 99 insertions(+), 34 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index d7eabfb..3161bf6 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2499,9 +2499,9 @@ int xc_psr_cmt_get_data(xc_interface *xch, uint32_t rmid, 
uint32_t cpu,
 uint64_t *tsc);
 int xc_psr_cmt_enabled(xc_interface *xch);
 
-int xc_psr_cat_set_domain_data(xc_interface *xch, uint32_t domid,
-   xc_psr_val_type type, uint32_t target,
-   uint64_t data);
+int xc_psr_set_domain_data(xc_interface *xch, uint32_t domid,
+   xc_psr_val_type type, uint32_t target,
+   uint64_t data);
 int xc_psr_get_domain_data(xc_interface *xch, uint32_t domid,
xc_psr_val_type type, uint32_t target,
uint64_t *data);
diff --git a/tools/libxc/xc_psr.c b/tools/libxc/xc_psr.c
index de501b0..4dde76f 100644
--- a/tools/libxc/xc_psr.c
+++ b/tools/libxc/xc_psr.c
@@ -248,9 +248,9 @@ int xc_psr_cmt_enabled(xc_interface *xch)
 
 return 0;
 }
-int xc_psr_cat_set_domain_data(xc_interface *xch, uint32_t domid,
-   xc_psr_val_type type, uint32_t target,
-   uint64_t data)
+int xc_psr_set_domain_data(xc_interface *xch, uint32_t domid,
+   xc_psr_val_type type, uint32_t target,
+   uint64_t data)
 {
 DECLARE_DOMCTL;
 uint32_t cmd;
@@ -269,6 +269,9 @@ int xc_psr_cat_set_domain_data(xc_interface *xch, uint32_t 
domid,
 case XC_PSR_CAT_L2_CBM:
 cmd = XEN_DOMCTL_PSR_CAT_OP_SET_L2_CBM;
 break;
+case XC_PSR_MBA_THRTL:
+cmd = XEN_DOMCTL_PSR_MBA_OP_SET_THRTL;
+break;
 default:
 errno = EINVAL;
 return -1;
diff --git a/tools/libxl/libxl_psr.c b/tools/libxl/libxl_psr.c
index 1f2eee2..bd10e8b 100644
--- a/tools/libxl/libxl_psr.c
+++ b/tools/libxl/libxl_psr.c
@@ -328,33 +328,7 @@ int libxl_psr_cat_set_cbm(libxl_ctx *ctx, uint32_t domid,
   libxl_psr_cbm_type type, libxl_bitmap *target_map,
   uint64_t cbm)
 {
-GC_INIT(ctx);
-int rc;
-int socketid, nr_sockets;
-
-rc = libxl__count_physical_sockets(gc, &nr_sockets);
-if (rc) {
-LOGED(ERROR, domid, "failed to get system socket count");
-goto out;
-}
-
-libxl_for_each_set_bit(socketid, *target_map) {
-xc_psr_val_type xc_type;
-
-if (socketid >= nr_sockets)
-break;
-
-xc_type = libxl__psr_cbm_type_to_libxc_psr_val_type(type);
-if (xc_psr_cat_set_domain_data(ctx->xch, domid, xc_type,
-   socketid, cbm)) {
-libxl__psr_alloc_log_err_msg(gc, errno, type);
-rc = ERROR_FAIL;
-}
-}
-
-out:
-GC_FREE;
-return rc;
+return libxl_psr_set_val(ctx, domid, type, target_map, cbm);
 }
 
 int libxl_psr_cat_get_cbm(libxl_ctx *ctx, uint32_t domid,
@@ -457,7 +431,33 @@ int libxl_psr_set_val(libxl_ctx *ctx, uint32_t domid,
   libxl_psr_cbm_type type, libxl_bitmap *target_map,
   uint64_t val)
 {
-return ERROR_FAIL;
+GC_INIT(ctx);
+int rc;
+int socketid, nr_sockets;
+
+rc = libxl__count_physical_sockets(gc, &nr_sockets);
+if (rc) {
+LOGED(ERROR, domid, "failed to get system socket count");
+goto out;
+}
+
+libxl_for_each_set_bit(socketid, *target_map) {
+xc_psr_val_type xc_type;
+
+if (socketid >= nr_sockets)
+break;
+
+xc_type = libxl__psr_cbm_type_to_libxc_psr_val_type(type);
+if (xc_psr_set_domain_data(ctx->xch, domid, xc_type,
+   socketid, val)) {
+libxl__psr_alloc_log_err_msg(gc, errno, type);
+rc = ERROR_FAIL;
+}
+}
+
+out:
+GC_FREE;
+return rc;
 }
 
 int libxl_psr_get_val(libxl_ctx *ctx, uint32_t domid,
diff --git a/tools/xl/xl.h b/tools/xl/xl.h
index 59065c4..2cbe89c 100644
--- a/tools/xl/xl.h
+++ b/tools/xl/xl.h
@@ -206,6 +206,7 @@ int main_psr_cmt_show(int argc, char **argv);
 #ifdef LIBXL_HAVE_PSR_CAT
 int main_psr_cat_cbm_set(int argc, char **argv);
 int main_psr_cat_show(int argc, char **argv);
+int main_psr_mba_set(int argc, char **argv);
 int main_psr_mba_show(in

[Xen-devel] [xen-4.5-testing test] 112838: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds  7 xen-boot fail  like 110906
 test-xtf-amd64-amd64-2   59 leak-check/check fail  like 110906
 test-xtf-amd64-amd64-3   59 leak-check/check fail  like 110906
 test-xtf-amd64-amd64-4   59 leak-check/check fail  like 110906
 test-xtf-amd64-amd64-5   59 leak-check/check fail  like 110906
 test-xtf-amd64-amd64-1   59 leak-check/check fail  like 110906
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 110906
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 110906
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 110906
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 110906
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 110906
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 110906
 test-xtf-amd64-amd64-2   19 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2 33 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2 40 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2   44 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4   19 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-5   19 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4 33 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-5 33 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4 40 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4   44 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-5 40 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-5   44 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1   19 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1 33 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-amd64-amd64-xl-pvh-intel 15 guest-saverestorefail  never pass
 test-xtf-amd64-amd64-1 40 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-amd64-amd64-xl-pvh-amd  12 guest-start  fail   never pass
 test-xtf-amd64-amd64-1   44 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2   58 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-3   58 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-4   58 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-5   58 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-1   58 xtf/test-hvm64-xsa-195   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-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-amd64-amd64-xl-qemuu-ws16-amd64 13 guest-saverestore  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-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 13 guest-saverestore  fail 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-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 guest-start  fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   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-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-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-am

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

[Lan Tianyu]

On 2017年08月23日 15:58, Roger Pau Monné wrote:
> On Wed, Aug 09, 2017 at 04:34:12PM -0400, Lan Tianyu wrote:
>> From: Chao Gao 
>>
>> This patch adds create/destroy/query function for the emulated VTD
>> and adapts it to the common VIOMMU abstraction.
>>
>> Signed-off-by: Chao Gao 
>> Signed-off-by: Lan Tianyu 
>> ---
>>  xen/drivers/passthrough/vtd/Makefile |   7 +-
>>  xen/drivers/passthrough/vtd/iommu.h  |  99 +-
>>  xen/drivers/passthrough/vtd/vvtd.c   | 158 
>> +++
>>  xen/include/asm-x86/viommu.h |   3 +
>>  4 files changed, 241 insertions(+), 26 deletions(-)
>>  create mode 100644 xen/drivers/passthrough/vtd/vvtd.c
>>
>> diff --git a/xen/drivers/passthrough/vtd/Makefile 
>> b/xen/drivers/passthrough/vtd/Makefile
>> index f302653..163c7fe 100644
>> --- a/xen/drivers/passthrough/vtd/Makefile
>> +++ b/xen/drivers/passthrough/vtd/Makefile
>> @@ -1,8 +1,9 @@
>>  subdir-$(CONFIG_X86) += x86
>>  
>> -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
>> +obj-$(CONFIG_VIOMMU) += vvtd.o
>> diff --git a/xen/drivers/passthrough/vtd/iommu.h 
>> b/xen/drivers/passthrough/vtd/iommu.h
>> index 72c1a2e..55f3b6e 100644
>> --- a/xen/drivers/passthrough/vtd/iommu.h
>> +++ b/xen/drivers/passthrough/vtd/iommu.h
>> @@ -23,31 +23,54 @@
>>  #include 
>>  
>>  /*
>> - * Intel IOMMU register specification per version 1.0 public spec.
>> + * Intel IOMMU register specification per version 2.4 public spec.
>>   */
>>  
>> -#defineDMAR_VER_REG0x0/* Arch version supported by this IOMMU */
>> -#defineDMAR_CAP_REG0x8/* Hardware supported capabilities */
>> -#defineDMAR_ECAP_REG0x10/* Extended capabilities supported */
>> -#defineDMAR_GCMD_REG0x18/* Global command register */
>> -#defineDMAR_GSTS_REG0x1c/* Global status register */
>> -#defineDMAR_RTADDR_REG0x20/* Root entry table */
>> -#defineDMAR_CCMD_REG0x28/* Context command reg */
>> -#defineDMAR_FSTS_REG0x34/* Fault Status register */
>> -#defineDMAR_FECTL_REG0x38/* Fault control register */
>> -#defineDMAR_FEDATA_REG0x3c/* Fault event interrupt data 
>> register */
>> -#defineDMAR_FEADDR_REG0x40/* Fault event interrupt addr 
>> register */
>> -#defineDMAR_FEUADDR_REG 0x44/* Upper address register */
>> -#defineDMAR_AFLOG_REG0x58/* Advanced Fault control */
>> -#defineDMAR_PMEN_REG0x64/* Enable Protected Memory Region */
>> -#defineDMAR_PLMBASE_REG 0x68/* PMRR Low addr */
>> -#defineDMAR_PLMLIMIT_REG 0x6c/* PMRR low limit */
>> -#defineDMAR_PHMBASE_REG 0x70/* pmrr high base addr */
>> -#defineDMAR_PHMLIMIT_REG 0x78/* pmrr high limit */
>> -#defineDMAR_IQH_REG0x80/* invalidation queue head */
>> -#defineDMAR_IQT_REG0x88/* invalidation queue tail */
>> -#defineDMAR_IQA_REG0x90/* invalidation queue addr */
>> -#defineDMAR_IRTA_REG   0xB8/* intr remap */
>> +#define DMAR_VER_REG0x0  /* Arch version supported by this 
>> IOMMU */
>> +#define DMAR_CAP_REG0x8  /* Hardware supported capabilities */
>> +#define DMAR_ECAP_REG   0x10 /* Extended capabilities supported */
>> +#define DMAR_GCMD_REG   0x18 /* Global command register */
>> +#define DMAR_GSTS_REG   0x1c /* Global status register */
>> +#define DMAR_RTADDR_REG 0x20 /* Root entry table */
>> +#define DMAR_CCMD_REG   0x28 /* Context command reg */
>> +#define DMAR_FSTS_REG   0x34 /* Fault Status register */
>> +#define DMAR_FECTL_REG  0x38 /* Fault control register */
>> +#define DMAR_FEDATA_REG 0x3c /* Fault event interrupt data register 
>> */
>> +#define DMAR_FEADDR_REG 0x40 /* Fault event interrupt addr register 
>> */
>> +#define DMAR_FEUADDR_REG0x44 /* Upper address register */
>> +#define DMAR_AFLOG_REG  0x58 /* Advanced Fault control */
>> +#define DMAR_PMEN_REG   0x64 /* Enable Protected Memory Region */
>> +#define DMAR_PLMBASE_REG0x68 /* PMRR Low addr */
>> +#define DMAR_PLMLIMIT_REG   0x6c /* PMRR low limit */
>> +#define DMAR_PHMBASE_REG0x70 /* pmrr high base addr */
>> +#define DMAR_PHMLIMIT_REG   0x78 /* pmrr high limit */
>> +#define DMAR_IQH_REG0x80 /* invalidation queue head */
>> +#define DMAR_IQT_REG0x88 /* invalidation queue tail */
>> +#define DMAR_IQT_REG_HI 0x8c
>> +#define DMAR_IQA_REG0x90 /* invalidation queue addr */
>> +#define DMAR_IQA_REG_HI 0x94
>> +#define DMAR_ICS_REG0x9c /* Invalidation complete status */
>> +#define DMAR_IECTL_REG  0xa0 /* Invalidation event control */
>> +#define DMAR_IEDATA_REG 0xa4 /* Invalidation event data */
>> +#define DM

[Xen-devel] [xen-unstable test] 112841: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail REGR. vs. 
112809
 test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install  fail REGR. vs. 112809
 test-amd64-i386-xl-qemut-win7-amd64 10 windows-install   fail REGR. vs. 112809
 test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install   fail REGR. vs. 112809

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 like 112809
 build-arm64-pvops 2 hosts-allocate  broken like 112809
 build-arm64-xsm   2 hosts-allocate  broken like 112809
 build-arm64   3 capture-logsbroken like 112809
 build-arm64-xsm   3 capture-logsbroken like 112809
 build-arm64-pvops 3 capture-logsbroken like 112809
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112809
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112809
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 112809
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112809
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112809
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 112809
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   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-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-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-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   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
 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-libvirt-xsm 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
 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 13 migrate-support-checkfail   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-libvirt-vhd 12 migrate-support-checkfail   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-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 xen  4a0485c3d343e1c582fa824e4896b9b613a14efe
baseline version:
 xen  9053a74c08fd6abf43bb45ff932b4386de7e8510

Last test of basis   112809  2017-08-22 04:57:01 Z1 days
Testing same since   11284

Re: [Xen-devel] [PATCH V2 7/25] tools/libacpi: Add new fields in acpi_config for DMAR table

[Lan Tianyu]

On 2017年08月23日 16:04, Roger Pau Monné wrote:
> On Wed, Aug 23, 2017 at 03:52:01PM +0800, Lan Tianyu wrote:
>> On 2017年08月23日 00:41, Roger Pau Monné wrote:
> +drhd = (struct acpi_dmar_hardware_unit *)((void*)dmar + 
> sizeof(*dmar));
> +drhd->type = ACPI_DMAR_TYPE_HARDWARE_UNIT;
> +drhd->length = sizeof(*drhd) + ioapic_scope_size;
> +drhd->flags = ACPI_DMAR_INCLUDE_PCI_ALL;
> +drhd->pci_segment = 0;
> +drhd->base_address = config->iommu_base_addr;
> +
> +scope = &drhd->scope[0];
> +scope->type = ACPI_DMAR_DEVICE_SCOPE_IOAPIC;
> +scope->length = ioapic_scope_size;
> +scope->enumeration_id = config->ioapic_id;
> +scope->bus = I440_PSEUDO_BUS_PLATFORM;
> +scope->path[0] = I440_PSEUDO_DEVFN_IOAPIC;
>>> I'm not sure whether this constants should instead be fields in the
>>> acpi_config struct passed down from libxl. libxc shouldn't really need
>>> to know anything about which chipset a VM is using.
>>
>> How about rename I440_PSEUDO_XXX to VIOMMU_PSEUDO_XXX?
> 
> I'm not really complaining about the naming, I'm just saying that I'm
> not sure whether this constants should live in libxl. It would be
> better IMHO if they where defined in some libxl x86 specific header,
> and passed to libxc inside of the acpi_config struct.
> 
> At the end it is libxl which decides which chipset the VM is going to
> use, not libxc.

We can do that but the bdf is reserved for IOAPIC and should be same for
different chipset. Do we still need to pass it via acpi_config?


> 
> Roger.
> 


-- 
Best regards
Tianyu Lan

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

Re: [Xen-devel] [PATCH V2 9/25] tools/libxl: build DMAR table for a guest with one virtual VTD

[Lan Tianyu]

On 2017年08月23日 16:34, Wei Liu wrote:
> On Wed, Aug 23, 2017 at 01:35:17PM +0800, Lan Tianyu wrote:
>> On 2017年08月22日 21:48, Wei Liu wrote:
> Hi, Wei
> Thanks for your comments.
>
> iirc, HVM only supports one module; DMAR cannot be a new module. Joining 
> to
> the existing one is the approach we are taking. 
>
> Which kind of conflicts you think should be resolved? If you mean I
> forget to free the old buf, I will fix this. If you mean the potential
> overlap between the binary passed by admin and DMAR table built here, I
> don't have much idea on this. Even without the DMAR table, the binary
> may contains MADT or other tables and tool stacks don't intrepret the
> binary and check whether there are conflicts, right?
>
>>> Thinking a bit more about this, when I first said "conflicts" I didn't
>>> mean to parse the content. I was referring to the code in
>>> libxl_x86_apci.c which also seems to manipulate acpi_modules.
>>
>> Code in libxl_x86_acpi.c works for Hvmlite/PVHv2. The code we added is
>> for hvm guest.
>>
> 
> That's correct for the code as-is but what is preventing the code there
> from working with HVM? Assuming correct checks and branches are added
> to appropriate places?
> 
> I'm against having multiple locations doing things that could
> potentially clash with each other. In the foreseeable future PVH is
> going to get need similar functionality.
> 
> My expectation is that if the existing code needs to be taken into
> consideration and the contributors need to figure out if and how it can
> be modified to suite their needs. If everyone is doing their own thing
> in their own little function Xen will eventually become unmaintainable.
> 
>>>
>>> I would like the code to generate dmar take into consideration
>>> libxl__dom_load_acpi.
>>>
>>
>> If add dmar table for hvmlite, we should combine dmar table with other
>> ACPI table and populate into acpi_modules[2]. This is how hvmlite add
>> other ACPI tables in libxl__dom_load_acpi().
>>
> 
> Sure, that sounds plausible.
> 
> What I would like to see is to have one entry point to manipulate APCI
> tables.
> 
> Given the patch volume we're seeing now, we expect contributors to drive
> the discussion forward. If you're not sure, feel free to ask more questions.

I am not sure whether I understood correctly.

PVHv2 builds all ACPI table in tool stack and uses acpi_module[0, 1, 2]
to pass related table content.

HVM builds ACPI tables in hvmloader and just use acpi_module[0] to pass
additional ACPI firmware or table.

These two modes have different way to use acpi_modules[]. So I think we
can't combine them, right?

For build dmar table, we have introduced construct_dmar() in under
libacpi to build dmar table and PVHv2 also can use it in
libxl__dom_load_acpi().


-- 
Best regards
Tianyu Lan

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

Re: [Xen-devel] [PATCH RESEND1 00/12] ALSA: vsnd: Add Xen para-virtualized frontend driver

[Takashi Sakamoto]

On Aug 23 2017 23:51, Oleksandr Grytsov wrote:

Hi,

Thank you for detailed explanation.

We understand that emulated interrupt on the frontend side is completely not
acceptable and definitely we need to provide some feedback mechanism from
Dom0 to DomU.

In our case it is technically impossible to provide precise period interrupt
(mostly because our backend is a user space application).
The best we can implement it is provide number of frames (time, bytes etc.)
consumed by real HW. This info will be outdated due to different delays but
we can provide precise timestamps when this info was acquired.


Stuffs of ALSA PCM in kernel land is an abstraction layer for actual
hardware for data transmission. The stuffs get affects from a design of
actual hardware. Furthermore, sound subsystems on the other operating
systems such as Microsoft Windows are also designed with a consideration
about actual hardware. When you design any interfaces as an abstraction
for such software layer, it's better to understand actual hardware and
design of low-level software layer somehow.

Actually the 'sndif' has no good abstraction for actual hardware,
therefore an idea to implement frontend driver as an ALSA driver is not
reasonable at all. It's better to implement it as an application in
the other software layer, e.g. sinks/sources of PulseAudio in DomU via
Xenbus. This idea is nearer an original concept of Xen framework, I
guess. But I don't know we can write any applications of Xenbus in user
land of DomU or not.

Anyway, it's not a good idea to have an ALSA driver for the present 
'sndif', in my opinion.



Regards

Takashi Sakamoto

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

Re: [Xen-devel] [PATCH] x86: enable RCU based table free when PARAVIRT

[Kirill A. Shutemov]

On Wed, Aug 23, 2017 at 08:27:18PM +, Linus Torvalds wrote:
> On Wed, Aug 23, 2017 at 12:59 PM, Kirill A. Shutemov
>  wrote:
> >
> > In this case we need performance numbers for !PARAVIRT kernel.
> 
> Yes.
> 
> > Numbers for tight loop of "mmap(MAP_POPULATE); munmap()" might be
> > interesting too for worst case scenario.
> 
> Actually, I don't think you want to populate all the pages. You just
> want to populate *one* page, in order to build up the page directory
> structure, not allocate all the final points.
> 
> And we only free the actual page tables when there is nothing around,
> so it should be at least a 2MB-aligned region etc.
> 
> So you should do a *big* allocation, and then touch a single page in
> the middle, and then minmap it - that should give you maximal page
> table activity. Otherwise the page tables will generally just stay
> around.
> 
> Realistically, it's mainly exit() that frees page tables. Yes, you may
> have a few page tables free'd by a normal munmap(), but it's usually
> very limited. Which is why I suggested that script-heavy thing with
> lots of small executables. That tends to be the main realistic load
> that really causes a ton of page directory activity.

Below is test cases that allocates a lot of page tables and measuare
fork/exit time. (I'm not entirely sure it's the best way to stress the
codepath.)

Unpatched:  average 4.8322s, stddev 0.114s
Patched:average 4.8362s, stddev 0.111s

Both without PARAVIRT. Patch is modified to enable HAVE_RCU_TABLE_FREE for
!PARAVIRT too.

The test-case requires "echo 1 > /proc/sys/vm/overcommit_memory".

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define PUD_SIZE (1UL << 30)
#define PMD_SIZE (1UL << 21)

#define NR_PUD 4096

#define NSEC_PER_SEC10L

int main(void)
{
char *addr = NULL;
unsigned long i, j;
struct timespec start, finish;
long long nsec;

prctl(PR_SET_THP_DISABLE);
for (i = 0; i < NR_PUD ; i++) {
addr = mmap(addr + PUD_SIZE, PUD_SIZE, PROT_WRITE|PROT_READ,
MAP_ANONYMOUS|MAP_PRIVATE, -1, 0);
if (addr == MAP_FAILED) {
perror("mmap");
break;
}

for (j = 0; j < PUD_SIZE; j += PMD_SIZE)
assert(addr[j] == 0);
}

for (i = 0; i < 10; i++) {
pid_t pid;

clock_gettime(CLOCK_MONOTONIC, &start);
pid = fork();
if (pid == -1)
perror("fork");
if (!pid)
exit(0);
wait(NULL);
clock_gettime(CLOCK_MONOTONIC, &finish);

nsec = (finish.tv_sec - start.tv_sec) * NSEC_PER_SEC +
(finish.tv_nsec - start.tv_nsec);
printf("%lld\n", nsec);
}

return 0;
}
-- 
 Kirill A. Shutemov

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

Re: [Xen-devel] [PATCH v4] hvm: vmx/svm_cpu_up_prepare should be called only once

[Tian, Kevin]

> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: Tuesday, August 22, 2017 10:08 AM
> 
> These routines are first called via CPU_UP_PREPARE notifier by
> the BSP and then by the booting ASP from vmx_cpu_up()/_svm_cpu_up().
> 
> Avoid the unnecessary second call. Because BSP doesn't go through
> CPU_UP_PREPARE it is a special case. We pass 'bsp' flag to newly
> added _vmx_cpu_up() (just like it's already done for _svm_cpu_up())
> so they can decide whether or not to call vmx/svm_cpu_up_prepare().
> 
> Signed-off-by: Boris Ostrovsky 
> Reported-by: Andrew Cooper 

Reviewed-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH V2 16/25] x86/vioapic: Hook interrupt delivery of vIOAPIC

[Lan Tianyu]

On 2017年08月23日 17:59, Roger Pau Monné wrote:
> On Wed, Aug 09, 2017 at 04:34:17PM -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 
>> ---
>>  xen/arch/x86/hvm/vioapic.c | 14 ++
>>  1 file changed, 14 insertions(+)
>>
>> diff --git a/xen/arch/x86/hvm/vioapic.c b/xen/arch/x86/hvm/vioapic.c
>> index 72cae93..322f33c 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 
>> @@ -39,6 +40,8 @@
>>  #include 
>>  #include 
>>  
>> +#include "../../../drivers/passthrough/vtd/vtd.h"
> 
> Ouch, that's not very nice. Why do you need this? I though that you
> introduced an arch-agnostic layer that should be suitable?

Yes, agree. So far, I think of introducing a callback of checking
remapping mode in viommu ops and let vIOMMU device model to check
whether vioapic is in interrupt remapping mode. Device model can use
Intel or AMD IOAPIC remapping format to parse IOAPIC entry.

> 
>>  /* HACK: Route IRQ0 only to VCPU0 to prevent time jumps. */
>>  #define IRQ0_SPECIAL_ROUTING 1
>>  
>> @@ -387,9 +390,20 @@ 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 IO_APIC_route_remap_entry rte = { { vioapic->redirtbl[pin].bits 
>> } };
> 
> Designated initializers please.
> 
> Roger.
> 


-- 
Best regards
Tianyu Lan

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

[Xen-devel] [linux-3.18 test] 112843: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvops 3 capture-logs   broken REGR. vs. 112102

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-multivcpu  7 xen-boot  fail pass in 112817

Regressions which are regarded as allowable (not blocking):
 build-arm64   2 hosts-allocate broken REGR. vs. 112102
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 112102
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 112102

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-xsm   3 capture-logs  broken blocked in 112102
 build-arm64   3 capture-logs  broken blocked in 112102
 test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail blocked in 
112102
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop   fail blocked in 112102
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop  fail blocked in 112102
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail in 112817 
blocked in 112102
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 112817 
like 112102
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 112085
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112102
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112102
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112102
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112102
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   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-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-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 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-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   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-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-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-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-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-

Re: [Xen-devel] [PATCH v4 01/53] xen: add an optional string end parameter to parse_bool()

[Tian, Kevin]

> From: Juergen Gross [mailto:jgr...@suse.com]
> Sent: Thursday, August 24, 2017 1:34 AM
> 
> Add a parameter to parse_bool() to specify the end of the to be
> parsed string. Specifying it as NULL will preserve the current
> behavior to parse until the end of the input string, while passing
> a non-NULL pointer will specify the first character after the input
> string.
> 
> This will allow to parse boolean sub-strings without having to
> write a NUL byte into the input string.
> 
> Modify all users of parse_bool() to pass NULL for the new parameter.
> 
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> Cc: Kevin Tian 
> Signed-off-by: Juergen Gross 

Reviewed-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH v4 11/53] xen/arch/x86/hvm/vmx/vmcs.c: let custom parameter parsing routines return errno

[Tian, Kevin]

> From: Juergen Gross [mailto:jgr...@suse.com]
> Sent: Thursday, August 24, 2017 1:34 AM
> 
> Modify the custom parameter parsing routines in:
> 
> xen/arch/x86/hvm/vmx/vmcs.c
> 
> to indicate whether the parameter value was parsed successfully.
> 
> Cc: Jun Nakajima 
> Cc: Kevin Tian 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Signed-off-by: Juergen Gross 

Acked-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH v4 36/53] xen/drivers/passthrough/vtd/dmar.c: let custom parameter parsing routines return errno

[Tian, Kevin]

> From: Juergen Gross [mailto:jgr...@suse.com]
> Sent: Thursday, August 24, 2017 1:34 AM
> 
> Modify the custom parameter parsing routines in:
> 
> xen/drivers/passthrough/vtd/dmar.c
> 
> to indicate whether the parameter value was parsed successfully.
> 
> Cc: Kevin Tian 
> Signed-off-by: Juergen Gross 
> Acked-by: Wei Liu 

Acked-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH v4 37/53] xen/drivers/passthrough/vtd/quirks.c: let custom parameter parsing routines return errno

[Tian, Kevin]

> From: Juergen Gross [mailto:jgr...@suse.com]
> Sent: Thursday, August 24, 2017 1:35 AM
> 
> Modify the custom parameter parsing routines in:
> 
> xen/drivers/passthrough/vtd/quirks.c
> 
> to indicate whether the parameter value was parsed successfully.
> 
> Cc: Kevin Tian 
> Signed-off-by: Juergen Gross 
> Acked-by: Wei Liu 

Acked-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH] xen: Don't try to call xen_alloc_p2m_entry() on autotranslating guests

[Juergen Gross]

On 24/08/17 00:27, Boris Ostrovsky wrote:
> Commit aba831a69632 ("xen: remove tests for pvh mode in pure pv paths")
> removed XENFEAT_auto_translated_physmap test in xen_alloc_p2m_entry()
> since it is assumed that the routine is never called by non-PV guests.
> 
> However, alloc_xenballooned_pages() may make this call on a PVH guest.
> Prevent this from happening by adding XENFEAT_auto_translated_physmap
> check there.
> 
> Signed-off-by: Boris Ostrovsky 
> Fixes: aba831a69632 ("xen: remove tests for pvh mode in pure pv paths")

Reviewed-by: Juergen Gross 


Thanks,

Juergen

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

Re: [Xen-devel] [PATCH V2 19/25] x86/vioapic: extend vioapic_get_vector() to support remapping format RTE

[Lan Tianyu]

On 2017年08月23日 18:14, Roger Pau Monné wrote:
> On Wed, Aug 09, 2017 at 04:34:20PM -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 | 18 +-
>>  1 file changed, 17 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/x86/hvm/vioapic.c b/xen/arch/x86/hvm/vioapic.c
>> index 322f33c..ff0742d 100644
>> --- a/xen/arch/x86/hvm/vioapic.c
>> +++ b/xen/arch/x86/hvm/vioapic.c
>> @@ -565,11 +565,27 @@ int vioapic_get_vector(const struct domain *d, 
>> unsigned int gsi)
>>  {
>>  unsigned int pin;
>>  const struct hvm_vioapic *vioapic = gsi_vioapic(d, gsi, &pin);
>> +struct IO_APIC_route_remap_entry rte = { { vioapic->redirtbl[pin].bits 
>> } };
> 
> Designated initialization and const.
> 
>>  
>>  if ( !vioapic )
>>  return -EINVAL;
>>  
>> -return vioapic->redirtbl[pin].fields.vector;
>> +if ( rte.format )
>> +{
>> +int err;
>> +struct irq_remapping_request request;
>> +struct irq_remapping_info info;
>> +
>> +irq_request_ioapic_fill(&request, vioapic->id, rte.val);
>> +/* Currently, only viommu 0 is supported */
> 
> This seems to be hardcoded in a bunch of places, which makes me wonder
> whether having an array of vIOMMUs is the correct choice. I think that
> you should remove the array and have a single vIOMMU per domain.

The array is reserved for mult-vIOMMU support but so far no such
requirement as I know. In design stage, someone commented we should take
mult-vIOMMU support into account.

We may add callback of getting vIOMMU in vIOMMU ops and let vIOMMU
device model return associated vIOMMU instance according irq remapping
information(e.g source id). One VM suppose to have only one vIOMMU type.
When add multi-vIOMMU support, this logic also can be applied.

For current scenario. device model should return the first vIOMMU directly.

> 
>> +err = viommu_get_irq_info(vioapic->domain, 0, &request, &info);
>> +return !err ? info.vector : -1;
> 
> maybe:
> 
> return err ?: info.vector;
> 
> ?
> 
>> +}
>> +else
>> +{
>> +return vioapic->redirtbl[pin].fields.vector;
>> +}
>> +
>>  }
>>  
>>  int vioapic_get_trigger_mode(const struct domain *d, unsigned int gsi)
>> -- 
>> 1.8.3.1
>>
>>
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> https://lists.xen.org/xen-devel


-- 
Best regards
Tianyu Lan

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

Re: [Xen-devel] [PATCH 4/6] xsm: flask: change the interface and default policy for xsm_map_gmfn_foregin

[Jan Beulich]

>>> On 23.08.17 at 19:16,  wrote:
> On Wed, 23 Aug 2017, Jan Beulich wrote:
>> >>> On 22.08.17 at 20:08,  wrote:
>> > The original xsm_map_gmfn_foregin policy 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, this restricts some useful 
>> > yet not
>> > dangerous usages of the API, such as sharing pages among DomU's by calling
>> > XENMEM_add_to_physmap from Dom0.
>> > 
>> > Change the policy to: IIF current domain has the proper privilege on the
>> > target domain and source domain, grant the access.
>> 
>> You say "and here", yet ...
>> 
>> > --- a/xen/include/xsm/dummy.h
>> > +++ b/xen/include/xsm/dummy.h
>> > @@ -525,10 +525,12 @@ static XSM_INLINE int 
>> > xsm_remove_from_physmap(XSM_DEFAULT_ARG struct domain *d1,
>> >  return xsm_default_action(action, d1, d2);
>> >  }
>> >  
>> > -static XSM_INLINE int xsm_map_gmfn_foreign(XSM_DEFAULT_ARG struct domain 
>> > *d, struct domain *t)
>> > +static XSM_INLINE int xsm_map_gmfn_foreign(XSM_DEFAULT_ARG struct domain 
>> > *cd,
>> > +   struct domain *d, struct 
>> > domain *t)
>> >  {
>> >  XSM_ASSERT_ACTION(XSM_TARGET);
>> > -return xsm_default_action(action, d, t);
>> > +return xsm_default_action(action, cd, d) ||
>> > +xsm_default_action(action, cd, t);
>> >  }
>> 
>> ... you use "or" here and ...
>> 
>> > --- a/xen/xsm/flask/hooks.c
>> > +++ b/xen/xsm/flask/hooks.c
>> > @@ -1165,9 +1165,11 @@ static int flask_remove_from_physmap(struct domain 
>> > *d1, struct domain *d2)
>> >  return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
>> >  }
>> >  
>> > -static int flask_map_gmfn_foreign(struct domain *d, struct domain *t)
>> > +static int flask_map_gmfn_foreign(struct domain *cd,
>> > +  struct domain *d, struct domain *t)
>> >  {
>> > -return domain_has_perm(d, t, SECCLASS_MMU, MMU__MAP_READ | 
>> > MMU__MAP_WRITE);
>> > +return domain_has_perm(cd, d, SECCLASS_MMU, MMU__MAP_READ | 
>> > MMU__MAP_WRITE) ||
>> > +domain_has_perm(cd, t, SECCLASS_MMU, MMU__MAP_READ | 
>> > MMU__MAP_WRITE);
>> >  }
>> 
>> ... here. A domain can't have XSM_TARGET permission over two
>> other domains, so what you want to do here can't work at all,
>> afaict.
> 
> It would work with XSM_TARGET if cd == d, and cd has XSM_TARGET
> permission over t (current case). Otherwise, it would work if cd is
> XSM_PRIV (Zhongze's case). Did I get it wrong?

I think so, yes, but besides the "and" vs "or" discrepancy the patch
description suggests a three-way operation (i.e. including the case
of all three domains being different ones). The case you describe
doesn't require three domains to be passed into the hook, it would
- afaict - just be the traditional "cd is XSM_TARGET over t" case
(matching for example xsm_evtchn_{status,unbound}()).

Jan


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

Re: [Xen-devel] [PATCH V2 24/25] x86/vvtd: Add queued invalidation (QI) support

[Lan Tianyu]

On 2017年08月23日 20:16, Roger Pau Monné wrote:
> On Wed, Aug 09, 2017 at 04:34:25PM -0400, Lan Tianyu wrote:
>> > From: Chao Gao 
>> > 
>> > Queued Invalidation Interface is an expanded invalidation interface with
>> > extended capabilities. Hardware implementations report support for queued
>> > invalidation interface through the Extended Capability Register. The queued
>> > invalidation interface uses an Invalidation Queue (IQ), which is a circular
>> > buffer in system memory. Software submits commands by writing Invalidation
>> > Descriptors to the IQ.
>> > 
>> > In this patch, a new function viommu_process_iq() is used for emulating how
>> > hardware handles invalidation requests through QI.
> It seems like this is an extended feature, which is not needed for
> basic functionality. Would it be possible to have this series focus on
> the bare-minimum functionality, leaving everything else to a separate
> series?
> 

No, IOMMU supporting interrupt remapping must also support Queued
Invalidation (QI) according VTD spec.

-- 
Best regards
Tianyu Lan

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

Re: [Xen-devel] [PATCH v2 2/3] tools/libxc: add API for bitmap access for restore

[Olaf Hering]

On Thu, Aug 17, Olaf Hering wrote:

> Extend API for managing bitmaps. Each bitmap is now represented by a
> generic struct xc_sr_bitmap.

> +static inline bool xc_sr_bitmap_resize(struct xc_sr_bitmap *bm, unsigned 
> long bits)
> +static inline void xc_sr_bitmap_free(struct xc_sr_bitmap *bm)

> +static inline bool xc_sr_set_bit(unsigned long bit, struct xc_sr_bitmap *bm)
> +static inline bool xc_sr_test_bit(unsigned long bit, struct xc_sr_bitmap *bm)
> +static inline int xc_sr_test_and_clear_bit(unsigned long bit, struct 
> xc_sr_bitmap *bm)
> +static inline int xc_sr_test_and_set_bit(unsigned long bit, struct 
> xc_sr_bitmap *bm)

Any objection to remove the trailing '_bit' from these four function names?

Olaf


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 4/6] xsm: flask: change the interface and default policy for xsm_map_gmfn_foregin

[Jan Beulich]

>>> On 24.08.17 at 02:51,  wrote:
> 2017-08-23 17:55 GMT+08:00 Jan Beulich :
> On 22.08.17 at 20:08,  wrote:
>>> --- a/xen/include/xsm/dummy.h
>>> +++ b/xen/include/xsm/dummy.h
>>> @@ -525,10 +525,12 @@ static XSM_INLINE int 
>>> xsm_remove_from_physmap(XSM_DEFAULT_ARG struct domain *d1,
>>>  return xsm_default_action(action, d1, d2);
>>>  }
>>>
>>> -static XSM_INLINE int xsm_map_gmfn_foreign(XSM_DEFAULT_ARG struct domain 
>>> *d, struct domain *t)
>>> +static XSM_INLINE int xsm_map_gmfn_foreign(XSM_DEFAULT_ARG struct domain 
>>> *cd,
>>> +   struct domain *d, struct domain 
>>> *t)
>>>  {
>>>  XSM_ASSERT_ACTION(XSM_TARGET);
>>> -return xsm_default_action(action, d, t);
>>> +return xsm_default_action(action, cd, d) ||
>>> +xsm_default_action(action, cd, t);
>>>  }
>>
>> ... you use "or" here and ...
> 
> This might be confusing. But think of returning 0 as "allowed", the
> only condition where this
> statement returns a 0 is when both calls return 0 -- so it's actually
> an "and". (Think of de-morgan's law.)
> 
> But as Stefano has pointed out, I should preserve the error code.

Ah, right - the code as written suggests boolean return values,
which gives it the wrong look. You really mean ?: instead of ||.
Why do you, btw, pass in current->domain (as cd) instead of
obtaining it here (just like various other hooks do)?

Jan


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

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

[osstest service owner]

, 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

broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64-xsm hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 hosts-allocate
broken-step build-arm64-xsm capture-logs
broken-step build-arm64 capture-logs

Not pushing.


commit 56d7305db6d7c9b98c2bb44c53e67f1ec8336daa
Merge: 1f29673 1f98e55
Author: Peter Maydell 
Date:   Wed Aug 23 09:04:20 2017 +0100

Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.10-20170823' 
into staging

ppc patch queue 2017-08-23

This is identical to the pull request from yesterday (20180822),
except that a bug in one patch is fixed so that it doesn't break TCG
on a ppc host.

Last minute ppc related fixes for qemu-2.10.  I'm not sure if these
are critical enough to prompt another rc, but I'm submitting them for
consideration.

First, is Cornelia's fix for 480bc11e6 which meant "make check" would
always fail on a ppc host.  Tracking that down delayed submission of
the rest of these patches, sorry.

The rest are all fairly important bugfixes for qemu crashes or guest
behaviour regression on ppc.  Patches 2-4 specifically are fixes for
regressions from qemu-2.9, caused by the compatibility mode and
hotplug handling cleanups for the pseries machine type.

# gpg: Signature made Wed 23 Aug 2017 01:31:47 BST
# gpg:using RSA key 0x6C38CACA20D9B392
# gpg: Good signature from "David Gibson "
# gpg: aka "David Gibson (Red Hat) "
# gpg: aka "David Gibson (ozlabs.org) "
# gpg: aka "David Gibson (kernel.org) "
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E  87DC 6C38 CACA 20D9 
B392

* remotes/dgibson/tags/ppc-for-2.10-20170823:
  hw/ppc/spapr_iommu: Fix crash when removing the "spapr-tce-table" device
  hw/ppc/spapr_rtc: Mark the RTC device with user_creatable = false
  hw/ppc/spapr: Fix segfault when instantiating a 'pc-dimm' without 'memdev'
  spapr: Allow configure-connector to be called multiple times
  ppc: fix ppc_set_compat() with KVM PR
  target/ppc: 'PVR != host PVR' in KVM_SET_SREGS workaround
  boot-serial-test: prefer tcg accelerator

Signed-off-by: Peter Maydell 

commit 1f98e55385d11da1dc0de6440e66f19d191d2a1b
Author: Thomas Huth 
Date:   Thu Aug 17 16:19:16 2017 +0200

hw/ppc/spapr_iommu: Fix crash when removing the "spapr-tce-table" device

QEMU currently aborts unexpectedly when the user tries to add and
remove a "spapr-tce-table" device:

$ qemu-system-ppc64 -nographic -S -nodefaults -monitor stdio
QEMU 2.9.92 monitor - type 'help' for more information
(qemu) device_add spapr-tce-table,id=x
(qemu) device_del x
**
ERROR:qemu/qdev-monitor.c:872:qdev_unplug: assertion failed: (hotplug_ctrl)
Aborted (core dumped)

The device should not be accessable for the users at all, it's just
used internally, so mark it with user_creatable = false.

Signed-off-by: Thomas Huth 
Signed-off-by: David Gibson 

commit 8ff9dd7ba24c7a78861172e8dc6b07f1c392
Author: Thomas Huth 
Date:   Thu Aug 17 07:15:10 2017 +0200

hw/ppc/spapr_rtc: Mark the RTC device with user_creatable = false

QEMU currently aborts unexpectedly when a user tries to do something
like this:

$ qemu-system-ppc64 -nographic -S -nodefaults -monitor stdio
QEMU 2.9.92 monitor - type 'help' for more information
(qemu) device_add spapr-rtc,id=spapr-rtc
(qemu) device_del spapr-rtc
**
ERROR:qemu/qdev-monitor.c:872:qdev_unplug: assertion failed: (hotplug_ctrl)
Aborted (core dumped)

The RTC device is not meant to be hot-pluggable - it's an internal
device only and it even should not be possible to create it a
second time with the "-device" parameter, so let's mark this
with "user_creatable = false".

Signed-off-by: Thomas Huth 
Signed-off-by: David Gibson 

commit 0479097859372a760843ad1b9c6ed3705c6423ca
Author: Thomas Huth 
Date:   Mon Aug 21 08:30:29 2017 +0200

hw/ppc/spapr: Fix segfault when instantiating a 'pc-dimm' without 'memdev'

QEMU currently crashes when trying to use a 'pc-dimm' on the pseries
machine without specifying its 'memdev' property. This happens because
pc_dimm_get_memory_region() does not check whe

Re: [Xen-devel] [PATCH V2 7/25] tools/libacpi: Add new fields in acpi_config for DMAR table

[Jan Beulich]

>>> On 24.08.17 at 04:33,  wrote:
> On 2017年08月23日 16:04, Roger Pau Monné wrote:
>> On Wed, Aug 23, 2017 at 03:52:01PM +0800, Lan Tianyu wrote:
>>> On 2017年08月23日 00:41, Roger Pau Monné wrote:
>> +drhd = (struct acpi_dmar_hardware_unit *)((void*)dmar + 
>> sizeof(*dmar));
>> +drhd->type = ACPI_DMAR_TYPE_HARDWARE_UNIT;
>> +drhd->length = sizeof(*drhd) + ioapic_scope_size;
>> +drhd->flags = ACPI_DMAR_INCLUDE_PCI_ALL;
>> +drhd->pci_segment = 0;
>> +drhd->base_address = config->iommu_base_addr;
>> +
>> +scope = &drhd->scope[0];
>> +scope->type = ACPI_DMAR_DEVICE_SCOPE_IOAPIC;
>> +scope->length = ioapic_scope_size;
>> +scope->enumeration_id = config->ioapic_id;
>> +scope->bus = I440_PSEUDO_BUS_PLATFORM;
>> +scope->path[0] = I440_PSEUDO_DEVFN_IOAPIC;
 I'm not sure whether this constants should instead be fields in the
 acpi_config struct passed down from libxl. libxc shouldn't really need
 to know anything about which chipset a VM is using.
>>>
>>> How about rename I440_PSEUDO_XXX to VIOMMU_PSEUDO_XXX?
>> 
>> I'm not really complaining about the naming, I'm just saying that I'm
>> not sure whether this constants should live in libxl. It would be
>> better IMHO if they where defined in some libxl x86 specific header,
>> and passed to libxc inside of the acpi_config struct.
>> 
>> At the end it is libxl which decides which chipset the VM is going to
>> use, not libxc.
> 
> We can do that but the bdf is reserved for IOAPIC and should be same for
> different chipset. Do we still need to pass it via acpi_config?

Well, which value is the right (reserved) one surely can - at least
in theory - depend on the chipset. Which means that it should
come from the same place which determines the chipset to be
emulated for the guest.

Jan

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