date:20161123

>>> On 23.11.16 at 00:47,  wrote:
> I have a prototype that replaces XEN_DOMCTL_set_avail_vcpus with 
> XEN_DOMCTL_acpi_access and it seems to work OK. The toolstack needs to 
> perform two (or more, if >32 VCPUs) hypercalls and the logic on the 
> hypervisor side is almost the same as the ioreq handling that this 
> series added in patch 8.

Why would there be multiple hypercalls needed? (I guess I may need
to see the prototype to understand.)

> However, I now realized that this interface will not be available to PV 
> guests (and it will only become available to HVM guests when we move 
> hotplug from qemu to hypervisor). And it's x86-specific.

As you make clear below, the PV aspect is likely a non-issue. But
why is this x86-specific? It's generic ACPI, isn't it?

Jan

> This means that PV guests will not know what the number of available 
> VCPUs is and therefore we will not be able to enforce it. OTOH we don't 
> know how to do that anyway since PV guests bring up all VCPUs and then 
> offline them.
> 
> -boris




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

Re: [Xen-devel] [PATCH 1/3] x86/HVM: limit writes to incoming TSS during task switch

>>> On 22.11.16 at 17:32,  wrote:
> On 22/11/16 13:55, Jan Beulich wrote:
>> The only field modified (and even that conditionally) is the back link.
>> Write only that field, and only when it actually has been written to.
>>
>> Take the opportunity and also ditch the pointless initializer from the
>> "tss" local variable.
> 
> It would help to point out that tss is unconditionally filled completely
> from guest memory.
> 
>> Signed-off-by: Jan Beulich 
> 
> As for the mechanical adjustments here, Reviewed-by: Andrew Cooper
> 
> 
> However, is the position of the backlink write actually correct?  I'd
> have thought that all access to the old tss happen before switching cr3.

But the backlink gets written into the incoming TSS. And I think it
is being assumed anyway that both TSSes (just like the GDT) are
visible through either CR3, the more that the incoming TSS
necessarily is being read in the old address space context.

Jan


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

Re: [Xen-devel] [PATCH 2/3] x86/HVM: limit writes to outgoing TSS during task switch

>>> On 22.11.16 at 17:46,  wrote:
> On 22/11/16 13:55, Jan Beulich wrote:
>> The only fields modified are EIP, EFLAGS, GPRs, and segment selectors.
>> CR3 in particular is not supposed to be updated.
>>
>> Signed-off-by: Jan Beulich 
>>
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -2952,7 +2952,6 @@ void hvm_task_switch(
>>  if ( taskswitch_reason == TSW_iret )
>>  eflags &= ~X86_EFLAGS_NT;
>>  
>> -tss.cr3= v->arch.hvm_vcpu.guest_cr[3];
>>  tss.eip= regs->eip;
>>  tss.eflags = eflags;
>>  tss.eax= regs->eax;
>> @@ -2979,8 +2978,10 @@ void hvm_task_switch(
>>  hvm_get_segment_register(v, x86_seg_ldtr, &segr);
>>  tss.ldt = segr.sel;
>>  
>> -rc = hvm_copy_to_guest_virt(
>> -prev_tr.base, &tss, sizeof(tss), PFEC_page_present);
>> +rc = hvm_copy_to_guest_virt(prev_tr.base + offsetof(typeof(tss), eip),
>> +&tss.eip,
>> +(void *)&tss.trace - (void *)&tss.eip,
> 
> How about offsetof(typeof(tss), trace) - offsetof(typeof(tss), eip)?
> 
> It avoids some casts and void pointer arithmetic.

Oh, yes, that's better.

> Either way, Reviewed-by: Andrew Cooper 

Thanks, Jan


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

Re: [Xen-devel] [PATCH 3/3] x86/HVM: correct error code writing during task switch

>>> On 22.11.16 at 17:58,  wrote:
> On 22/11/16 13:56, Jan Beulich wrote:
>> Whether to write 32 or just 16 bits depends on the D bit of the target
>> CS. The width of the stack pointer to use depends on the B bit of the
>> target SS.
>>
>> Also avoid using the no-fault copying routine.
>>
>> Finally avoid using yet another struct segment_register variable here.
>>
>> Signed-off-by: Jan Beulich 
>>
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -3033,9 +3033,6 @@ void hvm_task_switch(
>>  goto out;
>>  }
>>  
>> -if ( (tss.trace & 1) && !exn_raised )
>> -hvm_inject_hw_exception(TRAP_debug, HVM_DELIVER_NO_ERROR_CODE);
>> -
>>  tr.attr.fields.type = 0xb; /* busy 32-bit tss */
>>  hvm_set_segment_register(v, x86_seg_tr, &tr);
>>  
>> @@ -3051,17 +3048,32 @@ void hvm_task_switch(
>>  
>>  if ( errcode >= 0 )
>>  {
>> -struct segment_register reg;
>>  unsigned long linear_addr;
>> -regs->esp -= 4;
>> -hvm_get_segment_register(current, x86_seg_ss, ®);
>> -/* Todo: do not ignore access faults here. */
>> -if ( hvm_virtual_to_linear_addr(x86_seg_ss, ®, regs->esp,
>> -4, hvm_access_write, 32,
>> +unsigned int opsz, sp;
>> +
>> +hvm_get_segment_register(current, x86_seg_cs, &segr);
> 
> You already have current latched in v at this point.

Oh, right - I've blindly modified the old function invocation.

> Otherwise, Reviewed-by: Andrew Cooper 

Thanks, Jan


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

[Xen-devel] [patch added to 3.12-stable] x86/mm/xen: Suppress hugetlbfs in PV guests

2016-11-23 Thread Jiri Slaby

From: Jan Beulich 

This patch has been added to the 3.12 stable tree. If you have any
objections, please let us know.

===

commit 103f6112f253017d7062cd74d17f4a514ed4485c upstream.

Huge pages are not normally available to PV guests. Not suppressing
hugetlbfs use results in an endless loop of page faults when user mode
code tries to access a hugetlbfs mapped area (since the hypervisor
denies such PTEs to be created, but error indications can't be
propagated out of xen_set_pte_at(), just like for various of its
siblings), and - once killed in an oops like this:

  kernel BUG at .../fs/hugetlbfs/inode.c:428!
  invalid opcode:  [#1] SMP
  ...
  RIP: e030:[]  [] 
remove_inode_hugepages+0x25b/0x320
  ...
  Call Trace:
   [] hugetlbfs_evict_inode+0x15/0x40
   [] evict+0xbd/0x1b0
   [] __dentry_kill+0x19a/0x1f0
   [] dput+0x1fe/0x220
   [] __fput+0x155/0x200
   [] task_work_run+0x60/0xa0
   [] do_exit+0x160/0x400
   [] do_group_exit+0x3b/0xa0
   [] get_signal+0x1ed/0x470
   [] do_signal+0x14/0x110
   [] prepare_exit_to_usermode+0xe9/0xf0
   [] retint_user+0x8/0x13

This is CVE-2016-3961 / XSA-174.

Reported-by: Vitaly Kuznetsov 
Signed-off-by: Jan Beulich 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Boris Ostrovsky 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: David Vrabel 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Juergen Gross 
Cc: Linus Torvalds 
Cc: Luis R. Rodriguez 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Toshi Kani 
Cc: xen-devel 
Link: http://lkml.kernel.org/r/57188ed80278000e4...@prv-mh.provo.novell.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Jiri Slaby 
---
 arch/x86/include/asm/hugetlb.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/include/asm/hugetlb.h b/arch/x86/include/asm/hugetlb.h
index 68c05398bba9..7aadd3cea843 100644
--- a/arch/x86/include/asm/hugetlb.h
+++ b/arch/x86/include/asm/hugetlb.h
@@ -4,6 +4,7 @@
 #include 
 #include 
 
+#define hugepages_supported() cpu_has_pse
 
 static inline int is_hugepage_only_range(struct mm_struct *mm,
 unsigned long addr,
-- 
2.10.2


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

[Xen-devel] [PATCH 0/3] xen: XSA-197 follow-ups

1: fix quad word bufioreq handling
2: slightly simplify bufioreq handling
3: ignore direction in bufioreq handling

Signed-off-by: Jan Beulich 


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

[Xen-devel] [PATCH 1/3] xen: fix quad word bufioreq handling

We should not consume the second slot if it didn't get written yet.
Normal writers - i.e. Xen - would not update write_pointer between the
two writes, but the page may get fiddled with by the guest itself, and
we're better off entering an infinite loop in that case.

Reported-by: yanghongke 
Signed-off-by: Jan Beulich 
---
TBD: Alternatively we could call e.g. hw_error() instead.

--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -1021,6 +1021,9 @@ static int handle_buffered_iopage(XenIOS
 xen_rmb();
 qw = (req.size == 8);
 if (qw) {
+if (rdptr + 1 == wrptr) {
+break;
+}
 buf_req = &buf_page->buf_ioreq[(rdptr + 1) %
IOREQ_BUFFER_SLOT_NUM];
 req.data |= ((uint64_t)buf_req->data) << 32;




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

[Xen-devel] [PATCH 2/3] xen: slightly simplify bufioreq handling

There's no point setting fields always receiving the same value on each
iteration, as handle_ioreq() doesn't alter them anyway. Set state and
count once ahead of the loop, drop the redundant clearing of
data_is_ptr, and avoid the meaningless setting of df altogether.

Also avoid doing an unsigned long calculation of size when the field to
be initialized is only 32 bits wide (and the shift value in the range
0...3).

Signed-off-by: Jan Beulich 

--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -995,6 +995,8 @@ static int handle_buffered_iopage(XenIOS
 }
 
 memset(&req, 0x00, sizeof(req));
+req.state = STATE_IOREQ_READY;
+req.count = 1;
 
 for (;;) {
 uint32_t rdptr = buf_page->read_pointer, wrptr;
@@ -1009,15 +1011,11 @@ static int handle_buffered_iopage(XenIOS
 break;
 }
 buf_req = &buf_page->buf_ioreq[rdptr % IOREQ_BUFFER_SLOT_NUM];
-req.size = 1UL << buf_req->size;
-req.count = 1;
+req.size = 1U << buf_req->size;
 req.addr = buf_req->addr;
 req.data = buf_req->data;
-req.state = STATE_IOREQ_READY;
 req.dir = buf_req->dir;
-req.df = 1;
 req.type = buf_req->type;
-req.data_is_ptr = 0;
 xen_rmb();
 qw = (req.size == 8);
 if (qw) {
@@ -1032,6 +1030,13 @@ static int handle_buffered_iopage(XenIOS
 
 handle_ioreq(state, &req);
 
+/* Only req.data may get updated by handle_ioreq(), albeit even that
+ * should not happen as such data would never make it to the guest.
+ */
+assert(req.state == STATE_IOREQ_READY);
+assert(req.count == 1);
+assert(!req.data_is_ptr);
+
 atomic_add(&buf_page->read_pointer, qw + 1);
 }
 




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

[Xen-devel] [PATCH 3/3] xen: ignore direction in bufioreq handling

There's no way to communicate back read data, so only writes can ever
be usefully specified. Ignore the field, paving the road for eventually
re-using the bit for something else in a few (many?) years time.

Signed-off-by: Jan Beulich 

--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -997,6 +997,7 @@ static int handle_buffered_iopage(XenIOS
 memset(&req, 0x00, sizeof(req));
 req.state = STATE_IOREQ_READY;
 req.count = 1;
+req.dir = IOREQ_WRITE;
 
 for (;;) {
 uint32_t rdptr = buf_page->read_pointer, wrptr;
@@ -1014,7 +1015,6 @@ static int handle_buffered_iopage(XenIOS
 req.size = 1U << buf_req->size;
 req.addr = buf_req->addr;
 req.data = buf_req->data;
-req.dir = buf_req->dir;
 req.type = buf_req->type;
 xen_rmb();
 qw = (req.size == 8);
@@ -1031,10 +1031,12 @@ static int handle_buffered_iopage(XenIOS
 handle_ioreq(state, &req);
 
 /* Only req.data may get updated by handle_ioreq(), albeit even that
- * should not happen as such data would never make it to the guest.
+ * should not happen as such data would never make it to the guest (we
+ * can only usefully see writes here after all).
  */
 assert(req.state == STATE_IOREQ_READY);
 assert(req.count == 1);
+assert(req.dir == IOREQ_WRITE);
 assert(!req.data_is_ptr);
 
 atomic_add(&buf_page->read_pointer, qw + 1);




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

Re: [Xen-devel] [xen-4.6-testing test] 102519: regressions - FAIL

>>> On 23.11.16 at 05:11,  wrote:
> flight 102519 xen-4.6-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/102519/ 
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-xtf-amd64-amd64-3   20 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 
> 101938
>  test-xtf-amd64-amd64-3 29 xtf/test-hvm32pae-invlpg~shadow fail REGR. vs. 
> 101938
>  test-xtf-amd64-amd64-3   40 xtf/test-hvm64-invlpg~shadow fail REGR. vs. 
> 101938

Namely them representing a pattern, these concern me: Did we
screw up the backport for one of the XSAs? Otoh they succeeded
on 4.5. Or is this because the 4.6 ones ran on and AMD box,
while the 4.5 ones (and perhaps the earlier successful 4.6 flight
then too) made it onto an Intel system?

Jan

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

Re: [Xen-devel] [PATCH 1/3] xen: fix quad word bufioreq handling

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 23 November 2016 09:24
> To: qemu-de...@nongnu.org
> Cc: Anthony Perard ; Paul Durrant
> ; Stefano Stabellini ; xen-
> devel 
> Subject: [PATCH 1/3] xen: fix quad word bufioreq handling
> 
> We should not consume the second slot if it didn't get written yet.
> Normal writers - i.e. Xen - would not update write_pointer between the
> two writes, but the page may get fiddled with by the guest itself, and
> we're better off entering an infinite loop in that case.
> 

Xen would never put QEMU in this situation and the guest can't actually modify 
the page whilst it's in use, since activation of the IOREQ server removes the 
page from the guest's p2m so the premise of the patch is not correct.

  Paul

> Reported-by: yanghongke 
> Signed-off-by: Jan Beulich 
> ---
> TBD: Alternatively we could call e.g. hw_error() instead.
> 
> --- a/xen-hvm.c
> +++ b/xen-hvm.c
> @@ -1021,6 +1021,9 @@ static int handle_buffered_iopage(XenIOS
>  xen_rmb();
>  qw = (req.size == 8);
>  if (qw) {
> +if (rdptr + 1 == wrptr) {
> +break;
> +}
>  buf_req = &buf_page->buf_ioreq[(rdptr + 1) %
> IOREQ_BUFFER_SLOT_NUM];
>  req.data |= ((uint64_t)buf_req->data) << 32;
> 
> 


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

Re: [Xen-devel] [xen-4.6-testing test] 102519: regressions - FAIL

On 23/11/2016 09:43, Jan Beulich wrote:
 On 23.11.16 at 05:11,  wrote:
>> flight 102519 xen-4.6-testing real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/102519/ 
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  test-xtf-amd64-amd64-3   20 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 
>> 101938
>>  test-xtf-amd64-amd64-3 29 xtf/test-hvm32pae-invlpg~shadow fail REGR. vs. 
>> 101938
>>  test-xtf-amd64-amd64-3   40 xtf/test-hvm64-invlpg~shadow fail REGR. vs. 
>> 101938
> Namely them representing a pattern, these concern me: Did we
> screw up the backport for one of the XSAs? Otoh they succeeded
> on 4.5. Or is this because the 4.6 ones ran on and AMD box,
> while the 4.5 ones (and perhaps the earlier successful 4.6 flight
> then too) made it onto an Intel system?

http://logs.test-lab.xenproject.org/osstest/logs/102519/test-xtf-amd64-amd64-3/nocera0---var-log-xen-console-guest-test-hvm32pae-invlpg~shadow.log

--- Xen Test Framework ---
Environment: HVM 32bit (PAE 3 levels)
Invlpg tests
Testing 'invlpg (0x1000)' with segment bases
  Test: No segment
TLB refill of 0x1000
  Test: %fs (base 0x0)
TLB refill of 0x1000
  Test: %fs (base 0x0, limit 0x1)
Fail: Unexpected #GP[]
Fail: No TLB refill at all
  Test: %fs (base 0x1000)
TLB refill of 0x2000
  Test: %fs (base 0x1000, limit 0x1001)
TLB refill of 0x2000
Testing 'invlpg' in normally-faulting conditions
  Test: Mapped address
  Test: Unmapped address
  Test: NULL segment override
Fail: Unexpected #GP[]
  Test: Past segment limit
Fail: Unexpected #GP[]
  Test: Before expand-down segment limit
Fail: Unexpected #GP[]
Test result: FAILURE

The invlpg logic isn't (or is no longer) squashing segmentation faults.

I can't recall whether you backported the change that far, but it looks
as if the test might accidentally been relying on XSA-191 to function on
older versions of Xen.

~Andrew

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

[Xen-devel] [PATCH v2] xen_disk: split discard input to match internal representation

The guest sends discard requests as u64 sector/count pairs, but the
block layer operates internally with s64/s32 pairs. The conversion
leads to IO errors in the guest, the discard request is not processed.

  domU.cfg:
  'vdev=xvda, format=qcow2, backendtype=qdisk, target=/x.qcow2'
  domU:
  mkfs.ext4 -F /dev/xvda
  Discarding device blocks: failed - Input/output error

Fix this by splitting the request into chunks of BDRV_REQUEST_MAX_SECTORS.
Add input range checking to avoid overflow.

Fixes f313520 ("xen_disk: add discard support")

Signed-off-by: Olaf Hering 
---
v2:
 adjust overflow check
 add Fixes revspec because the initial commit also failed to convert u64 to s32
 adjust summary

 hw/block/xen_disk.c | 42 --
 1 file changed, 36 insertions(+), 6 deletions(-)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 3a7dc19..8d74b69 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -660,6 +660,38 @@ static void qemu_aio_complete(void *opaque, int ret)
 qemu_bh_schedule(ioreq->blkdev->bh);
 }
 
+static bool blk_split_discard(struct ioreq *ioreq, blkif_sector_t 
sector_number,
+  uint64_t nr_sectors)
+{
+struct XenBlkDev *blkdev = ioreq->blkdev;
+int64_t byte_offset;
+int byte_chunk;
+uint64_t byte_remaining, limit;
+uint64_t sec_start = sector_number;
+uint64_t sec_count = nr_sectors;
+
+/* Wrap around, or overflowing byte limit? */
+if (sec_start + sec_count < sec_count ||
+   sec_start + sec_count > INT64_MAX >> BDRV_SECTOR_BITS) {
+return false;
+}
+
+limit = BDRV_REQUEST_MAX_SECTORS << BDRV_SECTOR_BITS;
+byte_offset = sec_start << BDRV_SECTOR_BITS;
+byte_remaining = sec_count << BDRV_SECTOR_BITS;
+
+do {
+byte_chunk = byte_remaining > limit ? limit : byte_remaining;
+ioreq->aio_inflight++;
+blk_aio_pdiscard(blkdev->blk, byte_offset, byte_chunk,
+ qemu_aio_complete, ioreq);
+byte_remaining -= byte_chunk;
+byte_offset += byte_chunk;
+} while (byte_remaining > 0);
+
+return true;
+}
+
 static int ioreq_runio_qemu_aio(struct ioreq *ioreq)
 {
 struct XenBlkDev *blkdev = ioreq->blkdev;
@@ -708,12 +740,10 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq)
 break;
 case BLKIF_OP_DISCARD:
 {
-struct blkif_request_discard *discard_req = (void *)&ioreq->req;
-ioreq->aio_inflight++;
-blk_aio_pdiscard(blkdev->blk,
- discard_req->sector_number << BDRV_SECTOR_BITS,
- discard_req->nr_sectors << BDRV_SECTOR_BITS,
- qemu_aio_complete, ioreq);
+struct blkif_request_discard *req = (void *)&ioreq->req;
+if (!blk_split_discard(ioreq, req->sector_number, req->nr_sectors)) {
+goto err;
+}
 break;
 }
 default:

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

Re: [Xen-devel] [PATCH 2/3] xen: slightly simplify bufioreq handling

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 23 November 2016 09:25
> To: qemu-de...@nongnu.org
> Cc: Anthony Perard ; Paul Durrant
> ; Stefano Stabellini ; xen-
> devel 
> Subject: [PATCH 2/3] xen: slightly simplify bufioreq handling
> 
> There's no point setting fields always receiving the same value on each
> iteration, as handle_ioreq() doesn't alter them anyway. Set state and
> count once ahead of the loop, drop the redundant clearing of
> data_is_ptr, and avoid the meaningless setting of df altogether.
> 
> Also avoid doing an unsigned long calculation of size when the field to
> be initialized is only 32 bits wide (and the shift value in the range
> 0...3).
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Paul Durrant 

> 
> --- a/xen-hvm.c
> +++ b/xen-hvm.c
> @@ -995,6 +995,8 @@ static int handle_buffered_iopage(XenIOS
>  }
> 
>  memset(&req, 0x00, sizeof(req));
> +req.state = STATE_IOREQ_READY;
> +req.count = 1;
> 
>  for (;;) {
>  uint32_t rdptr = buf_page->read_pointer, wrptr;
> @@ -1009,15 +1011,11 @@ static int handle_buffered_iopage(XenIOS
>  break;
>  }
>  buf_req = &buf_page->buf_ioreq[rdptr % IOREQ_BUFFER_SLOT_NUM];
> -req.size = 1UL << buf_req->size;
> -req.count = 1;
> +req.size = 1U << buf_req->size;
>  req.addr = buf_req->addr;
>  req.data = buf_req->data;
> -req.state = STATE_IOREQ_READY;
>  req.dir = buf_req->dir;
> -req.df = 1;
>  req.type = buf_req->type;
> -req.data_is_ptr = 0;
>  xen_rmb();
>  qw = (req.size == 8);
>  if (qw) {
> @@ -1032,6 +1030,13 @@ static int handle_buffered_iopage(XenIOS
> 
>  handle_ioreq(state, &req);
> 
> +/* Only req.data may get updated by handle_ioreq(), albeit even that
> + * should not happen as such data would never make it to the guest.
> + */
> +assert(req.state == STATE_IOREQ_READY);
> +assert(req.count == 1);
> +assert(!req.data_is_ptr);
> +
>  atomic_add(&buf_page->read_pointer, qw + 1);
>  }
> 
> 
> 


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

Re: [Xen-devel] [PATCH 3/3] xen: ignore direction in bufioreq handling

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 23 November 2016 09:25
> To: qemu-de...@nongnu.org
> Cc: Anthony Perard ; Paul Durrant
> ; Stefano Stabellini ; xen-
> devel 
> Subject: [PATCH 3/3] xen: ignore direction in bufioreq handling
> 
> There's no way to communicate back read data, so only writes can ever
> be usefully specified. Ignore the field, paving the road for eventually
> re-using the bit for something else in a few (many?) years time.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Paul Durrant 

> 
> --- a/xen-hvm.c
> +++ b/xen-hvm.c
> @@ -997,6 +997,7 @@ static int handle_buffered_iopage(XenIOS
>  memset(&req, 0x00, sizeof(req));
>  req.state = STATE_IOREQ_READY;
>  req.count = 1;
> +req.dir = IOREQ_WRITE;
> 
>  for (;;) {
>  uint32_t rdptr = buf_page->read_pointer, wrptr;
> @@ -1014,7 +1015,6 @@ static int handle_buffered_iopage(XenIOS
>  req.size = 1U << buf_req->size;
>  req.addr = buf_req->addr;
>  req.data = buf_req->data;
> -req.dir = buf_req->dir;
>  req.type = buf_req->type;
>  xen_rmb();
>  qw = (req.size == 8);
> @@ -1031,10 +1031,12 @@ static int handle_buffered_iopage(XenIOS
>  handle_ioreq(state, &req);
> 
>  /* Only req.data may get updated by handle_ioreq(), albeit even that
> - * should not happen as such data would never make it to the guest.
> + * should not happen as such data would never make it to the guest 
> (we
> + * can only usefully see writes here after all).
>   */
>  assert(req.state == STATE_IOREQ_READY);
>  assert(req.count == 1);
> +assert(req.dir == IOREQ_WRITE);
>  assert(!req.data_is_ptr);
> 
>  atomic_add(&buf_page->read_pointer, qw + 1);
> 
> 


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

Re: [Xen-devel] [PATCH 1/2] build system: Include SeaBIOS and TianoCore directory

On Tue, Nov 22, 2016 at 11:02:04PM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 23, 2016 at 02:39:35AM +, Wei Liu wrote:
> > On Sun, Nov 20, 2016 at 10:27:21PM -0500, Konrad Rzeszutek Wilk wrote:
> > > The release source did not include those two directories.
> > > 
> > > Signed-off-by: Konrad Rzeszutek Wilk 
> > > ---
> > >  tools/misc/mktarball | 5 +
> > >  1 file changed, 5 insertions(+)
> > > 
> > > diff --git a/tools/misc/mktarball b/tools/misc/mktarball
> > > index 73282b5..7942846 100755
> > > --- a/tools/misc/mktarball
> > > +++ b/tools/misc/mktarball
> > > @@ -35,6 +35,11 @@ git_archive_into 
> > > $xen_root/tools/qemu-xen-traditional-dir-remote $tdir/xen-$desc
> > >  
> > >  git_archive_into $xen_root/extras/mini-os-remote 
> > > $tdir/xen-$desc/extras/mini-os
> > >  
> > > +git_archive_into $xen_root/tools/firmware/seabios-dir-remote 
> > > $tdir/xen-$desc/tools/firmware/seabios-dir
> > > +
> > > +if [ -d $xen_root/tools/firmware/ovmf-dir-remote ]; then
> > 
> > Is this test really needed? I think subtree-force-update-all will clone
> > ovmf anyway.
> 
> I think it only does that if CONFIG_OVMF is in your local .config -
> which is only the case if you run ./configure --enable-ovmf
> 

In that case, shouldn't seabios and rombios be treated the same way?

> 
> > 
> > > +git_archive_into $xen_root/tools/firmware/ovmf-dir-remote 
> > > $tdir/xen-$desc/tools/firmware/ovmf-dir
> > > +fi
> > >  GZIP=-9v tar cz -f $xen_root/dist/xen-$desc.tar.gz -C $tdir xen-$desc
> > >  
> > >  echo "Source tarball in $xen_root/dist/xen-$desc.tar.gz"
> > > -- 
> > > 2.9.3
> > > 
> > 
> > ___
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > https://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH v4] xen/gntdev: Use VM_MIXEDMAP instead of VM_IO to avoid NUMA balancing

On Mon, Nov 21, Boris Ostrovsky wrote:

> Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to
> NUMA balancing") set VM_IO flag to prevent grant maps from being
> subjected to NUMA balancing.


Tested-by: Olaf Hering 

This should go to stable as well.

Olaf


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

Re: [Xen-devel] [Qemu-devel] [PATCH v2] xen_disk: split discard input to match internal representation

2016-11-23 Thread no-reply

Hi,

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

Subject: [Qemu-devel] [PATCH v2] xen_disk: split discard input to match 
internal representation
Type: series
Message-id: 20161123094914.15675-1-o...@aepfle.de

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

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

# Useful git options
git config --local diff.renamelimit 0
git config --local diff.renames True

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

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag] 
patchew/1479896194-32672-1-git-send-email-fanc.f...@cn.fujitsu.com -> 
patchew/1479896194-32672-1-git-send-email-fanc.f...@cn.fujitsu.com
 * [new tag] patchew/20161123094914.15675-1-o...@aepfle.de -> 
patchew/20161123094914.15675-1-o...@aepfle.de
Switched to a new branch 'test'
947512f xen_disk: split discard input to match internal representation

=== OUTPUT BEGIN ===
Checking PATCH 1/1: xen_disk: split discard input to match internal 
representation...
ERROR: code indent should never use tabs
#45: FILE: hw/block/xen_disk.c:675:
+^Isec_start + sec_count > INT64_MAX >> BDRV_SECTOR_BITS) {$

total: 1 errors, 0 warnings, 54 lines checked

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

=== OUTPUT END ===

Test command exited with code: 1


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

Re: [Xen-devel] [xen-4.6-testing test] 102519: regressions - FAIL

>>> On 23.11.16 at 10:49,  wrote:
> The invlpg logic isn't (or is no longer) squashing segmentation faults.
> 
> I can't recall whether you backported the change that far, but it looks
> as if the test might accidentally been relying on XSA-191 to function on
> older versions of Xen.

That change didn't get backported anywhere so far. If it's
applicable to 4.6, we can certainly put it there. But it's obviously
absent in 4.5 too, and there the test succeeded (flight 102520).
Hence I'm afraid I don't fully understand your reply.

Jan

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

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

2016-11-23 Thread osstest service owner

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen  986f790e0184d4bf575462077378e14fa9f85aa9
baseline version:
 xen  58bd0c7985890e0292212f94a56235228a3445c3

Last test of basis   102447  2016-11-20 09:18:44 Z3 days
Testing same since   102559  2016-11-23 09:25:19 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  Ian Jackson 
  Jan Beulich 
  Roger Pau MonnÃ© 
  Tamas K Lengyel 

jobs:
 coverity-amd64   pass



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

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

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

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


Pushing revision :

+ branch=xen-unstable-coverity
+ revision=986f790e0184d4bf575462077378e14fa9f85aa9
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push 
xen-unstable-coverity 986f790e0184d4bf575462077378e14fa9f85aa9
+ branch=xen-unstable-coverity
+ revision=986f790e0184d4bf575462077378e14fa9f85aa9
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-coverity
+ qemuubranch=qemu-upstream-unstable-coverity
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-coverity
+ prevxenbranch=xen-4.7-testing
+ '[' x986f790e0184d4bf575462077378e14fa9f85aa9 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable-coverity
++ : daily-cron.xen-unstable-coverity

[Xen-devel] XEN tools for ARM64 build issue

Dear all,

Building latest XEN master branch
(58bd0c7985890e0292212f94a56235228a3445c3) for salvator-x platform using
the same yocto as here
https://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X
I've
faced following issue:

Maximum error count (200) exceeded

/home/aanisov/DEV/salvatorx-new/build/tmp/work/aarch64-poky-linux/xen/4.8.0+gitAUTOINC+58bd0c7985-r0/git/tools/libxl/dsdt_anycpu_arm.asl
 3: OperationRegion ( MSUM, SystemMemory, \_SB.MSUA, 1 )
Error4084 -

 Object does not exist ^  (\_SB.MSUA)
/home/aanisov/DEV/salvatorx-new/build/tmp/work/aarch64-poky-linux/xen/4.8.0+gitAUTOINC+58bd0c7985-r0/git/tools/libxl/dsdt_anycpu_arm.asl
 8: If ( LLess(Arg0, NCPU) ) {
Error4084 -

   Object does not exist ^  (NCPU)
/home/aanisov/DEV/salvatorx-new/build/tmp/work/aarch64-poky-linux/xen/4.8.0+gitAUTOINC+58bd0c7985-r0/git/tools/libxl/dsdt_anycpu_arm.asl
16: OperationRegion ( MATR, SystemMemory, Add(\_SB.MAPA,
0), 8 )
Error4084 -

 Object does not exist ^  (\_SB.MAPA)

See attached full log [log.do_compile.14752.tbz2].
The original yocto adopts iasl 20120215. I upgraded iasl to 20160527, but
nothing noticeably to me changed, see [log.do_compile.18488.tbz2].

Unfortunately I'm not really familiar with the ACPI stuff so have no ideas
about the issue.
Any suggestions?

Sincerely,
Andrii Anisov.


log.do_compile.14752.tbz2
Description: application/bzip-compressed-tar


log.do_compile.18488.tbz2
Description: application/bzip-compressed-tar
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/3] xen: fix quad word bufioreq handling

>>> On 23.11.16 at 10:48,  wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 23 November 2016 09:24
>> 
>> We should not consume the second slot if it didn't get written yet.
>> Normal writers - i.e. Xen - would not update write_pointer between the
>> two writes, but the page may get fiddled with by the guest itself, and
>> we're better off entering an infinite loop in that case.
>> 
> 
> Xen would never put QEMU in this situation and the guest can't actually 
> modify the page whilst it's in use, since activation of the IOREQ server 
> removes the page from the guest's p2m so the premise of the patch is not 
> correct.

Is that the case even for pre-ioreq-server Xen versions? The issue
here was reported together with what became XSA-197, and it's
not been assigned its own XSA just because there are other ways
for a guest to place high load on its qemu process (and there are
ways to deal with such high load situations).

Jan


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

Re: [Xen-devel] [PATCH] xen/arm: Add support for 16 bit VMIDs

2016-11-23 Thread Bhupinder Thakur

Hi,


 static DECLARE_BITMAP(vmid_mask, MAX_VMID);
>>
>>  void p2m_vmid_allocator_init(void)
>>  {
>> +unsigned int cpu;
>> +
>>  set_bit(INVALID_VMID, vmid_mask);
>> +
>> +max_vmid = MAX_VMID;
>>
>
> max_vmid is only declared for ARM64 and will break compilation for ARM32.
> Please try to build each patch for both architecture before sending to the
> ML.
>
> I will compile for ARM32.


> However, in this case. It would make more sense to keep the maximum vmid
> static for ARM32 as it will never change.
>
>
I quite like what has been done for P2M_ROOT_{LEVEL,ORDER} where the define
> is a constant on ARM32 and point to a variable on ARM64.
>
> I will keep the bitmap statically defined for ARM32. For ARM64 bitmap will
be allocated dynamically.


> +
>> +#ifdef CONFIG_ARM_64
>> +/*
>> + * if any cpu does not support 16-bit VMID then restrict the
>> + * max VMIDs which can be allocated to 256
>> + */
>> +for_each_online_cpu ( cpu )
>> +{
>> +const struct cpuinfo_arm *info = &cpu_data[cpu];
>> +
>> +if ( info->mm64.vmid_bits != VMID_16_BITS_SUPPORT )
>> +{
>> +max_vmid = (1UL << 8);
>> +break;
>> +}
>> +}
>> +#endif
>>
>
> I would rework this code to have max_vmid set to 8 bits by default and the
> turn on 16 bits if available on every CPU.
>
> I will modify the code accordingly.


>  }
>>
>>  static int p2m_alloc_vmid(struct domain *d)
>> @@ -1254,11 +1282,11 @@ static int p2m_alloc_vmid(struct domain *d)
>>
>>  spin_lock(&vmid_alloc_lock);
>>
>> -nr = find_first_zero_bit(vmid_mask, MAX_VMID);
>> +nr = find_first_zero_bit(vmid_mask, max_vmid);
>>
>>  ASSERT(nr != INVALID_VMID);
>>
>> -if ( nr == MAX_VMID )
>> +if ( nr == max_vmid )
>>  {
>>  rc = -EBUSY;
>>  printk(XENLOG_ERR "p2m.c: dom%d: VMID pool exhausted\n",
>> d->domain_id);
>> @@ -1646,6 +1674,10 @@ void __init setup_virt_paging(void)
>>
>>  val |= VTCR_PS(pa_range);
>>  val |= VTCR_TG0_4K;
>> +
>> +/* set the VS bit only if 16 bit VMID is supported */
>> +if ( max_vmid == MAX_VMID )
>>
>
> This check is confusing, I would be clearer to use MAX_VMID_16 or else.
>
> I will explicitly use 16 bit macro


> +val |= VTCR_VS;
>>  val |= VTCR_SL0(pa_range_info[pa_range].sl0);
>>  val |= VTCR_T0SZ(pa_range_info[pa_range].t0sz);
>>
>> diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
>> index fdb6b47..bfcdbf1 100644
>> --- a/xen/include/asm-arm/p2m.h
>> +++ b/xen/include/asm-arm/p2m.h
>> @@ -30,7 +30,7 @@ struct p2m_domain {
>>  struct page_info *root;
>>
>>  /* Current VMID in use */
>> -uint8_t vmid;
>> +uint16_t vmid;
>>
>>  /* Current Translation Table Base Register for the p2m */
>>  uint64_t vttbr;
>> diff --git a/xen/include/asm-arm/processor.h
>> b/xen/include/asm-arm/processor.h
>> index 15bf890..4b6be3d 100644
>> --- a/xen/include/asm-arm/processor.h
>> +++ b/xen/include/asm-arm/processor.h
>> @@ -215,6 +215,7 @@
>>
>>  #define VTCR_PS(x)  ((x)<<16)
>>
>> +#define VTCR_VS(_AC(0x1,UL)<<19)
>>
>
> Newline here please.
>
> Ok.

>  #endif
>>
>>  #define VTCR_RES1   (_AC(1,UL)<<31)
>> @@ -269,6 +270,11 @@
>>  /* FSR long format */
>>  #define FSRL_STATUS_DEBUG   (_AC(0x22,UL)<<0)
>>
>> +#ifdef CONFIG_ARM_64
>> +#define VMID_8_BITS_SUPPORT 0x0
>> +#define VMID_16_BITS_SUPPORT0x2
>> +#endif
>>
>
> I would prefix the 2 define with MM64_ so we know how the values will be
> matched.
>
> You mean I define them like this ?
#define MM64_VMID_8_BITS_SUPPORT   0x0
#define MM64_VMID_16_BITS_SUPPORT 0x2

+
>>  #ifndef __ASSEMBLY__
>>
>>  struct cpuinfo_arm {
>> @@ -337,7 +343,16 @@ struct cpuinfo_arm {
>>  unsigned long tgranule_64K:4;
>>  unsigned long tgranule_4K:4;
>>  unsigned long __res0:32;
>> -   };
>> +
>> +unsigned long hafdbs:4;
>> +unsigned long vmid_bits:4;
>> +unsigned long vh:4;
>> +unsigned long hpds:4;
>> +unsigned long lo:4;
>> +unsigned long pan:4;
>> +unsigned long __res1:8;
>> +unsigned long __res2:32;
>> +};
>>  } mm64;
>>
>>  struct {
>>
>>
> Regards,
>
> --
> Julien Grall
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3] xen_disk: split discard input to match internal representation

The guest sends discard requests as u64 sector/count pairs, but the
block layer operates internally with s64/s32 pairs. The conversion
leads to IO errors in the guest, the discard request is not processed.

  domU.cfg:
  'vdev=xvda, format=qcow2, backendtype=qdisk, target=/x.qcow2'
  domU:
  mkfs.ext4 -F /dev/xvda
  Discarding device blocks: failed - Input/output error

Fix this by splitting the request into chunks of BDRV_REQUEST_MAX_SECTORS.
Add input range checking to avoid overflow.

Fixes f313520 ("xen_disk: add discard support")

Signed-off-by: Olaf Hering 
---
v3:
 turn tab into spaces to fix checkpatch warning
v2:
 adjust overflow check
 add Fixes revspec because the initial commit also failed to convert u64 to s32
 adjust summary

 hw/block/xen_disk.c | 42 --
 1 file changed, 36 insertions(+), 6 deletions(-)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 3a7dc19..456a2d5 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -660,6 +660,38 @@ static void qemu_aio_complete(void *opaque, int ret)
 qemu_bh_schedule(ioreq->blkdev->bh);
 }
 
+static bool blk_split_discard(struct ioreq *ioreq, blkif_sector_t 
sector_number,
+  uint64_t nr_sectors)
+{
+struct XenBlkDev *blkdev = ioreq->blkdev;
+int64_t byte_offset;
+int byte_chunk;
+uint64_t byte_remaining, limit;
+uint64_t sec_start = sector_number;
+uint64_t sec_count = nr_sectors;
+
+/* Wrap around, or overflowing byte limit? */
+if (sec_start + sec_count < sec_count ||
+sec_start + sec_count > INT64_MAX >> BDRV_SECTOR_BITS) {
+return false;
+}
+
+limit = BDRV_REQUEST_MAX_SECTORS << BDRV_SECTOR_BITS;
+byte_offset = sec_start << BDRV_SECTOR_BITS;
+byte_remaining = sec_count << BDRV_SECTOR_BITS;
+
+do {
+byte_chunk = byte_remaining > limit ? limit : byte_remaining;
+ioreq->aio_inflight++;
+blk_aio_pdiscard(blkdev->blk, byte_offset, byte_chunk,
+ qemu_aio_complete, ioreq);
+byte_remaining -= byte_chunk;
+byte_offset += byte_chunk;
+} while (byte_remaining > 0);
+
+return true;
+}
+
 static int ioreq_runio_qemu_aio(struct ioreq *ioreq)
 {
 struct XenBlkDev *blkdev = ioreq->blkdev;
@@ -708,12 +740,10 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq)
 break;
 case BLKIF_OP_DISCARD:
 {
-struct blkif_request_discard *discard_req = (void *)&ioreq->req;
-ioreq->aio_inflight++;
-blk_aio_pdiscard(blkdev->blk,
- discard_req->sector_number << BDRV_SECTOR_BITS,
- discard_req->nr_sectors << BDRV_SECTOR_BITS,
- qemu_aio_complete, ioreq);
+struct blkif_request_discard *req = (void *)&ioreq->req;
+if (!blk_split_discard(ioreq, req->sector_number, req->nr_sectors)) {
+goto err;
+}
 break;
 }
 default:

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

Re: [Xen-devel] [PATCH 1/3] xen: fix quad word bufioreq handling

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 23 November 2016 10:36
> To: Paul Durrant 
> Cc: Anthony Perard ; Stefano Stabellini
> ; xen-devel ;
> qemu-de...@nongnu.org
> Subject: RE: [PATCH 1/3] xen: fix quad word bufioreq handling
> 
> >>> On 23.11.16 at 10:48,  wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: 23 November 2016 09:24
> >>
> >> We should not consume the second slot if it didn't get written yet.
> >> Normal writers - i.e. Xen - would not update write_pointer between the
> >> two writes, but the page may get fiddled with by the guest itself, and
> >> we're better off entering an infinite loop in that case.
> >>
> >
> > Xen would never put QEMU in this situation and the guest can't actually
> > modify the page whilst it's in use, since activation of the IOREQ server
> > removes the page from the guest's p2m so the premise of the patch is not
> > correct.
> 
> Is that the case even for pre-ioreq-server Xen versions? The issue
> here was reported together with what became XSA-197, and it's
> not been assigned its own XSA just because there are other ways
> for a guest to place high load on its qemu process (and there are
> ways to deal with such high load situations).
> 

No, if QEMU is using a default ioreq server (i.e. the legacy way of doing 
things) then it's vulnerable to the guest messing with the rings and I'd 
forgotten that migrated-in guests from old QEMUs also end up using the default 
server, so I guess this is a worthy checkt to make... although maybe it's best 
to just bail if the check fails, since it would indicate a malicious guest.

  Paul

> Jan


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

Re: [Xen-devel] XEN tools for ARM64 build issue

>>> On 23.11.16 at 11:29,  wrote:
> Building latest XEN master branch
> (58bd0c7985890e0292212f94a56235228a3445c3) for salvator-x platform using
> the same yocto as here
> https://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X 
> I've
> faced following issue:
> 
> Maximum error count (200) exceeded
> 
> /home/aanisov/DEV/salvatorx-new/build/tmp/work/aarch64-poky-linux/xen/4.8.0+
> gitAUTOINC+58bd0c7985-r0/git/tools/libxl/dsdt_anycpu_arm.asl
>  3: OperationRegion ( MSUM, SystemMemory, \_SB.MSUA, 1 )
> Error4084 -
> 
>  Object does not exist ^  (\_SB.MSUA)

Looking at the source I see that this statement gets included for
x86 only. Are you perhaps doing a cross build of the ARM tools
on an x86 host? If so, it looks like some work would be needed to
make that work (again? not sure if it ever worked), as there are
various build host architecture conditionals in mk_dsdt.c.

Shannon, it was you who introduced this (in commit c4ac107799),
so would you please take a look?

Jan

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

Re: [Xen-devel] [PATCH] xen_disk: convert discard input to byte ranges

Ping.

On Fri, Nov 18, Olaf Hering wrote:

> On Fri, Nov 18, Olaf Hering wrote:
> 
> > @@ -708,12 +743,10 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq)
> > +if (!blk_split_discard(ioreq, req->sector_number, 
> > req->nr_sectors)) {
> > +goto err;
> 
> How is error handling supposed to work here?
> Initially I forgot the "!", which just hung the mkfs command in domU.
> I have not yet tried to force errors in other part of that function.


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 1/3] x86/HVM: limit writes to incoming TSS during task switch

On 23/11/16 08:27, Jan Beulich wrote:
 On 22.11.16 at 17:32,  wrote:
>> On 22/11/16 13:55, Jan Beulich wrote:
>>> The only field modified (and even that conditionally) is the back link.
>>> Write only that field, and only when it actually has been written to.
>>>
>>> Take the opportunity and also ditch the pointless initializer from the
>>> "tss" local variable.
>> It would help to point out that tss is unconditionally filled completely
>> from guest memory.
>>
>>> Signed-off-by: Jan Beulich 
>> As for the mechanical adjustments here, Reviewed-by: Andrew Cooper
>> 
>>
>> However, is the position of the backlink write actually correct?  I'd
>> have thought that all access to the old tss happen before switching cr3.
> But the backlink gets written into the incoming TSS.

Ah - of course it does.  I was getting confused by the repeated use of
the tss structure.  Sorry for the noise.

~Andrew

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

Re: [Xen-devel] XEN tools for ARM64 build issue

> Looking at the source I see that this statement gets included for
> x86 only. Are you perhaps doing a cross build of the ARM tools
> on an x86 host?
Indeed. I do.

Sincerely,
Andrii Anisov.

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

Re: [Xen-devel] [PATCH] xen_disk: convert discard input to byte ranges

On Wed, Nov 23, Olaf Hering wrote:

> > > +if (!blk_split_discard(ioreq, req->sector_number, 
> > > req->nr_sectors)) {
> > > +goto err;
> > How is error handling supposed to work here?

In the guest the cmd is stuck, instead of getting an IO error:

[   91.966404] mkfs.ext4   D  0  2878   2831 0x
[   91.966406]  88002204bc48 880030530480 88002fae5800 
88002204c000
[   91.966407]   7fff 8000 
024000c0
[   91.966409]  88002204bc60 815dd985 880038815c00 
88002204bd08
[   91.966409] Call Trace:
[   91.966413]  [] schedule+0x35/0x80
[   91.966416]  [] schedule_timeout+0x237/0x2d0
[   91.966419]  [] io_schedule_timeout+0xa6/0x110
[   91.966421]  [] wait_for_completion_io+0xa3/0x110
[   91.966425]  [] submit_bio_wait+0x50/0x60
[   91.966430]  [] blkdev_issue_discard+0x78/0xb0
[   91.966433]  [] blk_ioctl_discard+0x7b/0xa0
[   91.966436]  [] blkdev_ioctl+0x730/0x920
[   91.966440]  [] block_ioctl+0x3d/0x40
[   91.966444]  [] do_vfs_ioctl+0x2cd/0x4a0
[   91.966453]  [] SyS_ioctl+0x74/0x80
[   91.966456]  [] entry_SYSCALL_64_fastpath+0x12/0x6d

Olaf


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

[Xen-devel] [PATCH] x86emul: CMOVcc always writes its destination

This would be benign if there wasn't the zero-extending side effect of
32-bit operations in 64-bit mode.

Signed-off-by: Jan Beulich 

--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -653,6 +653,21 @@ int main(int argc, char **argv)
 printf("okay\n");
 #else
 printf("skipped\n");
+
+printf("%-40s", "Testing cmovz %ecx,%eax...");
+instr[0] = 0x0f; instr[1] = 0x44; instr[2] = 0xc1;
+regs.eflags = 0x200;
+regs.eip= (unsigned long)&instr[0];
+regs.rax= 0x;
+regs.rcx= 0x;
+rc = x86_emulate(&ctxt, &emulops);
+if ( (rc != X86EMUL_OKAY) ||
+ (regs.rax != 0x) ||
+ (regs.rcx != 0x) ||
+ (regs.eflags != 0x200) ||
+ (regs.eip != (unsigned long)&instr[3]) )
+goto fail;
+printf("okay\n");
 #endif
 
 printf("%-40s", "Testing movbe (%%ecx),%%eax...");
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -4784,9 +4784,8 @@ x86_emulate(
 
 case X86EMUL_OPC(0x0f, 0x40) ... X86EMUL_OPC(0x0f, 0x4f): /* cmovcc */
 vcpu_must_have_cmov();
-dst.val = src.val;
-if ( !test_cc(b, _regs.eflags) )
-dst.type = OP_NONE;
+if ( test_cc(b, _regs.eflags) )
+dst.val = src.val;
 break;
 
 case X86EMUL_OPC(0x0f, 0x34): /* sysenter */ {



x86emul: CMOVcc always writes its destination

This would be benign if there wasn't the zero-extending side effect of
32-bit operations in 64-bit mode.

Signed-off-by: Jan Beulich 

--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -653,6 +653,21 @@ int main(int argc, char **argv)
 printf("okay\n");
 #else
 printf("skipped\n");
+
+printf("%-40s", "Testing cmovz %ecx,%eax...");
+instr[0] = 0x0f; instr[1] = 0x44; instr[2] = 0xc1;
+regs.eflags = 0x200;
+regs.eip= (unsigned long)&instr[0];
+regs.rax= 0x;
+regs.rcx= 0x;
+rc = x86_emulate(&ctxt, &emulops);
+if ( (rc != X86EMUL_OKAY) ||
+ (regs.rax != 0x) ||
+ (regs.rcx != 0x) ||
+ (regs.eflags != 0x200) ||
+ (regs.eip != (unsigned long)&instr[3]) )
+goto fail;
+printf("okay\n");
 #endif
 
 printf("%-40s", "Testing movbe (%%ecx),%%eax...");
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -4784,9 +4784,8 @@ x86_emulate(
 
 case X86EMUL_OPC(0x0f, 0x40) ... X86EMUL_OPC(0x0f, 0x4f): /* cmovcc */
 vcpu_must_have_cmov();
-dst.val = src.val;
-if ( !test_cc(b, _regs.eflags) )
-dst.type = OP_NONE;
+if ( test_cc(b, _regs.eflags) )
+dst.val = src.val;
 break;
 
 case X86EMUL_OPC(0x0f, 0x34): /* sysenter */ {
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/3] xen: fix quad word bufioreq handling

>>> On 23.11.16 at 11:45,  wrote:
> No, if QEMU is using a default ioreq server (i.e. the legacy way of doing 
> things) then it's vulnerable to the guest messing with the rings and I'd 
> forgotten that migrated-in guests from old QEMUs also end up using the 
> default 
> server, so I guess this is a worthy checkt to make... although maybe it's 
> best to just bail if the check fails, since it would indicate a malicious 
> guest.

Okay, that's basically the TBD note I have in the patch; I'll wait for
at least one of the qemu maintainers to voice their preference.

Jan


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

Re: [Xen-devel] [Qemu-devel] [PATCH for-2.8 v3] xen_disk: split discard input to match internal representation

2016-11-23 Thread Eric Blake

On 11/23/2016 04:39 AM, Olaf Hering wrote:
> The guest sends discard requests as u64 sector/count pairs, but the
> block layer operates internally with s64/s32 pairs. The conversion
> leads to IO errors in the guest, the discard request is not processed.
> 
>   domU.cfg:
>   'vdev=xvda, format=qcow2, backendtype=qdisk, target=/x.qcow2'
>   domU:
>   mkfs.ext4 -F /dev/xvda
>   Discarding device blocks: failed - Input/output error
> 
> Fix this by splitting the request into chunks of BDRV_REQUEST_MAX_SECTORS.
> Add input range checking to avoid overflow.
> 
> Fixes f313520 ("xen_disk: add discard support")
> 
> Signed-off-by: Olaf Hering 
> ---

Qualifies as a bug fix, so requesting 2.8 inclusion.
Reviewed-by: Eric Blake 

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



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

[Xen-devel] [PATCH v5 2/3] Added document containing governance related todo list

Contains items that at some point need to be addressed.
The items do not directly affect governance.pandoc

Signed-off-by: Lars Kurth 
---
 governance.todo | 23 +++
 1 file changed, 23 insertions(+)
 create mode 100644 governance.todo

diff --git a/governance.todo b/governance.todo
new file mode 100644
index 000..81e068c
--- /dev/null
+++ b/governance.todo
@@ -0,0 +1,23 @@
+This document contains some governance related TODO items that at some point 
+need to be addressed. The items do not directly affect governance.pandoc
+
+### Maintainers
+
+CONSISTENCY ISSUES that probably ought to be cleaned up at some point
+- The xen.git MAINTAINERS file does not list our release managers and 
+  stable branch maintainers
+- We do have a number of repos without MAINTAINERS files, e.g. mini-os.git, 
+  osstest.git
+- For projects with many repositories (e.g. XAPI and Mirage OS), using 
MAINTAINERS 
+  files is not very practical. XAPI seems to sometimes use MAINTAINERS and 
README 
+  files at other times. We may need a more central place to state roles.
+
+### Project Leadership Team and Project Lead
+
+CONSISTENCY ISSUES that probably ought to be cleaned up at some point
+- XAPI and Mirage OS ought to decide who their leadership team is 
+  (I made some assumptions for now)
+
+### Per Sub-Project Governance Specialisation 
+
+- XAPI, WinPV and MirageOS need to provide this information, if they deviate
\ No newline at end of file
-- 
2.5.4 (Apple Git-61)


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

[Xen-devel] [PATCH v5 3/3] Significant changes to decision making; some new roles and minor changes

List of changes
- Added Goal: Local Decision Making
- Split roles into project wide and sub-project specific roles
- Added new roles: Community Manager, Security Response Team, Leadership Team
- Added RTC Policy
- Added +2 ... -2 scheme for expressing opinions more clearly
- Clarified lazy consensus / lazy voting with examples
- Added Informal Votes or Surveys
- Added Project Team Leadership decisions (majority vote, non-monotonicity)
- Clarified and Adapted Conflict Resolution to previous changes
- Updated Elections to cover new roles and terminology
- Changed Project Wide Decision making (per project, non-monotonicity)
- Clarified scope of Decision making
- Added section on Community Decisions with Funding and Legal Implications
- Modified all other sections which have dependencies on changes above
- Added Per Sub-Project Governance Specialisation
- Fixed various typos
- Fixed changelog

Signed-off-by: Lars Kurth 
---
 governance.pandoc | 628 ++
 1 file changed, 496 insertions(+), 132 deletions(-)

diff --git a/governance.pandoc b/governance.pandoc
index 2ce780c..188fa41 100644
--- a/governance.pandoc
+++ b/governance.pandoc
@@ -1,5 +1,5 @@
 This document has come in effect in June 2011 and will be reviewed 
periodically 
-(see revision sections). The last modification has been made in July 2016.
+(see revision sections). The last modification has been made in December 2016.
 
 Content
 ---
@@ -11,8 +11,10 @@ Content
 -   [Making Contributions](#contributions)
 -   [Decision Making, Conflict Resolution, Role Nominations and 
 Elections](#decisions)
--   [Formal Votes](#formal-votes)
+-   [Project Wide Decision Making](#project-decisions)
+-   [Community Decisions with Funding and Legal 
Implications](#funding-and-legal)
 -   [Project Governance](#project-governance)
+-   [Per Sub-Project Governance Specialisations](#specialisations)
 
 Goals {#goals}
 -
@@ -54,7 +56,12 @@ The Xen Project is a meritocracy. The more you contribute 
the more
 responsibility you will earn. Leadership roles in Xen are also merit-based and 
 earned by peer acclaim.
 
-Xen Project Wide Roles {#roles-global}
+### Local Decision Making
+
+The Xen Project consists of a number of sub-projects: each sub-project makes 
+technical and other decisions that solely affect it locally.
+
+Xen Project Wide Roles {#roles-global} 
 --
 
 ### Sub-projects and Teams
@@ -64,9 +71,22 @@ the [Project Governance](#project-governance) (or Project 
Lifecycle) as
 outlined in this document. Sub-projects (sometimes simply referred to as 
 projects) are run by individuals and are often referred to as teams to 
 highlight the collaborative nature of development. For example, each 
-sub-project has a [team portal](/developers/teams.html) on Xenproject.org.
+sub-project has a [team portal](/developers/teams.html) on Xenproject.org. 
+Sub-projects own and are responsible for a collection of source repositories 
+and other resources (e.g. test infrastructure, CI infrastructure, ...), which 
+we call **sub-project assets** (or team assets) in this document.
+
+Sub-projects can either be **incubation projects** or **mature projects** as 
+outlined in [Basic Project Life Cycle](#project-governance). In line with the 
+meritocratic principle, mature projects have more influence than incubation 
+projects, on [project wide decisions](#project-decisions).
+
+### Community Manager
 
-### Xen Project Advisory Board
+The Xen Project has a community manager, whose primary role it is to support 
+the entire Xen Project Community.
+
+### Xen Project Advisory Board {#roles-ab}
 
 The [Xen Project Advisory Board](/join.html) consists of members who are 
 committed to steering the project to advance its market and technical success, 
@@ -76,7 +96,7 @@ shared project infrastructure, marketing and events, and 
managing the Xen
 Project trademark. The Advisory Board leaves all technical decisions to the 
 open source meritocracy.
 
-### The Linux Foundation
+### The Linux Foundation {#roles-lf}
 
 The Xen Project is a [Linux Foundation](/linux-foundation.html) Collaborative 
 Project. Collaborative Projects are independently funded software projects 
that 
@@ -95,21 +115,48 @@ members or other distinguished community members.
 ### Sponsor
 
 To form a new sub-project or team on Xenproject.org, we require a sponsor to 
-support the creation of the new project. A sponsor can be a project lead or 
-committer of a mature project, a member of the advisory board or the community 
-manager. This ensures that a distinguished community member supports the idea 
-behind the project.
+support the creation of the new project. A sponsor can be a member of the 
+project leadership team of a mature project, a member of the advisory board or 
+the community manager. This ensures that a distinguished community member 
+supports the idea behind the project.
 
 Project Team Roles {#roles-local}
 --

[Xen-devel] [PATCH v5 1/3] Code motion changes to make real patches easier to read

Added TOC
Re-arranged sections compared to previous version of document
Added new anchors where needed
Split Roles section into two sections

The actual content was not changed (with the exception of minor
typos that I spotted)

Signed-off-by: Lars Kurth 
---
 governance.pandoc | 207 +-
 1 file changed, 113 insertions(+), 94 deletions(-)

diff --git a/governance.pandoc b/governance.pandoc
index 60fc942..2ce780c 100644
--- a/governance.pandoc
+++ b/governance.pandoc
@@ -1,9 +1,20 @@
-
-This document has come in effect in June 2011 and will be 
-reviewed periodically (see revision sections). The last modification has been 
-made in May 2013.
-
-Goals
+This document has come in effect in June 2011 and will be reviewed 
periodically 
+(see revision sections). The last modification has been made in July 2016.
+
+Content
+---
+
+-   [Goals](#goals)
+-   [Principles](#principles)
+-   [Xen Project Wide Roles](#roles-global)
+-   [Project Team Roles](#roles-local)
+-   [Making Contributions](#contributions)
+-   [Decision Making, Conflict Resolution, Role Nominations and 
+Elections](#decisions)
+-   [Formal Votes](#formal-votes)
+-   [Project Governance](#project-governance)
+
+Goals {#goals}
 -
 
 The goals of Xen Project Governance are to:
@@ -22,7 +33,7 @@ going elsewhere
 -   Set clear expectations to vendors, upstream and downstream projects and 
 community members
 
-Principles
+Principles {#principles}
 --
 
 ### Openness
@@ -43,71 +54,8 @@ The Xen Project is a meritocracy. The more you contribute 
the more
 responsibility you will earn. Leadership roles in Xen are also merit-based and 
 earned by peer acclaim.
 
-### Consensus Decision Making
-
-Sub-projects or teams hosted on Xenproject.org are normally auto-governing and 
-driven by the people who volunteer for the job. This functions well for most 
-cases. When more formal decision making and coordination is required, 
decisions 
-are taken with a lazy consensus approach: a few positive votes with no 
negative 
-vote are enough to get going.
-
-Voting is done with numbers:
-
--   +1 : a positive vote
--   0 : abstain, have no opinion
--   -1 : a negative vote
-
-A negative vote should include an alternative proposal or a detailed 
-explanation of the reasons for the negative vote. The project community then 
-tries to gather consensus on an alternative proposal that resolves the issue. 
-In the great majority of cases, the concerns leading to the negative vote can 
-be addressed.
-
-### Conflict Resolution
-
- Refereeing
-
-Sub-projects and teams hosted on Xenproject.org are not democracies but 
-meritocracies. In situations where there is disagreement on issues related to 
-the day-to-day running of the project, Committers and Project Leads are 
-expected to act as referees and make a decision on behalf of the community. 
-Referees should however consider whether making a decision may be divisive and 
-damaging for the community. In such cases, the committer community of the 
-project can privately vote on an issue, giving the decision more weight.
-
- Last Resort
-
-In some rare cases, the lazy consensus approach may lead to the community 
being 
-paralyzed. Thus, as a last resort when consensus cannot be achieved on a 
-question internal to a project, the final decision will be made by a private 
-majority vote amongst the committers and project lead. If the vote is tied, 
the 
-project lead gets an extra vote to break the tie.
-
-For questions that affect several projects, committers and project leads of 
-mature projects will hold a private majority vote. If the vote is tied, the 
-[Xen Project Advisory Board](/join.html) will break the tie through a casting 
-vote.
-
-Roles
--
-
-### Maintainers
-
-Maintainers own one or several components in the Xen tree. A maintainer 
reviews 
-and approves changes that affect their components. It is a maintainer's prime 
-responsibility to review, comment on, co-ordinate and accept patches from 
other 
-community member's and to maintain the design cohesion of their components. 
-Maintainers are listed in a MAINTAINERS file in the root of the source tree.
-
-### Committers
-
-Committers are Maintainers that are allowed to commit changes into the source 
-code repository. The committer acts on the wishes of the maintainers and 
-applies changes that have been approved by the respective maintainer(s) to the 
-source tree. Due to their status in the community, committers can also act as 
-referees should disagreements amongst maintainers arise. Committers are listed 
-on the sub-project's team portal (e.g. [Hypervisor team 
-portal](/developers/teams/hypervisor.html)).
+Xen Project Wide Roles {#roles-global}
+--
 
 ### Sub-projects and Teams
 
@@ -118,16 +66,6 @@ projects) are run by individuals and are often referred to 
as teams to
 highlight the collaborative nature of development. For example, each 
 sub-projec

[Xen-devel] [PATCH v5 0/3] Significant changes to Xen Project Governance (governance.html) - COMMITTERS PLEASE VOTE ON THE PROPOSAL

THIS IS VERSION 5 OF THIS PATCH AND WE ARE READY FOR FORMAL VOTING, UNLESS
SOMEONE OBJECTS. PEOPLE LISTED AS COMMITTERS IN
- https://xenproject.org/developers/teams/hypervisor.html
- https://xenproject.org/developers/teams/xapi.html
PLEASE VOTE BEFORE DEC 2nd

I made some significant proposed changes to governance.html based on a number 
of issues that were raised in a number of surveys last year, and via other 
means, as well as in the recent discussions related to governance.html changes 
(the issue of too many committers in XAPI and XAPI being able to hijack the 
entire project).

In any case, the changes are expressed in 3 patches governance.pandoc,
which is the pandoc source for governance.html:

- Code motion changes to make real patches easier to read
  No content has been changed
  An index was added
  Fixed some minor typos and formatting issues

- Added document containing governance related todo list
  These do not affect this series and are basically a TODO list for myself

- Significant changes to decision making; some new roles; minor changes
  Added Goal: Local Decision Making
  Split roles into project wide and sub-project specific roles
  Added new roles: Community Manager, Security Response Team, Leadership Team
  Added RTC Policy
  Added +2 ... -2 scheme for expressing opinions more clearly
  Clarified lazy consensus / lazy voting with examples
  Added Informal Votes or Surveys
  Added Project Team Leadership decisions (majority vote, non-monotonicity)
  Clarified and Adapted Conflict Resolution to previous changes
  Updated Elections to cover new roles and terminology
  Changed Project Wide Decision making (per project, non-monotonicity)
  Clarified scope of Decision making
  Added section on Community Decisions with Funding and Legal Implications
  Modified all other sections which have dependencies on changes above
  Added Per Sub-Project Governance Specialisation
  Fixed some typos
  
The patch series is based on git://xenbits.xen.org/people/larsk/governance.git

You can see the changes in my personal git repo at 
http://xenbits.xen.org/gitweb/
?p=people/larsk/governance.git;a=shortlog;h=refs/heads/2016-overhaul-v5

Open Issues to be fixed (but these don't need to be reviewed)
- Fix up tables as these don't render very nicely as html
  Also see http://rapporter.github.io/pander/pandoc_table.html
  
---
Changes since v1
- Agreed and changed counting schemes for lazy consensus/votinh
- Added Community Decisions with Funding and Legal Implications
- Clarified AB role in last resort cases
- Removed comments where superceded by decisions we already made
- Adapted sections with dependencies

Changes since v2
- Fixed minor typographic issues
- Removed comments from the series, as these are distracting
  and make the document harder to review
- Broke out remaining comments that need addressing at some
  point into governance.todo
- Added an extra patch regarding quorum and security team
  members

Changes since v3
- Fixed quorum for global decision making

Changes since v4 (not posted)
- Fixed conversion issues and changelog in document

-- 
2.5.4 (Apple Git-61)


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

[Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.

Make the libxl ACPI support build configurable by the same config
option as the hypervisor side support.

Signed-off-by: Andrii Anisov 
---
 tools/libxl/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index f5053a0..a4e9319 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -90,7 +90,7 @@ acpi:
 
 LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o 
libxl_x86_acpi.o
 LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o libxl_libfdt_compat.o
-ifeq ($(CONFIG_ARM_64),y)
+ifeq ($(CONFIG_ACPI),y)
 DSDT_FILES-y = dsdt_anycpu_arm.c
 LIBXL_OBJS-y += libxl_arm_acpi.o $(patsubst %.c,%.o,$(DSDT_FILES-y))
 dsdt_anycpu_arm.c:
-- 
2.7.4


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

Re: [Xen-devel] [PATCH 1/2] build system: Include SeaBIOS and TianoCore directory

2016-11-23 Thread Konrad Rzeszutek Wilk

On November 23, 2016 5:14:00 AM EST, Wei Liu  wrote:
>On Tue, Nov 22, 2016 at 11:02:04PM -0500, Konrad Rzeszutek Wilk wrote:
>> On Wed, Nov 23, 2016 at 02:39:35AM +, Wei Liu wrote:
>> > On Sun, Nov 20, 2016 at 10:27:21PM -0500, Konrad Rzeszutek Wilk
>wrote:
>> > > The release source did not include those two directories.
>> > > 
>> > > Signed-off-by: Konrad Rzeszutek Wilk 
>> > > ---
>> > >  tools/misc/mktarball | 5 +
>> > >  1 file changed, 5 insertions(+)
>> > > 
>> > > diff --git a/tools/misc/mktarball b/tools/misc/mktarball
>> > > index 73282b5..7942846 100755
>> > > --- a/tools/misc/mktarball
>> > > +++ b/tools/misc/mktarball
>> > > @@ -35,6 +35,11 @@ git_archive_into
>$xen_root/tools/qemu-xen-traditional-dir-remote $tdir/xen-$desc
>> > >  
>> > >  git_archive_into $xen_root/extras/mini-os-remote
>$tdir/xen-$desc/extras/mini-os
>> > >  
>> > > +git_archive_into $xen_root/tools/firmware/seabios-dir-remote
>$tdir/xen-$desc/tools/firmware/seabios-dir
>> > > +
>> > > +if [ -d $xen_root/tools/firmware/ovmf-dir-remote ]; then
>> > 
>> > Is this test really needed? I think subtree-force-update-all will
>clone
>> > ovmf anyway.
>> 
>> I think it only does that if CONFIG_OVMF is in your local .config -
>> which is only the case if you run ./configure --enable-ovmf
>> 
>
>In that case, shouldn't seabios and rombios be treated the same way?
>

Yes. 

And I did have an follow up patch for that but I figured I would wait until Ian 
would chime in with : 'Yeah, no clue why we forgot that', or 'No, because ...'.

I can resend the patches with the last one for completion later tonight.

>> 
>> > 
>> > > +git_archive_into $xen_root/tools/firmware/ovmf-dir-remote
>$tdir/xen-$desc/tools/firmware/ovmf-dir
>> > > +fi
>> > >  GZIP=-9v tar cz -f $xen_root/dist/xen-$desc.tar.gz -C $tdir
>xen-$desc
>> > >  
>> > >  echo "Source tarball in $xen_root/dist/xen-$desc.tar.gz"
>> > > -- 
>> > > 2.9.3
>> > > 
>> > 
>> > ___
>> > Xen-devel mailing list
>> > Xen-devel@lists.xen.org
>> > https://lists.xen.org/xen-devel


Thanks!


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

Re: [Xen-devel] [Qemu-devel] [PATCH for-2.8 v3] xen_disk: split discard input to match internal representation

2016-11-23 Thread Kevin Wolf

Am 23.11.2016 um 12:40 hat Eric Blake geschrieben:
> On 11/23/2016 04:39 AM, Olaf Hering wrote:
> > The guest sends discard requests as u64 sector/count pairs, but the
> > block layer operates internally with s64/s32 pairs. The conversion
> > leads to IO errors in the guest, the discard request is not processed.
> > 
> >   domU.cfg:
> >   'vdev=xvda, format=qcow2, backendtype=qdisk, target=/x.qcow2'
> >   domU:
> >   mkfs.ext4 -F /dev/xvda
> >   Discarding device blocks: failed - Input/output error
> > 
> > Fix this by splitting the request into chunks of BDRV_REQUEST_MAX_SECTORS.
> > Add input range checking to avoid overflow.
> > 
> > Fixes f313520 ("xen_disk: add discard support")
> > 
> > Signed-off-by: Olaf Hering 
> > ---
> 
> Qualifies as a bug fix, so requesting 2.8 inclusion.
> Reviewed-by: Eric Blake 

Stefano, are you going to merge this or should I take a look?

Kevin


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

[Xen-devel] [PATCH v2 XSA-followup for-4.8] libelf: fix symtab/strtab loading for 32bit domains

2016-11-23 Thread Roger Pau Monne

Commit ed04ca introduced a bug in the symtab/strtab loading for 32bit
guests, that corrupted the section headers array due to the padding
introduced by the elf_shdr union.

The Elf section header array on 32bit should be accessible as an array of
Elf32_Shdr elements, and the union with Elf64_Shdr done in elf_shdr was
breaking this due to size differences between Elf32_Shdr and Elf64_Shdr.

Fix this by copying each section header one by one, and using the proper
size depending on the bitness of the guest kernel. While there, also fix
a couple of consistency issues, by making sure we always use the sizes of
our local versions of the ELF header and the ELF sections headers.

Reported-by: Brian Marcotte 
Signed-off-by: Roger Pau Monné 
Acked-by: Ian Jackson 
Reviewed-by: Jan Beulich 
---
Cc: Brian Marcotte 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
Should be backported to Xen 4.7 stable branch.
---
Changes since v5:
 - Fix rebase issues. It seems like a chunk of the patch was lost during the
   rebase to staging.

Changes since v4:
 - Fix consistency issues: make sure the sizes of our local copy of the ELF
   header and the ELF section headers are always used.

Changes since v3:
 - Move the definition of elf_sym_header into libelf-loader.c.

Changes since v2:
 - Use offsetof to correctly account for the memory used by the elf header.

Changes since v1:
 - No need to calculate shdr_size again, it's already fetched from the
   original elf header.
 - Remove shdr variable.
 - Use offsetof instead of subtracting two sizeofs.
 - Fix elf_parse_bsdsyms so that it takes into account the size of elf_ehdr
   instead of the size of the native elf header.
---
 xen/common/libelf/libelf-loader.c | 78 ---
 1 file changed, 57 insertions(+), 21 deletions(-)

diff --git a/xen/common/libelf/libelf-loader.c 
b/xen/common/libelf/libelf-loader.c
index d67e0a7..4e12a71 100644
--- a/xen/common/libelf/libelf-loader.c
+++ b/xen/common/libelf/libelf-loader.c
@@ -21,10 +21,17 @@
 
 #include "libelf-private.h"
 
+/*  */
+
 /* Number of section header needed in order to fit the SYMTAB and STRTAB. */
 #define ELF_BSDSYM_SECTIONS 3
-
-/*  */
+struct elf_sym_header {
+uint32_t size;
+struct {
+elf_ehdr header;
+elf_shdr section[ELF_BSDSYM_SECTIONS];
+} elf_header;
+} __attribute__((packed));
 
 elf_errorstatus elf_init(struct elf_binary *elf, const char *image_input, 
size_t size)
 {
@@ -172,9 +179,10 @@ void elf_parse_bsdsyms(struct elf_binary *elf, uint64_t 
pstart)
 /* Space to store the size of the elf image */
 sz = sizeof(uint32_t);
 
-/* Space for the elf and elf section headers */
-sz += elf_uval(elf, elf->ehdr, e_ehsize) +
-  ELF_BSDSYM_SECTIONS * elf_uval(elf, elf->ehdr, e_shentsize);
+/* Space for the ELF header and section headers */
+sz += offsetof(struct elf_sym_header, elf_header.section) +
+  ELF_BSDSYM_SECTIONS * (elf_64bit(elf) ? sizeof(Elf64_Shdr) :
+  sizeof(Elf32_Shdr));
 sz = elf_round_up(elf, sz);
 
 /*
@@ -251,18 +259,11 @@ static void elf_load_bsdsyms(struct elf_binary *elf)
  * strtab, so we only need three section headers in our fake ELF
  * header (first section header is always the undefined section).
  */
-struct {
-uint32_t size;
-struct {
-elf_ehdr header;
-elf_shdr section[ELF_BSDSYM_SECTIONS];
-} __attribute__((packed)) elf_header;
-} __attribute__((packed)) header;
-
+struct elf_sym_header header;
 ELF_HANDLE_DECL(elf_ehdr) header_handle;
-unsigned long shdr_size;
+unsigned long shdr_size, ehdr_size, header_size;
 ELF_HANDLE_DECL(elf_shdr) section_handle;
-unsigned int link, rc;
+unsigned int link, rc, i;
 elf_ptrval header_base;
 elf_ptrval elf_header_base;
 elf_ptrval symtab_base;
@@ -297,12 +298,28 @@ do {  
  \
   sizeof(uint32_t);
 symtab_base = elf_round_up(elf, header_base + sizeof(header));
 
+/*
+ * Set the size of the ELF header and the section headers, based on the
+ * size of our local copy.
+ */
+ehdr_size = elf_64bit(elf) ? sizeof(header.elf_header.header.e64) :
+ sizeof(header.elf_header.header.e32);
+shdr_size = elf_64bit(elf) ? sizeof(header.elf_header.section[0].e64) :
+ sizeof(header.elf_header.section[0].e32);
+
 /* Fill the ELF header, copied from the original ELF header. */
 header_handle = ELF_MAKE_HANDLE(elf_ehdr,
 ELF_REALPTR2PTRVAL(&header.elf_header.header))

[Xen-devel] [PATCH KERNEL] xen/events: use xen_vcpu_id mapping for EVTCHNOP_status

2016-11-23 Thread Vitaly Kuznetsov

EVTCHNOP_status hypercall returns Xen's idea of vcpu id so we need to
compare it against xen_vcpu_id mapping, not the Linux cpu id.

Suggested-by: Radim Krcmar 
Signed-off-by: Vitaly Kuznetsov 
---
 drivers/xen/events/events_base.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 9ecfcdc..137bd0e 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -948,7 +948,7 @@ static int find_virq(unsigned int virq, unsigned int cpu)
continue;
if (status.status != EVTCHNSTAT_virq)
continue;
-   if (status.u.virq == virq && status.vcpu == cpu) {
+   if (status.u.virq == virq && status.vcpu == xen_vcpu_nr(cpu)) {
rc = port;
break;
}
-- 
2.7.4


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

[Xen-devel] [distros-debian-squeeze test] 68084: tolerable FAIL

2016-11-23 Thread Platform Team regression test user

flight 68084 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68084/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-amd64-squeeze-netboot-pygrub 9 debian-di-install fail like 
68048
 test-amd64-amd64-i386-squeeze-netboot-pygrub 9 debian-di-install fail like 
68048
 test-amd64-i386-amd64-squeeze-netboot-pygrub 9 debian-di-install fail like 
68048
 test-amd64-i386-i386-squeeze-netboot-pygrub 9 debian-di-install fail like 68048

baseline version:
 flight   68048

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-squeeze-netboot-pygrubfail
 test-amd64-i386-amd64-squeeze-netboot-pygrub fail
 test-amd64-amd64-i386-squeeze-netboot-pygrub fail
 test-amd64-i386-i386-squeeze-netboot-pygrub  fail



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.


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

[Xen-devel] [PATCH v2 XSA-followup for-4.8] libelf: fix symtab/strtab loading for 32bit domains

2016-11-23 Thread Roger Pau Monné

From: Roger Pau Monne 

Commit ed04ca introduced a bug in the symtab/strtab loading for 32bit
guests, that corrupted the section headers array due to the padding
introduced by the elf_shdr union.

The Elf section header array on 32bit should be accessible as an array of
Elf32_Shdr elements, and the union with Elf64_Shdr done in elf_shdr was
breaking this due to size differences between Elf32_Shdr and Elf64_Shdr.

Fix this by copying each section header one by one, and using the proper
size depending on the bitness of the guest kernel. While there, also fix
a couple of consistency issues, by making sure we always use the sizes of
our local versions of the ELF header and the ELF sections headers.

Reported-by: Brian Marcotte 
Signed-off-by: Roger Pau Monné 
Acked-by: Ian Jackson 
Reviewed-by: Jan Beulich 
---
Cc: Brian Marcotte 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
Should be backported to Xen 4.7 stable branch.
---
Changes since v5:
 - Fix rebase issues. It seems like a chunk of the patch was lost during the
   rebase to staging.

Changes since v4:
 - Fix consistency issues: make sure the sizes of our local copy of the ELF
   header and the ELF section headers are always used.

Changes since v3:
 - Move the definition of elf_sym_header into libelf-loader.c.

Changes since v2:
 - Use offsetof to correctly account for the memory used by the elf header.

Changes since v1:
 - No need to calculate shdr_size again, it's already fetched from the
   original elf header.
 - Remove shdr variable.
 - Use offsetof instead of subtracting two sizeofs.
 - Fix elf_parse_bsdsyms so that it takes into account the size of elf_ehdr
   instead of the size of the native elf header.
---
 xen/common/libelf/libelf-loader.c | 78 ---
 1 file changed, 57 insertions(+), 21 deletions(-)

diff --git a/xen/common/libelf/libelf-loader.c 
b/xen/common/libelf/libelf-loader.c
index d67e0a7..4e12a71 100644
--- a/xen/common/libelf/libelf-loader.c
+++ b/xen/common/libelf/libelf-loader.c
@@ -21,10 +21,17 @@
 
 #include "libelf-private.h"
 
+/*  */
+
 /* Number of section header needed in order to fit the SYMTAB and STRTAB. */
 #define ELF_BSDSYM_SECTIONS 3
-
-/*  */
+struct elf_sym_header {
+uint32_t size;
+struct {
+elf_ehdr header;
+elf_shdr section[ELF_BSDSYM_SECTIONS];
+} elf_header;
+} __attribute__((packed));
 
 elf_errorstatus elf_init(struct elf_binary *elf, const char *image_input, 
size_t size)
 {
@@ -172,9 +179,10 @@ void elf_parse_bsdsyms(struct elf_binary *elf, uint64_t 
pstart)
 /* Space to store the size of the elf image */
 sz = sizeof(uint32_t);
 
-/* Space for the elf and elf section headers */
-sz += elf_uval(elf, elf->ehdr, e_ehsize) +
-  ELF_BSDSYM_SECTIONS * elf_uval(elf, elf->ehdr, e_shentsize);
+/* Space for the ELF header and section headers */
+sz += offsetof(struct elf_sym_header, elf_header.section) +
+  ELF_BSDSYM_SECTIONS * (elf_64bit(elf) ? sizeof(Elf64_Shdr) :
+  sizeof(Elf32_Shdr));
 sz = elf_round_up(elf, sz);
 
 /*
@@ -251,18 +259,11 @@ static void elf_load_bsdsyms(struct elf_binary *elf)
  * strtab, so we only need three section headers in our fake ELF
  * header (first section header is always the undefined section).
  */
-struct {
-uint32_t size;
-struct {
-elf_ehdr header;
-elf_shdr section[ELF_BSDSYM_SECTIONS];
-} __attribute__((packed)) elf_header;
-} __attribute__((packed)) header;
-
+struct elf_sym_header header;
 ELF_HANDLE_DECL(elf_ehdr) header_handle;
-unsigned long shdr_size;
+unsigned long shdr_size, ehdr_size, header_size;
 ELF_HANDLE_DECL(elf_shdr) section_handle;
-unsigned int link, rc;
+unsigned int link, rc, i;
 elf_ptrval header_base;
 elf_ptrval elf_header_base;
 elf_ptrval symtab_base;
@@ -297,12 +298,28 @@ do {  
  \
   sizeof(uint32_t);
 symtab_base = elf_round_up(elf, header_base + sizeof(header));
 
+/*
+ * Set the size of the ELF header and the section headers, based on the
+ * size of our local copy.
+ */
+ehdr_size = elf_64bit(elf) ? sizeof(header.elf_header.header.e64) :
+ sizeof(header.elf_header.header.e32);
+shdr_size = elf_64bit(elf) ? sizeof(header.elf_header.section[0].e64) :
+ sizeof(header.elf_header.section[0].e32);
+
 /* Fill the ELF header, copied from the original ELF header. */
 header_handle = ELF_MAKE_HANDLE(elf_ehdr,
 ELF_REALPTR2PTRVAL(&he

Re: [Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.


Hello,

On 23/11/16 12:25, Andrii Anisov wrote:

Make the libxl ACPI support build configurable by the same config
option as the hypervisor side support.


This will not work because Kconfig support only exists for the hypervisor.

Furthermore, people may want to disable ACPI for the host but still 
support ACPI for guest.


The way forward is to have an option in the configure to opt-out the 
support of guest ACPI and also remove the iasl check.


Regards,



Signed-off-by: Andrii Anisov 
---
 tools/libxl/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index f5053a0..a4e9319 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -90,7 +90,7 @@ acpi:

 LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o 
libxl_x86_acpi.o
 LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o libxl_libfdt_compat.o
-ifeq ($(CONFIG_ARM_64),y)
+ifeq ($(CONFIG_ACPI),y)
 DSDT_FILES-y = dsdt_anycpu_arm.c
 LIBXL_OBJS-y += libxl_arm_acpi.o $(patsubst %.c,%.o,$(DSDT_FILES-y))
 dsdt_anycpu_arm.c:



--
Julien Grall

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

[Xen-devel] [xen-4.4-testing baseline-only test] 68083: tolerable FAIL

2016-11-23 Thread Platform Team regression test user

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl19 guest-start/debian.repeat fail baseline untested
 test-amd64-amd64-xl-credit2 19 guest-start/debian.repeat fail baseline untested
 test-amd64-i386-xl-qemuu-ovmf-amd64 13 guest-localmigrate fail baseline 
untested
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop  fail baseline untested
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop   fail baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop  fail baseline untested
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail 
baseline untested
 test-amd64-i386-xend-qemut-winxpsp3  9 windows-install  fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 build-amd64-rumprun   6 xen-buildfail   never pass
 build-i386-rumprun6 xen-buildfail   never pass
 test-xtf-amd64-amd64-2   10 xtf-fep  fail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-xtf-amd64-amd64-2   51 xtf/test-pv32pae-pv-iopl~hypercall fail never pass
 test-xtf-amd64-amd64-252 xtf/test-pv32pae-pv-iopl~vmassist fail never pass
 test-xtf-amd64-amd64-5   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-2  59 xtf/test-pv64-pv-iopl~hypercall fail never pass
 test-xtf-amd64-amd64-2   60 xtf/test-pv64-pv-iopl~vmassist fail never pass
 test-xtf-amd64-amd64-1   10 xtf-fep  fail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-xtf-amd64-amd64-1   20 xtf/test-hvm32-invlpg~shadow fail   never pass
 test-xtf-amd64-amd64-1  29 xtf/test-hvm32pae-invlpg~shadow fail never pass
 test-xtf-amd64-amd64-5   51 xtf/test-pv32pae-pv-iopl~hypercall fail never pass
 test-xtf-amd64-amd64-552 xtf/test-pv32pae-pv-iopl~vmassist fail never pass
 test-xtf-amd64-amd64-5  59 xtf/test-pv64-pv-iopl~hypercall fail never pass
 test-xtf-amd64-amd64-5   60 xtf/test-pv64-pv-iopl~vmassist fail never pass
 test-xtf-amd64-amd64-1   40 xtf/test-hvm64-invlpg~shadow fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-1   51 xtf/test-pv32pae-pv-iopl~hypercall fail never pass
 test-xtf-amd64-amd64-152 xtf/test-pv32pae-pv-iopl~vmassist fail never pass
 test-xtf-amd64-amd64-1  59 xtf/test-pv64-pv-iopl~hypercall fail never pass
 test-xtf-amd64-amd64-1   60 xtf/test-pv64-pv-iopl~vmassist fail never pass
 test-xtf-amd64-amd64-4   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-3   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-4   20 xtf/test-hvm32-invlpg~shadow fail   never pass
 test-xtf-amd64-amd64-4  29 xtf/test-hvm32pae-invlpg~shadow fail never pass
 test-xtf-amd64-amd64-4   40 xtf/test-hvm64-invlpg~shadow fail   never pass
 test-xtf-amd64-amd64-4   51 xtf/test-pv32pae-pv-iopl~hypercall fail never pass
 test-xtf-amd64-amd64-452 xtf/test-pv32pae-pv-iopl~vmassist fail never pass
 test-xtf-amd64-amd64-3   51 xtf/test-pv32pae-pv-iopl~hypercall fail never pass
 test-xtf-amd64-amd64-4  59 xtf/test-pv64-pv-iopl~hypercall fail never pass
 test-xtf-amd64-amd64-352 xtf/test-pv32pae-pv-iopl~vmassist fail never pass
 test-xtf-amd64-amd64-4   60 xtf/test-pv64-pv-iopl~vmassist fail never pass
 test-xtf-amd64-amd64-3  59 xtf/test-pv64-pv-iopl~hypercall fail never pass
 test-xtf-amd64-amd64-3   60 xtf/test-pv64-pv-iopl~vmassist fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 11 guest-start  fail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-inst

Re: [Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.

> This will not work because Kconfig support only exists for the hypervisor.

So I totally confused where CONFIG_ARM_64 is defined for tools.

Sincerely,
Andrii Anisov.

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

Re: [Xen-devel] [PATCH] xen/arm: Add support for 16 bit VMIDs


On 23/11/16 10:38, Bhupinder Thakur wrote:

Hi,


Hi Bhupinder,

Can you configure your e-mail client to use ">" to quote the previous 
answer? Using tab makes the mail quite confusing. Thank you.




 static DECLARE_BITMAP(vmid_mask, MAX_VMID);

 void p2m_vmid_allocator_init(void)
 {
+unsigned int cpu;
+
 set_bit(INVALID_VMID, vmid_mask);
+
+max_vmid = MAX_VMID;


max_vmid is only declared for ARM64 and will break compilation for
ARM32. Please try to build each patch for both architecture before
sending to the ML.

I will compile for ARM32.


However, in this case. It would make more sense to keep the maximum
vmid static for ARM32 as it will never change.


I quite like what has been done for P2M_ROOT_{LEVEL,ORDER} where the
define is a constant on ARM32 and point to a variable on ARM64.

I will keep the bitmap statically defined for ARM32. For ARM64 bitmap
will be allocated dynamically.


I am not asking the bitmap to be static but the number of vmid to be a 
constant (not a variable) for ARM32.


I prefer to have the bitmap dynamic on both architecture because it is 
will be easier to maintain the code in long term.


What I was asking for is:

#ifdef CONFIG_ARM_64
/* The VMID is encoded on 8-bit minimum. */
static unsigned int __read_mostly max_vmid = MAX_VMID_8BIT;
#define MAX_VMID max_vmid
#else
/* The VMID is always encoded on 8-bit */
#define MAX_VMID MAX_VMID_8BIT
#endif

The code would use MAX_VMID and the variable max_vmid would only be 
defined for arm64 breaking the compilation directly if used in the 
common code.


[...]


 #endif

 #define VTCR_RES1   (_AC(1,UL)<<31)
@@ -269,6 +270,11 @@
 /* FSR long format */
 #define FSRL_STATUS_DEBUG   (_AC(0x22,UL)<<0)

+#ifdef CONFIG_ARM_64
+#define VMID_8_BITS_SUPPORT 0x0
+#define VMID_16_BITS_SUPPORT0x2
+#endif


I would prefix the 2 define with MM64_ so we know how the values
will be matched.

You mean I define them like this ?
#define MM64_VMID_8_BITS_SUPPORT   0x0
#define MM64_VMID_16_BITS_SUPPORT 0x2


Yes, or any other name mentioning the register name in the define. This 
is how are defined all the register constant within this file.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.

On Wed, Nov 23, 2016 at 03:03:54PM +0200, Andrii Anisov wrote:
> > This will not work because Kconfig support only exists for the hypervisor.
> 
> So I totally confused where CONFIG_ARM_64 is defined for tools.
> 

It is defined in config/arm64.mk, which is included by various
makefiles.


> Sincerely,
> Andrii Anisov.

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

Re: [Xen-devel] [PATCH v2 XSA-followup for-4.8] libelf: fix symtab/strtab loading for 32bit domains

On Wed, Nov 23, 2016 at 12:27:38PM +, Roger Pau Monne wrote:
> Commit ed04ca introduced a bug in the symtab/strtab loading for 32bit
> guests, that corrupted the section headers array due to the padding
> introduced by the elf_shdr union.
> 
> The Elf section header array on 32bit should be accessible as an array of
> Elf32_Shdr elements, and the union with Elf64_Shdr done in elf_shdr was
> breaking this due to size differences between Elf32_Shdr and Elf64_Shdr.
> 
> Fix this by copying each section header one by one, and using the proper
> size depending on the bitness of the guest kernel. While there, also fix
> a couple of consistency issues, by making sure we always use the sizes of
> our local versions of the ELF header and the ELF sections headers.
> 
> Reported-by: Brian Marcotte 
> Signed-off-by: Roger Pau Monné 
> Acked-by: Ian Jackson 
> Reviewed-by: Jan Beulich 

Applied.

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

Re: [Xen-devel] [PATCH v3 01/11] x86/domctl: Add XEN_DOMCTL_set_avail_vcpus

2016-11-23 Thread Boris Ostrovsky

On 11/23/2016 03:09 AM, Jan Beulich wrote:
 On 23.11.16 at 00:47,  wrote:
>> I have a prototype that replaces XEN_DOMCTL_set_avail_vcpus with 
>> XEN_DOMCTL_acpi_access and it seems to work OK. The toolstack needs to 
>> perform two (or more, if >32 VCPUs) hypercalls and the logic on the 
>> hypervisor side is almost the same as the ioreq handling that this 
>> series added in patch 8.
> Why would there be multiple hypercalls needed? (I guess I may need
> to see the prototype to understand.)

The interface is

#define XEN_DOMCTL_acpi_access 81
struct xen_domctl_acpi_access {
uint8_t rw;
uint8_t bytes;
uint16_t port;
uint32_t val;
};

And so as an example, to add VCPU1 to already existing VCPU0:

/* Update the VCPU map*/
val = 3;
xc_acpi_access(ctx->xch, domid, WRITE, 0xaf00, 1/*bytes*/, &val);

/* Set event status in GPE block */
val= 1 << 2;
xc_acpi_access(ctx->xch, domid, WRITE, 0xafe0, 1/*bytes*/, &val);


If we want to support ACPI registers in memory space then we need to add
'uint8_t space' and extend val to uint64_t. We also may want to make val
a uint64_t to have fewer hypercalls for VCPU map updates. (We could, in
fact, pass a pointer to the map but I think a scalar is cleaner.)


>
>> However, I now realized that this interface will not be available to PV 
>> guests (and it will only become available to HVM guests when we move 
>> hotplug from qemu to hypervisor). And it's x86-specific.
> As you make clear below, the PV aspect is likely a non-issue. But
> why is this x86-specific? It's generic ACPI, isn't it?

Mostly because I don't know how ARM handles hotplug. I was told that ARM
does not use PRST, it uses PSCI, which I am not familiar with.

The interface is generic enough to be used by any architecture.

-boris

>
>
>> This means that PV guests will not know what the number of available 
>> VCPUs is and therefore we will not be able to enforce it. OTOH we don't 
>> know how to do that anyway since PV guests bring up all VCPUs and then 
>> offline them.
>>
>> -boris
>
>



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

Re: [Xen-devel] [RFC] Shared coprocessor framework

Stefano,

Please see my answers below:
>
> Thank you for the document, I think is a very good start. I also see the
> need for this framework. Please add more details about the proposed
> interface (Xen API, hypercalls, etc) in the next version; I am looking
> forward to it.

We will come up with the document update once we have it agreed internally.

>> AA> Due to the fact that some domain assigned a vcoproc could access coproc 
>> when
>> AA> it is running another domain context, framework will implement iomem 
>> access
>> AA> emulation for domains which are not provided coproc at the moment of 
>> access.
>
> This is certainly going to be the hardest part. I take the framework is
> just going to provide a generic API for implementing a coprocessor
> emulator and it is going to be up to each coprocessor implementation to
> provide the code.

This piece together with the context switching logic is definitely a
platform specific stuff and its complexity could be different
coprocessor to coprocessor.
Registers access emultaion for not running vcopro is expected to be
not very complex for our case:
- saved context return on register read
- stacking on writes to be executed during switching context to that vcoproc
- rare more complex corner cases

> Is the emulator going to live in the Xen hypervisor?
That is the idea.

> It would be nice to provide a simple coprocessor example, if you have one.
I'm not really sure about a simple functional example. We are
targeting GPU sharing for the first drop.

Sincerely,
Andrii Anisov.

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

Re: [Xen-devel] [PATCH v3 01/11] x86/domctl: Add XEN_DOMCTL_set_avail_vcpus

>>> On 23.11.16 at 14:33,  wrote:
> On 11/23/2016 03:09 AM, Jan Beulich wrote:
> On 23.11.16 at 00:47,  wrote:
>>> I have a prototype that replaces XEN_DOMCTL_set_avail_vcpus with 
>>> XEN_DOMCTL_acpi_access and it seems to work OK. The toolstack needs to 
>>> perform two (or more, if >32 VCPUs) hypercalls and the logic on the 
>>> hypervisor side is almost the same as the ioreq handling that this 
>>> series added in patch 8.
>> Why would there be multiple hypercalls needed? (I guess I may need
>> to see the prototype to understand.)
> 
> The interface is
> 
> #define XEN_DOMCTL_acpi_access 81
> struct xen_domctl_acpi_access {
> uint8_t rw;
> uint8_t bytes;
> uint16_t port;
> uint32_t val;
> };
> 
> And so as an example, to add VCPU1 to already existing VCPU0:
> 
> /* Update the VCPU map*/
> val = 3;
> xc_acpi_access(ctx->xch, domid, WRITE, 0xaf00, 1/*bytes*/, &val);
> 
> /* Set event status in GPE block */
> val= 1 << 2;
> xc_acpi_access(ctx->xch, domid, WRITE, 0xafe0, 1/*bytes*/, &val);
> 
> 
> If we want to support ACPI registers in memory space then we need to add
> 'uint8_t space' and extend val to uint64_t.

It's a domctl, so we can change it down the road, but of course if
would be nice if this was supporting a proper GAS (without access
width I guess) from the beginning.

> We also may want to make val
> a uint64_t to have fewer hypercalls for VCPU map updates. (We could, in
> fact, pass a pointer to the map but I think a scalar is cleaner.)

Well, mostly re-using GAS layout, we'd allow for up to 255 bits
per operation. That might be fine for now, but the need for the
caller to break things up seems awkward to me, so I'd in fact
lean towards passing a handle.

Jan


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

Re: [Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.

> It is defined in config/arm64.mk, which is included by various
> makefiles.
As I got, it is included by Config.mk which consequently included by
different makefiles in hypervisor, tools, docs, stubdom.
It looks like a piece of legasy configuration code, I see moves of
CONFIG_ options from it to Kconfig.

I guess extending that file is not acceptable, so I hope to be back
soon with modifications suggested by Julien:
>The way forward is to have an option in the configure to opt-out the support 
>of guest ACPI and also remove the iasl check.

Sincerely,
Andrii Anisov.

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

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

2016-11-23 Thread Iurii Mykhalskyi

Dear all,

Andrii, thanks for the remark - I'll rework this patch.

Julien, I have updated yocto layer [1] to use the most recent stable Xen
version - Xen 4.8-rc6

Looks like used patches for Xen should be described more briefly:
1. 0001-arm64-renesas-Introduce-early-console-for-Salvator-X.patch  - Early
console introduction for Salvator-X board
2. 0002-libxl-Hack-fix-compilation-on-arm64.patch  - required by to fix
build issue, described here [2]. I haven't found any better solution except
this one.
3. 0003-HACK-Fix-compilation-issues.patch  - is a hack to avoid acpi
compilation issue on arm64 platform. Looks like Andrii faces same problem
[3] [4].
4. 0004-Enable-XSM.patch - enable XSM for arm64 build - this patch is not
essential, but xsm might be usefull for some use-cases.
5. 0005-xen-arm-domain_build-allocate-lowmem-for-dom0-as-muc.patch -
Salvator-X board has 4GB RAM, but has only 32bit DMA controller - so, if
Dom0 will be allocated at over 4GB space - DMA operation will fail.
According to xen-devel list [5], this patch planned to be included in
Xen 4.9.
6. 0006-Do-no-trap-smc-instructions.patch - Renesas use OP-TEE out of box,
but by default Xen traps such calls, so we have to allow such actions.

[1] https://github.com/qbeeukraine/meta-platform-xen
[2] https://lists.xen.org/archives/html/xen-devel/2015-12/msg00137.html
[3] https://lists.xen.org/archives/html/xen-devel/2016-11/msg01903.html
[4] https://lists.xen.org/archives/html/xen-devel/2016-11/msg01930.html
[5] https://lists.xen.org/archives/html/xen-devel/2016-09/msg02561.html

In last email you have written:
> Also, it is not clear to me why you need a specific device tree and
hacked DOM0 linux (see [2]) on this board for Xen. This would need some
documentation on the wiki.

Yes, this need some explanation. I'll update related wiki page in few hours.

Thanks for all of your comments.

With the best regards,
Iurii Mykhalskyi

On Tue, Nov 22, 2016 at 1:20 PM, Andrii Anisov 
wrote:

> Well,
>
> > This patch https://github.com/qbeeukraine/meta-platform-xen/blob/2.12/
> minimal/meta-rcar-gen3-xen/recipes-bsp/u-boot/u-boot/
> 0002-arm-fdt-Don-t-touch-memory-node-from-full-U-Boot-in-.patch
> > Is a total mess.
> It seems you've lost some code and related history during porting the
> original patch.
>
> Sincerely,
> Andrii Anisov.
>
> On Tue, Nov 22, 2016 at 12:59 PM, Andrii Anisov 
> wrote:
>
>> Dear Iurii,
>>
>> This patch https://github.com/qbeeukraine/meta-platform-xen/blob/2.12/m
>> inimal/meta-rcar-gen3-xen/recipes-bsp/u-boot/u-boot/0002-
>> arm-fdt-Don-t-touch-memory-node-from-full-U-Boot-in-.patch
>> Is a total mess. Somewhy you check defined CONFIG_XEN to introduce the
>> arch_fixup_fdt() function, which, as per you idea, is not needed to be
>> built for the XEN boot. You have no patch lines to introduce CONFIG_XEN so
>> the code works.
>> Also arch_fixup_fdt() not only mangles memory nodes, so it is not right
>> to drop whole the function.
>>
>> But the problem in that piece of code still exists:
>>
>>- u-boot updates the first memory node in the dtb with all memory
>>banks it found in the board code, does not take into consideration other
>>memory nodes
>>- as a result memory banks in device tree are duplicated
>>- unlike the kernel which tolerates that mess from u-boot, XEN does
>>not accept memory banks are duplicated and crashes.
>>
>> Putting all memory banks into one memory node in the device tree is the
>> simplest workaround.
>> I'm not really sure where should be a proper fix. Should it be on u-boot
>> or XEN side?
>>
>> Sincerely,
>> Andrii Anisov.
>>
>>
>

-- 

Iurii Mykhalskyi | Senior Software Engineer
GlobalLogic
P +38.044.492.9695x3664  M +38.096.311.5467  S mad-nemoi
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.

On Wed, Nov 23, 2016 at 03:59:54PM +0200, Andrii Anisov wrote:
> > It is defined in config/arm64.mk, which is included by various
> > makefiles.
> As I got, it is included by Config.mk which consequently included by
> different makefiles in hypervisor, tools, docs, stubdom.
> It looks like a piece of legasy configuration code, I see moves of
> CONFIG_ options from it to Kconfig.
> 
> I guess extending that file is not acceptable, so I hope to be back

I think it would be fine to add other CONFIG_* to those files.

> soon with modifications suggested by Julien:
> >The way forward is to have an option in the configure to opt-out the
> >support of guest ACPI and also remove the iasl check.

But before you write any code, let me try to understand the real issue
first: you're trying to cross-build ARM tools on x86, but x86
iasl doesn't support ARM ACPI definition(s), right?

> 
> Sincerely,
> Andrii Anisov.

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

Re: [Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.

> But before you write any code, let me try to understand the real issue
> first: you're trying to cross-build ARM tools on x86, but x86
> iasl doesn't support ARM ACPI definition(s), right?
Well, as I stated here [1], I'm pretty far from ACPI and understanding
of what's going wrong with the compilation. But I have a strong
feeling that this option should be optional.

[1] https://lists.xenproject.org/archives/html/xen-devel/2016-11/msg01903.html

Sincerely,
Andrii Anisov.

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

Re: [Xen-devel] [PATCH v3 01/11] x86/domctl: Add XEN_DOMCTL_set_avail_vcpus

2016-11-23 Thread Boris Ostrovsky

On 11/23/2016 08:58 AM, Jan Beulich wrote:
 On 23.11.16 at 14:33,  wrote:
>> On 11/23/2016 03:09 AM, Jan Beulich wrote:
>> On 23.11.16 at 00:47,  wrote:
 I have a prototype that replaces XEN_DOMCTL_set_avail_vcpus with 
 XEN_DOMCTL_acpi_access and it seems to work OK. The toolstack needs to 
 perform two (or more, if >32 VCPUs) hypercalls and the logic on the 
 hypervisor side is almost the same as the ioreq handling that this 
 series added in patch 8.
>>> Why would there be multiple hypercalls needed? (I guess I may need
>>> to see the prototype to understand.)
>> The interface is
>>
>> #define XEN_DOMCTL_acpi_access 81
>> struct xen_domctl_acpi_access {
>> uint8_t rw;
>> uint8_t bytes;
>> uint16_t port;
>> uint32_t val;
>> };
>>
>> And so as an example, to add VCPU1 to already existing VCPU0:
>>
>> /* Update the VCPU map*/
>> val = 3;
>> xc_acpi_access(ctx->xch, domid, WRITE, 0xaf00, 1/*bytes*/, &val);
>>
>> /* Set event status in GPE block */
>> val= 1 << 2;
>> xc_acpi_access(ctx->xch, domid, WRITE, 0xafe0, 1/*bytes*/, &val);
>>
>>
>> If we want to support ACPI registers in memory space then we need to add
>> 'uint8_t space' and extend val to uint64_t.

This obviously was meant to be 'port', not 'val'.

> It's a domctl, so we can change it down the road, but of course if
> would be nice if this was supporting a proper GAS (without access
> width I guess) from the beginning.
>
>> We also may want to make val
>> a uint64_t to have fewer hypercalls for VCPU map updates. (We could, in
>> fact, pass a pointer to the map but I think a scalar is cleaner.)
> Well, mostly re-using GAS layout, we'd allow for up to 255 bits
> per operation. That might be fine for now, but the need for the
> caller to break things up seems awkward to me, so I'd in fact
> lean towards passing a handle.

I haven't thought about representing this as proper GAS. Then it looks
like we can have up to 256 bits worth of data and then pass the handle.
We may still need to make more than one call to read or write full VCPU
map but that should be be an exceedingly rare event, e.g. when we add
more than 256 VCPUs at once. And since we can only have 128 VCPUs now we
don't need to support this in the toolstack right away.
Of course, this still requires two hypercalls --- one for map update and
one for GPE.

-boris


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

[Xen-devel] [PATCH RFC] docs/designs: PV stats interface

This patch introduces a design proposal for an interface to used by
guest PV drivers or agents to convey statistics to a monitoring agent
running in a toolstack domain.

Signed-off-by: Paul Durrant 
---
RFC at the moment since this is a first draft and it is not yet
prototyped
---
 docs/designs/pv_stats.markdown | 116 +
 1 file changed, 116 insertions(+)
 create mode 100755 docs/designs/pv_stats.markdown

diff --git a/docs/designs/pv_stats.markdown b/docs/designs/pv_stats.markdown
new file mode 100755
index 000..4189369
--- /dev/null
+++ b/docs/designs/pv_stats.markdown
@@ -0,0 +1,116 @@
+# Statistics Interface for PV Drivers/Agents
+
+## Background
+
+It is common for guest PV drivers or agents to communicate statistics to an
+agent running in a toolstack domain so that these can be displayed via a UI,
+or even influence guest placement etc. The mechanism for conveying these
+statistics is currently ad-hoc, undocumented, and usually based on xenstore.
+
+Whilst xenstore does indeed provide a convenient mechanism, the lack of
+documentation and standardisation of the protocols used creates
+compatibility issues for PV drivers or agents not tied to a specific
+product or environment. Also, the guest xenstore quota and the single
+instance of xenstored can easily become scalability issues.
+
+## Proposal
+
+The proposed interface is intended to be used only for the purposes of
+conveying statistics from guest PV drivers or agents to an agent or agents
+running in a toolstack domain. It is not intended for bulk data transfer,
+nor as another means of control of the PV drivers or agents by the
+toolstack domain.
+
+PV drivers or agents typically publish multiple related sets of statistics.
+For example, a PV network frontend may publish statistics relating to
+received traffic and transmitted traffic. These sets are likely to be
+updated asynchronously from each other and therefore it makes sense that
+they can be separated such that a monitoring agent can refresh its view of
+them asynchronously. It is therefore proposed that a two-level hierarchy of
+xenstore keys is used to advertise sets of guest statistics.
+
+The toolstack will create a writeable top-level `stats` key in the guest
+space. Under this each guest statistics *provider* creates a key its name,
+e.g. `Network #0`. This key acts as a parent to keys that then name each
+set of statistics that it provides, e.g. `Tx`. Under the key for a
+particular set the provider then writes entries containing grant references
+of pages containing the names and values of the statistics in that set, and
+an event channel to be used for signalling e.g.:
+
+name-type-ref0 = 10
+name-type-ref1 = 11
+val-ref0 = 12
+val-ref1 = 13
+event-channel = 10
+
+The provider must always write the `event-channel` key after all the other
+keys have been written such that a monitoring agent with a watch on the
+guest's top-level `stats` key can make the assumption that it is safe to
+sample all other keys once that key has been written. Thus no explicit
+`state` key is required.
+
+There are separate references for pages containing the names and types of
+the statistics and the values of those statistics since it is required that
+the names and types do not change and hence a monitoring agent need only
+sample them once and can do so as soon as the as the `name-ref` keys are
+valid. The format of each (*name, type*) tuple is as follows:
+
+struct stats_name_type {
+   uint8_t type;
+   char name[63];
+};
+
+and the possible types are:
+
+#define STATS_TYPE_S64 1
+#define STATS_TYPE_U64 2
+#define STATS_TYPE_DOUBLE  3
+#define STATS_TYPE_ASCII   4
+
+The `name` must be a NUL terminated ASCII string containing only
+alphanumeric characters, printable non-alphanumeric characters or a space
+character, i.e. the expression:
+
+(isalnum(name[i]) || ispunct(name[i]) || name[i] == ' ')
+
+must be true for each value of `i` until `name[i] == '\0'`
+
+When iterating through the `stats_name_type` structures a monitoring agents
+can determine that it has finished when it either encounters a `type` value
+of 0, or it has iterated through all 64 structures in the granted page and
+there are no further `name-type-ref` keys.
+
+A monitoring agent can find the value of a statistic by noting the
+`name-type-ref` index and the offset into the page where the
+`stats_name_type` was found and the looking at the same offset in the
+corresponding `val-ref` page. Values are therefore also 64 octets
+in length and contain:
+
+* `STATS_TYPE_S64` : A signed 64-bit integer in little endian form in
+octets 0..7
+* `STATS_TYPE_U64` : An unsigned 64-bit integer in little endian form in
+octets 0..7
+* `STATS_TYPE_DOUBLE` : A double precision floating point value in little
+   endian form in
+   octets 0..7
+* `

Re: [Xen-devel] [PATCH 0/3] x86/HVM: XSA-192 follow-ups

On Tue, Nov 22, 2016 at 06:51:27AM -0700, Jan Beulich wrote:
> 1: limit writes to incoming TSS during task switch
> 2: limit writes to outgoing TSS during task switch
> 3: correct error code writing during task switch
> 
> Signed-off-by: Jan Beulich 
> 

Release-acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 0/2] x86emul: recent XSA follow-up

On Tue, Nov 22, 2016 at 07:09:04AM -0700, Jan Beulich wrote:
> These aren't outright bug fixes, so aren't strictly candidates for 4.8,
> but I think they're still worthwhile to consider.
> 
> 1: simplify DstBitBase handling code
> 2: in_longmode() should not ignore ->read_msr() errors
> 
> Signed-off-by: Jan Beulich 
> 

Release-acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

Iurii,

About the following:

> 2. 0002-libxl-Hack-fix-compilation-on-arm64.patch  - required by to fix
> build issue, described here [2]. I haven't found any better solution except
> this one.

Please review this [1] thread.

[1] https://lists.xenproject.org/archives/html/xen-devel/2016-11/msg01921.html

Sincerely,
Andrii Anisov.

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

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

Dear Iurii,

Following:
> 2. 0002-libxl-Hack-fix-compilation-on-arm64.patch  - required by to fix
> build issue, described here [2]. I haven't found any better solution except
> this one.

Is not needed.
The issue does not appear with the current master HEAD.

Sincerely,
Andrii Anisov.


On Wed, Nov 23, 2016 at 4:00 PM, Iurii Mykhalskyi
 wrote:
> Dear all,
>
> Andrii, thanks for the remark - I'll rework this patch.
>
> Julien, I have updated yocto layer [1] to use the most recent stable Xen
> version - Xen 4.8-rc6
>
> Looks like used patches for Xen should be described more briefly:
> 1. 0001-arm64-renesas-Introduce-early-console-for-Salvator-X.patch  - Early
> console introduction for Salvator-X board

> 3. 0003-HACK-Fix-compilation-issues.patch  - is a hack to avoid acpi
> compilation issue on arm64 platform. Looks like Andrii faces same problem
> [3] [4].
> 4. 0004-Enable-XSM.patch - enable XSM for arm64 build - this patch is not
> essential, but xsm might be usefull for some use-cases.
> 5. 0005-xen-arm-domain_build-allocate-lowmem-for-dom0-as-muc.patch -
> Salvator-X board has 4GB RAM, but has only 32bit DMA controller - so, if
> Dom0 will be allocated at over 4GB space - DMA operation will fail.
> According to xen-devel list [5], this patch planned to be included in
> Xen 4.9.
> 6. 0006-Do-no-trap-smc-instructions.patch - Renesas use OP-TEE out of box,
> but by default Xen traps such calls, so we have to allow such actions.
>
> [1] https://github.com/qbeeukraine/meta-platform-xen
> [2] https://lists.xen.org/archives/html/xen-devel/2015-12/msg00137.html
> [3] https://lists.xen.org/archives/html/xen-devel/2016-11/msg01903.html
> [4] https://lists.xen.org/archives/html/xen-devel/2016-11/msg01930.html
> [5] https://lists.xen.org/archives/html/xen-devel/2016-09/msg02561.html
>
> In last email you have written:
>> Also, it is not clear to me why you need a specific device tree and hacked
>> DOM0 linux (see [2]) on this board for Xen. This would need some
>> documentation on the wiki.
>
> Yes, this need some explanation. I'll update related wiki page in few hours.
>
> Thanks for all of your comments.
>
> With the best regards,
> Iurii Mykhalskyi
>
>
>
> On Tue, Nov 22, 2016 at 1:20 PM, Andrii Anisov 
> wrote:
>>
>> Well,
>>
>> > This patch
>> > https://github.com/qbeeukraine/meta-platform-xen/blob/2.12/minimal/meta-rcar-gen3-xen/recipes-bsp/u-boot/u-boot/0002-arm-fdt-Don-t-touch-memory-node-from-full-U-Boot-in-.patch
>> > Is a total mess.
>> It seems you've lost some code and related history during porting the
>> original patch.
>>
>> Sincerely,
>> Andrii Anisov.
>>
>> On Tue, Nov 22, 2016 at 12:59 PM, Andrii Anisov 
>> wrote:
>>>
>>> Dear Iurii,
>>>
>>> This patch
>>> https://github.com/qbeeukraine/meta-platform-xen/blob/2.12/minimal/meta-rcar-gen3-xen/recipes-bsp/u-boot/u-boot/0002-arm-fdt-Don-t-touch-memory-node-from-full-U-Boot-in-.patch
>>> Is a total mess. Somewhy you check defined CONFIG_XEN to introduce the
>>> arch_fixup_fdt() function, which, as per you idea, is not needed to be built
>>> for the XEN boot. You have no patch lines to introduce CONFIG_XEN so the
>>> code works.
>>> Also arch_fixup_fdt() not only mangles memory nodes, so it is not right
>>> to drop whole the function.
>>>
>>> But the problem in that piece of code still exists:
>>>
>>> u-boot updates the first memory node in the dtb with all memory banks it
>>> found in the board code, does not take into consideration other memory nodes
>>> as a result memory banks in device tree are duplicated
>>> unlike the kernel which tolerates that mess from u-boot, XEN does not
>>> accept memory banks are duplicated and crashes.
>>>
>>> Putting all memory banks into one memory node in the device tree is the
>>> simplest workaround.
>>> I'm not really sure where should be a proper fix. Should it be on u-boot
>>> or XEN side?
>>>
>>> Sincerely,
>>> Andrii Anisov.
>>>
>>
>
>
>
> --
>
> Iurii Mykhalskyi | Senior Software Engineer
> GlobalLogic
> P +38.044.492.9695x3664  M +38.096.311.5467  S mad-nemoi
> www.globallogic.com
>
> http://www.globallogic.com/email_disclaimer.txt

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

Re: [Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.

>>> On 23.11.16 at 15:05,  wrote:
> But before you write any code, let me try to understand the real issue
> first: you're trying to cross-build ARM tools on x86, but x86
> iasl doesn't support ARM ACPI definition(s), right?

No, the problem is that Shannon has broken cross builds of libacpi's
mk_dsdt.c (see my reply to Andrii's original problem report at
lists.xenproject.org/archives/html/xen-devel/2016-11/msg01903.html).

Jan

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

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

2016-11-23 Thread Iurii Mykhalskyi

Dear Andrii and all,

On Wed, Nov 23, 2016 at 4:15 PM, Andrii Anisov 
wrote:

> Iurii,
>
> About the following:
>
> > 2. 0002-libxl-Hack-fix-compilation-on-arm64.patch  - required by to fix
> > build issue, described here [2]. I haven't found any better solution
> except
> > this one.
>
> Please review this [1] thread.
>
> [1] https://lists.xenproject.org/archives/html/xen-devel/2016-
> 11/msg01921.html

I have made typos,  Description to 2 & 3 items should exchanged vise-versa.

But I don't agree with this patch - ACPI sould be enable only for ARM64
platforms - in your patch it can be enable for both platforms, depending on
CONFIG_ACPI flag state.

>
>
> Sincerely,
> Andrii Anisov.
>

Thanks for your comments.

With the best regards,
Iurii Mykhalskyi

-- 

Iurii Mykhalskyi | Senior Software Engineer
GlobalLogic
P +38.044.492.9695x3664  M +38.096.311.5467  S mad-nemoi
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.

On Wed, Nov 23, 2016 at 04:12:28PM +0200, Andrii Anisov wrote:
> > But before you write any code, let me try to understand the real issue
> > first: you're trying to cross-build ARM tools on x86, but x86
> > iasl doesn't support ARM ACPI definition(s), right?
> Well, as I stated here [1], I'm pretty far from ACPI and understanding
> of what's going wrong with the compilation. But I have a strong
> feeling that this option should be optional.
> 
> [1] https://lists.xenproject.org/archives/html/xen-devel/2016-11/msg01903.html

What is the exact rune you got when compiling mk_dsdt ?

If everything it set up properly you should be using a cross-build gcc
which should have the correct architecture?

Can you try this (untested) patch?


diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
index ccc32c9..2b9d5b8 100644
--- a/tools/libacpi/Makefile
+++ b/tools/libacpi/Makefile
@@ -44,7 +44,7 @@ $(H_SRC): $(ACPI_BUILD_DIR)/%.h: %.asl iasl
rm -f $(addprefix $(ACPI_BUILD_DIR)/, $*.aml $*.hex)
  
 $(MK_DSDT): mk_dsdt.c
-   $(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -D__XEN_TOOLS__ -o $@ 
mk_dsdt.c
+   $(CC) $(CFLAGS) $(CFLAGS_xeninclude) -D__XEN_TOOLS__ -o $@ mk_dsdt.c
 
 $(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl dsdt_acpi_info.asl 
$(MK_DSDT)
# Remove last bracket

> 
> Sincerely,
> Andrii Anisov.

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

Re: [Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.


Hi Wei,

On 23/11/16 14:29, Wei Liu wrote:

On Wed, Nov 23, 2016 at 04:12:28PM +0200, Andrii Anisov wrote:

But before you write any code, let me try to understand the real issue
first: you're trying to cross-build ARM tools on x86, but x86
iasl doesn't support ARM ACPI definition(s), right?

Well, as I stated here [1], I'm pretty far from ACPI and understanding
of what's going wrong with the compilation. But I have a strong
feeling that this option should be optional.

[1] https://lists.xenproject.org/archives/html/xen-devel/2016-11/msg01903.html


What is the exact rune you got when compiling mk_dsdt ?

If everything it set up properly you should be using a cross-build gcc
which should have the correct architecture?

Can you try this (untested) patch?


diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
index ccc32c9..2b9d5b8 100644
--- a/tools/libacpi/Makefile
+++ b/tools/libacpi/Makefile
@@ -44,7 +44,7 @@ $(H_SRC): $(ACPI_BUILD_DIR)/%.h: %.asl iasl
rm -f $(addprefix $(ACPI_BUILD_DIR)/, $*.aml $*.hex)

 $(MK_DSDT): mk_dsdt.c
-   $(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -D__XEN_TOOLS__ -o $@ 
mk_dsdt.c
+   $(CC) $(CFLAGS) $(CFLAGS_xeninclude) -D__XEN_TOOLS__ -o $@ mk_dsdt.c


That will not work, CC will build an ARM binary. However mk_dsdt is used 
to generate the static ACPI table integrated in the libxl, so mk_dsdt 
needs to be built with HOSTCC.


I think the code should use CONFIG_ARM_64/CONFIG_ARM_32 rather than 
__*__ one.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.

On Wed, Nov 23, 2016 at 02:34:04PM +, Julien Grall wrote:
> Hi Wei,
> 
> On 23/11/16 14:29, Wei Liu wrote:
> >On Wed, Nov 23, 2016 at 04:12:28PM +0200, Andrii Anisov wrote:
> >>>But before you write any code, let me try to understand the real issue
> >>>first: you're trying to cross-build ARM tools on x86, but x86
> >>>iasl doesn't support ARM ACPI definition(s), right?
> >>Well, as I stated here [1], I'm pretty far from ACPI and understanding
> >>of what's going wrong with the compilation. But I have a strong
> >>feeling that this option should be optional.
> >>
> >>[1] 
> >>https://lists.xenproject.org/archives/html/xen-devel/2016-11/msg01903.html
> >
> >What is the exact rune you got when compiling mk_dsdt ?
> >
> >If everything it set up properly you should be using a cross-build gcc
> >which should have the correct architecture?
> >
> >Can you try this (untested) patch?
> >
> >
> >diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
> >index ccc32c9..2b9d5b8 100644
> >--- a/tools/libacpi/Makefile
> >+++ b/tools/libacpi/Makefile
> >@@ -44,7 +44,7 @@ $(H_SRC): $(ACPI_BUILD_DIR)/%.h: %.asl iasl
> > rm -f $(addprefix $(ACPI_BUILD_DIR)/, $*.aml $*.hex)
> >
> > $(MK_DSDT): mk_dsdt.c
> >-$(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -D__XEN_TOOLS__ -o $@ 
> >mk_dsdt.c
> >+$(CC) $(CFLAGS) $(CFLAGS_xeninclude) -D__XEN_TOOLS__ -o $@ mk_dsdt.c
> 
> That will not work, CC will build an ARM binary. However mk_dsdt is used to
> generate the static ACPI table integrated in the libxl, so mk_dsdt needs to
> be built with HOSTCC.

Yes, you're right.

> 
> I think the code should use CONFIG_ARM_64/CONFIG_ARM_32 rather than __*__
> one.
> 

That might work -- provided they are defined even in a cross-build.

> Regards,
> 
> -- 
> Julien Grall

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

Re: [Xen-devel] [PATCH v2] OvmfPkg/build.sh: Make GCC5 the default toolchain, catch GCC43 and earlier

2016-11-23 Thread Laszlo Ersek

On 11/23/16 03:36, Konrad Rzeszutek Wilk wrote:
> From Laszlo:
> " change the catch-all (*) to GCC5, from GCC44
> - remove the (5.*.*) pattern from GCC49
> - add a branch (with multiple patterns if necessary) for gcc-4.3 and
>   earlier to exit with an error message / failure (those compiler
>   versions are unsupported)"
> 
> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=62
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
> v1: First submission
> v2: Redo it per Laszlo suggestion.
> 
>  OvmfPkg/build.sh | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
> index eb5eb73..cab7c70 100755
> --- a/OvmfPkg/build.sh
> +++ b/OvmfPkg/build.sh
> @@ -83,6 +83,13 @@ case `uname` in
>Linux*)
>  gcc_version=$(gcc -v 2>&1 | tail -1 | awk '{print $3}')
>  case $gcc_version in
> +  4.1.[0-0].*|4.2.*|4.3.*)

* The [0-0] bracketed expression will work as expected, but it's
somewhat unusual :) Is it intentional?

* If it's a typo, are you okay if I replace it with a plain 0 on commit?

* Also, IIRC, Olaf considered pre-4.0 gcc releases as well (rejecting
them of course), which is sort of meant as part of "gcc-4.3 and
earlier". But, given your extensive testing with old distros (thanks for
that!), I think it's safe to ignore pre-4.0 gcc releases altogether.

Reviewed-by: Laszlo Ersek 

Thanks!
Laszlo

> +echo OvmfPkg requires GCC4.4 or later
> +exit 1
> +;;
> +  4.4.*)
> +TARGET_TOOLS=GCC44
> +;;
>4.5.*)
>  TARGET_TOOLS=GCC45
>  ;;
> @@ -95,11 +102,11 @@ case `uname` in
>4.8.*)
>  TARGET_TOOLS=GCC48
>  ;;
> -  4.9.*|4.1[0-9].*|5.*.*)
> +  4.9.*)
>  TARGET_TOOLS=GCC49
>  ;;
>*)
> -TARGET_TOOLS=GCC44
> +TARGET_TOOLS=GCC5
>  ;;
>  esac
>  esac
> 


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

Re: [Xen-devel] [PATCH v2] OvmfPkg/build.sh: Make GCC5 the default toolchain, catch GCC43 and earlier

2016-11-23 Thread Laszlo Ersek

On 11/23/16 15:55, Laszlo Ersek wrote:
> On 11/23/16 03:36, Konrad Rzeszutek Wilk wrote:
>> From Laszlo:
>> " change the catch-all (*) to GCC5, from GCC44
>> - remove the (5.*.*) pattern from GCC49
>> - add a branch (with multiple patterns if necessary) for gcc-4.3 and
>>   earlier to exit with an error message / failure (those compiler
>>   versions are unsupported)"
>>
>> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=62
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Konrad Rzeszutek Wilk 
>> ---
>> v1: First submission
>> v2: Redo it per Laszlo suggestion.
>>
>>  OvmfPkg/build.sh | 11 +--
>>  1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
>> index eb5eb73..cab7c70 100755
>> --- a/OvmfPkg/build.sh
>> +++ b/OvmfPkg/build.sh
>> @@ -83,6 +83,13 @@ case `uname` in
>>Linux*)
>>  gcc_version=$(gcc -v 2>&1 | tail -1 | awk '{print $3}')
>>  case $gcc_version in
>> +  4.1.[0-0].*|4.2.*|4.3.*)
> 
> * The [0-0] bracketed expression will work as expected, but it's
> somewhat unusual :) Is it intentional?
> 
> * If it's a typo, are you okay if I replace it with a plain 0 on commit?

On a second thought, perhaps you meant

  4.0.*|4.1.*|4.2.*|4.3.*)

or

  4.[0-3].*)

If you wish to re-submit for this, we could consider those pre-4
releases as well:

  [1-3].*|4.[0-3].*)

Thanks!
Laszlo

> * Also, IIRC, Olaf considered pre-4.0 gcc releases as well (rejecting
> them of course), which is sort of meant as part of "gcc-4.3 and
> earlier". But, given your extensive testing with old distros (thanks for
> that!), I think it's safe to ignore pre-4.0 gcc releases altogether.
> 
> Reviewed-by: Laszlo Ersek 
> 
> Thanks!
> Laszlo
> 
>> +echo OvmfPkg requires GCC4.4 or later
>> +exit 1
>> +;;
>> +  4.4.*)
>> +TARGET_TOOLS=GCC44
>> +;;
>>4.5.*)
>>  TARGET_TOOLS=GCC45
>>  ;;
>> @@ -95,11 +102,11 @@ case `uname` in
>>4.8.*)
>>  TARGET_TOOLS=GCC48
>>  ;;
>> -  4.9.*|4.1[0-9].*|5.*.*)
>> +  4.9.*)
>>  TARGET_TOOLS=GCC49
>>  ;;
>>*)
>> -TARGET_TOOLS=GCC44
>> +TARGET_TOOLS=GCC5
>>  ;;
>>  esac
>>  esac
>>
> 


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

Re: [Xen-devel] [PATCH v2] OvmfPkg/build.sh: Make GCC5 the default toolchain, catch GCC43 and earlier

2016-11-23 Thread Konrad Rzeszutek Wilk

On Wed, Nov 23, 2016 at 03:55:11PM +0100, Laszlo Ersek wrote:
> On 11/23/16 03:36, Konrad Rzeszutek Wilk wrote:
> > From Laszlo:
> > " change the catch-all (*) to GCC5, from GCC44
> > - remove the (5.*.*) pattern from GCC49
> > - add a branch (with multiple patterns if necessary) for gcc-4.3 and
> >   earlier to exit with an error message / failure (those compiler
> >   versions are unsupported)"
> > 
> > Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=62
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Konrad Rzeszutek Wilk 
> > ---
> > v1: First submission
> > v2: Redo it per Laszlo suggestion.
> > 
> >  OvmfPkg/build.sh | 11 +--
> >  1 file changed, 9 insertions(+), 2 deletions(-)
> > 
> > diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
> > index eb5eb73..cab7c70 100755
> > --- a/OvmfPkg/build.sh
> > +++ b/OvmfPkg/build.sh
> > @@ -83,6 +83,13 @@ case `uname` in
> >Linux*)
> >  gcc_version=$(gcc -v 2>&1 | tail -1 | awk '{print $3}')
> >  case $gcc_version in
> > +  4.1.[0-0].*|4.2.*|4.3.*)
> 
> * The [0-0] bracketed expression will work as expected, but it's
> somewhat unusual :) Is it intentional?
> 
> * If it's a typo, are you okay if I replace it with a plain 0 on commit?

It is a typo! It was 0-9 but I forgot to type 'git commit --amend'. Argh!

Are you OK doing:

 s/[0-0]/[0-9]/

when you commit or would you prefer I repost this with this in _and_ with
your Reviewed-by?

> 
> * Also, IIRC, Olaf considered pre-4.0 gcc releases as well (rejecting
> them of course), which is sort of meant as part of "gcc-4.3 and
> earlier". But, given your extensive testing with old distros (thanks for

Oh gosh.
> that!), I think it's safe to ignore pre-4.0 gcc releases altogether.

Yes :-)
> 
> Reviewed-by: Laszlo Ersek 
> 
> Thanks!
> Laszlo
> 
> > +echo OvmfPkg requires GCC4.4 or later
> > +exit 1
> > +;;
> > +  4.4.*)
> > +TARGET_TOOLS=GCC44
> > +;;
> >4.5.*)
> >  TARGET_TOOLS=GCC45
> >  ;;
> > @@ -95,11 +102,11 @@ case `uname` in
> >4.8.*)
> >  TARGET_TOOLS=GCC48
> >  ;;
> > -  4.9.*|4.1[0-9].*|5.*.*)
> > +  4.9.*)
> >  TARGET_TOOLS=GCC49
> >  ;;
> >*)
> > -TARGET_TOOLS=GCC44
> > +TARGET_TOOLS=GCC5
> >  ;;
> >  esac
> >  esac
> > 
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

On 23/11/16 14:00, Iurii Mykhalskyi wrote:

Dear all,

Hello Iurii,

Julien, I have updated yocto layer [1] to use the most recent stable Xen
version - Xen 4.8-rc6

Can you explain why you want to impose a specific version of Xen to the
user of this board?

If Xen does not work out-of-box on this box, then you should work
towards upstreaming the missing pieces.

Also, the way you wrote the page and hook into the main wiki page [6]
will mislead the user because it gives the impression that you can boot
xen upstream on the board without any change.

So the wiki page needs to be rewritten to make clear that you are not
using Xen upstream nor Linux upstream but a custom one maintained by you.

Looks like used patches for Xen should be described more briefly:
1. 0001-arm64-renesas-Introduce-early-console-for-Salvator-X.patch -
Early console introduction for Salvator-X board

Patch already posted and will be included in the next version.

2. 0002-libxl-Hack-fix-compilation-on-arm64.patch - required by to fix
build issue, described here [2]. I haven't found any better solution
except this one.

Rather than carrying hack on Xen, I would highly recommend you to work
with the community to fix them upstream. This is a win-win situation for
everyone.

3. 0003-HACK-Fix-compilation-issues.patch - is a hack to avoid acpi
compilation issue on arm64 platform. Looks like Andrii faces same
problem [3] [4].

We are working with Andrii to fix this.

4. 0004-Enable-XSM.patch - enable XSM for arm64 build - this patch is
not essential, but xsm might be usefull for some use-cases.

You impose the user a specific configuration with option that are not
necessary. The wiki should compile the minimal way to use Xen on this
platform, i.e:

- version of Xen
- version of Linux
- DTS used
- U-boot

If you want to use yocto, then fine. But you have to explain what is
done and how the user can modify it.

5. 0005-xen-arm-domain_build-allocate-lowmem-for-dom0-as-muc.patch -
Salvator-X board has 4GB RAM, but has only 32bit DMA controller - so, if
Dom0 will be allocated at over 4GB space - DMA operation will fail.
According to xen-devel list [5], this patch planned to be included
in Xen 4.9.
6. 0006-Do-no-trap-smc-instructions.patch - Renesas use OP-TEE out of
box, but by default Xen traps such calls, so we have to allow such actions.

This patch allows all the guests to issue an SMC. Are you aware that you
open a security hole for any user using your recipes to build Xen?

Regarding the limitation you pointed on the wiki page [7], you can use
platform specific code (see specific_mapping and blacklist_dev) rather
hacking the device tree. This is my preferred way and avoid the user to
have to port the hack when upgrade the kernel if the DT needs some upgrade.

To conclude, it looks like to me that Xen is not yet ready to officially
support this board.

I will be happy to review any of these patches when they will be sent
upstream.

Regards,

[1] https://github.com/qbeeukraine/meta-platform-xen

[2] https://lists.xen.org/archives/html/xen-devel/2015-12/msg00137.html

[3] https://lists.xen.org/archives/html/xen-devel/2016-11/msg01903.html

[4] https://lists.xen.org/archives/html/xen-devel/2016-11/msg01930.html

[5] https://lists.xen.org/archives/html/xen-devel/2016-09/msg02561.html

[6] https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions
[7]
https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X#Known_limitations

--
Julien Grall

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

Re: [Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.


Hello Andrii,

On 23/11/16 14:12, Andrii Anisov wrote:

But before you write any code, let me try to understand the real issue
first: you're trying to cross-build ARM tools on x86, but x86
iasl doesn't support ARM ACPI definition(s), right?

Well, as I stated here [1], I'm pretty far from ACPI and understanding
of what's going wrong with the compilation. But I have a strong
feeling that this option should be optional.


The ACPI support is pretty much contained in a single file and I am not 
sure you will win much space. Can you explain why the ACPI guest support 
should be optional?


Regards,



[1] https://lists.xenproject.org/archives/html/xen-devel/2016-11/msg01903.html

Sincerely,
Andrii Anisov.



--
Julien Grall

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

Re: [Xen-devel] Xen ARM small task (WAS: Re: [Xen Question])

2016-11-23 Thread Artem Mygaiev

On 22.11.16 21:36, Julien Grall wrote:
> On 22/11/16 19:06, Stefano Stabellini wrote:
>> On Mon, 21 Nov 2016, Julien Grall wrote:
>>> On 21/11/2016 21:13, Edgar E. Iglesias wrote:
 On Mon, Nov 21, 2016 at 01:01:15PM -0800, Stefano Stabellini wrote:
> On Mon, 21 Nov 2016, Edgar E. Iglesias wrote:
>> On Fri, Nov 18, 2016 at 10:58:42AM -0800, Stefano Stabellini wrote:
>>> On Thu, 17 Nov 2016, Julien Grall wrote:
 Hi Stefano,

 On 17/11/2016 11:26, Stefano Stabellini wrote:
> On Mon, 14 Nov 2016, Julien Grall wrote:
>> On 11/11/2016 13:55, Stefano Stabellini wrote:
>>> On Fri, 11 Nov 2016, Julien Grall wrote:
 On 11/11/2016 02:24, Stefano Stabellini wrote:
> On Thu, 10 Nov 2016, Julien Grall wrote:
>> (CC Stefano and change the title)
>> On 10/11/16 12:13, casionwoo wrote:
>>> I’m pleased about your reply and you have a lot of
>>> code to
>>> clean-up.
>>>
>>> As you mentioned, It’s really huge to digest at once.
>>> Thank you
>>> for
>>> understanding me.
>>>
>>> And that’s why i need a small fix up and todo list.
>>>
>>> I feel familiar with ARM and c language and there’s no
>>> specific
>>> area
>>> yet.
>>>
>>> I think that i can find interesting area with
>>> following up the
>>> codes.
>>>
>>> I’m looking forward to being stuck on Xen.
>>>
>>> Then it would be easier for me to understand about Xen
>>> on ARM.
>>>
>>> Please let me know the TODO and bug-fix lists.
>>
>> Stefano, before giving a list of code clean-up, do you
>> have any
>> small
>> TODO
>> on
>> ARM in mind?
>
> A simple task we talked about recently is to enable the
> vuart
> (xen/arch/arm/vuart.c) for all guests. At the moment it is
> only
> emulated
> for Dom0, but some guests, in particular BareMetal guests
> (https://en.wikipedia.org/wiki/BareMetal), would benefit
> from it.
>
> It would be best to introduce an option in libxl to
> explicitly
> enable/disable the vuart for DomUs. Something like vuart=1
> in the VM
> config file.

 The vuart has not been enabled for DomU because it the UART
 region may
 clash
 with the guest memory layout (which is static).

 I don't think this option should be available until we allow
 the guest
 to
 use
 the same memory layout as the host (see e820_host parameter
 for x86).
>>>
>>> Actually there is no reason for the vuart to use the same
>>> address as
>>> the physical uart on the platform, is there?
>>> In fact it doesn't even
>>> have to prentend to be the same uart as the one on the board,
>>> right?
>>> The vuart MMIO address could be completely configurable and
>>> independent
>>> from the one of the physical uart.
>>
>> There is no reason to use the same information as the physical
>> UART.
>>
>> However, the vuart requires quite a few information (e.g base
>> address,
>> offset
>> of different register... see vuart_info structure in
>> include/xen/serial.h
>> for
>> more details) in order to fully work.
>>
>> IHMO this is a lot of works for the user to configure. I would
>> much prefer
>> to
>> see a PL011 emulated at a specific base address and let the user
>> select
>> whether he wants a UART to debug or not.
>
> So you envision the configuration of the MMIO base address to be
> done as
> part of a new dynamic guest memory map?

 For guest using dynamic memory map, I would expect to expose an
 uncompleted
 emulation of the physical UART (e.g it would only be possible to
 write) at the
 exact same address as on the host.
>>>
>>> Why? Is this a requirement for baremetal guests?
>>>
>>> I would have actually opted for always emulating a PL011 even for
>>> guests
>>> using a dynamic memory map (which of course one way or another
>>> need to
>>> be able to choose the address of the UART, the memory and the
>>> rest).
>>
>> I guess it's not black and white but trying to reduce the gap
>> towards
>> being able to run unmodified SW f

Re: [Xen-devel] [PATCH RFC] docs/designs: PV stats interface

2016-11-23 Thread Konrad Rzeszutek Wilk

On Wed, Nov 23, 2016 at 02:14:27PM +, Paul Durrant wrote:
> This patch introduces a design proposal for an interface to used by
> guest PV drivers or agents to convey statistics to a monitoring agent
> running in a toolstack domain.
> 

Hey Paul!

Thank you for posting this, adding on the CC some extra folks
from Oracle. We have also an internal driver:

https://oss.oracle.com/git/?p=linux-uek.git;a=blob;f=drivers/xen/ovmapi.c;h=672d33f46f7c62053d002fb48ef6ad9f187a69bb;hb=020026b088c778996dfa7617ccb632ddbf04e9fe

which could use a design document or some synergy.

But first of couple of questions:
 - What about qemu-agent? Why not use that?

 - What about using Microsoft key-value pair drivers? They function
   in Linux and Windows. Linux underlaying layers can be changed
   so that the protocol is an XenStore one instead of the ring
   the kvp driver is using..

> Signed-off-by: Paul Durrant 
> ---
> RFC at the moment since this is a first draft and it is not yet
> prototyped
> ---
>  docs/designs/pv_stats.markdown | 116 
> +
>  1 file changed, 116 insertions(+)
>  create mode 100755 docs/designs/pv_stats.markdown
> 
> diff --git a/docs/designs/pv_stats.markdown b/docs/designs/pv_stats.markdown
> new file mode 100755
> index 000..4189369
> --- /dev/null
> +++ b/docs/designs/pv_stats.markdown
> @@ -0,0 +1,116 @@
> +# Statistics Interface for PV Drivers/Agents
> +
> +## Background
> +
> +It is common for guest PV drivers or agents to communicate statistics to an
> +agent running in a toolstack domain so that these can be displayed via a UI,
> +or even influence guest placement etc. The mechanism for conveying these
> +statistics is currently ad-hoc, undocumented, and usually based on xenstore.
> +
> +Whilst xenstore does indeed provide a convenient mechanism, the lack of
> +documentation and standardisation of the protocols used creates
> +compatibility issues for PV drivers or agents not tied to a specific
> +product or environment. Also, the guest xenstore quota and the single
> +instance of xenstored can easily become scalability issues.
> +
> +## Proposal
> +
> +The proposed interface is intended to be used only for the purposes of
> +conveying statistics from guest PV drivers or agents to an agent or agents
> +running in a toolstack domain. It is not intended for bulk data transfer,
> +nor as another means of control of the PV drivers or agents by the
> +toolstack domain.
> +
> +PV drivers or agents typically publish multiple related sets of statistics.
> +For example, a PV network frontend may publish statistics relating to
> +received traffic and transmitted traffic. These sets are likely to be
> +updated asynchronously from each other and therefore it makes sense that
> +they can be separated such that a monitoring agent can refresh its view of
> +them asynchronously. It is therefore proposed that a two-level hierarchy of
> +xenstore keys is used to advertise sets of guest statistics.
> +
> +The toolstack will create a writeable top-level `stats` key in the guest
> +space. Under this each guest statistics *provider* creates a key its name,
> +e.g. `Network #0`. This key acts as a parent to keys that then name each
> +set of statistics that it provides, e.g. `Tx`. Under the key for a
> +particular set the provider then writes entries containing grant references
> +of pages containing the names and values of the statistics in that set, and
> +an event channel to be used for signalling e.g.:
> +
> +name-type-ref0 = 10
> +name-type-ref1 = 11
> +val-ref0 = 12
> +val-ref1 = 13
> +event-channel = 10
> +
> +The provider must always write the `event-channel` key after all the other
> +keys have been written such that a monitoring agent with a watch on the
> +guest's top-level `stats` key can make the assumption that it is safe to
> +sample all other keys once that key has been written. Thus no explicit
> +`state` key is required.
> +
> +There are separate references for pages containing the names and types of
> +the statistics and the values of those statistics since it is required that
> +the names and types do not change and hence a monitoring agent need only
> +sample them once and can do so as soon as the as the `name-ref` keys are
> +valid. The format of each (*name, type*) tuple is as follows:
> +
> +struct stats_name_type {
> + uint8_t type;
> + char name[63];
> +};
> +
> +and the possible types are:
> +
> +#define STATS_TYPE_S64   1
> +#define STATS_TYPE_U64   2
> +#define STATS_TYPE_DOUBLE3
> +#define STATS_TYPE_ASCII 4
> +
> +The `name` must be a NUL terminated ASCII string containing only
> +alphanumeric characters, printable non-alphanumeric characters or a space
> +character, i.e. the expression:
> +
> +(isalnum(name[i]) || ispunct(name[i]) || name[i] == ' ')
> +
> +must be true for each value of `i` until `name[i] == '\0'`
> +
> +When iterating through the `stats_name_

Re: [Xen-devel] Xen ARM small task (WAS: Re: [Xen Question])


Hello Artem,

On 23/11/16 15:10, Artem Mygaiev wrote:

On 22.11.16 21:36, Julien Grall wrote:
I'm just curious - is it really have to be UART? can it be a PV TTY
device(s)? Wouldn't it be better to avoid unneeded HW emulation and just
provide "serial" function?


There is a couple of usecase where we cannot use PV console:
	- Running unmodified baremetal application as guest. Those applications 
will not have PV driver.
	- Guest compliant with the VM system specification for ARM [1]. A pl011 
is required.


Do you have any concern with this?

Regards,

[1] 
http://www.linaro.org/app/resources/WhitePaper/VMSystemSpecificationForARM-v2.0.pdf


--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC] docs/designs: PV stats interface

> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: 23 November 2016 15:08
> To: Paul Durrant ; annie...@oracle.com;
> adnan.mishe...@oracle.com
> Cc: xen-de...@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH RFC] docs/designs: PV stats interface
> 
> On Wed, Nov 23, 2016 at 02:14:27PM +, Paul Durrant wrote:
> > This patch introduces a design proposal for an interface to used by
> > guest PV drivers or agents to convey statistics to a monitoring agent
> > running in a toolstack domain.
> >
> 
> Hey Paul!
> 
> Thank you for posting this, adding on the CC some extra folks
> from Oracle. We have also an internal driver:
> 
> https://oss.oracle.com/git/?p=linux-
> uek.git;a=blob;f=drivers/xen/ovmapi.c;h=672d33f46f7c62053d002fb48ef6ad9
> f187a69bb;hb=020026b088c778996dfa7617ccb632ddbf04e9fe
> 
> which could use a design document or some synergy.
> 
> But first of couple of questions:
>  - What about qemu-agent? Why not use that?
> 
>  - What about using Microsoft key-value pair drivers? They function
>in Linux and Windows. Linux underlaying layers can be changed
>so that the protocol is an XenStore one instead of the ring
>the kvp driver is using..
> 

I don't want to limit the s/w that can be used inside the guest. There are many 
PV drivers and agents already out there and the aim of this proposal is to 
provide a uniform mechanism that any of them can use: IOW I'm only proposing 
the transport here, not what's sat on either end of it.

  Paul

> > Signed-off-by: Paul Durrant 
> > ---
> > RFC at the moment since this is a first draft and it is not yet
> > prototyped
> > ---
> >  docs/designs/pv_stats.markdown | 116
> +
> >  1 file changed, 116 insertions(+)
> >  create mode 100755 docs/designs/pv_stats.markdown
> >
> > diff --git a/docs/designs/pv_stats.markdown
> b/docs/designs/pv_stats.markdown
> > new file mode 100755
> > index 000..4189369
> > --- /dev/null
> > +++ b/docs/designs/pv_stats.markdown
> > @@ -0,0 +1,116 @@
> > +# Statistics Interface for PV Drivers/Agents
> > +
> > +## Background
> > +
> > +It is common for guest PV drivers or agents to communicate statistics to
> an
> > +agent running in a toolstack domain so that these can be displayed via a
> UI,
> > +or even influence guest placement etc. The mechanism for conveying
> these
> > +statistics is currently ad-hoc, undocumented, and usually based on
> xenstore.
> > +
> > +Whilst xenstore does indeed provide a convenient mechanism, the lack of
> > +documentation and standardisation of the protocols used creates
> > +compatibility issues for PV drivers or agents not tied to a specific
> > +product or environment. Also, the guest xenstore quota and the single
> > +instance of xenstored can easily become scalability issues.
> > +
> > +## Proposal
> > +
> > +The proposed interface is intended to be used only for the purposes of
> > +conveying statistics from guest PV drivers or agents to an agent or agents
> > +running in a toolstack domain. It is not intended for bulk data transfer,
> > +nor as another means of control of the PV drivers or agents by the
> > +toolstack domain.
> > +
> > +PV drivers or agents typically publish multiple related sets of statistics.
> > +For example, a PV network frontend may publish statistics relating to
> > +received traffic and transmitted traffic. These sets are likely to be
> > +updated asynchronously from each other and therefore it makes sense
> that
> > +they can be separated such that a monitoring agent can refresh its view of
> > +them asynchronously. It is therefore proposed that a two-level hierarchy
> of
> > +xenstore keys is used to advertise sets of guest statistics.
> > +
> > +The toolstack will create a writeable top-level `stats` key in the guest
> > +space. Under this each guest statistics *provider* creates a key its name,
> > +e.g. `Network #0`. This key acts as a parent to keys that then name each
> > +set of statistics that it provides, e.g. `Tx`. Under the key for a
> > +particular set the provider then writes entries containing grant references
> > +of pages containing the names and values of the statistics in that set, and
> > +an event channel to be used for signalling e.g.:
> > +
> > +name-type-ref0 = 10
> > +name-type-ref1 = 11
> > +val-ref0 = 12
> > +val-ref1 = 13
> > +event-channel = 10
> > +
> > +The provider must always write the `event-channel` key after all the other
> > +keys have been written such that a monitoring agent with a watch on the
> > +guest's top-level `stats` key can make the assumption that it is safe to
> > +sample all other keys once that key has been written. Thus no explicit
> > +`state` key is required.
> > +
> > +There are separate references for pages containing the names and types
> of
> > +the statistics and the values of those statistics since it is required that
> > +the names and types do not change and hence a monitoring age

[Xen-devel] [PATCH 05/15] x86/emul: Remove opencoded exception generation

Introduce generate_exception() for unconditional exception generation, and
replace existing uses.  Both generate_exception() and generate_exception_if()
are updated to make their error code parameters optional, which removes the
use of the -1 sentinal.

The ioport_access_check() check loses the presence check for %tr, as the x86
architecture has no concept of a non-usable task register.

No functional change.

Signed-off-by: Andrew Cooper 
Signed-off-by: Jan Beulich 
---
CC: Jan Beulich 
---
 xen/arch/x86/x86_emulate/x86_emulate.c | 196 +
 1 file changed, 100 insertions(+), 96 deletions(-)

diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c 
b/xen/arch/x86/x86_emulate/x86_emulate.c
index 2e65322..f8271b3 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -457,14 +457,20 @@ typedef union {
 #define EXC_BR  5
 #define EXC_UD  6
 #define EXC_NM  7
+#define EXC_DF  8
 #define EXC_TS 10
 #define EXC_NP 11
 #define EXC_SS 12
 #define EXC_GP 13
 #define EXC_PF 14
 #define EXC_MF 16
+#define EXC_AC 17
 #define EXC_XM 19
 
+#define EXC_HAS_EC  \
+((1u << EXC_DF) | (1u << EXC_TS) | (1u << EXC_NP) | \
+ (1u << EXC_SS) | (1u << EXC_GP) | (1u << EXC_PF) | (1u << EXC_AC))
+
 /* Segment selector error code bits. */
 #define ECODE_EXT (1 << 0)
 #define ECODE_IDT (1 << 1)
@@ -667,14 +673,22 @@ do {\
 if ( rc ) goto done;\
 } while (0)
 
-#define generate_exception_if(p, e, ec)   \
+static inline int mkec(uint8_t e, int32_t ec, ...)
+{
+return (e < 32 && (1u << e) & EXC_HAS_EC) ? ec : X86_EVENT_NO_EC;
+}
+
+#define generate_exception_if(p, e, ec...)\
 ({  if ( (p) ) {  \
 fail_if(ops->inject_hw_exception == NULL);\
-rc = ops->inject_hw_exception(e, ec, ctxt) ? : X86EMUL_EXCEPTION; \
+rc = ops->inject_hw_exception(e, mkec(e, ##ec, 0), ctxt)  \
+? : X86EMUL_EXCEPTION;\
 goto done;\
 } \
 })
 
+#define generate_exception(e, ec...) generate_exception_if(true, e, ##ec)
+
 /*
  * Given byte has even parity (even number of 1s)? SDM Vol. 1 Sec. 3.4.3.1,
  * "Status Flags": EFLAGS.PF reflects parity of least-sig. byte of result only.
@@ -785,7 +799,7 @@ static int _get_fpu(
 return rc;
 generate_exception_if(!(cr4 & ((type == X86EMUL_FPU_xmm)
? CR4_OSFXSR : CR4_OSXSAVE)),
-  EXC_UD, -1);
+  EXC_UD);
 }
 
 rc = ops->read_cr(0, &cr0, ctxt);
@@ -798,13 +812,13 @@ static int _get_fpu(
 }
 if ( cr0 & CR0_EM )
 {
-generate_exception_if(type == X86EMUL_FPU_fpu, EXC_NM, -1);
-generate_exception_if(type == X86EMUL_FPU_mmx, EXC_UD, -1);
-generate_exception_if(type == X86EMUL_FPU_xmm, EXC_UD, -1);
+generate_exception_if(type == X86EMUL_FPU_fpu, EXC_NM);
+generate_exception_if(type == X86EMUL_FPU_mmx, EXC_UD);
+generate_exception_if(type == X86EMUL_FPU_xmm, EXC_UD);
 }
 generate_exception_if((cr0 & CR0_TS) &&
   (type != X86EMUL_FPU_wait || (cr0 & CR0_MP)),
-  EXC_NM, -1);
+  EXC_NM);
 }
 
  done:
@@ -832,7 +846,7 @@ do {
\
 (_fic)->exn_raised = EXC_UD;\
 }   \
 generate_exception_if((_fic)->exn_raised >= 0,  \
-  (_fic)->exn_raised, -1);  \
+  (_fic)->exn_raised);  \
 } while (0)
 
 #define emulate_fpu_insn(_op)   \
@@ -1167,11 +1181,9 @@ static int ioport_access_check(
 if ( (rc = ops->read_segment(x86_seg_tr, &tr, ctxt)) != 0 )
 return rc;
 
-/* Ensure that the TSS is valid and has an io-bitmap-offset field. */
-if ( !tr.attr.fields.p ||
- ((tr.attr.fields.type & 0xd) != 0x9) ||
- (tr.limit < 0x67) )
-goto raise_exception;
+/* Ensure the TSS has an io-bitmap-offset field. */
+generate_exception_if(tr.attr.fields.type != 0xb ||
+  tr.limit < 0x67, EXC_GP, 0);
 
 if ( (rc = read_ulong(x86_seg_none, tr.base + 0x66,
   &iobmp, 2, ctxt, ops)) )
@@ -1179,21 +1191,16 @@ static int ioport_access_check(
 
 /* Ensure TSS includes t

[Xen-devel] [PATCH 02/15] x86/emul: Simplfy emulation state setup

The current code to set up emulation state is ad-hoc and error prone.

 * Consistently zero all emulation state structures.
 * Avoid explicitly initialising some state to 0.
 * Explicitly identify all input and output state in x86_emulate_ctxt.  This
   involves rearanging some fields.
 * Have x86_decode() explicitly initalise all output state at its start.

In addition, move the calculation of hvmemul_ctxt->ctxt.swint_emulate from
_hvm_emulate_one() to hvm_emulate_init_once(), as it doesn't need
recalculating for each instruction.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Tim Deegan 
CC: George Dunlap 
CC: Paul Durrant 
---
 xen/arch/x86/hvm/emulate.c | 28 +++-
 xen/arch/x86/mm.c  |  3 ++-
 xen/arch/x86/mm/shadow/common.c|  4 ++--
 xen/arch/x86/x86_emulate/x86_emulate.c |  2 ++
 xen/arch/x86/x86_emulate/x86_emulate.h | 22 +++---
 5 files changed, 36 insertions(+), 23 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 3ab0e8e..f24e211 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1769,13 +1769,6 @@ static int _hvm_emulate_one(struct hvm_emulate_ctxt 
*hvmemul_ctxt,
 
 vio->mmio_retry = 0;
 
-if ( cpu_has_vmx )
-hvmemul_ctxt->ctxt.swint_emulate = x86_swint_emulate_none;
-else if ( cpu_has_svm_nrips )
-hvmemul_ctxt->ctxt.swint_emulate = x86_swint_emulate_icebp;
-else
-hvmemul_ctxt->ctxt.swint_emulate = x86_swint_emulate_all;
-
 rc = x86_emulate(&hvmemul_ctxt->ctxt, ops);
 
 if ( rc == X86EMUL_OKAY && vio->mmio_retry )
@@ -1946,14 +1939,23 @@ void hvm_emulate_init_once(
 struct hvm_emulate_ctxt *hvmemul_ctxt,
 struct cpu_user_regs *regs)
 {
-hvmemul_ctxt->intr_shadow = hvm_funcs.get_interrupt_shadow(current);
-hvmemul_ctxt->ctxt.regs = regs;
-hvmemul_ctxt->ctxt.force_writeback = 1;
-hvmemul_ctxt->seg_reg_accessed = 0;
-hvmemul_ctxt->seg_reg_dirty = 0;
-hvmemul_ctxt->set_context = 0;
+struct vcpu *curr = current;
+
+memset(hvmemul_ctxt, 0, sizeof(*hvmemul_ctxt));
+
+hvmemul_ctxt->intr_shadow = hvm_funcs.get_interrupt_shadow(curr);
 hvmemul_get_seg_reg(x86_seg_cs, hvmemul_ctxt);
 hvmemul_get_seg_reg(x86_seg_ss, hvmemul_ctxt);
+
+hvmemul_ctxt->ctxt.regs = regs;
+hvmemul_ctxt->ctxt.force_writeback = true;
+
+if ( cpu_has_vmx )
+hvmemul_ctxt->ctxt.swint_emulate = x86_swint_emulate_none;
+else if ( cpu_has_svm_nrips )
+hvmemul_ctxt->ctxt.swint_emulate = x86_swint_emulate_icebp;
+else
+hvmemul_ctxt->ctxt.swint_emulate = x86_swint_emulate_all;
 }
 
 void hvm_emulate_init_per_insn(
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 03dcd71..9901f6f 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5363,8 +5363,9 @@ int ptwr_do_page_fault(struct vcpu *v, unsigned long addr,
 goto bail;
 }
 
+memset(&ptwr_ctxt, 0, sizeof(ptwr_ctxt));
+
 ptwr_ctxt.ctxt.regs = regs;
-ptwr_ctxt.ctxt.force_writeback = 0;
 ptwr_ctxt.ctxt.addr_size = ptwr_ctxt.ctxt.sp_size =
 is_pv_32bit_domain(d) ? 32 : BITS_PER_LONG;
 ptwr_ctxt.ctxt.swint_emulate = x86_swint_emulate_none;
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index ced2313..6f6668d 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -385,8 +385,9 @@ const struct x86_emulate_ops *shadow_init_emulation(
 struct vcpu *v = current;
 unsigned long addr;
 
+memset(sh_ctxt, 0, sizeof(*sh_ctxt));
+
 sh_ctxt->ctxt.regs = regs;
-sh_ctxt->ctxt.force_writeback = 0;
 sh_ctxt->ctxt.swint_emulate = x86_swint_emulate_none;
 
 if ( is_pv_vcpu(v) )
@@ -396,7 +397,6 @@ const struct x86_emulate_ops *shadow_init_emulation(
 }
 
 /* Segment cache initialisation. Primed with CS. */
-sh_ctxt->valid_seg_regs = 0;
 creg = hvm_get_seg_reg(x86_seg_cs, sh_ctxt);
 
 /* Work out the emulation mode. */
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c 
b/xen/arch/x86/x86_emulate/x86_emulate.c
index 04f0dac..c5d9664 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1904,6 +1904,8 @@ x86_decode(
 state->regs = ctxt->regs;
 state->eip = ctxt->regs->eip;
 
+/* Initialise output state in x86_emulate_ctxt */
+ctxt->opcode = ~0u;
 ctxt->retire.byte = 0;
 
 op_bytes = def_op_bytes = ad_bytes = def_ad_bytes = ctxt->addr_size/8;
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.h 
b/xen/arch/x86/x86_emulate/x86_emulate.h
index 993c576..93b268e 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.h
+++ b/xen/arch/x86/x86_emulate/x86_emulate.h
@@ -412,6 +412,10 @@ struct cpu_user_regs;
 
 struct x86_emulate_ctxt
 {
+/*
+ * Input state:
+ */
+
 /* Register state before/after emulation. */
 struct cpu_user_regs *regs;
 
@@ -421,14 +425,21 @@ struct x86_emulate_ctxt

[Xen-devel] [PATCH for-4.9 00/15] XSA-191 followup

This is partly RFC as there is a whole lot of rebasing happened recently and I
haven't run thorough tests yet.

This is the quantity of changes required to fix some edgecases in XSA-191
which were ultimately chosen not to go out in the security fix.  The main
purpose of this series is to fix emulation sufficiently to allow patch 15 to
avoid opencoding all of the segmenation logic.

Andrew Cooper (15):
  x86/hvm: Rename hvm_emulate_init() and hvm_emulate_prepare() for clarity
  x86/emul: Simplfy emulation state setup
  x86/emul: Rename hvm_trap to x86_event and move it into the emulation 
infrastructure
  x86/emul: Rename HVM_DELIVER_NO_ERROR_CODE to X86_EVENT_NO_EC
  x86/emul: Remove opencoded exception generation
  x86/emul: Rework emulator event injection
  x86/vmx: Use hvm_{get,set}_segment_register() rather than 
vmx_{get,set}_segment_register()
  x86/hvm: Reposition the modification of raw segment data from the VMCB/VMCS
  x86/emul: Avoid raising faults behind the emulators back
  x86/hvm: Extend the hvm_copy_*() API with a pagefault_info pointer
  x86/hvm: Reimplement hvm_copy_*_nofault() in terms of no pagefault_info
  x86/hvm: Rename hvm_copy_*_guest_virt() to hvm_copy_*_guest_linear()
  x86/hvm: Avoid __hvm_copy() raising #PF behind the emulators back
  x86/hvm: Prepare to allow use of system segments for memory references
  x86/hvm: Use system-segment relative memory accesses

 tools/tests/x86_emulator/test_x86_emulator.c |   1 +
 xen/arch/x86/hvm/emulate.c   | 238 +++--
 xen/arch/x86/hvm/hvm.c   | 366 +++
 xen/arch/x86/hvm/io.c|   6 +-
 xen/arch/x86/hvm/ioreq.c |   2 +-
 xen/arch/x86/hvm/nestedhvm.c |   2 +-
 xen/arch/x86/hvm/svm/emulate.c   |   4 +-
 xen/arch/x86/hvm/svm/nestedsvm.c |  13 +-
 xen/arch/x86/hvm/svm/svm.c   | 102 
 xen/arch/x86/hvm/vmx/intr.c  |   2 +-
 xen/arch/x86/hvm/vmx/realmode.c  |  18 +-
 xen/arch/x86/hvm/vmx/vmx.c   | 107 
 xen/arch/x86/hvm/vmx/vvmx.c  |  44 ++--
 xen/arch/x86/mm.c|   8 +-
 xen/arch/x86/mm/shadow/common.c  |  29 ++-
 xen/arch/x86/mm/shadow/multi.c   |   4 +-
 xen/arch/x86/x86_emulate/x86_emulate.c   | 328 +---
 xen/arch/x86/x86_emulate/x86_emulate.h   | 149 +--
 xen/include/asm-x86/desc.h   |   6 +
 xen/include/asm-x86/hvm/emulate.h|   9 +-
 xen/include/asm-x86/hvm/hvm.h|  86 +++
 xen/include/asm-x86/hvm/support.h|  42 ++-
 xen/include/asm-x86/hvm/svm/nestedsvm.h  |   6 +-
 xen/include/asm-x86/hvm/vcpu.h   |   2 +-
 xen/include/asm-x86/hvm/vmx/vmx.h|   2 -
 xen/include/asm-x86/hvm/vmx/vvmx.h   |   4 +-
 26 files changed, 901 insertions(+), 679 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH 09/15] x86/emul: Avoid raising faults behind the emulators back

Introduce a new x86_emul_pagefault() similar to x86_emul_hw_exception(), and
use this instead of hvm_inject_page_fault() from emulation codepaths.

Replace one hvm_inject_hw_exception() in the shadow emulation codepaths.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Paul Durrant 
CC: Tim Deegan 
CC: George Dunlap 

NOTE: this is a functional change for the shadow code, as a #PF previously
raised properly with the guest will now cause X86EMUL_UNHANDLABLE. It is my
understanding after a discusion with Tim that this is ok, but I haven't done
extenstive testing yet.
---
 xen/arch/x86/hvm/emulate.c |  4 ++--
 xen/arch/x86/mm/shadow/common.c|  5 +++--
 xen/arch/x86/x86_emulate/x86_emulate.h | 13 +
 3 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index c0fbde1..3ebb200 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -459,7 +459,7 @@ static int hvmemul_linear_to_phys(
 {
 if ( pfec & (PFEC_page_paged | PFEC_page_shared) )
 return X86EMUL_RETRY;
-hvm_inject_page_fault(pfec, addr);
+x86_emul_pagefault(pfec, addr, &hvmemul_ctxt->ctxt);
 return X86EMUL_EXCEPTION;
 }
 
@@ -483,7 +483,7 @@ static int hvmemul_linear_to_phys(
 ASSERT(!reverse);
 if ( npfn != gfn_x(INVALID_GFN) )
 return X86EMUL_UNHANDLEABLE;
-hvm_inject_page_fault(pfec, addr & PAGE_MASK);
+x86_emul_pagefault(pfec, addr & PAGE_MASK, 
&hvmemul_ctxt->ctxt);
 return X86EMUL_EXCEPTION;
 }
 *reps = done;
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 6f6668d..c8b61b9 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -162,8 +162,9 @@ static int hvm_translate_linear_addr(
 
 if ( !okay )
 {
-hvm_inject_hw_exception(
-(seg == x86_seg_ss) ? TRAP_stack_error : TRAP_gp_fault, 0);
+x86_emul_hw_exception(
+(seg == x86_seg_ss) ? TRAP_stack_error : TRAP_gp_fault,
+0, &sh_ctxt->ctxt);
 return X86EMUL_EXCEPTION;
 }
 
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.h 
b/xen/arch/x86/x86_emulate/x86_emulate.h
index ddcd93c..cc26e9d 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.h
+++ b/xen/arch/x86/x86_emulate/x86_emulate.h
@@ -600,6 +600,19 @@ static inline void x86_emul_hw_exception(
 ctxt->event_pending = true;
 }
 
+static inline void x86_emul_pagefault(
+unsigned int error_code, unsigned long cr2, struct x86_emulate_ctxt *ctxt)
+{
+ASSERT(!ctxt->event_pending);
+
+ctxt->event.vector = 14; /* TRAP_page_fault */
+ctxt->event.type = X86_EVENTTYPE_HW_EXCEPTION;
+ctxt->event.error_code = error_code;
+ctxt->event.cr2 = cr2;
+
+ctxt->event_pending = true;
+}
+
 static inline void x86_emul_software_event(
 enum x86_swint_type type, uint8_t vector, uint8_t insn_len,
 struct x86_emulate_ctxt *ctxt)
-- 
2.1.4


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

[Xen-devel] [PATCH 01/15] x86/hvm: Rename hvm_emulate_init() and hvm_emulate_prepare() for clarity

 * Move hvm_emulate_init() to immediately hvm_emulate_prepare(), as they are
   very closely related.
 * Rename hvm_emulate_prepare() to hvm_emulate_init_once() and
   hvm_emulate_init() to hvm_emulate_init_per_insn() to make it clearer how to
   and when to use them.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Paul Durrant 
CC: Jun Nakajima 
CC: Kevin Tian 
CC: Boris Ostrovsky 
CC: Suravee Suthikulpanit 
CC: Wei Liu 

As hvm_emulate_prepare() was new in 4.8, it would be a good idea to take this
patch to avoid future confusion on the stable-4.8 branch
---
 xen/arch/x86/hvm/emulate.c| 111 +++---
 xen/arch/x86/hvm/hvm.c|   2 +-
 xen/arch/x86/hvm/io.c |   2 +-
 xen/arch/x86/hvm/ioreq.c  |   2 +-
 xen/arch/x86/hvm/svm/emulate.c|   4 +-
 xen/arch/x86/hvm/vmx/realmode.c   |   2 +-
 xen/include/asm-x86/hvm/emulate.h |   6 ++-
 7 files changed, 66 insertions(+), 63 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index e9b8f8c..3ab0e8e 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1755,57 +1755,6 @@ static const struct x86_emulate_ops 
hvm_emulate_ops_no_write = {
 .vmfunc= hvmemul_vmfunc,
 };
 
-void hvm_emulate_init(
-struct hvm_emulate_ctxt *hvmemul_ctxt,
-const unsigned char *insn_buf,
-unsigned int insn_bytes)
-{
-struct vcpu *curr = current;
-unsigned int pfec = PFEC_page_present;
-unsigned long addr;
-
-if ( hvm_long_mode_enabled(curr) &&
- hvmemul_ctxt->seg_reg[x86_seg_cs].attr.fields.l )
-{
-hvmemul_ctxt->ctxt.addr_size = hvmemul_ctxt->ctxt.sp_size = 64;
-}
-else
-{
-hvmemul_ctxt->ctxt.addr_size =
-hvmemul_ctxt->seg_reg[x86_seg_cs].attr.fields.db ? 32 : 16;
-hvmemul_ctxt->ctxt.sp_size =
-hvmemul_ctxt->seg_reg[x86_seg_ss].attr.fields.db ? 32 : 16;
-}
-
-if ( hvmemul_ctxt->seg_reg[x86_seg_ss].attr.fields.dpl == 3 )
-pfec |= PFEC_user_mode;
-
-hvmemul_ctxt->insn_buf_eip = hvmemul_ctxt->ctxt.regs->eip;
-if ( !insn_bytes )
-{
-hvmemul_ctxt->insn_buf_bytes =
-hvm_get_insn_bytes(curr, hvmemul_ctxt->insn_buf) ?:
-(hvm_virtual_to_linear_addr(x86_seg_cs,
-&hvmemul_ctxt->seg_reg[x86_seg_cs],
-hvmemul_ctxt->insn_buf_eip,
-sizeof(hvmemul_ctxt->insn_buf),
-hvm_access_insn_fetch,
-hvmemul_ctxt->ctxt.addr_size,
-&addr) &&
- hvm_fetch_from_guest_virt_nofault(hvmemul_ctxt->insn_buf, addr,
-   sizeof(hvmemul_ctxt->insn_buf),
-   pfec) == HVMCOPY_okay) ?
-sizeof(hvmemul_ctxt->insn_buf) : 0;
-}
-else
-{
-hvmemul_ctxt->insn_buf_bytes = insn_bytes;
-memcpy(hvmemul_ctxt->insn_buf, insn_buf, insn_bytes);
-}
-
-hvmemul_ctxt->exn_pending = 0;
-}
-
 static int _hvm_emulate_one(struct hvm_emulate_ctxt *hvmemul_ctxt,
 const struct x86_emulate_ops *ops)
 {
@@ -1815,7 +1764,8 @@ static int _hvm_emulate_one(struct hvm_emulate_ctxt 
*hvmemul_ctxt,
 struct hvm_vcpu_io *vio = &curr->arch.hvm_vcpu.hvm_io;
 int rc;
 
-hvm_emulate_init(hvmemul_ctxt, vio->mmio_insn, vio->mmio_insn_bytes);
+hvm_emulate_init_per_insn(hvmemul_ctxt, vio->mmio_insn,
+  vio->mmio_insn_bytes);
 
 vio->mmio_retry = 0;
 
@@ -1915,7 +1865,7 @@ int hvm_emulate_one_mmio(unsigned long mfn, unsigned long 
gla)
 else
 ops = &hvm_ro_emulate_ops_mmio;
 
-hvm_emulate_prepare(&ctxt, guest_cpu_user_regs());
+hvm_emulate_init_once(&ctxt, guest_cpu_user_regs());
 ctxt.ctxt.data = &mmio_ro_ctxt;
 rc = _hvm_emulate_one(&ctxt, ops);
 switch ( rc )
@@ -1940,7 +1890,7 @@ void hvm_emulate_one_vm_event(enum emul_kind kind, 
unsigned int trapnr,
 struct hvm_emulate_ctxt ctx = {{ 0 }};
 int rc;
 
-hvm_emulate_prepare(&ctx, guest_cpu_user_regs());
+hvm_emulate_init_once(&ctx, guest_cpu_user_regs());
 
 switch ( kind )
 {
@@ -1992,7 +1942,7 @@ void hvm_emulate_one_vm_event(enum emul_kind kind, 
unsigned int trapnr,
 hvm_emulate_writeback(&ctx);
 }
 
-void hvm_emulate_prepare(
+void hvm_emulate_init_once(
 struct hvm_emulate_ctxt *hvmemul_ctxt,
 struct cpu_user_regs *regs)
 {
@@ -2006,6 +1956,57 @@ void hvm_emulate_prepare(
 hvmemul_get_seg_reg(x86_seg_ss, hvmemul_ctxt);
 }
 
+void hvm_emulate_init_per_insn(
+struct hvm_emulate_ctxt *hvmemul_ctxt,
+const unsigned char *insn_buf,
+unsigned int insn_bytes)
+{
+struct vcpu *curr = current;
+unsigned int pfec = PFEC_page_present;
+unsigned long addr;
+
+if ( hvm_long_mode_enabl

[Xen-devel] [PATCH 07/15] x86/vmx: Use hvm_{get, set}_segment_register() rather than vmx_{get, set}_segment_register()

No functional change at this point, but this is a prerequisite for forthcoming
functional changes.

Make vmx_get_segment_register() private to vmx.c like all the other Vendor
get/set functions.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
Reviewed-by: George Dunlap 
---
CC: Jun Nakajima 
CC: Kevin Tian 
---
 xen/arch/x86/hvm/vmx/vmx.c| 14 +++---
 xen/arch/x86/hvm/vmx/vvmx.c   |  6 +++---
 xen/include/asm-x86/hvm/vmx/vmx.h |  2 --
 3 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index eb7c902..29c6088 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -940,8 +940,8 @@ static void vmx_ctxt_switch_to(struct vcpu *v)
 .fields = { .type = 0xb, .s = 0, .dpl = 0, .p = 1, .avl = 0,\
 .l = 0, .db = 0, .g = 0, .pad = 0 } }).bytes)
 
-void vmx_get_segment_register(struct vcpu *v, enum x86_segment seg,
-  struct segment_register *reg)
+static void vmx_get_segment_register(struct vcpu *v, enum x86_segment seg,
+ struct segment_register *reg)
 {
 unsigned long attr = 0, sel = 0, limit;
 
@@ -1504,19 +1504,19 @@ static void vmx_update_guest_cr(struct vcpu *v, 
unsigned int cr)
  * Need to read them all either way, as realmode reads can update
  * the saved values we'll use when returning to prot mode. */
 for ( s = 0; s < ARRAY_SIZE(reg); s++ )
-vmx_get_segment_register(v, s, ®[s]);
+hvm_get_segment_register(v, s, ®[s]);
 v->arch.hvm_vmx.vmx_realmode = realmode;
 
 if ( realmode )
 {
 for ( s = 0; s < ARRAY_SIZE(reg); s++ )
-vmx_set_segment_register(v, s, ®[s]);
+hvm_set_segment_register(v, s, ®[s]);
 }
 else 
 {
 for ( s = 0; s < ARRAY_SIZE(reg); s++ )
 if ( !(v->arch.hvm_vmx.vm86_segment_mask & (1rip, mode);
 
-vmx_get_segment_register(v, x86_seg_ss, &ss);
+hvm_get_segment_register(v, x86_seg_ss, &ss);
 if ( ss.attr.fields.dpl )
 {
 __vmread(VM_ENTRY_INTR_INFO, &intr_info);
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index efaf54c..bcc4a97 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -360,7 +360,7 @@ static int vmx_inst_check_privilege(struct cpu_user_regs 
*regs, int vmxop_check)
 else if ( !vcpu_2_nvmx(v).vmxon_region_pa )
 goto invalid_op;
 
-vmx_get_segment_register(v, x86_seg_cs, &cs);
+hvm_get_segment_register(v, x86_seg_cs, &cs);
 
 if ( (regs->eflags & X86_EFLAGS_VM) ||
  (hvm_long_mode_enabled(v) && cs.attr.fields.l == 0) )
@@ -419,13 +419,13 @@ static int decode_vmx_inst(struct cpu_user_regs *regs,
 
 if ( hvm_long_mode_enabled(v) )
 {
-vmx_get_segment_register(v, x86_seg_cs, &seg);
+hvm_get_segment_register(v, x86_seg_cs, &seg);
 mode_64bit = seg.attr.fields.l;
 }
 
 if ( info.fields.segment > VMX_SREG_GS )
 goto gp_fault;
-vmx_get_segment_register(v, sreg_to_index[info.fields.segment], &seg);
+hvm_get_segment_register(v, sreg_to_index[info.fields.segment], &seg);
 seg_base = seg.base;
 
 base = info.fields.base_reg_invalid ? 0 :
diff --git a/xen/include/asm-x86/hvm/vmx/vmx.h 
b/xen/include/asm-x86/hvm/vmx/vmx.h
index 4cdd9b1..0e5902d 100644
--- a/xen/include/asm-x86/hvm/vmx/vmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h
@@ -550,8 +550,6 @@ static inline int __vmxon(u64 addr)
 return rc;
 }
 
-void vmx_get_segment_register(struct vcpu *, enum x86_segment,
-  struct segment_register *);
 void vmx_inject_extint(int trap, uint8_t source);
 void vmx_inject_nmi(void);
 
-- 
2.1.4


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

Re: [Xen-devel] [RFC PATCH 01/24] ARM: GICv3 ITS: parse and store ITS subnodes from hardware DT




On 14/11/16 17:35, Andre Przywara wrote:

Hi,


Hi Andre,


On 01/11/16 15:13, Julien Grall wrote:

On 28/09/2016 19:24, Andre Przywara wrote:

Parse the DT GIC subnodes to find every ITS MSI controller the hardware
offers. Store that information in a list to both propagate all of them
later to Dom0, but also to be able to iterate over all ITSes.
This introduces an ITS Kconfig option.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/Kconfig  |  5 
 xen/arch/arm/Makefile |  1 +
 xen/arch/arm/gic-its.c| 67
+++
 xen/arch/arm/gic-v3.c |  6 
 xen/include/asm-arm/gic-its.h | 57 
 5 files changed, 136 insertions(+)
 create mode 100644 xen/arch/arm/gic-its.c
 create mode 100644 xen/include/asm-arm/gic-its.h

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 797c91f..9fe3b8e 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -45,6 +45,11 @@ config ACPI
 config HAS_GICV3
 bool

+config HAS_ITS
+bool "GICv3 ITS MSI controller support"
+depends on ARM_64


HAS_GICV3 will only be selected for 64-bit. It would need some rework to
be supported on 32-bit. So I would drop this dependency.


OK, makes sense.


+depends on HAS_GICV3
+


I am not convinced that we should (currently) let the user selecting the
ITS support. It increases the test coverage (we have to test with and
without). Do we expect people using GICv3 without ITS?


My concern was more that if it breaks something, people can just disable
it. But I have to go through the patches again to see if disabling it
really brings us something (because thinking about it I don't think so).

So given the test coverage argument I think we should at least enable it
by default for ARM64. Is there some "expert options" group somewhere
where we could insert the option to turn it off?


You can use "if EXPERT=y", see how we handle ACPI for instance.

Thinking a bit more about this, I would like to see ITS as a technical 
preview at the beginning. This would let us a bit of time to stabilize 
the code. Any opinions?


Regards,

--
Julien Grall

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

[Xen-devel] [PATCH 08/15] x86/hvm: Reposition the modification of raw segment data from the VMCB/VMCS

Intel VT-x and AMD SVM provide access to the full segment descriptor cache via
fields in the VMCB/VMCS.  However, the bits which are actually checked by
hardware and preserved across vmentry/exit are inconsistent, and the vendor
accessor functions perform inconsistent modification to the raw values.

Convert {svm,vmx}_{get,set}_segment_register() into raw accessors, and alter
hvm_{get,set}_segment_register() to cook the values consistently.  This allows
the common emulation code to better rely on finding architecturally-expected
values.

This does cause some functional changes because of the modifications being
applied uniformly.  A side effect of this fixes latent bugs where
vmx_set_segment_register() didn't correctly fix up .G for segments, and
inconsistent fixing up of the GDTR/IDTR limits.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Jun Nakajima 
CC: Kevin Tian 
CC: Boris Ostrovsky 
CC: Suravee Suthikulpanit 
---
 xen/arch/x86/hvm/hvm.c| 151 ++
 xen/arch/x86/hvm/svm/svm.c|  20 +-
 xen/arch/x86/hvm/vmx/vmx.c|   6 +-
 xen/include/asm-x86/desc.h|   6 ++
 xen/include/asm-x86/hvm/hvm.h |  17 ++---
 5 files changed, 164 insertions(+), 36 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index ef83100..804cd88 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -6051,6 +6051,157 @@ void hvm_domain_soft_reset(struct domain *d)
 }
 
 /*
+ * Segment caches in VMCB/VMCS are inconsistent about which bits are checked,
+ * important, and preserved across vmentry/exit.  Cook the values to make them
+ * closer to what is architecturally expected from entries in the segment
+ * cache.
+ */
+void hvm_get_segment_register(struct vcpu *v, enum x86_segment seg,
+  struct segment_register *reg)
+{
+hvm_funcs.get_segment_register(v, seg, reg);
+
+switch ( seg )
+{
+case x86_seg_ss:
+/* SVM may retain %ss.DB when %ss is loaded with a NULL selector. */
+if ( !reg->attr.fields.p )
+reg->attr.fields.db = 0;
+break;
+
+case x86_seg_tr:
+/*
+ * SVM doesn't track %tr.B. Architecturally, a loaded TSS segment will
+ * always be busy.
+ */
+reg->attr.fields.type |= 0x2;
+
+/*
+ * %cs and %tr are unconditionally present.  SVM ignores these present
+ * bits and will happily run without them set.
+ */
+case x86_seg_cs:
+reg->attr.fields.p = 1;
+break;
+
+case x86_seg_gdtr:
+case x86_seg_idtr:
+/*
+ * Treat GDTR/IDTR as being present system segments.  This avoids them
+ * needing special casing for segmentation checks.
+ */
+reg->attr.bytes = 0x80;
+break;
+
+default: /* Avoid triggering -Werror=switch */
+break;
+}
+
+if ( reg->attr.fields.p )
+{
+/*
+ * For segments which are present/usable, cook the system flag.  SVM
+ * ignores the S bit on all segments and will happily run with them in
+ * any state.
+ */
+reg->attr.fields.s = is_x86_user_segment(seg);
+
+/*
+ * SVM discards %cs.G on #VMEXIT.  Other user segments do have .G
+ * tracked, but Linux commit 80112c89ed87 "KVM: Synthesize G bit for
+ * all segments." indicates that this isn't necessarily the case when
+ * nested under ESXi.
+ *
+ * Unconditionally recalculate G.
+ */
+reg->attr.fields.g = !!(reg->limit >> 20);
+
+/*
+ * SVM doesn't track the Accessed flag.  It will always be set for
+ * usable user segments loaded into the descriptor cache.
+ */
+if ( is_x86_user_segment(seg) )
+reg->attr.fields.type |= 0x1;
+}
+}
+
+void hvm_set_segment_register(struct vcpu *v, enum x86_segment seg,
+  struct segment_register *reg)
+{
+/* Set G to match the limit field.  VT-x cares, while SVM doesn't. */
+if ( reg->attr.fields.p )
+reg->attr.fields.g = !!(reg->limit >> 20);
+
+switch ( seg )
+{
+case x86_seg_cs:
+ASSERT(reg->attr.fields.p);  /* Usable. */
+ASSERT(reg->attr.fields.s);  /* User segment. */
+ASSERT((reg->base >> 32) == 0);  /* Upper bits clear. */
+break;
+
+case x86_seg_ss:
+if ( reg->attr.fields.p )
+{
+ASSERT(reg->attr.fields.s);  /* User segment. */
+ASSERT(!(reg->attr.fields.type & 0x8));  /* Data segment. */
+ASSERT(reg->attr.fields.type & 0x2); /* Writeable. */
+ASSERT((reg->base >> 32) == 0);  /* Upper bits clear. */
+}
+break;
+
+case x86_seg_ds:
+case x86_seg_es:
+case x86_seg_fs:
+case x86_seg_gs:
+if ( reg->attr.fields.p )
+{
+ASSERT(reg->attr.fi

[Xen-devel] [PATCH 04/15] x86/emul: Rename HVM_DELIVER_NO_ERROR_CODE to X86_EVENT_NO_EC

and move it to live with the other x86_event infrastructure in x86_emulate.h.
Switch it and x86_event.error_code to being signed, matching the rest of the
code.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Paul Durrant 
CC: Jun Nakajima 
CC: Kevin Tian 
CC: Boris Ostrovsky 
CC: Suravee Suthikulpanit 
---
 xen/arch/x86/hvm/emulate.c |  2 +-
 xen/arch/x86/hvm/hvm.c |  6 +++---
 xen/arch/x86/hvm/nestedhvm.c   |  2 +-
 xen/arch/x86/hvm/svm/nestedsvm.c   |  6 +++---
 xen/arch/x86/hvm/svm/svm.c | 22 +++---
 xen/arch/x86/hvm/vmx/intr.c|  2 +-
 xen/arch/x86/hvm/vmx/vmx.c | 23 ---
 xen/arch/x86/hvm/vmx/vvmx.c|  2 +-
 xen/arch/x86/x86_emulate/x86_emulate.h |  3 ++-
 xen/include/asm-x86/hvm/support.h  |  2 --
 10 files changed, 35 insertions(+), 35 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index d0c3185..790e9c1 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1609,7 +1609,7 @@ static int hvmemul_inject_sw_interrupt(
 
 hvmemul_ctxt->exn_pending = 1;
 hvmemul_ctxt->trap.vector = vector;
-hvmemul_ctxt->trap.error_code = HVM_DELIVER_NO_ERROR_CODE;
+hvmemul_ctxt->trap.error_code = X86_EVENT_NO_EC;
 hvmemul_ctxt->trap.insn_len = insn_len;
 
 return X86EMUL_OKAY;
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 7b434aa..b950842 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -502,7 +502,7 @@ void hvm_do_resume(struct vcpu *v)
 kind = EMUL_KIND_SET_CONTEXT_INSN;
 
 hvm_emulate_one_vm_event(kind, TRAP_invalid_op,
- HVM_DELIVER_NO_ERROR_CODE);
+ X86_EVENT_NO_EC);
 
 v->arch.vm_event->emulate_flags = 0;
 }
@@ -3054,7 +3054,7 @@ void hvm_task_switch(
 }
 
 if ( (tss.trace & 1) && !exn_raised )
-hvm_inject_hw_exception(TRAP_debug, HVM_DELIVER_NO_ERROR_CODE);
+hvm_inject_hw_exception(TRAP_debug, X86_EVENT_NO_EC);
 
  out:
 hvm_unmap_entry(optss_desc);
@@ -4073,7 +4073,7 @@ void hvm_ud_intercept(struct cpu_user_regs *regs)
 switch ( hvm_emulate_one(&ctxt) )
 {
 case X86EMUL_UNHANDLEABLE:
-hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
+hvm_inject_hw_exception(TRAP_invalid_op, X86_EVENT_NO_EC);
 break;
 case X86EMUL_EXCEPTION:
 if ( ctxt.exn_pending )
diff --git a/xen/arch/x86/hvm/nestedhvm.c b/xen/arch/x86/hvm/nestedhvm.c
index caad525..c4671d8 100644
--- a/xen/arch/x86/hvm/nestedhvm.c
+++ b/xen/arch/x86/hvm/nestedhvm.c
@@ -17,7 +17,7 @@
  */
 
 #include 
-#include/* for HVM_DELIVER_NO_ERROR_CODE */
+#include 
 #include 
 #include /* for struct p2m_domain */
 #include 
diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c
index b6b8526..8c9b073 100644
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -756,7 +756,7 @@ nsvm_vcpu_vmrun(struct vcpu *v, struct cpu_user_regs *regs)
 default:
 gdprintk(XENLOG_ERR,
 "nsvm_vcpu_vmentry failed, injecting #UD\n");
-hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
+hvm_inject_hw_exception(TRAP_invalid_op, X86_EVENT_NO_EC);
 /* Must happen after hvm_inject_hw_exception or it doesn't work right. 
*/
 nv->nv_vmswitch_in_progress = 0;
 return 1;
@@ -1581,7 +1581,7 @@ void svm_vmexit_do_stgi(struct cpu_user_regs *regs, 
struct vcpu *v)
 unsigned int inst_len;
 
 if ( !nestedhvm_enabled(v->domain) ) {
-hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
+hvm_inject_hw_exception(TRAP_invalid_op, X86_EVENT_NO_EC);
 return;
 }
 
@@ -1601,7 +1601,7 @@ void svm_vmexit_do_clgi(struct cpu_user_regs *regs, 
struct vcpu *v)
 vintr_t intr;
 
 if ( !nestedhvm_enabled(v->domain) ) {
-hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
+hvm_inject_hw_exception(TRAP_invalid_op, X86_EVENT_NO_EC);
 return;
 }
 
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 66eb30b..fb4fd0b 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -89,7 +89,7 @@ static DEFINE_SPINLOCK(osvw_lock);
 static void svm_crash_or_fault(struct vcpu *v)
 {
 if ( vmcb_get_cpl(v->arch.hvm_svm.vmcb) )
-hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
+hvm_inject_hw_exception(TRAP_invalid_op, X86_EVENT_NO_EC);
 else
 domain_crash(v->domain);
 }
@@ -116,7 +116,7 @@ void __update_guest_eip(struct cpu_user_regs *regs, 
unsigned int inst_len)
 curr->arch.hvm_svm.vmcb->interrupt_shadow = 0;
 
 if ( regs->eflags & X86_EFLAGS_TF )
-hvm_inject_hw_exception(TRAP_debug, HVM_DELIVER_NO_ERROR_CODE);
+hvm_i

[Xen-devel] [PATCH 03/15] x86/emul: Rename hvm_trap to x86_event and move it into the emulation infrastructure

The x86 emulator needs to gain an understanding of interrupts and exceptions
generated by its actions.  The naming choice is to match both the Intel and
AMD terms, and to avoid 'trap' specifically as it has an architectural meaning
different to its current usage.

While making this change, make other changes for consistency

 * Rename *_trap() infrastructure to *_event()
 * Rename trapnr/trap parameters to vector
 * Convert hvm_inject_hw_exception() and hvm_inject_page_fault() to being
   static inlines, as they are only thin wrappers around hvm_inject_event()

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Paul Durrant 
CC: Jun Nakajima 
CC: Kevin Tian 
CC: Boris Ostrovsky 
CC: Suravee Suthikulpanit 
---
 xen/arch/x86/hvm/emulate.c  |  6 +--
 xen/arch/x86/hvm/hvm.c  | 33 
 xen/arch/x86/hvm/io.c   |  2 +-
 xen/arch/x86/hvm/svm/nestedsvm.c|  7 ++--
 xen/arch/x86/hvm/svm/svm.c  | 62 ++---
 xen/arch/x86/hvm/vmx/vmx.c  | 66 +++
 xen/arch/x86/hvm/vmx/vvmx.c | 11 +++---
 xen/arch/x86/x86_emulate/x86_emulate.c  | 11 ++
 xen/arch/x86/x86_emulate/x86_emulate.h  | 22 +++
 xen/include/asm-x86/hvm/emulate.h   |  2 +-
 xen/include/asm-x86/hvm/hvm.h   | 69 -
 xen/include/asm-x86/hvm/svm/nestedsvm.h |  6 +--
 xen/include/asm-x86/hvm/vcpu.h  |  2 +-
 xen/include/asm-x86/hvm/vmx/vvmx.h  |  4 +-
 14 files changed, 159 insertions(+), 144 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index f24e211..d0c3185 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1679,7 +1679,7 @@ static int hvmemul_invlpg(
  * violations, so squash them.
  */
 hvmemul_ctxt->exn_pending = 0;
-hvmemul_ctxt->trap = (struct hvm_trap){};
+hvmemul_ctxt->trap = (struct x86_event){};
 rc = X86EMUL_OKAY;
 }
 
@@ -1868,7 +1868,7 @@ int hvm_emulate_one_mmio(unsigned long mfn, unsigned long 
gla)
 break;
 case X86EMUL_EXCEPTION:
 if ( ctxt.exn_pending )
-hvm_inject_trap(&ctxt.trap);
+hvm_inject_event(&ctxt.trap);
 /* fallthrough */
 default:
 hvm_emulate_writeback(&ctxt);
@@ -1928,7 +1928,7 @@ void hvm_emulate_one_vm_event(enum emul_kind kind, 
unsigned int trapnr,
 break;
 case X86EMUL_EXCEPTION:
 if ( ctx.exn_pending )
-hvm_inject_trap(&ctx.trap);
+hvm_inject_event(&ctx.trap);
 break;
 }
 
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 25dc759..7b434aa 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -535,7 +535,7 @@ void hvm_do_resume(struct vcpu *v)
 /* Inject pending hw/sw trap */
 if ( v->arch.hvm_vcpu.inject_trap.vector != -1 )
 {
-hvm_inject_trap(&v->arch.hvm_vcpu.inject_trap);
+hvm_inject_event(&v->arch.hvm_vcpu.inject_trap);
 v->arch.hvm_vcpu.inject_trap.vector = -1;
 }
 }
@@ -1676,19 +1676,19 @@ void hvm_triple_fault(void)
 domain_shutdown(d, reason);
 }
 
-void hvm_inject_trap(const struct hvm_trap *trap)
+void hvm_inject_event(const struct x86_event *event)
 {
 struct vcpu *curr = current;
 
 if ( nestedhvm_enabled(curr->domain) &&
  !nestedhvm_vmswitch_in_progress(curr) &&
  nestedhvm_vcpu_in_guestmode(curr) &&
- nhvm_vmcx_guest_intercepts_trap(
- curr, trap->vector, trap->error_code) )
+ nhvm_vmcx_guest_intercepts_event(
+ curr, event->vector, event->error_code) )
 {
 enum nestedhvm_vmexits nsret;
 
-nsret = nhvm_vcpu_vmexit_trap(curr, trap);
+nsret = nhvm_vcpu_vmexit_event(curr, event);
 
 switch ( nsret )
 {
@@ -1704,26 +1704,7 @@ void hvm_inject_trap(const struct hvm_trap *trap)
 }
 }
 
-hvm_funcs.inject_trap(trap);
-}
-
-void hvm_inject_hw_exception(unsigned int trapnr, int errcode)
-{
-struct hvm_trap trap = {
-.vector = trapnr,
-.type = X86_EVENTTYPE_HW_EXCEPTION,
-.error_code = errcode };
-hvm_inject_trap(&trap);
-}
-
-void hvm_inject_page_fault(int errcode, unsigned long cr2)
-{
-struct hvm_trap trap = {
-.vector = TRAP_page_fault,
-.type = X86_EVENTTYPE_HW_EXCEPTION,
-.error_code = errcode,
-.cr2 = cr2 };
-hvm_inject_trap(&trap);
+hvm_funcs.inject_event(event);
 }
 
 int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla,
@@ -4096,7 +4077,7 @@ void hvm_ud_intercept(struct cpu_user_regs *regs)
 break;
 case X86EMUL_EXCEPTION:
 if ( ctxt.exn_pending )
-hvm_inject_trap(&ctxt.trap);
+hvm_inject_event(&ctxt.trap);
 /* fall through */
 default:
 hvm_emulate_writeback(&ctxt);
diff --git a/xen/arch/x86/hvm/io.c b/xen/

[Xen-devel] [PATCH 06/15] x86/emul: Rework emulator event injection

The emulator needs to gain an understanding of interrupts and exceptions
generated by its actions.

Move hvm_emulate_ctxt.{exn_pending,trap} into struct x86_emulate_ctxt so they
are visible to the emulator.  This removes the need for the
inject_{hw,sw}_interrupt() hooks, which are dropped and replaced with
x86_emul_{hw_exception,software_event}() instead.

The shadow pagetable and PV uses of x86_emulate() previously failed with
X86EMUL_UNHANDLEABLE due to the lack of inject_*() hooks, but this behaviour
has subtly changed.  Adjust the return value checking to cause a pending event
to fall back into the previous codepath.

No overall functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Paul Durrant 
CC: Tim Deegan 
CC: George Dunlap 
CC: Jun Nakajima 
CC: Kevin Tian 
CC: Boris Ostrovsky 
CC: Suravee Suthikulpanit 
---
 tools/tests/x86_emulator/test_x86_emulator.c |  1 +
 xen/arch/x86/hvm/emulate.c   | 81 
 xen/arch/x86/hvm/hvm.c   |  4 +-
 xen/arch/x86/hvm/io.c|  4 +-
 xen/arch/x86/hvm/vmx/realmode.c  | 16 +++---
 xen/arch/x86/mm.c|  5 +-
 xen/arch/x86/mm/shadow/multi.c   |  4 +-
 xen/arch/x86/x86_emulate/x86_emulate.c   | 12 ++---
 xen/arch/x86/x86_emulate/x86_emulate.h   | 67 ++-
 xen/include/asm-x86/hvm/emulate.h|  3 --
 10 files changed, 86 insertions(+), 111 deletions(-)

diff --git a/tools/tests/x86_emulator/test_x86_emulator.c 
b/tools/tests/x86_emulator/test_x86_emulator.c
index 948ee8d..146e15e 100644
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -1,3 +1,4 @@
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 790e9c1..c0fbde1 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -568,12 +568,9 @@ static int hvmemul_virtual_to_linear(
 return X86EMUL_UNHANDLEABLE;
 
 /* This is a singleton operation: fail it with an exception. */
-hvmemul_ctxt->exn_pending = 1;
-hvmemul_ctxt->trap.vector =
-(seg == x86_seg_ss) ? TRAP_stack_error : TRAP_gp_fault;
-hvmemul_ctxt->trap.type = X86_EVENTTYPE_HW_EXCEPTION;
-hvmemul_ctxt->trap.error_code = 0;
-hvmemul_ctxt->trap.insn_len = 0;
+x86_emul_hw_exception((seg == x86_seg_ss)
+  ? TRAP_stack_error
+  : TRAP_gp_fault, 0, &hvmemul_ctxt->ctxt);
 return X86EMUL_EXCEPTION;
 }
 
@@ -1562,59 +1559,6 @@ int hvmemul_cpuid(
 return X86EMUL_OKAY;
 }
 
-static int hvmemul_inject_hw_exception(
-uint8_t vector,
-int32_t error_code,
-struct x86_emulate_ctxt *ctxt)
-{
-struct hvm_emulate_ctxt *hvmemul_ctxt =
-container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
-
-hvmemul_ctxt->exn_pending = 1;
-hvmemul_ctxt->trap.vector = vector;
-hvmemul_ctxt->trap.type = X86_EVENTTYPE_HW_EXCEPTION;
-hvmemul_ctxt->trap.error_code = error_code;
-hvmemul_ctxt->trap.insn_len = 0;
-
-return X86EMUL_OKAY;
-}
-
-static int hvmemul_inject_sw_interrupt(
-enum x86_swint_type type,
-uint8_t vector,
-uint8_t insn_len,
-struct x86_emulate_ctxt *ctxt)
-{
-struct hvm_emulate_ctxt *hvmemul_ctxt =
-container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
-
-switch ( type )
-{
-case x86_swint_icebp:
-hvmemul_ctxt->trap.type = X86_EVENTTYPE_PRI_SW_EXCEPTION;
-break;
-
-case x86_swint_int3:
-case x86_swint_into:
-hvmemul_ctxt->trap.type = X86_EVENTTYPE_SW_EXCEPTION;
-break;
-
-case x86_swint_int:
-hvmemul_ctxt->trap.type = X86_EVENTTYPE_SW_INTERRUPT;
-break;
-
-default:
-return X86EMUL_UNHANDLEABLE;
-}
-
-hvmemul_ctxt->exn_pending = 1;
-hvmemul_ctxt->trap.vector = vector;
-hvmemul_ctxt->trap.error_code = X86_EVENT_NO_EC;
-hvmemul_ctxt->trap.insn_len = insn_len;
-
-return X86EMUL_OKAY;
-}
-
 static int hvmemul_get_fpu(
 void (*exception_callback)(void *, struct cpu_user_regs *),
 void *exception_callback_arg,
@@ -1678,8 +1622,7 @@ static int hvmemul_invlpg(
  * hvmemul_virtual_to_linear() raises exceptions for type/limit
  * violations, so squash them.
  */
-hvmemul_ctxt->exn_pending = 0;
-hvmemul_ctxt->trap = (struct x86_event){};
+x86_emul_reset_event(ctxt);
 rc = X86EMUL_OKAY;
 }
 
@@ -1696,7 +1639,7 @@ static int hvmemul_vmfunc(
 
 rc = hvm_funcs.altp2m_vcpu_emulate_vmfunc(ctxt->regs);
 if ( rc != X86EMUL_OKAY )
-hvmemul_inject_hw_exception(TRAP_invalid_op, 0, ctxt);
+x86_emul_hw_exception(TRAP_invalid_op, 0, ctxt);
 
 return rc;
 }
@@ -1720,8 +1663,6 @@ static const struct x86_emulate_ops hvm_emulate_ops = {
 .write_msr = hvmemul_write_msr,
 .wbinvd= hvmemul_wbinvd,
 .cpuid

Re: [Xen-devel] [PATCH RFC] docs/designs: PV stats interface

> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: 23 November 2016 15:08
> To: Paul Durrant ; annie...@oracle.com;
> adnan.mishe...@oracle.com
> Cc: xen-de...@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH RFC] docs/designs: PV stats interface
> 
> On Wed, Nov 23, 2016 at 02:14:27PM +, Paul Durrant wrote:
> > This patch introduces a design proposal for an interface to used by
> > guest PV drivers or agents to convey statistics to a monitoring agent
> > running in a toolstack domain.
> >
> 
> Hey Paul!
> 
> Thank you for posting this, adding on the CC some extra folks
> from Oracle. We have also an internal driver:
> 
> https://oss.oracle.com/git/?p=linux-
> uek.git;a=blob;f=drivers/xen/ovmapi.c;h=672d33f46f7c62053d002fb48ef6ad9
> f187a69bb;hb=020026b088c778996dfa7617ccb632ddbf04e9fe
> 
> which could use a design document or some synergy.

Took a quick look... Looks like that may have a more general usecase than just 
statistics. Looks more like something that could make use of AF_VSOCK.

  Paul

> 
> But first of couple of questions:
>  - What about qemu-agent? Why not use that?
> 
>  - What about using Microsoft key-value pair drivers? They function
>in Linux and Windows. Linux underlaying layers can be changed
>so that the protocol is an XenStore one instead of the ring
>the kvp driver is using..
> 
> > Signed-off-by: Paul Durrant 
> > ---
> > RFC at the moment since this is a first draft and it is not yet
> > prototyped
> > ---
> >  docs/designs/pv_stats.markdown | 116
> +
> >  1 file changed, 116 insertions(+)
> >  create mode 100755 docs/designs/pv_stats.markdown
> >
> > diff --git a/docs/designs/pv_stats.markdown
> b/docs/designs/pv_stats.markdown
> > new file mode 100755
> > index 000..4189369
> > --- /dev/null
> > +++ b/docs/designs/pv_stats.markdown
> > @@ -0,0 +1,116 @@
> > +# Statistics Interface for PV Drivers/Agents
> > +
> > +## Background
> > +
> > +It is common for guest PV drivers or agents to communicate statistics to
> an
> > +agent running in a toolstack domain so that these can be displayed via a
> UI,
> > +or even influence guest placement etc. The mechanism for conveying
> these
> > +statistics is currently ad-hoc, undocumented, and usually based on
> xenstore.
> > +
> > +Whilst xenstore does indeed provide a convenient mechanism, the lack of
> > +documentation and standardisation of the protocols used creates
> > +compatibility issues for PV drivers or agents not tied to a specific
> > +product or environment. Also, the guest xenstore quota and the single
> > +instance of xenstored can easily become scalability issues.
> > +
> > +## Proposal
> > +
> > +The proposed interface is intended to be used only for the purposes of
> > +conveying statistics from guest PV drivers or agents to an agent or agents
> > +running in a toolstack domain. It is not intended for bulk data transfer,
> > +nor as another means of control of the PV drivers or agents by the
> > +toolstack domain.
> > +
> > +PV drivers or agents typically publish multiple related sets of statistics.
> > +For example, a PV network frontend may publish statistics relating to
> > +received traffic and transmitted traffic. These sets are likely to be
> > +updated asynchronously from each other and therefore it makes sense
> that
> > +they can be separated such that a monitoring agent can refresh its view of
> > +them asynchronously. It is therefore proposed that a two-level hierarchy
> of
> > +xenstore keys is used to advertise sets of guest statistics.
> > +
> > +The toolstack will create a writeable top-level `stats` key in the guest
> > +space. Under this each guest statistics *provider* creates a key its name,
> > +e.g. `Network #0`. This key acts as a parent to keys that then name each
> > +set of statistics that it provides, e.g. `Tx`. Under the key for a
> > +particular set the provider then writes entries containing grant references
> > +of pages containing the names and values of the statistics in that set, and
> > +an event channel to be used for signalling e.g.:
> > +
> > +name-type-ref0 = 10
> > +name-type-ref1 = 11
> > +val-ref0 = 12
> > +val-ref1 = 13
> > +event-channel = 10
> > +
> > +The provider must always write the `event-channel` key after all the other
> > +keys have been written such that a monitoring agent with a watch on the
> > +guest's top-level `stats` key can make the assumption that it is safe to
> > +sample all other keys once that key has been written. Thus no explicit
> > +`state` key is required.
> > +
> > +There are separate references for pages containing the names and types
> of
> > +the statistics and the values of those statistics since it is required that
> > +the names and types do not change and hence a monitoring agent need
> only
> > +sample them once and can do so as soon as the as the `name-ref` keys are
> > +valid. The format of each (*name, type*) t

[Xen-devel] [PATCH 11/15] x86/hvm: Reimplement hvm_copy_*_nofault() in terms of no pagefault_info

No functional change.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
---
CC: Paul Durrant 
CC: Tim Deegan 
---
 xen/arch/x86/hvm/emulate.c|  6 ++---
 xen/arch/x86/hvm/hvm.c| 56 +--
 xen/arch/x86/mm/shadow/common.c   |  8 +++---
 xen/include/asm-x86/hvm/support.h | 11 
 4 files changed, 19 insertions(+), 62 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index e50ee24..34c9d77 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1936,9 +1936,9 @@ void hvm_emulate_init_per_insn(
 hvm_access_insn_fetch,
 hvmemul_ctxt->ctxt.addr_size,
 &addr) &&
- hvm_fetch_from_guest_virt_nofault(hvmemul_ctxt->insn_buf, addr,
-   sizeof(hvmemul_ctxt->insn_buf),
-   pfec) == HVMCOPY_okay) ?
+ hvm_fetch_from_guest_virt(hvmemul_ctxt->insn_buf, addr,
+   sizeof(hvmemul_ctxt->insn_buf),
+   pfec, NULL) == HVMCOPY_okay) ?
 sizeof(hvmemul_ctxt->insn_buf) : 0;
 }
 else
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index afba51f..6dfe81b 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3066,8 +3066,6 @@ void hvm_task_switch(
 
 #define HVMCOPY_from_guest (0u<<0)
 #define HVMCOPY_to_guest   (1u<<0)
-#define HVMCOPY_no_fault   (0u<<1)
-#define HVMCOPY_fault  (1u<<1)
 #define HVMCOPY_phys   (0u<<2)
 #define HVMCOPY_virt   (1u<<2)
 static enum hvm_copy_result __hvm_copy(
@@ -3112,13 +3110,10 @@ static enum hvm_copy_result __hvm_copy(
 return HVMCOPY_gfn_paged_out;
 if ( pfec & PFEC_page_shared )
 return HVMCOPY_gfn_shared;
-if ( flags & HVMCOPY_fault )
+if ( pfinfo )
 {
-if ( pfinfo )
-{
-pfinfo->linear = addr;
-pfinfo->ec = pfec;
-}
+pfinfo->linear = addr;
+pfinfo->ec = pfec;
 
 hvm_inject_page_fault(pfec, addr);
 }
@@ -3290,16 +3285,14 @@ enum hvm_copy_result hvm_copy_to_guest_phys(
 paddr_t paddr, void *buf, int size)
 {
 return __hvm_copy(buf, paddr, size,
-  HVMCOPY_to_guest | HVMCOPY_fault | HVMCOPY_phys,
-  0, NULL);
+  HVMCOPY_to_guest | HVMCOPY_phys, 0, NULL);
 }
 
 enum hvm_copy_result hvm_copy_from_guest_phys(
 void *buf, paddr_t paddr, int size)
 {
 return __hvm_copy(buf, paddr, size,
-  HVMCOPY_from_guest | HVMCOPY_fault | HVMCOPY_phys,
-  0, NULL);
+  HVMCOPY_from_guest | HVMCOPY_phys, 0, NULL);
 }
 
 enum hvm_copy_result hvm_copy_to_guest_virt(
@@ -3307,7 +3300,7 @@ enum hvm_copy_result hvm_copy_to_guest_virt(
 pagefault_info_t *pfinfo)
 {
 return __hvm_copy(buf, vaddr, size,
-  HVMCOPY_to_guest | HVMCOPY_fault | HVMCOPY_virt,
+  HVMCOPY_to_guest | HVMCOPY_virt,
   PFEC_page_present | PFEC_write_access | pfec, pfinfo);
 }
 
@@ -3316,7 +3309,7 @@ enum hvm_copy_result hvm_copy_from_guest_virt(
 pagefault_info_t *pfinfo)
 {
 return __hvm_copy(buf, vaddr, size,
-  HVMCOPY_from_guest | HVMCOPY_fault | HVMCOPY_virt,
+  HVMCOPY_from_guest | HVMCOPY_virt,
   PFEC_page_present | pfec, pfinfo);
 }
 
@@ -3325,34 +3318,10 @@ enum hvm_copy_result hvm_fetch_from_guest_virt(
 pagefault_info_t *pfinfo)
 {
 return __hvm_copy(buf, vaddr, size,
-  HVMCOPY_from_guest | HVMCOPY_fault | HVMCOPY_virt,
+  HVMCOPY_from_guest | HVMCOPY_virt,
   PFEC_page_present | PFEC_insn_fetch | pfec, pfinfo);
 }
 
-enum hvm_copy_result hvm_copy_to_guest_virt_nofault(
-unsigned long vaddr, void *buf, int size, uint32_t pfec)
-{
-return __hvm_copy(buf, vaddr, size,
-  HVMCOPY_to_guest | HVMCOPY_no_fault | HVMCOPY_virt,
-  PFEC_page_present | PFEC_write_access | pfec, NULL);
-}
-
-enum hvm_copy_result hvm_copy_from_guest_virt_nofault(
-void *buf, unsigned long vaddr, int size, uint32_t pfec)
-{
-return __hvm_copy(buf, vaddr, size,
-  HVMCOPY_from_guest | HVMCOPY_no_fault | HVMCOPY_virt,
-  PFEC_page_present | pfec, NULL);
-}
-
-enum hvm_copy_result hvm_fetch_from_guest_virt_nofault(
-void *buf, unsigned long vaddr, int size, uint32_t pfec)
-{
-return __hvm_copy(buf, vaddr, size,
-  HVMCOPY_from_guest | HVMCOPY_no_fault | HVMCOPY_virt

[Xen-devel] [PATCH 13/15] x86/hvm: Avoid __hvm_copy() raising #PF behind the emulators back

Drop the call to hvm_inject_page_fault() in __hvm_copy(), and require callers
to inject the pagefault themselves.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Paul Durrant 
CC: Tim Deegan 
CC: Jun Nakajima 
CC: Kevin Tian 
---
 xen/arch/x86/hvm/emulate.c|  2 ++
 xen/arch/x86/hvm/hvm.c| 11 +--
 xen/arch/x86/hvm/vmx/vvmx.c   | 20 +++-
 xen/arch/x86/mm/shadow/common.c   |  1 +
 xen/include/asm-x86/hvm/support.h |  4 +---
 5 files changed, 28 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index dd24979..c248eca 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -799,6 +799,7 @@ static int __hvmemul_read(
 case HVMCOPY_okay:
 break;
 case HVMCOPY_bad_gva_to_gfn:
+x86_emul_pagefault(pfinfo.ec, pfinfo.linear, &hvmemul_ctxt->ctxt);
 return X86EMUL_EXCEPTION;
 case HVMCOPY_bad_gfn_to_mfn:
 if ( access_type == hvm_access_insn_fetch )
@@ -905,6 +906,7 @@ static int hvmemul_write(
 case HVMCOPY_okay:
 break;
 case HVMCOPY_bad_gva_to_gfn:
+x86_emul_pagefault(pfinfo.ec, pfinfo.linear, &hvmemul_ctxt->ctxt);
 return X86EMUL_EXCEPTION;
 case HVMCOPY_bad_gfn_to_mfn:
 return hvmemul_linear_mmio_write(addr, bytes, p_data, pfec, 
hvmemul_ctxt, 0);
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index d0c4129..e1f2c9e 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2927,6 +2927,8 @@ void hvm_task_switch(
 
 rc = hvm_copy_from_guest_linear(
 &tss, prev_tr.base, sizeof(tss), PFEC_page_present, &pfinfo);
+if ( rc == HVMCOPY_bad_gva_to_gfn )
+hvm_inject_page_fault(pfinfo.ec, pfinfo.linear);
 if ( rc != HVMCOPY_okay )
 goto out;
 
@@ -2965,11 +2967,15 @@ void hvm_task_switch(
   offsetof(typeof(tss), trace) -
   offsetof(typeof(tss), eip),
   PFEC_page_present, &pfinfo);
+if ( rc == HVMCOPY_bad_gva_to_gfn )
+hvm_inject_page_fault(pfinfo.ec, pfinfo.linear);
 if ( rc != HVMCOPY_okay )
 goto out;
 
 rc = hvm_copy_from_guest_linear(
 &tss, tr.base, sizeof(tss), PFEC_page_present, &pfinfo);
+if ( rc == HVMCOPY_bad_gva_to_gfn )
+hvm_inject_page_fault(pfinfo.ec, pfinfo.linear);
 /*
  * Note: The HVMCOPY_gfn_shared case could be optimised, if the callee
  * functions knew we want RO access.
@@ -3012,7 +3018,10 @@ void hvm_task_switch(
   &tss.back_link, sizeof(tss.back_link), 0,
   &pfinfo);
 if ( rc == HVMCOPY_bad_gva_to_gfn )
+{
+hvm_inject_page_fault(pfinfo.ec, pfinfo.linear);
 exn_raised = 1;
+}
 else if ( rc != HVMCOPY_okay )
 goto out;
 }
@@ -3114,8 +3123,6 @@ static enum hvm_copy_result __hvm_copy(
 {
 pfinfo->linear = addr;
 pfinfo->ec = pfec;
-
-hvm_inject_page_fault(pfec, addr);
 }
 return HVMCOPY_bad_gva_to_gfn;
 }
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index fd7ea0a..e6e9ebd 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -396,7 +396,6 @@ static int decode_vmx_inst(struct cpu_user_regs *regs,
 struct vcpu *v = current;
 union vmx_inst_info info;
 struct segment_register seg;
-pagefault_info_t pfinfo;
 unsigned long base, index, seg_base, disp, offset;
 int scale, size;
 
@@ -451,10 +450,17 @@ static int decode_vmx_inst(struct cpu_user_regs *regs,
   offset + size - 1 > seg.limit) )
 goto gp_fault;
 
-if ( poperandS != NULL &&
- hvm_copy_from_guest_linear(poperandS, base, size, 0, &pfinfo)
-  != HVMCOPY_okay )
-return X86EMUL_EXCEPTION;
+if ( poperandS != NULL )
+{
+pagefault_info_t pfinfo;
+int rc = hvm_copy_from_guest_linear(poperandS, base, size,
+0, &pfinfo);
+
+if ( rc == HVMCOPY_bad_gva_to_gfn )
+hvm_inject_page_fault(pfinfo.ec, pfinfo.linear);
+if ( rc != HVMCOPY_okay )
+return X86EMUL_EXCEPTION;
+}
 decode->mem = base;
 decode->len = size;
 }
@@ -1623,6 +1629,8 @@ int nvmx_handle_vmptrst(struct cpu_user_regs *regs)
 gpa = nvcpu->nv_vvmcxaddr;
 
 rc = hvm_copy_to_guest_linear(decode.mem, &gpa, decode.len, 0, &pfinfo);
+if ( rc == HVMCOPY_bad_gva_to_gfn )
+hvm_inject_page_fault(pfinfo.ec, pfinfo.linear);
 if ( rc != HVMCOPY_okay )
 return X86EMUL_EXCEPTION;
 
@@ -1694,6 +1702,8 @@ int nvmx_handle_vmread(struct cpu_user_regs *regs)
 switch (

[Xen-devel] [PATCH 14/15] x86/hvm: Prepare to allow use of system segments for memory references

All system segments (GDT/IDT/LDT and TR) describe a linear address and limit,
and act similarly to user segments.  However all current uses of these tables
in the emulator opencode the address calculations and limit checks.  In
particular, no care is taken for access which wrap around the 4GB or
non-canonical boundaries.

Alter hvm_virtual_to_linear_addr() to cope with performing segmentation checks
on system segments.  This involves restricting access checks in the 32bit case
to user segments only, and adding presence/limit checks in the 64bit case.

When suffering a segmentation fault for a system segments, return
X86EMUL_EXCEPTION but leave the fault injection to the caller.  The fault type
depends on the higher level action being performed.

Signed-off-by: Andrew Cooper 
Signed-off-by: Jan Beulich 
Reviewed-by: George Dunlap 
---
CC: Paul Durrant 
---
 xen/arch/x86/hvm/emulate.c | 14 
 xen/arch/x86/hvm/hvm.c | 40 ++
 xen/arch/x86/mm/shadow/common.c| 12 +++---
 xen/arch/x86/x86_emulate/x86_emulate.h | 26 ++
 4 files changed, 62 insertions(+), 30 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index c248eca..3a7d1f3 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -567,10 +567,16 @@ static int hvmemul_virtual_to_linear(
 if ( *reps != 1 )
 return X86EMUL_UNHANDLEABLE;
 
-/* This is a singleton operation: fail it with an exception. */
-x86_emul_hw_exception((seg == x86_seg_ss)
-  ? TRAP_stack_error
-  : TRAP_gp_fault, 0, &hvmemul_ctxt->ctxt);
+/*
+ * Leave exception injection to the caller for non-user segments: We
+ * neither know the exact error code to be used, nor can we easily
+ * determine the kind of exception (#GP or #TS) in that case.
+ */
+if ( is_x86_user_segment(seg) )
+x86_emul_hw_exception((seg == x86_seg_ss)
+  ? TRAP_stack_error
+  : TRAP_gp_fault, 0, &hvmemul_ctxt->ctxt);
+
 return X86EMUL_EXCEPTION;
 }
 
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index e1f2c9e..2bcef1f 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2497,24 +2497,28 @@ bool_t hvm_virtual_to_linear_addr(
 if ( !reg->attr.fields.p )
 goto out;
 
-switch ( access_type )
+/* Read/write restrictions only exist for user segments. */
+if ( reg->attr.fields.s )
 {
-case hvm_access_read:
-if ( (reg->attr.fields.type & 0xa) == 0x8 )
-goto out; /* execute-only code segment */
-break;
-case hvm_access_write:
-if ( (reg->attr.fields.type & 0xa) != 0x2 )
-goto out; /* not a writable data segment */
-break;
-default:
-break;
+switch ( access_type )
+{
+case hvm_access_read:
+if ( (reg->attr.fields.type & 0xa) == 0x8 )
+goto out; /* execute-only code segment */
+break;
+case hvm_access_write:
+if ( (reg->attr.fields.type & 0xa) != 0x2 )
+goto out; /* not a writable data segment */
+break;
+default:
+break;
+}
 }
 
 last_byte = (uint32_t)offset + bytes - !!bytes;
 
 /* Is this a grows-down data segment? Special limit check if so. */
-if ( (reg->attr.fields.type & 0xc) == 0x4 )
+if ( reg->attr.fields.s && (reg->attr.fields.type & 0xc) == 0x4 )
 {
 /* Is upper limit 0x or 0x? */
 if ( !reg->attr.fields.db )
@@ -2530,10 +2534,18 @@ bool_t hvm_virtual_to_linear_addr(
 else
 {
 /*
- * LONG MODE: FS and GS add segment base. Addresses must be canonical.
+ * User segments are always treated as present.  System segment may
+ * not be, and also incur limit checks.
  */
+if ( is_x86_system_segment(seg) &&
+ (!reg->attr.fields.p || (offset + bytes - !!bytes) > reg->limit) )
+goto out;
 
-if ( (seg == x86_seg_fs) || (seg == x86_seg_gs) )
+/*
+ * LONG MODE: FS, GS and system segments: add segment base. All
+ * addresses must be canonical.
+ */
+if ( seg >= x86_seg_fs )
 addr += reg->base;
 
 last_byte = addr + bytes - !!bytes;
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 88d4642..954c157 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -162,9 +162,15 @@ static int hvm_translate_linear_addr(
 
 if ( !okay )
 {
-x86_emul_hw_exception(
-(seg == x86_seg_ss) ? TRAP_stack_error : TRAP_gp_fault,
-0, &sh_c

[Xen-devel] [PATCH 15/15] x86/hvm: Use system-segment relative memory accesses

With hvm_virtual_to_linear_addr() capable of doing proper system-segment
relative memory accesses, avoid open-coding the address and limit calculations
locally.

When a table spans the 4GB boundary (32bit) or non-canonical boundary (64bit),
segmentation errors are now raised.  Previously, the use of x86_seg_none
resulted in segmentation being skipped, and the linear address being truncated
through the pagewalk, and possibly coming out valid on the far side.

Signed-off-by: Andrew Cooper 
Signed-off-by: Jan Beulich 
Reviewed-by: George Dunlap 
---
 xen/arch/x86/hvm/hvm.c |   8 +++
 xen/arch/x86/x86_emulate/x86_emulate.c | 117 -
 2 files changed, 79 insertions(+), 46 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 2bcef1f..fbdb8dd 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2470,6 +2470,14 @@ bool_t hvm_virtual_to_linear_addr(
 unsigned long addr = offset, last_byte;
 bool_t okay = 0;
 
+/*
+ * These checks are for a memory access through an active segment.
+ *
+ * It is expected that the access rights of reg are suitable for seg (and
+ * that this is enforced at the point that seg is loaded).
+ */
+ASSERT(seg < x86_seg_none);
+
 if ( !(current->arch.hvm_vcpu.guest_cr[0] & X86_CR0_PE) )
 {
 /*
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c 
b/xen/arch/x86/x86_emulate/x86_emulate.c
index 768a436..6f94593 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1181,20 +1181,38 @@ static int ioport_access_check(
 return rc;
 
 /* Ensure the TSS has an io-bitmap-offset field. */
-generate_exception_if(tr.attr.fields.type != 0xb ||
-  tr.limit < 0x67, EXC_GP, 0);
+generate_exception_if(tr.attr.fields.type != 0xb, EXC_GP, 0);
 
-if ( (rc = read_ulong(x86_seg_none, tr.base + 0x66,
-  &iobmp, 2, ctxt, ops)) )
+switch ( rc = read_ulong(x86_seg_tr, 0x66, &iobmp, 2, ctxt, ops) )
+{
+case X86EMUL_OKAY:
+break;
+
+case X86EMUL_EXCEPTION:
+if ( !ctxt->event_pending )
+generate_exception_if(true, EXC_GP, 0);
+/* fallthrough */
+
+default:
 return rc;
+}
 
-/* Ensure TSS includes two bytes including byte containing first port. */
-iobmp += first_port / 8;
-generate_exception_if(tr.limit <= iobmp, EXC_GP, 0);
+/* Read two bytes including byte containing first port. */
+switch ( rc = read_ulong(x86_seg_tr, iobmp + first_port / 8,
+ &iobmp, 2, ctxt, ops) )
+{
+case X86EMUL_OKAY:
+break;
+
+case X86EMUL_EXCEPTION:
+if ( !ctxt->event_pending )
+generate_exception_if(true, EXC_GP, 0);
+/* fallthrough */
 
-if ( (rc = read_ulong(x86_seg_none, tr.base + iobmp,
-  &iobmp, 2, ctxt, ops)) )
+default:
 return rc;
+}
+
 generate_exception_if(iobmp & (((1 << bytes) - 1) << (first_port & 7)),
   EXC_GP, 0);
 
@@ -1317,9 +1335,12 @@ realmode_load_seg(
 struct x86_emulate_ctxt *ctxt,
 const struct x86_emulate_ops *ops)
 {
-int rc = ops->read_segment(seg, sreg, ctxt);
+int rc;
+
+if ( !ops->read_segment )
+return X86EMUL_UNHANDLEABLE;
 
-if ( !rc )
+if ( (rc = ops->read_segment(seg, sreg, ctxt)) == X86EMUL_OKAY )
 {
 sreg->sel  = sel;
 sreg->base = (uint32_t)sel << 4;
@@ -1336,7 +1357,7 @@ protmode_load_seg(
 struct x86_emulate_ctxt *ctxt,
 const struct x86_emulate_ops *ops)
 {
-struct segment_register desctab;
+enum x86_segment sel_seg = (sel & 4) ? x86_seg_ldtr : x86_seg_gdtr;
 struct { uint32_t a, b; } desc;
 uint8_t dpl, rpl;
 int cpl = get_cpl(ctxt, ops);
@@ -1369,21 +1390,19 @@ protmode_load_seg(
 if ( !is_x86_user_segment(seg) && (sel & 4) )
 goto raise_exn;
 
-if ( (rc = ops->read_segment((sel & 4) ? x86_seg_ldtr : x86_seg_gdtr,
- &desctab, ctxt)) )
-return rc;
-
-/* Segment not valid for use (cooked meaning of .p)? */
-if ( !desctab.attr.fields.p )
-goto raise_exn;
+switch ( rc = ops->read(sel_seg, sel & 0xfff8, &desc, sizeof(desc), ctxt) )
+{
+case X86EMUL_OKAY:
+break;
 
-/* Check against descriptor table limit. */
-if ( ((sel & 0xfff8) + 7) > desctab.limit )
-goto raise_exn;
+case X86EMUL_EXCEPTION:
+if ( !ctxt->event_pending )
+goto raise_exn;
+/* fallthrough */
 
-if ( (rc = ops->read(x86_seg_none, desctab.base + (sel & 0xfff8),
- &desc, sizeof(desc), ctxt)) )
+default:
 return rc;
+}
 
 if ( !is_x86_user_segment(seg) )
 {
@@ -1471,9 +1490,12 @@ protmode_load_seg(
 {
 uint32_t new_desc_b = desc.b | a_flag;
 
-if ( (rc = ops->cmpxch

[Xen-devel] [PATCH 12/15] x86/hvm: Rename hvm_copy__guest_virt() to hvm_copy__guest_linear()

The functions use linear addresses, not virtual addresses, as no segmentation
is used.  (Lots of other code in Xen makes this mistake.)

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Paul Durrant 
CC: Tim Deegan 
CC: Jun Nakajima 
CC: Kevin Tian 
---
 xen/arch/x86/hvm/emulate.c| 12 
 xen/arch/x86/hvm/hvm.c| 60 +++
 xen/arch/x86/hvm/vmx/vvmx.c   |  6 ++--
 xen/arch/x86/mm/shadow/common.c   |  8 +++---
 xen/include/asm-x86/hvm/support.h | 14 -
 5 files changed, 50 insertions(+), 50 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 34c9d77..dd24979 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -791,8 +791,8 @@ static int __hvmemul_read(
 pfec |= PFEC_user_mode;
 
 rc = ((access_type == hvm_access_insn_fetch) ?
-  hvm_fetch_from_guest_virt(p_data, addr, bytes, pfec, &pfinfo) :
-  hvm_copy_from_guest_virt(p_data, addr, bytes, pfec, &pfinfo));
+  hvm_fetch_from_guest_linear(p_data, addr, bytes, pfec, &pfinfo) :
+  hvm_copy_from_guest_linear(p_data, addr, bytes, pfec, &pfinfo));
 
 switch ( rc )
 {
@@ -898,7 +898,7 @@ static int hvmemul_write(
  (hvmemul_ctxt->seg_reg[x86_seg_ss].attr.fields.dpl == 3) )
 pfec |= PFEC_user_mode;
 
-rc = hvm_copy_to_guest_virt(addr, p_data, bytes, pfec, &pfinfo);
+rc = hvm_copy_to_guest_linear(addr, p_data, bytes, pfec, &pfinfo);
 
 switch ( rc )
 {
@@ -1936,9 +1936,9 @@ void hvm_emulate_init_per_insn(
 hvm_access_insn_fetch,
 hvmemul_ctxt->ctxt.addr_size,
 &addr) &&
- hvm_fetch_from_guest_virt(hvmemul_ctxt->insn_buf, addr,
-   sizeof(hvmemul_ctxt->insn_buf),
-   pfec, NULL) == HVMCOPY_okay) ?
+ hvm_fetch_from_guest_linear(hvmemul_ctxt->insn_buf, addr,
+ sizeof(hvmemul_ctxt->insn_buf),
+ pfec, NULL) == HVMCOPY_okay) ?
 sizeof(hvmemul_ctxt->insn_buf) : 0;
 }
 else
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 6dfe81b..d0c4129 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2925,7 +2925,7 @@ void hvm_task_switch(
 goto out;
 }
 
-rc = hvm_copy_from_guest_virt(
+rc = hvm_copy_from_guest_linear(
 &tss, prev_tr.base, sizeof(tss), PFEC_page_present, &pfinfo);
 if ( rc != HVMCOPY_okay )
 goto out;
@@ -2960,15 +2960,15 @@ void hvm_task_switch(
 hvm_get_segment_register(v, x86_seg_ldtr, &segr);
 tss.ldt = segr.sel;
 
-rc = hvm_copy_to_guest_virt(prev_tr.base + offsetof(typeof(tss), eip),
-&tss.eip,
-offsetof(typeof(tss), trace) -
-offsetof(typeof(tss), eip),
-PFEC_page_present, &pfinfo);
+rc = hvm_copy_to_guest_linear(prev_tr.base + offsetof(typeof(tss), eip),
+  &tss.eip,
+  offsetof(typeof(tss), trace) -
+  offsetof(typeof(tss), eip),
+  PFEC_page_present, &pfinfo);
 if ( rc != HVMCOPY_okay )
 goto out;
 
-rc = hvm_copy_from_guest_virt(
+rc = hvm_copy_from_guest_linear(
 &tss, tr.base, sizeof(tss), PFEC_page_present, &pfinfo);
 /*
  * Note: The HVMCOPY_gfn_shared case could be optimised, if the callee
@@ -3008,9 +3008,9 @@ void hvm_task_switch(
 regs->eflags |= X86_EFLAGS_NT;
 tss.back_link = prev_tr.sel;
 
-rc = hvm_copy_to_guest_virt(tr.base + offsetof(typeof(tss), back_link),
-&tss.back_link, sizeof(tss.back_link), 0,
-&pfinfo);
+rc = hvm_copy_to_guest_linear(tr.base + offsetof(typeof(tss), 
back_link),
+  &tss.back_link, sizeof(tss.back_link), 0,
+  &pfinfo);
 if ( rc == HVMCOPY_bad_gva_to_gfn )
 exn_raised = 1;
 else if ( rc != HVMCOPY_okay )
@@ -3047,8 +3047,8 @@ void hvm_task_switch(
 16 << segr.attr.fields.db,
 &linear_addr) )
 {
-rc = hvm_copy_to_guest_virt(linear_addr, &errcode, opsz, 0,
-&pfinfo);
+rc = hvm_copy_to_guest_linear(linear_addr, &errcode, opsz, 0,
+  &pfinfo);
 if ( rc == HVMCOPY_bad_gva_to_gfn )
 exn_raised = 1;
 else if ( rc != HVMCOPY_okay )
@@ -3067,7 +3067,7 @@ void hvm_task_switch(
 #define HVMCOPY_from_gue

Re: [Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.

Hello Julien,

> The ACPI support is pretty much contained in a single file and I am not sure 
> you will win much space.
> Can you explain why the ACPI guest support should be optional?
This would increase the system configurability and would let one
shrink a system to a minimal footprint with required functionality
only. Such possibility is very useful in embedded applications.

Unfortunately I don't know the exact space impact of this particular
feature 'cause I can't build it. From other hand I do not need it in
my system. So I would like to have a way to drop not needed
functionality easily.
BTW, excessive functionality reduction is also a way to get more
stable and predictable system.

Sincerely,
Andrii Anisov.

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

[Xen-devel] [PATCH 10/15] x86/hvm: Extend the hvm_copy_*() API with a pagefault_info pointer

which is filled with pagefault information should one occur.

No functional change.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
---
CC: Paul Durrant 
CC: Tim Deegan 
CC: Jun Nakajima 
CC: Kevin Tian 
---
 xen/arch/x86/hvm/emulate.c|  8 ---
 xen/arch/x86/hvm/hvm.c| 49 +--
 xen/arch/x86/hvm/vmx/vvmx.c   |  9 ---
 xen/arch/x86/mm/shadow/common.c   |  5 ++--
 xen/include/asm-x86/hvm/support.h | 23 +-
 5 files changed, 63 insertions(+), 31 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 3ebb200..e50ee24 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -770,6 +770,7 @@ static int __hvmemul_read(
 struct hvm_emulate_ctxt *hvmemul_ctxt)
 {
 struct vcpu *curr = current;
+pagefault_info_t pfinfo;
 unsigned long addr, reps = 1;
 uint32_t pfec = PFEC_page_present;
 struct hvm_vcpu_io *vio = &curr->arch.hvm_vcpu.hvm_io;
@@ -790,8 +791,8 @@ static int __hvmemul_read(
 pfec |= PFEC_user_mode;
 
 rc = ((access_type == hvm_access_insn_fetch) ?
-  hvm_fetch_from_guest_virt(p_data, addr, bytes, pfec) :
-  hvm_copy_from_guest_virt(p_data, addr, bytes, pfec));
+  hvm_fetch_from_guest_virt(p_data, addr, bytes, pfec, &pfinfo) :
+  hvm_copy_from_guest_virt(p_data, addr, bytes, pfec, &pfinfo));
 
 switch ( rc )
 {
@@ -878,6 +879,7 @@ static int hvmemul_write(
 struct hvm_emulate_ctxt *hvmemul_ctxt =
 container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
 struct vcpu *curr = current;
+pagefault_info_t pfinfo;
 unsigned long addr, reps = 1;
 uint32_t pfec = PFEC_page_present | PFEC_write_access;
 struct hvm_vcpu_io *vio = &curr->arch.hvm_vcpu.hvm_io;
@@ -896,7 +898,7 @@ static int hvmemul_write(
  (hvmemul_ctxt->seg_reg[x86_seg_ss].attr.fields.dpl == 3) )
 pfec |= PFEC_user_mode;
 
-rc = hvm_copy_to_guest_virt(addr, p_data, bytes, pfec);
+rc = hvm_copy_to_guest_virt(addr, p_data, bytes, pfec, &pfinfo);
 
 switch ( rc )
 {
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 804cd88..afba51f 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2859,6 +2859,7 @@ void hvm_task_switch(
 struct desc_struct *optss_desc = NULL, *nptss_desc = NULL, tss_desc;
 bool_t otd_writable, ntd_writable;
 unsigned long eflags;
+pagefault_info_t pfinfo;
 int exn_raised, rc;
 struct {
 u16 back_link,__blh;
@@ -2925,7 +2926,7 @@ void hvm_task_switch(
 }
 
 rc = hvm_copy_from_guest_virt(
-&tss, prev_tr.base, sizeof(tss), PFEC_page_present);
+&tss, prev_tr.base, sizeof(tss), PFEC_page_present, &pfinfo);
 if ( rc != HVMCOPY_okay )
 goto out;
 
@@ -2963,12 +2964,12 @@ void hvm_task_switch(
 &tss.eip,
 offsetof(typeof(tss), trace) -
 offsetof(typeof(tss), eip),
-PFEC_page_present);
+PFEC_page_present, &pfinfo);
 if ( rc != HVMCOPY_okay )
 goto out;
 
 rc = hvm_copy_from_guest_virt(
-&tss, tr.base, sizeof(tss), PFEC_page_present);
+&tss, tr.base, sizeof(tss), PFEC_page_present, &pfinfo);
 /*
  * Note: The HVMCOPY_gfn_shared case could be optimised, if the callee
  * functions knew we want RO access.
@@ -3008,7 +3009,8 @@ void hvm_task_switch(
 tss.back_link = prev_tr.sel;
 
 rc = hvm_copy_to_guest_virt(tr.base + offsetof(typeof(tss), back_link),
-&tss.back_link, sizeof(tss.back_link), 0);
+&tss.back_link, sizeof(tss.back_link), 0,
+&pfinfo);
 if ( rc == HVMCOPY_bad_gva_to_gfn )
 exn_raised = 1;
 else if ( rc != HVMCOPY_okay )
@@ -3045,7 +3047,8 @@ void hvm_task_switch(
 16 << segr.attr.fields.db,
 &linear_addr) )
 {
-rc = hvm_copy_to_guest_virt(linear_addr, &errcode, opsz, 0);
+rc = hvm_copy_to_guest_virt(linear_addr, &errcode, opsz, 0,
+&pfinfo);
 if ( rc == HVMCOPY_bad_gva_to_gfn )
 exn_raised = 1;
 else if ( rc != HVMCOPY_okay )
@@ -3068,7 +3071,8 @@ void hvm_task_switch(
 #define HVMCOPY_phys   (0u<<2)
 #define HVMCOPY_virt   (1u<<2)
 static enum hvm_copy_result __hvm_copy(
-void *buf, paddr_t addr, int size, unsigned int flags, uint32_t pfec)
+void *buf, paddr_t addr, int size, unsigned int flags, uint32_t pfec,
+pagefault_info_t *pfinfo)
 {
 struct vcpu *curr = current;
 unsigned long gfn;
@@ -3109,7 +3113,15 @@ static enum hvm_copy_result __hvm_copy(
 if ( pfec & PFEC_page_shared

Re: [Xen-devel] [PATCH 01/15] x86/hvm: Rename hvm_emulate_init() and hvm_emulate_prepare() for clarity

> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 23 November 2016 15:39
> To: Xen-devel 
> Cc: Andrew Cooper ; Jan Beulich
> ; Paul Durrant ; Jun
> Nakajima ; Kevin Tian ;
> Boris Ostrovsky ; Suravee Suthikulpanit
> ; Wei Liu 
> Subject: [PATCH 01/15] x86/hvm: Rename hvm_emulate_init() and
> hvm_emulate_prepare() for clarity
> 
>  * Move hvm_emulate_init() to immediately hvm_emulate_prepare(), as
> they are
>very closely related.
>  * Rename hvm_emulate_prepare() to hvm_emulate_init_once() and
>hvm_emulate_init() to hvm_emulate_init_per_insn() to make it clearer
> how to
>and when to use them.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Paul Durrant 

> ---
> CC: Jan Beulich 
> CC: Paul Durrant 
> CC: Jun Nakajima 
> CC: Kevin Tian 
> CC: Boris Ostrovsky 
> CC: Suravee Suthikulpanit 
> CC: Wei Liu 
> 
> As hvm_emulate_prepare() was new in 4.8, it would be a good idea to take
> this
> patch to avoid future confusion on the stable-4.8 branch
> ---
>  xen/arch/x86/hvm/emulate.c| 111 +++---
> 
>  xen/arch/x86/hvm/hvm.c|   2 +-
>  xen/arch/x86/hvm/io.c |   2 +-
>  xen/arch/x86/hvm/ioreq.c  |   2 +-
>  xen/arch/x86/hvm/svm/emulate.c|   4 +-
>  xen/arch/x86/hvm/vmx/realmode.c   |   2 +-
>  xen/include/asm-x86/hvm/emulate.h |   6 ++-
>  7 files changed, 66 insertions(+), 63 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
> index e9b8f8c..3ab0e8e 100644
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -1755,57 +1755,6 @@ static const struct x86_emulate_ops
> hvm_emulate_ops_no_write = {
>  .vmfunc= hvmemul_vmfunc,
>  };
> 
> -void hvm_emulate_init(
> -struct hvm_emulate_ctxt *hvmemul_ctxt,
> -const unsigned char *insn_buf,
> -unsigned int insn_bytes)
> -{
> -struct vcpu *curr = current;
> -unsigned int pfec = PFEC_page_present;
> -unsigned long addr;
> -
> -if ( hvm_long_mode_enabled(curr) &&
> - hvmemul_ctxt->seg_reg[x86_seg_cs].attr.fields.l )
> -{
> -hvmemul_ctxt->ctxt.addr_size = hvmemul_ctxt->ctxt.sp_size = 64;
> -}
> -else
> -{
> -hvmemul_ctxt->ctxt.addr_size =
> -hvmemul_ctxt->seg_reg[x86_seg_cs].attr.fields.db ? 32 : 16;
> -hvmemul_ctxt->ctxt.sp_size =
> -hvmemul_ctxt->seg_reg[x86_seg_ss].attr.fields.db ? 32 : 16;
> -}
> -
> -if ( hvmemul_ctxt->seg_reg[x86_seg_ss].attr.fields.dpl == 3 )
> -pfec |= PFEC_user_mode;
> -
> -hvmemul_ctxt->insn_buf_eip = hvmemul_ctxt->ctxt.regs->eip;
> -if ( !insn_bytes )
> -{
> -hvmemul_ctxt->insn_buf_bytes =
> -hvm_get_insn_bytes(curr, hvmemul_ctxt->insn_buf) ?:
> -(hvm_virtual_to_linear_addr(x86_seg_cs,
> -&hvmemul_ctxt->seg_reg[x86_seg_cs],
> -hvmemul_ctxt->insn_buf_eip,
> -sizeof(hvmemul_ctxt->insn_buf),
> -hvm_access_insn_fetch,
> -hvmemul_ctxt->ctxt.addr_size,
> -&addr) &&
> - hvm_fetch_from_guest_virt_nofault(hvmemul_ctxt->insn_buf,
> addr,
> -   
> sizeof(hvmemul_ctxt->insn_buf),
> -   pfec) == HVMCOPY_okay) ?
> -sizeof(hvmemul_ctxt->insn_buf) : 0;
> -}
> -else
> -{
> -hvmemul_ctxt->insn_buf_bytes = insn_bytes;
> -memcpy(hvmemul_ctxt->insn_buf, insn_buf, insn_bytes);
> -}
> -
> -hvmemul_ctxt->exn_pending = 0;
> -}
> -
>  static int _hvm_emulate_one(struct hvm_emulate_ctxt *hvmemul_ctxt,
>  const struct x86_emulate_ops *ops)
>  {
> @@ -1815,7 +1764,8 @@ static int _hvm_emulate_one(struct
> hvm_emulate_ctxt *hvmemul_ctxt,
>  struct hvm_vcpu_io *vio = &curr->arch.hvm_vcpu.hvm_io;
>  int rc;
> 
> -hvm_emulate_init(hvmemul_ctxt, vio->mmio_insn, vio-
> >mmio_insn_bytes);
> +hvm_emulate_init_per_insn(hvmemul_ctxt, vio->mmio_insn,
> +  vio->mmio_insn_bytes);
> 
>  vio->mmio_retry = 0;
> 
> @@ -1915,7 +1865,7 @@ int hvm_emulate_one_mmio(unsigned long mfn,
> unsigned long gla)
>  else
>  ops = &hvm_ro_emulate_ops_mmio;
> 
> -hvm_emulate_prepare(&ctxt, guest_cpu_user_regs());
> +hvm_emulate_init_once(&ctxt, guest_cpu_user_regs());
>  ctxt.ctxt.data = &mmio_ro_ctxt;
>  rc = _hvm_emulate_one(&ctxt, ops);
>  switch ( rc )
> @@ -1940,7 +1890,7 @@ void hvm_emulate_one_vm_event(enum
> emul_kind kind, unsigned int trapnr,
>  struct hvm_emulate_ctxt ctx = {{ 0 }};
>  int rc;
> 
> -hvm_emulate_prepare(&ctx, guest_cpu_user_regs());
> +hvm_emulate_init_once(&ctx, guest_cpu_user_regs());
> 
>  switch ( kind )
>

Re: [Xen-devel] [PATCH 01/15] x86/hvm: Rename hvm_emulate_init() and hvm_emulate_prepare() for clarity

On Wed, Nov 23, 2016 at 03:38:44PM +, Andrew Cooper wrote:
>  * Move hvm_emulate_init() to immediately hvm_emulate_prepare(), as they are
>very closely related.
>  * Rename hvm_emulate_prepare() to hvm_emulate_init_once() and
>hvm_emulate_init() to hvm_emulate_init_per_insn() to make it clearer how to
>and when to use them.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 
Release-acked-by: Wei Liu 

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

[Xen-devel] [xen-unstable test] 102522: tolerable FAIL - PUSHED

2016-11-23 Thread osstest service owner

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-xtf-amd64-amd64-3   65 leak-check/check fail in 102500 pass in 102522
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install 
fail pass in 102500
 test-amd64-amd64-rumprun-amd64 16 rumprun-demo-xenstorels/xenstorels.repeat 
fail pass in 102500

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 102465
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 102465
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 102465
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 102465
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 102465
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 102465
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 102465
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 102465
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 102465
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 102465

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

version targeted for testing:
 xen  f678e2c78110e73431217306bbd33c736802d700
baseline version:
 xen  58bd0c7985890e0292212f94a56235228a3445c3

Last test of basis   102465  2016-11-21 01:58:00 Z2 days
Failing since102489  2016-11-21 17:49:05 Z1 days3 attempts
Testing same since   102500  2016-11-22 03:12:15 Z1 days2 attempts


People who touched revisions under test:
  Andrew Cooper 

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

Re: [Xen-devel] [PATCH 02/15] x86/emul: Simplfy emulation state setup