Re: [Xen-devel] [PATCH 2/2] xen/arm32: Use alternative to skip the check of pending serrors

[Wei Chen]

Hi Julien,

On 2017/3/17 1:36, Julien Grall wrote:
> Hi Wei,
>
> On 03/16/2017 09:53 AM, Wei Chen wrote:
>> We have provided an option to administrator to determine how to
>> handle the SErrors. In order to skip the check of pending SError,
>> in conventional way, we have to read the option every time before
>> we try to check the pending SError. This will add overhead to check
>> the option at every trap.
>>
>> The ARM32 supports the alternative patching feature. We can use an
>> ALTERNATIVE to avoid checking option at every trap. We added a new
>> cpufeature named "SKIP_CHECK_PENDING_VSERROR". This feature will be
>> enabled when the option is not diverse.
>
> Can you please squash this patch in #10 of the SError series?
>

I will squash it to new version of SError series.

> Cheers,
>


-- 
Regards,
Wei Chen

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

[Xen-devel] [xen-unstable test] 106724: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail REGR. vs. 
106652

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-rumprun-amd64 16 rumprun-demo-xenstorels/xenstorels.repeat 
fail in 106698 pass in 106724
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat  fail pass in 106698

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 106642
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 106652
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106652
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 106652
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 106652
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 106652
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 106652
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 106652

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 build-arm64   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-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-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-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-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 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
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 xen  bfd9a2095f1882e8c074b2d911bcb07d12cf6cf5
baseline version:
 xen  bd8ad2a52aba4911ada897c72f8795172a09a193

Last test of basis   106652  2017-03-14 08:24:37 Z2 days
Failing since106671  2017-03-14 20:44:11 Z2 days4 attempts
Testing same since   106698  2017-03-15 17:48:34 Z1 days3 attempts

Re: [Xen-devel] [PATCH] xen: sched: don't call hooks of the wrong scheduler via VCPU2OP

[Juergen Gross]

On 16/03/17 22:30, Dario Faggioli wrote:
> Within context_saved(), we call the context_saved hook,
> and we use VCPU2OP() to determine from what scheduler.
> VCPU2OP uses DOM2OP, which uses d->cpupool, which is
> NULL when d is the idle domain. And in that case,
> DOM2OP just returns ops, the scheduler of cpupool0.
> 
> Therefore, if:
> - cpupool0's scheduler defines context_saved (like
>   Credit2 and RTDS do),
> - we are not in cpupool0 (i.e., our scheduler is
>   not ops),
> - we are context switching from idle,
> 
> we call VCPU2OP(idle_vcpu), which means
> DOM2OP(idle->cpupool), which is ops.
> 
> Therefore, we both:
> - check if context_saved is defined in the wrong
>   scheduler;
> - if yes, call the wrong one.
> 
> When using Credit2 at boot, and also Credit2 in
> the other cpupool, this is wrong but innocuous,
> because it only involves the idle vcpus.
> 
> When using Credit2 at boot, and Credit1 in the
> other cpupool, this is *totally* wrong, and
> it's by chance it does not explode!
> 
> When using Credit2 and other schedulers I'm
> developping, I hit the following assert (in
> sched_credit2.c, on a CPU inside a cpupool that
> does not use Credit2):
> 
> csched2_context_saved()
> {
>  ...
>  ASSERT(!vcpu_on_runq(svc));
>  ...
> }
> 
> Fix this by taking care, in VCPU2OP, of the case
> when the vcpu is an idle one.
> 
> Signed-off-by: Dario Faggioli 

Reviewed-by: Juergen Gross 

... with or without the remark below addressed.

> ---
> Cc: George Dunlap 
> Cc: Juergen Gross 
> Cc: Jan Beulich 
> ---
> Cc-ing Jan, as this should be backported at least to 4.8, but, IMO, as back as
> possible.
> ---
>  xen/common/schedule.c |   14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/common/schedule.c b/xen/common/schedule.c
> index 223a120..d12f346 100644
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -78,7 +78,19 @@ static struct scheduler __read_mostly ops;
>: (typeof((opsptr)->fn(opsptr, ##__VA_ARGS__)))0 )
>  
>  #define DOM2OP(_d)(((_d)->cpupool == NULL) ?  : 
> ((_d)->cpupool->sched))
> -#define VCPU2OP(_v)   (DOM2OP((_v)->domain))
> +static inline struct scheduler* VCPU2OP(const struct vcpu *v)

Rename, e.g. get_scheduler() ?

> +{
> +struct domain *d = v->domain;
> +
> +if ( likely(d->cpupool != NULL) )
> +return d->cpupool->sched;
> +
> +/* v->processor never changes for idle vcpus, so using it here is safe */
> +if ( likely(is_idle_domain(d)) )
> +return per_cpu(scheduler, v->processor);
> +else
> +return 
> +}
>  #define VCPU2ONLINE(_v) cpupool_domain_cpumask((_v)->domain)
>  
>  static inline void trace_runstate_change(struct vcpu *v, int new_state)


Juergen


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

Re: [Xen-devel] [PATCH v3 4/7] xen/9pfs: connect to the backend

[Juergen Gross]

On 16/03/17 19:03, Stefano Stabellini wrote:
> On Thu, 16 Mar 2017, Juergen Gross wrote:
>> On 15/03/17 19:44, Stefano Stabellini wrote:
>>> On Wed, 15 Mar 2017, Juergen Gross wrote:
 On 14/03/17 22:22, Stefano Stabellini wrote:
> Hi Juergen,
>
> thank you for the review!
>
> On Tue, 14 Mar 2017, Juergen Gross wrote:
>> On 14/03/17 00:50, Stefano Stabellini wrote:
>>> Implement functions to handle the xenbus handshake. Upon connection,
>>> allocate the rings according to the protocol specification.
>>>
>>> Initialize a work_struct and a wait_queue. The work_struct will be used
>>> to schedule work upon receiving an event channel notification from the
>>> backend. The wait_queue will be used to wait when the ring is full and
>>> we need to send a new request.
>>>
>>> Signed-off-by: Stefano Stabellini 
>>> CC: boris.ostrov...@oracle.com
>>> CC: jgr...@suse.com
>>> CC: Eric Van Hensbergen 
>>> CC: Ron Minnich 
>>> CC: Latchesar Ionkov 
>>> CC: v9fs-develo...@lists.sourceforge.net
>>> ---

>> Did you think about using request_threaded_irq() instead of a workqueue?
>> For an example see e.g. drivers/scsi/xen-scsifront.c
>
> I like workqueues :-)  It might come down to personal preferences, but I
> think workqueues are more flexible and a better fit for this use case.
> Not only it is easy to schedule work in a workqueue from the interrupt
> handler, but also they can be used for sleeping in the request function
> if there is not enough room on the ring. Besides, they can easily be
> configured to share a single thread or to have multiple independent
> threads.

 I'm fine with the workqueues as long as you have decided to use them
 considering the alternatives. :-)

>> Can't you use xenbus_read_unsigned() instead of xenbus_read()?
>
> I can use xenbus_read_unsigned in the other cases below, but not here,
> because versions is in the form: "1,3,4"

 Is this documented somewhere?

 Hmm, are any of the Xenstore entries documented? Shouldn't this be done
 in xen_9pfs.h ?
>>>  
>>> They are documented in docs/misc/9pfs.markdown, under "Xenstore". Given
>>> that it's all written there, especially the semantics, I didn't repeat
>>> it in xen_9pfs.h
>>
>> Looking at it from the Linux kernel perspective this documentation is
>> not really highly visible. For me it is okay, but there have been
>> multiple examples in the past where documentation in the Xen repository
>> wasn't regarded as being sufficient.
>>
>> I recommend moving the documentation regarding the interface into the
>> header file like for the other pv interfaces.
> 
> What about adding a link such as:
> 
> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob_plain;f=docs/misc/9pfs.markdown;hb=HEAD
> 
> that should be easily accessible, right? For other specifications, such
> as 9p, only links are provided (see Documentation/filesystems/9p.txt).
> I am suggesting a link, because then we are sure the specs don't go out
> of sync. I realize that older PV protocols were described in header
> files, but that was before Xen Project had a formal process for getting
> new specifications accepted, and a formal place where to publish them.

Fine with me. Lets see if other maintainers are okay with it, too.


Juergen


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

Re: [Xen-devel] [PATCH 2/2] configure: use pkg-config for obtaining xen version

[Juergen Gross]

On 16/03/17 21:20, Stefano Stabellini wrote:
> On Thu, 16 Mar 2017, Juergen Gross wrote:
>> Instead of trying to guess the Xen version to use by compiling various
>> test programs first just ask the system via pkg-config. Only if it
>> can't return the version fall back to the test program scheme.
> 
> That's OK, but why did you remove the Xen unstable test?

From Xen 4.9 on pkg-config will return the needed information. There is
no longer a need for a test program to determine the Xen version. After
all this was the main objective of my series adding the pkg-config
files to Xen.


Juergen

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

Re: [Xen-devel] Bug#852324: x86/mm: Found insecure W+X mapping

[Boris Ostrovsky]

On 03/16/2017 08:18 PM, Ben Hutchings wrote:

On Thu, 2017-03-16 at 21:49 +, Andrew Cooper wrote:

On 16/03/2017 21:05, Ben Hutchings wrote:

On Thu, 2017-03-16 at 00:50 +, Ben Hutchings wrote:

On Wed, 2017-03-15 at 22:24 +, Ben Hutchings wrote:

Control: retitle -1 [xen] x86/mm: Found insecure W+X mapping
Control: tag -1 upstream confirmed
Control: found -1 4.9.13-1

I can reproduce this with a current Debian kernel on top of Xen 4.4.
It doesn't happen with the same hardware booting the kernel directly.


With CONFIG_X86_PTDUMP enabled, I can see that the first 16 MiB of the
low kernel mapping is mapped with W+X permissions, with a few
exceptions:

0x8800-0x88099000 612K USR RW x 
 pte
0x88099000-0x8809a000   4K USR ro 
NX pte
0x8809a000-0x8809b000   4K USR ro x 
 pte
0x8809b000-0x8809f000  16K USR RW 
NX pte
0x8809f000-0x8810 388K USR RW PWT PCD x 
 pte
0x8810-0x88102000   8K USR RW x 
 pte
0x88102000-0x88000100   15352K USR RW x 
 pte

This accounts for all the 4090 pages reported at boot.


I see this same mapping when running Linux 4.9 under either Xen 4.4 or
4.8 (from Debian stable or unstable).

I don't really understand how the PV MMU page tables are set up.  I did
try setting the NX flag in make_lowmem_page_readwrite() and that didn't
make any difference to the number of W+X pages.


64bit PV guests have some rather special pagetable set up.  For one, the
USR bit will be unconditionally set and Xen doesn't tolerate some
mappings being writeable,


I understood that much.


but these RWX areas are clearly ok in Xens eyes.


So that proves these pages aren't mapped to native page tables or other
sensitive structures, right?


Everything from 0x8800 upwards belongs to the guest kernel
per the PV ABI.  The initial layout will be constructed by the domain
builder on behalf of the kernel, but it is Linux's to arbitrarily alter
later on.


But it seems to avoid doing that in generic code - see phys_pte_init()
in arch/x86/mm/init_64.c.



I believe that's because we are reusing pre-built tables which don't 
have NX bit set, see xen_setup_kernel_pagetable().


-boris




Can you boot a debug hypervisor and look at `xl dmesg` starting at the
"*** LOADING DOMAIN 0 ***" line?  This should dump the state that the
domain builder leaves dom0 in, which would help identify whether those
regions are leftovers from the domain builder, or something constructed
by the Linux PV early boot code.


This is from a hypervisor built with CONFIG_DEBUG=y and everything else
set to defaults (I think):

(XEN) *** LOADING DOMAIN 0 ***
(XEN) ELF: phdr: paddr=0x100 memsz=0xac7000
(XEN) ELF: phdr: paddr=0x1c0 memsz=0x11c000
(XEN) ELF: phdr: paddr=0x1d1c000 memsz=0x193d8
(XEN) ELF: phdr: paddr=0x1d36000 memsz=0x221000
(XEN) ELF: memory: 0x100 -> 0x1f57000
(XEN) ELF: note: GUEST_OS = "linux"
(XEN) ELF: note: GUEST_VERSION = "2.6"
(XEN) ELF: note: XEN_VERSION = "xen-3.0"
(XEN) ELF: note: VIRT_BASE = 0x8000
(XEN) ELF: note: INIT_P2M = 0x80
(XEN) ELF: note: ENTRY = 0x81d36180
(XEN) ELF: note: HYPERCALL_PAGE = 0x81001000
(XEN) ELF: note: FEATURES = 
"!writable_page_tables|pae_pgdir_above_4gb|writable_descriptor_tables|auto_translated_physmap|supervisor_mode_kernel"
(XEN) ELF: note: SUPPORTED_FEATURES = 0x90d
(XEN) ELF: note: PAE_MODE = "yes"
(XEN) ELF: note: LOADER = "generic"
(XEN) ELF: note: unknown (0xd)
(XEN) ELF: note: SUSPEND_CANCEL = 0x1
(XEN) ELF: note: MOD_START_PFN = 0x1
(XEN) ELF: note: HV_START_LOW = 0x8000
(XEN) ELF: note: PADDR_OFFSET = 0
(XEN) ELF: addresses:
(XEN) virt_base= 0x8000
(XEN) elf_paddr_offset = 0x0
(XEN) virt_offset  = 0x8000
(XEN) virt_kstart  = 0x8100
(XEN) virt_kend= 0x81f57000
(XEN) virt_entry   = 0x81d36180
(XEN) p2m_base = 0x80
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x100 -> 0x1f57000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   00021400->00021600 (1947334 pages to be 
allocated)
(XEN)  Init. ramdisk: 00021e45a000->00021f5ff530
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: 8100->81f57000
(XEN)  Init. ramdisk: ->
(XEN)  Phys-Mach map: 0080->008000ef4360
(XEN)  Start info:81f57000->81f574b4
(XEN)  Page tables:   81f58000->81f6b000
(XEN)  Boot stack:81f6b000->81f6c000
(XEN)  TOTAL: 8000->8200
(XEN)  ENTRY ADDRESS: 81d36180
(XEN) Dom0 has 

[Xen-devel] [linux-4.1 test] 106720: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvh-intel 11 guest-start fail REGR. vs. 104301

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 104301
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 104301
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 104301
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 104301
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 104301
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 104301

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 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-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 build-arm64   5 xen-buildfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-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-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  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-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 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
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass

version targeted for testing:
 linuxd9e0350d2575a20ee7783427da9bd6b6107eb983
baseline version:
 linuxf40b3cc69de8c97bbcdb74e3cffda06ffcad2cd7

Last test of basis   104301  2017-01-19 13:16:22 Z   56 days
Testing same since   106644  2017-03-13 22:17:49 Z3 days6 attempts


People who touched revisions under test:
  "Eric W. Biederman" 
  Adrian Hunter 
  Akinobu Mita 
  Al Viro 
  Alan Stern 
  Aleksander Morgado 
  Alex Deucher 
  Ander Conselvan de Oliveira 
  Andrew Morton 
  Andrey Konovalov 
  Andrey Ryabinin 
  Anssi Hannula 

Re: [Xen-devel] [PATCH v9 00/25] Enable L2 Cache Allocation Technology & Refactor psr.c

[Yi Sun]

On 17-03-16 05:20:35, Jan Beulich wrote:
> >>> On 16.03.17 at 12:07,  wrote:
> > Acked and Reviewed list before V9:
> > 
> > a - Acked-by
> > r - Reviewed-by
> > 
> >   r  patch 1  - docs: create Cache Allocation Technology (CAT) and Code and
> > Data Prioritization (CDP) feature document
> >   ar patch 2  - x86: refactor psr: remove L3 CAT/CDP codes.
> >   r  patch 3  - x86: refactor psr: implement main data structures.
> >   r  patch 6  - x86: refactor psr: L3 CAT: implement Domain init/free and
> > schedule flows.
> >   r  patch 7  - x86: refactor psr: L3 CAT: implement get hw info flow.
> >   r  patch 8  - x86: refactor psr: L3 CAT: implement get value flow.
> 
> I didn't check whether you've kept them, but the changes you've
> listed certainly are such that the last four of the above pretty likely
> would need to have any prior tags dropped (in which case the
> overview above is misleading).
> 
Oh, sorry. I thought I should keep all ack/review history. But I am wrong.
For any reworked patch, I should remove a or r. But one question, if only
some minor changes added, shall I remove a or r? Thanks!

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

[Xen-devel] [qemu-mainline test] 106718: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 106702
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 106702
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106702
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 106702
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 106702
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 106702

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 build-arm64-xsm   5 xen-buildfail   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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail 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-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   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-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu3716fba3f58de0eea32b8da29976c902549cc836
baseline version:
 qemuu1883ff34b540daacae948f493b0ba525edf5f642

Last test of basis   106702  2017-03-15 21:17:32 Z1 days
Testing same since   106718  2017-03-16 13:23:34 Z0 days1 attempts


People who touched revisions under test:
  John Snow 
  Li Qiang 
  Li Qiang 
  Marcel Apfelbaum 
  Mark Cave-Ayland 
  Michael S. Tsirkin 
  Peter Maydell 
  zhanghailiang 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  fail
 build-armhf-xsm  pass
 build-i386-xsm   

Re: [Xen-devel] Bug#852324: x86/mm: Found insecure W+X mapping

[Ben Hutchings]

On Thu, 2017-03-16 at 21:49 +, Andrew Cooper wrote:
> On 16/03/2017 21:05, Ben Hutchings wrote:
> > On Thu, 2017-03-16 at 00:50 +, Ben Hutchings wrote:
> > > On Wed, 2017-03-15 at 22:24 +, Ben Hutchings wrote:
> > > > Control: retitle -1 [xen] x86/mm: Found insecure W+X mapping
> > > > Control: tag -1 upstream confirmed
> > > > Control: found -1 4.9.13-1
> > > > 
> > > > I can reproduce this with a current Debian kernel on top of Xen 4.4. 
> > > > It doesn't happen with the same hardware booting the kernel directly.
> > > 
> > > With CONFIG_X86_PTDUMP enabled, I can see that the first 16 MiB of the
> > > low kernel mapping is mapped with W+X permissions, with a few
> > > exceptions:
> > > 
> > > 0x8800-0x88099000 612K USR RW 
> > > x  pte
> > > 0x88099000-0x8809a000   4K USR ro 
> > > NX pte
> > > 0x8809a000-0x8809b000   4K USR ro 
> > > x  pte
> > > 0x8809b000-0x8809f000  16K USR RW 
> > > NX pte
> > > 0x8809f000-0x8810 388K USR RW PWT PCD 
> > > x  pte
> > > 0x8810-0x88102000   8K USR RW 
> > > x  pte
> > > 0x88102000-0x88000100   15352K USR RW 
> > > x  pte
> > > 
> > > This accounts for all the 4090 pages reported at boot.
> > 
> > I see this same mapping when running Linux 4.9 under either Xen 4.4 or
> > 4.8 (from Debian stable or unstable).
> > 
> > I don't really understand how the PV MMU page tables are set up.  I did
> > try setting the NX flag in make_lowmem_page_readwrite() and that didn't
> > make any difference to the number of W+X pages.
> 
> 64bit PV guests have some rather special pagetable set up.  For one, the
> USR bit will be unconditionally set and Xen doesn't tolerate some
> mappings being writeable,

I understood that much.

> but these RWX areas are clearly ok in Xens eyes.

So that proves these pages aren't mapped to native page tables or other
sensitive structures, right?

> Everything from 0x8800 upwards belongs to the guest kernel
> per the PV ABI.  The initial layout will be constructed by the domain
> builder on behalf of the kernel, but it is Linux's to arbitrarily alter
> later on.

But it seems to avoid doing that in generic code - see phys_pte_init()
in arch/x86/mm/init_64.c.

> Can you boot a debug hypervisor and look at `xl dmesg` starting at the
> "*** LOADING DOMAIN 0 ***" line?  This should dump the state that the
> domain builder leaves dom0 in, which would help identify whether those
> regions are leftovers from the domain builder, or something constructed
> by the Linux PV early boot code.

This is from a hypervisor built with CONFIG_DEBUG=y and everything else
set to defaults (I think):

(XEN) *** LOADING DOMAIN 0 ***
(XEN) ELF: phdr: paddr=0x100 memsz=0xac7000
(XEN) ELF: phdr: paddr=0x1c0 memsz=0x11c000
(XEN) ELF: phdr: paddr=0x1d1c000 memsz=0x193d8
(XEN) ELF: phdr: paddr=0x1d36000 memsz=0x221000
(XEN) ELF: memory: 0x100 -> 0x1f57000
(XEN) ELF: note: GUEST_OS = "linux"
(XEN) ELF: note: GUEST_VERSION = "2.6"
(XEN) ELF: note: XEN_VERSION = "xen-3.0"
(XEN) ELF: note: VIRT_BASE = 0x8000
(XEN) ELF: note: INIT_P2M = 0x80
(XEN) ELF: note: ENTRY = 0x81d36180
(XEN) ELF: note: HYPERCALL_PAGE = 0x81001000
(XEN) ELF: note: FEATURES = 
"!writable_page_tables|pae_pgdir_above_4gb|writable_descriptor_tables|auto_translated_physmap|supervisor_mode_kernel"
(XEN) ELF: note: SUPPORTED_FEATURES = 0x90d
(XEN) ELF: note: PAE_MODE = "yes"
(XEN) ELF: note: LOADER = "generic"
(XEN) ELF: note: unknown (0xd)
(XEN) ELF: note: SUSPEND_CANCEL = 0x1
(XEN) ELF: note: MOD_START_PFN = 0x1
(XEN) ELF: note: HV_START_LOW = 0x8000
(XEN) ELF: note: PADDR_OFFSET = 0
(XEN) ELF: addresses:
(XEN) virt_base= 0x8000
(XEN) elf_paddr_offset = 0x0
(XEN) virt_offset  = 0x8000
(XEN) virt_kstart  = 0x8100
(XEN) virt_kend= 0x81f57000
(XEN) virt_entry   = 0x81d36180
(XEN) p2m_base = 0x80
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x100 -> 0x1f57000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   00021400->00021600 (1947334 pages to be 
allocated)
(XEN)  Init. ramdisk: 00021e45a000->00021f5ff530
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: 8100->81f57000
(XEN)  Init. ramdisk: ->
(XEN)  Phys-Mach map: 0080->008000ef4360
(XEN)  Start info:81f57000->81f574b4
(XEN)  Page tables:   81f58000->81f6b000
(XEN)  Boot stack:81f6b000->81f6c000
(XEN)  TOTAL: 8000->8200
(XEN)  

Re: [Xen-devel] [PATCH 12/18] xen/arm: Introduce new helpers to handle guest/hyp SErrors

[Stefano Stabellini]

On Mon, 13 Mar 2017, Wei Chen wrote:
> Currently, ARM32 and ARM64 has different SError exception handlers.
> These handlers include lots of code to check SError handle options
> and code to distinguish guest-generated SErrors from hypervisor
> SErrors.
> 
> The new helpers: do_trap_guest_serror and do_trap_hyp_serror are
> wrappers of __do_trap_serror with constant guest/hyp parameters.
> __do_trap_serror moves the option checking code and SError checking
> code from assembly to C source. This will make the code become more
> readable and avoid placing check code in too many places.
> 
> These two helpers only handle the following 3 types of SErrors:
> 1) Guest-generated SError and had been delivered in EL1 and then
>been forwarded to EL2.
> 2) Guest-generated SError but hadn't been delivered in EL1 before
>trapping to EL2. This SError would be caught in EL2 as soon as
>we just unmasked the PSTATE.A bit.
> 3) Hypervisor generated native SError, that would be a bug.
> 
> In the new helpers, we have used the function "inject_vabt_exception"
> which was disabled by "#if 0" before. Now, we can remove the "#if 0"
> to make this function to be available.
> 
> Signed-off-by: Wei Chen 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/traps.c| 69 
> +++--
>  xen/include/asm-arm/processor.h |  4 +++
>  2 files changed, 71 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 053b7fc..48cfc8e 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -646,7 +646,6 @@ static void inject_dabt_exception(struct cpu_user_regs 
> *regs,
>  #endif
>  }
>  
> -#if 0
>  /* Inject a virtual Abort/SError into the guest. */
>  static void inject_vabt_exception(struct cpu_user_regs *regs)
>  {
> @@ -676,7 +675,59 @@ static void inject_vabt_exception(struct cpu_user_regs 
> *regs)
>  
>  current->arch.hcr_el2 |= HCR_VA;
>  }
> -#endif
> +
> +/*
> + * SError exception handler. We only handle the following 3 types of SErrors:
> + * 1) Guest-generated SError and had been delivered in EL1 and then
> + *been forwarded to EL2.
> + * 2) Guest-generated SError but hadn't been delivered in EL1 before
> + *trapping to EL2. This SError would be caught in EL2 as soon as
> + *we just unmasked the PSTATE.A bit.
> + * 3) Hypervisor generated native SError, that would be a bug.
> + *
> + * A true parameter "guest" means that the SError is type#1 or type#2.
> + */
> +static void __do_trap_serror(struct cpu_user_regs *regs, bool guest)
> +{
> +/*
> + * Only "DIVERSE" option needs to distinguish the guest-generated SErrors
> + * from hypervisor SErrors.
> + */
> +if ( serrors_op == SERRORS_DIVERSE )
> +{
> +/* Forward the type#1 and type#2 SErrors to guests. */
> +if ( guest )
> +return inject_vabt_exception(regs);
> +
> +/* Type#3 SErrors will panic the whole system */
> +goto crash_system;
> +}
> +
> +/*
> + * The "FORWARD" option will forward all SErrors to the guests, except
> + * idle domain generated SErrors.
> + */
> +if ( serrors_op == SERRORS_FORWARD )
> +{
> +/*
> + * Because the idle domain doesn't have the ability to handle the
> + * SErrors, we have to crash the whole system while we get a SError
> + * generated by idle domain.
> + */
> +if ( is_idle_vcpu(current) )
> +goto crash_system;
> +
> +return inject_vabt_exception(regs);
> +}
> +
> +crash_system:
> +/* Three possibilities to crash the whole system:
> + * 1) "DIVERSE" option with Hypervisor generated SErrors.
> + * 2) "FORWARD" option with Idle Domain generated SErrors.
> + * 3) "PANIC" option with all SErrors.
> + */
> +do_unexpected_trap("SError", regs);
> +}
>  
>  struct reg_ctxt {
>  /* Guest-side state */
> @@ -2863,6 +2914,20 @@ asmlinkage void do_trap_guest_error(struct 
> cpu_user_regs *regs)
>  domain_crash_synchronous();
>  }
>  
> +asmlinkage void do_trap_hyp_serror(struct cpu_user_regs *regs)
> +{
> +enter_hypervisor_head(regs);
> +
> +__do_trap_serror(regs, VABORT_GEN_BY_GUEST(regs));
> +}
> +
> +asmlinkage void do_trap_guest_serror(struct cpu_user_regs *regs)
> +{
> +enter_hypervisor_head(regs);
> +
> +__do_trap_serror(regs, true);
> +}
> +
>  asmlinkage void do_trap_irq(struct cpu_user_regs *regs)
>  {
>  enter_hypervisor_head(regs);
> diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
> index 148cc6f..885dbca 100644
> --- a/xen/include/asm-arm/processor.h
> +++ b/xen/include/asm-arm/processor.h
> @@ -709,6 +709,10 @@ int call_smc(register_t function_id, register_t arg0, 
> register_t arg1,
>  
>  void do_trap_guest_error(struct cpu_user_regs *regs);
>  
> +void do_trap_hyp_serror(struct cpu_user_regs *regs);
> +
> +void 

Re: [Xen-devel] [PATCH 13/18] xen/arm: Replace do_trap_guest_serror with new helpers

[Stefano Stabellini]

On Mon, 13 Mar 2017, Wei Chen wrote:
> We have introduced two helpers to handle the guest/hyp SErrors:
> do_trap_guest_serror and do_trap_guest_hyp_serror. These handlers
> can take the role of do_trap_guest_serror and reduce the assembly
> code in the same time. So we use these two helpers to replace it
> and drop it now.
> 
> Signed-off-by: Wei Chen 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/arm32/traps.c  |  5 +
>  xen/arch/arm/arm64/entry.S  | 36 +++-
>  xen/arch/arm/traps.c| 15 ---
>  xen/include/asm-arm/processor.h |  2 --
>  4 files changed, 4 insertions(+), 54 deletions(-)
> 
> diff --git a/xen/arch/arm/arm32/traps.c b/xen/arch/arm/arm32/traps.c
> index 4176f0e..5bc5f64 100644
> --- a/xen/arch/arm/arm32/traps.c
> +++ b/xen/arch/arm/arm32/traps.c
> @@ -62,10 +62,7 @@ asmlinkage void do_trap_prefetch_abort(struct 
> cpu_user_regs *regs)
>  
>  asmlinkage void do_trap_data_abort(struct cpu_user_regs *regs)
>  {
> -if ( VABORT_GEN_BY_GUEST(regs) )
> -do_trap_guest_error(regs);
> -else
> -do_unexpected_trap("Data Abort", regs);
> +do_trap_hyp_serror(regs);
>  }
>  
>  /*
> diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
> index 113e1c3..8d5a890 100644
> --- a/xen/arch/arm/arm64/entry.S
> +++ b/xen/arch/arm/arm64/entry.S
> @@ -178,40 +178,10 @@ hyp_error_invalid:
>  invalid BAD_ERROR
>  
>  hyp_error:
> -/*
> - * Only two possibilities:
> - * 1) Either we come from the exit path, having just unmasked
> - *PSTATE.A: change the return code to an EL2 fault, and
> - *carry on, as we're already in a sane state to handle it.
> - * 2) Or we come from anywhere else, and that's a bug: we panic.
> - */
>  entry   hyp=1
>  msr daifclr, #2
> -
> -/*
> - * The ELR_EL2 may be modified by an interrupt, so we have to use the
> - * saved value in cpu_user_regs to check whether we come from 1) or
> - * not.
> - */
> -ldr x0, [sp, #UREGS_PC]
> -adr x1, abort_guest_exit_start
> -cmp x0, x1
> -adr x1, abort_guest_exit_end
> -ccmpx0, x1, #4, ne
>  mov x0, sp
> -mov x1, #BAD_ERROR
> -
> -/*
> - * Not equal, the exception come from 2). It's a bug, we have to
> - * panic the hypervisor.
> - */
> -b.nedo_bad_mode
> -
> -/*
> - * Otherwise, the exception come from 1). It happened because of
> - * the guest. Crash this guest.
> - */
> -bl  do_trap_guest_error
> +bl  do_trap_hyp_serror
>  exithyp=1
>  
>  /* Traps taken in Current EL with SP_ELx */
> @@ -267,7 +237,7 @@ guest_error:
>  entry   hyp=0, compat=0
>  msr daifclr, #2
>  mov x0, sp
> -bl  do_trap_guest_error
> +bl  do_trap_guest_serror
>  exithyp=0, compat=0
>  
>  guest_sync_compat:
> @@ -309,7 +279,7 @@ guest_error_compat:
>  entry   hyp=0, compat=1
>  msr daifclr, #2
>  mov x0, sp
> -bl  do_trap_guest_error
> +bl  do_trap_guest_serror
>  exithyp=0, compat=1
>  
>  ENTRY(return_to_new_vcpu32)
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 48cfc8e..44a0281 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2899,21 +2899,6 @@ asmlinkage void do_trap_hypervisor(struct 
> cpu_user_regs *regs)
>  }
>  }
>  
> -asmlinkage void do_trap_guest_error(struct cpu_user_regs *regs)
> -{
> -enter_hypervisor_head(regs);
> -
> -/*
> - * Currently, to ensure hypervisor safety, when we received a
> - * guest-generated vSerror/vAbort, we just crash the guest to protect
> - * the hypervisor. In future we can better handle this by injecting
> - * a vSerror/vAbort to the guest.
> - */
> -gdprintk(XENLOG_WARNING, "Guest(Dom-%u) will be crashed by vSError\n",
> - current->domain->domain_id);
> -domain_crash_synchronous();
> -}
> -
>  asmlinkage void do_trap_hyp_serror(struct cpu_user_regs *regs)
>  {
>  enter_hypervisor_head(regs);
> diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
> index 885dbca..afad78c 100644
> --- a/xen/include/asm-arm/processor.h
> +++ b/xen/include/asm-arm/processor.h
> @@ -707,8 +707,6 @@ void vcpu_regs_user_to_hyp(struct vcpu *vcpu,
>  int call_smc(register_t function_id, register_t arg0, register_t arg1,
>   register_t arg2);
>  
> -void do_trap_guest_error(struct cpu_user_regs *regs);
> -
>  void do_trap_hyp_serror(struct cpu_user_regs *regs);
>  
>  void do_trap_guest_serror(struct cpu_user_regs *regs);
> -- 
> 2.7.4
> 
> 
> ___
> Xen-devel mailing list
> 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 105963
 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 105963

version targeted for testing:
 ovmf 056563f1bbda839bab2ba32bd9bef962b862a9bd
baseline version:
 ovmf e0307a7dad02aa8c0cd8b3b0b9edce8ddb3fef2e

Last test of basis   105963  2017-02-21 21:43:31 Z   23 days
Failing since105980  2017-02-22 10:03:53 Z   22 days   60 attempts
Testing same since   106716  2017-03-16 12:15:07 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Ard Biesheuvel 
  Bi, Dandan 
  Brijesh Singh 
  Chao Zhang 
  Chen A Chen 
  Dandan Bi 
  edk2-devel On Behalf Of rthomaiy <[mailto:edk2-devel-boun...@lists.01.org]>
  Feng Tian 
  Fu Siyuan 
  Hao Wu 
  Hegde Nagaraj P 
  Hess Chen 
  Jeff Fan 
  Jiaxin Wu 
  Jiewen Yao 
  Laszlo Ersek 
  Leo Duran 
  Marvin Haeuser 
  Marvin Häuser 
  Michael Zimmermann 
  Paolo Bonzini 
  Qin Long 
  Richard Thomaiyar 
  Ruiyu Ni 
  Ryan Harkin 
  Star Zeng 
  Wu Jiaxin 
  Yonghong Zhu 
  Zhang Lubo 
  Zhang, Chao B 
  Zhang, Lubo 

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



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] [PATCH 11/18] xen/arm: Move macro VABORT_GEN_BY_GUEST to common header

[Stefano Stabellini]

On Mon, 13 Mar 2017, Wei Chen wrote:
> We want to move part of SErrors checking code from hyp_error assembly code
> to a function. This new function will use this macro to distinguish the
> guest SErrors from hypervisor SErrors. So we have to move this macro to
> common header.
> 
> Signed-off-by: Wei Chen 
> ---
>  xen/arch/arm/arm64/entry.S|  2 ++
>  xen/include/asm-arm/arm32/processor.h | 10 --
>  xen/include/asm-arm/processor.h   | 10 ++
>  3 files changed, 12 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
> index 4baa3cb..113e1c3 100644
> --- a/xen/arch/arm/arm64/entry.S
> +++ b/xen/arch/arm/arm64/entry.S
> @@ -380,10 +380,12 @@ check_pending_vserror:
>   * exception handler, and the elr_el2 will be set to
>   * abort_guest_exit_start or abort_guest_exit_end.
>   */
> +.global abort_guest_exit_start
>  abort_guest_exit_start:
>  
>  isb
>  
> +.global abort_guest_exit_end
>  abort_guest_exit_end:
>  /* Mask PSTATE asynchronous abort bit, close the checking window. */
>  msr daifset, #4

These changes are unexplained in the commit message.


> diff --git a/xen/include/asm-arm/arm32/processor.h 
> b/xen/include/asm-arm/arm32/processor.h
> index f6d5df3..68cc821 100644
> --- a/xen/include/asm-arm/arm32/processor.h
> +++ b/xen/include/asm-arm/arm32/processor.h
> @@ -56,16 +56,6 @@ struct cpu_user_regs
>  uint32_t pad1; /* Doubleword-align the user half of the frame */
>  };
>  
> -/* Functions for pending virtual abort checking window. */
> -void abort_guest_exit_start(void);
> -void abort_guest_exit_end(void);
> -
> -#define VABORT_GEN_BY_GUEST(r)  \
> -( \
> -( (unsigned long)abort_guest_exit_start == (r)->pc ) || \
> -( (unsigned long)abort_guest_exit_end == (r)->pc ) \
> -)
> -
>  #endif
>  
>  /* Layout as used in assembly, with src/dest registers mixed in */
> diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
> index d7b0711..148cc6f 100644
> --- a/xen/include/asm-arm/processor.h
> +++ b/xen/include/asm-arm/processor.h
> @@ -709,6 +709,16 @@ int call_smc(register_t function_id, register_t arg0, 
> register_t arg1,
>  
>  void do_trap_guest_error(struct cpu_user_regs *regs);
>  
> +/* Functions for pending virtual abort checking window. */
> +void abort_guest_exit_start(void);
> +void abort_guest_exit_end(void);
> +
> +#define VABORT_GEN_BY_GUEST(r)  \
> +( \
> +( (unsigned long)abort_guest_exit_start == (r)->pc ) || \
> +( (unsigned long)abort_guest_exit_end == (r)->pc ) \
> +)
> +
>  register_t get_default_hcr_flags(void);
>  
>  #endif /* __ASSEMBLY__ */
> -- 
> 2.7.4
> 
> 
> ___
> 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 10/18] xen/arm32: Use cpu_hwcaps to skip the check of pending serrors

[Stefano Stabellini]

On Mon, 13 Mar 2017, Wei Chen wrote:
> We have provided an option to administrator to determine how to
> handle the SErrors. In order to skip the check of pending SError,
> in conventional way, we have to read the option every time before
> we try to check the pending SError.
> 
> Currently, we haven't export the option to other source file. But,
> in the previous patch, we had set "SKIP_CHECK_PENDING_VSERROR" to
> cpu_hwcaps when the option doesn't need to check the SErrors. So we
> can use checking cpu_hwcaps to replace checking the option directly.
> 
> Signed-off-by: Wei Chen 

Reviewed-by: Stefano Stabellini 


> ---
> This is a temporary solution, this would have to be dropped as soon
> as ARM32 gain support of alternative patching to avoid potential misusage.
> The alternative patching support patches for ARM32 are still in review
> stage.
> ---
>  xen/arch/arm/arm32/entry.S | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/xen/arch/arm/arm32/entry.S b/xen/arch/arm/arm32/entry.S
> index 2187226..79929ca 100644
> --- a/xen/arch/arm/arm32/entry.S
> +++ b/xen/arch/arm/arm32/entry.S
> @@ -1,5 +1,6 @@
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #define SAVE_ONE_BANKED(reg)mrs r11, reg; str r11, [sp, #UREGS_##reg]
> @@ -11,6 +12,21 @@
>  #define RESTORE_BANKED(mode) \
>  RESTORE_ONE_BANKED(SP_##mode) ; RESTORE_ONE_BANKED(LR_##mode) ; 
> RESTORE_ONE_BANKED(SPSR_##mode)
>  
> +/*
> + * If the SKIP_CHECK_PENDING_VSERROR has been set in the cpu feature,
> + * the checking of pending SErrors will be skipped.
> + *
> + * As it is a temporary solution, we are assuming that
> + * SKIP_CHECK_PENDING_VSERROR will always be in the first word for
> + * cpu_hwcaps. This would have to be dropped as soon as ARM32 gain
> + * support of alternative.
> + */
> +#define SKIP_VSERROR_CHECK  \
> +ldr r1, =cpu_hwcaps;\
> +ldr r1, [r1];   \
> +tst r1, #SKIP_CHECK_PENDING_VSERROR;\
> +moveq pc, lr
> +
>  #define SAVE_ALL\
>  sub sp, #(UREGS_SP_usr - UREGS_sp); /* SP, LR, SPSR, PC */  \
>  push {r0-r12}; /* Save R0-R12 */\
> @@ -44,6 +60,9 @@ save_guest_regs:
>  SAVE_BANKED(fiq)
>  SAVE_ONE_BANKED(R8_fiq); SAVE_ONE_BANKED(R9_fiq); 
> SAVE_ONE_BANKED(R10_fiq)
>  SAVE_ONE_BANKED(R11_fiq); SAVE_ONE_BANKED(R12_fiq);
> +
> +SKIP_VSERROR_CHECK
> +
>  /*
>   * Start to check pending virtual abort in the gap of Guest -> HYP
>   * world switch.
> -- 
> 2.7.4
> 
> 
> ___
> 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 09/18] xen/arm64: Use alternative to skip the check of pending serrors

[Stefano Stabellini]

On Mon, 13 Mar 2017, Wei Chen wrote:
> We have provided an option to administrator to determine how to
> handle the SErrors. In order to skip the check of pending SError,
> in conventional way, we have to read the option every time before
> we try to check the pending SError. This will add overhead to check
> the option at every trap.
> 
> The ARM64 supports the alternative patching feature. We can use an
> ALTERNATIVE to avoid checking option at every trap. We added a new
> cpufeature named "SKIP_CHECK_PENDING_VSERROR". This feature will be
> enabled when the option is not diverse.
> 
> Signed-off-by: Wei Chen 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/arm64/entry.S | 41 +
>  1 file changed, 25 insertions(+), 16 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
> index 02802c0..4baa3cb 100644
> --- a/xen/arch/arm/arm64/entry.S
> +++ b/xen/arch/arm/arm64/entry.S
> @@ -1,5 +1,6 @@
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  /*
> @@ -229,12 +230,14 @@ hyp_irq:
>  
>  guest_sync:
>  entry   hyp=0, compat=0
> -bl  check_pending_vserror
>  /*
> - * If x0 is Non-zero, a vSError took place, the initial exception
> - * doesn't have any significance to be handled. Exit ASAP
> + * The vSError will be checked while SKIP_CHECK_PENDING_VSERROR is
> + * not set. If a vSError took place, the initial exception will be
> + * skipped. Exit ASAP
>   */
> -cbnzx0, 1f
> +ALTERNATIVE("bl check_pending_vserror; cbnz x0, 1f",
> +"nop; nop",
> +SKIP_CHECK_PENDING_VSERROR)
>  msr daifclr, #2
>  mov x0, sp
>  bl  do_trap_hypervisor
> @@ -243,12 +246,14 @@ guest_sync:
>  
>  guest_irq:
>  entry   hyp=0, compat=0
> -bl  check_pending_vserror
>  /*
> - * If x0 is Non-zero, a vSError took place, the initial exception
> - * doesn't have any significance to be handled. Exit ASAP
> + * The vSError will be checked while SKIP_CHECK_PENDING_VSERROR is
> + * not set. If a vSError took place, the initial exception will be
> + * skipped. Exit ASAP
>   */
> -cbnzx0, 1f
> +ALTERNATIVE("bl check_pending_vserror; cbnz x0, 1f",
> +"nop; nop",
> +SKIP_CHECK_PENDING_VSERROR)
>  mov x0, sp
>  bl  do_trap_irq
>  1:
> @@ -267,12 +272,14 @@ guest_error:
>  
>  guest_sync_compat:
>  entry   hyp=0, compat=1
> -bl  check_pending_vserror
>  /*
> - * If x0 is Non-zero, a vSError took place, the initial exception
> - * doesn't have any significance to be handled. Exit ASAP
> + * The vSError will be checked while SKIP_CHECK_PENDING_VSERROR is
> + * not set. If a vSError took place, the initial exception will be
> + * skipped. Exit ASAP
>   */
> -cbnzx0, 1f
> +ALTERNATIVE("bl check_pending_vserror; cbnz x0, 1f",
> +"nop; nop",
> +SKIP_CHECK_PENDING_VSERROR)
>  msr daifclr, #2
>  mov x0, sp
>  bl  do_trap_hypervisor
> @@ -281,12 +288,14 @@ guest_sync_compat:
>  
>  guest_irq_compat:
>  entry   hyp=0, compat=1
> -bl  check_pending_vserror
>  /*
> - * If x0 is Non-zero, a vSError took place, the initial exception
> - * doesn't have any significance to be handled. Exit ASAP
> + * The vSError will be checked while SKIP_CHECK_PENDING_VSERROR is
> + * not set. If a vSError took place, the initial exception will be
> + * skipped. Exit ASAP
>   */
> -cbnzx0, 1f
> +ALTERNATIVE("bl check_pending_vserror; cbnz x0, 1f",
> +"nop; nop",
> +SKIP_CHECK_PENDING_VSERROR)
>  mov x0, sp
>  bl  do_trap_irq
>  1:
> -- 
> 2.7.4
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
> 

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 59254
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail REGR. vs. 59254
 build-armhf-pvops 4 host-build-prep   fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-win7-amd64  9 windows-installfail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-winxpsp3 17 guest-start/win.repeat fail REGR. vs. 
59254

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254

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

version targeted for testing:
 linux69eea5a4ab9c705496e912b55a9d312325de19e6
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  616 days
Failing since 59348  2015-07-10 04:24:05 Z  615 days  339 attempts
Testing same since   106714  2017-03-16 11:57:24 Z0 days1 attempts


8082 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  fail
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  blocked 
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvops   

Re: [Xen-devel] [PATCH 08/18] xen/arm: Introduce a initcall to update cpu_hwcaps by serror_op

[Stefano Stabellini]

On Mon, 13 Mar 2017, Wei Chen wrote:
> In the later patches of this series, we want to use the alternative
> patching framework to avoid checking serror_op in every entries.
> So we define a new cpu feature "SKIP_CHECK_PENDING_VSERROR" for
> serror_op. When serror_op is not equal to SERROR_DIVERSE, this
> feature will be set to cpu_hwcaps.
> 
> But we could not update cpu_hwcaps directly in the serror parameter
> parsing function. Because if the serror parameter is not placed in
> the command line, the parsing function would not be invoked.

Wait, the only way to set serrors_op != SERRORS_DIVERSE is to pass the
"serror" command line parameter. The parsing function is always invoked
if serrors_op != SERRORS_DIVERSE.


> So, we introduce this initcall to guarantee the cpu_hwcaps can be
> updated no matter the serror parameter is placed in the command line
> or not.
> 
> Signed-off-by: Wei Chen 
> ---
>  xen/arch/arm/traps.c | 9 +
>  xen/include/asm-arm/cpufeature.h | 3 ++-
>  2 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 5e31699..053b7fc 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -134,6 +134,15 @@ static void __init parse_serrors_behavior(const char 
> *str)
>  }
>  custom_param("serrors", parse_serrors_behavior);
>  
> +static __init int update_serrors_cpu_caps(void)

I think the coding style is "static int __init" ...


> +{
> +if ( serrors_op != SERRORS_DIVERSE )
> +cpus_set_cap(SKIP_CHECK_PENDING_VSERROR);
> +
> +return 0;
> +}
> +__initcall(update_serrors_cpu_caps);
> +
>  register_t get_default_hcr_flags(void)
>  {
>  return  (HCR_PTW|HCR_BSU_INNER|HCR_AMO|HCR_IMO|HCR_FMO|HCR_VM|
> diff --git a/xen/include/asm-arm/cpufeature.h 
> b/xen/include/asm-arm/cpufeature.h
> index c0a25ae..ec3f9e5 100644
> --- a/xen/include/asm-arm/cpufeature.h
> +++ b/xen/include/asm-arm/cpufeature.h
> @@ -40,8 +40,9 @@
>  #define ARM32_WORKAROUND_766422 2
>  #define ARM64_WORKAROUND_834220 3
>  #define LIVEPATCH_FEATURE   4
> +#define SKIP_CHECK_PENDING_VSERROR 5
>  
> -#define ARM_NCAPS   5
> +#define ARM_NCAPS   6
>  
>  #ifndef __ASSEMBLY__
>  
> -- 
> 2.7.4
> 
> 
> ___
> 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 03/18] xen/arm: Avoid setting/clearing HCR_RW at every context switch

[Stefano Stabellini]

On Thu, 16 Mar 2017, Julien Grall wrote:
> On 03/16/2017 10:40 PM, Stefano Stabellini wrote:
> > On Wed, 15 Mar 2017, Wei Chen wrote:
> > > Hi Stefano,
> > > 
> > > On 2017/3/15 8:25, Stefano Stabellini wrote:
> > > > On Mon, 13 Mar 2017, Wei Chen wrote:
> > > > > The HCR_EL2 flags for 64-bit and 32-bit domains are different. But
> > > > > when we initialized the HCR_EL2 for vcpu0 of Dom0 and all vcpus of
> > > > > DomU in vcpu_initialise, we didn't know the domain's address size
> > > > > information. We had to use compatible flags to initialize HCR_EL2,
> > > > > and set HCR_RW for 64-bit domain or clear HCR_RW for 32-bit domain
> > > > > at every context switch.
> > > > > 
> > > > > But, after we added the HCR_EL2 to vcpu's context, this behaviour
> > > > > seems a little fussy. We can update the HCR_RW bit in vcpu's context
> > > > > as soon as we get the domain's address size to avoid setting/clearing
> > > > > HCR_RW at every context switch.
> > > > > 
> > > > > Signed-off-by: Wei Chen 
> > > > > ---
> > > > >  xen/arch/arm/arm64/domctl.c  | 6 ++
> > > > >  xen/arch/arm/domain.c| 5 +
> > > > >  xen/arch/arm/domain_build.c  | 7 +++
> > > > >  xen/arch/arm/p2m.c   | 5 -
> > > > >  xen/include/asm-arm/domain.h | 1 +
> > > > >  5 files changed, 19 insertions(+), 5 deletions(-)
> > > > > 
> > > > > diff --git a/xen/arch/arm/arm64/domctl.c b/xen/arch/arm/arm64/domctl.c
> > > > > index 44e1e7b..ab8781f 100644
> > > > > --- a/xen/arch/arm/arm64/domctl.c
> > > > > +++ b/xen/arch/arm/arm64/domctl.c
> > > > > @@ -14,6 +14,8 @@
> > > > > 
> > > > >  static long switch_mode(struct domain *d, enum domain_type type)
> > > > >  {
> > > > > +struct vcpu *v;
> > > > > +
> > > > >  if ( d == NULL )
> > > > >  return -EINVAL;
> > > > >  if ( d->tot_pages != 0 )
> > > > > @@ -23,6 +25,10 @@ static long switch_mode(struct domain *d, enum
> > > > > domain_type type)
> > > > > 
> > > > >  d->arch.type = type;
> > > > > 
> > > > > +if ( is_64bit_domain(d) )
> > > > > +for_each_vcpu(d, v)
> > > > > +vcpu_switch_to_aarch64_mode(v);
> > > > > +
> > > > >  return 0;
> > > > >  }
> > > > > 
> > > > > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > > > > index 5d18bb0..69c2854 100644
> > > > > --- a/xen/arch/arm/domain.c
> > > > > +++ b/xen/arch/arm/domain.c
> > > > > @@ -537,6 +537,11 @@ void vcpu_destroy(struct vcpu *v)
> > > > >  free_xenheap_pages(v->arch.stack, STACK_ORDER);
> > > > >  }
> > > > > 
> > > > > +void vcpu_switch_to_aarch64_mode(struct vcpu *v)
> > > > > +{
> > > > > +v->arch.hcr_el2 |= HCR_RW;
> > > > > +}
> > > > 
> > > > if possible, I would write it as a static inline function
> > > > 
> > > 
> > > I had tried to write it as a static inline function in asm/domain.h
> > > But while the first source file (arm64/asm-offsets.c) include
> > > xen/sched.h wanted to compile this inline function it could not find
> > > 'struct vcpu'. Because the xen/sched.h included the asm/domain.h
> > > but defined the vcpu type later. Even though we had included the
> > > xen/sched.h in asm/domain.h already.
> > 
> > It might be too complex to disentangle. In this case, there isn't much
> > type safety to be gained by using a static inline over a macro, so it
> > would be OK to use a macro for this.
> 
> It is not like vCPU will be switch to AArch64 mode often? Only once at vCPU
> creation time.
> 
> So what do we gain to switch to static inline or even macro?

To turn 5 lines of code into 1. Obviously it's no big deal.

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

Re: [Xen-devel] [PATCH 03/18] xen/arm: Avoid setting/clearing HCR_RW at every context switch

[Julien Grall]

On 03/16/2017 10:40 PM, Stefano Stabellini wrote:

On Wed, 15 Mar 2017, Wei Chen wrote:

Hi Stefano,

On 2017/3/15 8:25, Stefano Stabellini wrote:

On Mon, 13 Mar 2017, Wei Chen wrote:

The HCR_EL2 flags for 64-bit and 32-bit domains are different. But
when we initialized the HCR_EL2 for vcpu0 of Dom0 and all vcpus of
DomU in vcpu_initialise, we didn't know the domain's address size
information. We had to use compatible flags to initialize HCR_EL2,
and set HCR_RW for 64-bit domain or clear HCR_RW for 32-bit domain
at every context switch.

But, after we added the HCR_EL2 to vcpu's context, this behaviour
seems a little fussy. We can update the HCR_RW bit in vcpu's context
as soon as we get the domain's address size to avoid setting/clearing
HCR_RW at every context switch.

Signed-off-by: Wei Chen 
---
 xen/arch/arm/arm64/domctl.c  | 6 ++
 xen/arch/arm/domain.c| 5 +
 xen/arch/arm/domain_build.c  | 7 +++
 xen/arch/arm/p2m.c   | 5 -
 xen/include/asm-arm/domain.h | 1 +
 5 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/arm64/domctl.c b/xen/arch/arm/arm64/domctl.c
index 44e1e7b..ab8781f 100644
--- a/xen/arch/arm/arm64/domctl.c
+++ b/xen/arch/arm/arm64/domctl.c
@@ -14,6 +14,8 @@

 static long switch_mode(struct domain *d, enum domain_type type)
 {
+struct vcpu *v;
+
 if ( d == NULL )
 return -EINVAL;
 if ( d->tot_pages != 0 )
@@ -23,6 +25,10 @@ static long switch_mode(struct domain *d, enum domain_type 
type)

 d->arch.type = type;

+if ( is_64bit_domain(d) )
+for_each_vcpu(d, v)
+vcpu_switch_to_aarch64_mode(v);
+
 return 0;
 }

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 5d18bb0..69c2854 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -537,6 +537,11 @@ void vcpu_destroy(struct vcpu *v)
 free_xenheap_pages(v->arch.stack, STACK_ORDER);
 }

+void vcpu_switch_to_aarch64_mode(struct vcpu *v)
+{
+v->arch.hcr_el2 |= HCR_RW;
+}


if possible, I would write it as a static inline function



I had tried to write it as a static inline function in asm/domain.h
But while the first source file (arm64/asm-offsets.c) include
xen/sched.h wanted to compile this inline function it could not find
'struct vcpu'. Because the xen/sched.h included the asm/domain.h
but defined the vcpu type later. Even though we had included the
xen/sched.h in asm/domain.h already.


It might be too complex to disentangle. In this case, there isn't much
type safety to be gained by using a static inline over a macro, so it
would be OK to use a macro for this.


It is not like vCPU will be switch to AArch64 mode often? Only once at 
vCPU creation time.


So what do we gain to switch to static inline or even macro?

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 02/18] xen/arm: Restore HCR_EL2 register

[Julien Grall]

Hi Stefano

On 03/16/2017 10:33 PM, Stefano Stabellini wrote:

On Wed, 15 Mar 2017, Julien Grall wrote:

Hi Wei,

On 15/03/17 08:34, Wei Chen wrote:

On 2017/3/15 8:25, Stefano Stabellini wrote:

On Mon, 13 Mar 2017, Wei Chen wrote:

Different domains may have different HCR_EL2 flags. For example, the
64-bit domain needs HCR_RW flag but the 32-bit does not need it. So
we give each domain a default HCR_EL2 value and save it in the VCPU's
context.

HCR_EL2 register has only one bit can be updated automatically without
explicit write (HCR_VSE). But we haven't used this bit currently, so
we can consider that the HCR_EL2 register will not be modified while
the guest is running. So save the HCR_EL2 while guest exiting to
hypervisor is not neccessary. We just have to restore this register for
each VCPU while leaving hypervisor.

We prefer to restore HCR_EL2 in leave_hypervisor_tail rather than in
ctxt_switch_to. Because the leave_hypervisor_tail is the closest place
to the exception return. In this case, we don't need to warrant the
HCR_EL2 will not be changed between ctxt_switch_to and exception return.


Please explain a bit better why it is good to restore HCR_EL2 in
leave_hypervisor_tail. Why is it a good thing that is closer to the
exception return? What can be the cause of a change in HCR_EL2?



Ok, I will try to improve it in next version. In current Xen code, I
can't see any code would change the HCR_EL2 between ctxt_switch_to and
return_from_trap. But my concern is that, in the future, if someone
want to insert some HCR_EL2 change code between them, we can't guarantee
he will restore correct HCR_EL2 value for current vcpu.


Well, the purpose of this series is to inject a virtual SError to the guest
when a host SError is happening. The host SError will be received in the
hypervisor whilst the vCPU is running and no context switch (e.g call to
ctxt_switch) may happen if the scheduler decides to keep the vCPU running.

Also, one could argue that HCR_EL2 could be modified on-fly in the function
but we may have other places in the future which will modify HCR_EL2. For
instance, this would be the case when the monitor app will gain support of
inspecting some registers.

So we want a single place to restore HCR_EL2. And leave_hypervisor_tail is the
best place for that.


You say that we want a single place to restore HCR_EL2, but this patch
introduces two places, one is p2m_restore_state, the other is
leave_hypervisor_tail. Are you saying Wei should remove the HCR_EL2
restore in p2m_restore_state and just keep the one in
leave_hypervisor_tail?


p2m_restore_state may be used to switch temporarily to a p2m state. For 
instance for TLB flushing or even doing VA -> PA translation. Though the 
later does not yet work quite well when not using the current vCPU.


Some bits in HCR_EL2 (specifically HCR_EL2.RW) will be used to know how 
to interpret the stage-1 page table as the encoding differ between 
AArch64 and AArch32.


So I think we have to keep the one in p2m_restore_state. But I would 
like to keep the number very limited.


Cheers.

--
Julien Grall

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

Re: [Xen-devel] [PATCH 03/18] xen/arm: Avoid setting/clearing HCR_RW at every context switch

[Stefano Stabellini]

On Wed, 15 Mar 2017, Wei Chen wrote:
> Hi Stefano,
> 
> On 2017/3/15 8:25, Stefano Stabellini wrote:
> > On Mon, 13 Mar 2017, Wei Chen wrote:
> >> The HCR_EL2 flags for 64-bit and 32-bit domains are different. But
> >> when we initialized the HCR_EL2 for vcpu0 of Dom0 and all vcpus of
> >> DomU in vcpu_initialise, we didn't know the domain's address size
> >> information. We had to use compatible flags to initialize HCR_EL2,
> >> and set HCR_RW for 64-bit domain or clear HCR_RW for 32-bit domain
> >> at every context switch.
> >>
> >> But, after we added the HCR_EL2 to vcpu's context, this behaviour
> >> seems a little fussy. We can update the HCR_RW bit in vcpu's context
> >> as soon as we get the domain's address size to avoid setting/clearing
> >> HCR_RW at every context switch.
> >>
> >> Signed-off-by: Wei Chen 
> >> ---
> >>  xen/arch/arm/arm64/domctl.c  | 6 ++
> >>  xen/arch/arm/domain.c| 5 +
> >>  xen/arch/arm/domain_build.c  | 7 +++
> >>  xen/arch/arm/p2m.c   | 5 -
> >>  xen/include/asm-arm/domain.h | 1 +
> >>  5 files changed, 19 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/xen/arch/arm/arm64/domctl.c b/xen/arch/arm/arm64/domctl.c
> >> index 44e1e7b..ab8781f 100644
> >> --- a/xen/arch/arm/arm64/domctl.c
> >> +++ b/xen/arch/arm/arm64/domctl.c
> >> @@ -14,6 +14,8 @@
> >>
> >>  static long switch_mode(struct domain *d, enum domain_type type)
> >>  {
> >> +struct vcpu *v;
> >> +
> >>  if ( d == NULL )
> >>  return -EINVAL;
> >>  if ( d->tot_pages != 0 )
> >> @@ -23,6 +25,10 @@ static long switch_mode(struct domain *d, enum 
> >> domain_type type)
> >>
> >>  d->arch.type = type;
> >>
> >> +if ( is_64bit_domain(d) )
> >> +for_each_vcpu(d, v)
> >> +vcpu_switch_to_aarch64_mode(v);
> >> +
> >>  return 0;
> >>  }
> >>
> >> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> >> index 5d18bb0..69c2854 100644
> >> --- a/xen/arch/arm/domain.c
> >> +++ b/xen/arch/arm/domain.c
> >> @@ -537,6 +537,11 @@ void vcpu_destroy(struct vcpu *v)
> >>  free_xenheap_pages(v->arch.stack, STACK_ORDER);
> >>  }
> >>
> >> +void vcpu_switch_to_aarch64_mode(struct vcpu *v)
> >> +{
> >> +v->arch.hcr_el2 |= HCR_RW;
> >> +}
> >
> > if possible, I would write it as a static inline function
> >
> 
> I had tried to write it as a static inline function in asm/domain.h
> But while the first source file (arm64/asm-offsets.c) include
> xen/sched.h wanted to compile this inline function it could not find
> 'struct vcpu'. Because the xen/sched.h included the asm/domain.h
> but defined the vcpu type later. Even though we had included the
> xen/sched.h in asm/domain.h already.

It might be too complex to disentangle. In this case, there isn't much
type safety to be gained by using a static inline over a macro, so it
would be OK to use a macro for this.

 
> >
> >>  int arch_domain_create(struct domain *d, unsigned int domcr_flags,
> >> struct xen_arch_domainconfig *config)
> >>  {
> >> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> >> index de59e5f..3abacc0 100644
> >> --- a/xen/arch/arm/domain_build.c
> >> +++ b/xen/arch/arm/domain_build.c
> >> @@ -2148,6 +2148,10 @@ int construct_dom0(struct domain *d)
> >>  return -EINVAL;
> >>  }
> >>  d->arch.type = kinfo.type;
> >> +
> >> +if ( is_64bit_domain(d) )
> >> +vcpu_switch_to_aarch64_mode(v);
> >> +
> >>  #endif
> >>
> >>  allocate_memory(d, );
> >> @@ -2240,6 +2244,9 @@ int construct_dom0(struct domain *d)
> >>  printk("Failed to allocate dom0 vcpu %d on pcpu %d\n", i, 
> >> cpu);
> >>  break;
> >>  }
> >> +
> >> +if ( is_64bit_domain(d) )
> >> +vcpu_switch_to_aarch64_mode(d->vcpu[i]);
> >>  }
> >>
> >>  return 0;
> >> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> >> index c49bfa6..1cba0d0 100644
> >> --- a/xen/arch/arm/p2m.c
> >> +++ b/xen/arch/arm/p2m.c
> >> @@ -136,11 +136,6 @@ void p2m_restore_state(struct vcpu *n)
> >>  WRITE_SYSREG64(p2m->vttbr, VTTBR_EL2);
> >>  isb();
> >>
> >> -if ( is_32bit_domain(n->domain) )
> >> -n->arch.hcr_el2 &= ~HCR_RW;
> >> -else
> >> -n->arch.hcr_el2 |= HCR_RW;
> >> -
> >>  WRITE_SYSREG(n->arch.sctlr, SCTLR_EL1);
> >>  isb();
> >>
> >> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> >> index 7b1dacc..68185e2 100644
> >> --- a/xen/include/asm-arm/domain.h
> >> +++ b/xen/include/asm-arm/domain.h
> >> @@ -268,6 +268,7 @@ struct arch_vcpu
> >>
> >>  void vcpu_show_execution_state(struct vcpu *);
> >>  void vcpu_show_registers(const struct vcpu *);
> >> +void vcpu_switch_to_aarch64_mode(struct vcpu *);
> >>
> >>  unsigned int domain_max_vcpus(const struct domain *);


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

Re: [Xen-devel] [PATCH 02/18] xen/arm: Restore HCR_EL2 register

[Stefano Stabellini]

On Wed, 15 Mar 2017, Julien Grall wrote:
> Hi Wei,
> 
> On 15/03/17 08:34, Wei Chen wrote:
> > On 2017/3/15 8:25, Stefano Stabellini wrote:
> > > On Mon, 13 Mar 2017, Wei Chen wrote:
> > > > Different domains may have different HCR_EL2 flags. For example, the
> > > > 64-bit domain needs HCR_RW flag but the 32-bit does not need it. So
> > > > we give each domain a default HCR_EL2 value and save it in the VCPU's
> > > > context.
> > > > 
> > > > HCR_EL2 register has only one bit can be updated automatically without
> > > > explicit write (HCR_VSE). But we haven't used this bit currently, so
> > > > we can consider that the HCR_EL2 register will not be modified while
> > > > the guest is running. So save the HCR_EL2 while guest exiting to
> > > > hypervisor is not neccessary. We just have to restore this register for
> > > > each VCPU while leaving hypervisor.
> > > > 
> > > > We prefer to restore HCR_EL2 in leave_hypervisor_tail rather than in
> > > > ctxt_switch_to. Because the leave_hypervisor_tail is the closest place
> > > > to the exception return. In this case, we don't need to warrant the
> > > > HCR_EL2 will not be changed between ctxt_switch_to and exception return.
> > > 
> > > Please explain a bit better why it is good to restore HCR_EL2 in
> > > leave_hypervisor_tail. Why is it a good thing that is closer to the
> > > exception return? What can be the cause of a change in HCR_EL2?
> > > 
> > 
> > Ok, I will try to improve it in next version. In current Xen code, I
> > can't see any code would change the HCR_EL2 between ctxt_switch_to and
> > return_from_trap. But my concern is that, in the future, if someone
> > want to insert some HCR_EL2 change code between them, we can't guarantee
> > he will restore correct HCR_EL2 value for current vcpu.
> 
> Well, the purpose of this series is to inject a virtual SError to the guest
> when a host SError is happening. The host SError will be received in the
> hypervisor whilst the vCPU is running and no context switch (e.g call to
> ctxt_switch) may happen if the scheduler decides to keep the vCPU running.
> 
> Also, one could argue that HCR_EL2 could be modified on-fly in the function
> but we may have other places in the future which will modify HCR_EL2. For
> instance, this would be the case when the monitor app will gain support of
> inspecting some registers.
> 
> So we want a single place to restore HCR_EL2. And leave_hypervisor_tail is the
> best place for that.

You say that we want a single place to restore HCR_EL2, but this patch
introduces two places, one is p2m_restore_state, the other is
leave_hypervisor_tail. Are you saying Wei should remove the HCR_EL2
restore in p2m_restore_state and just keep the one in
leave_hypervisor_tail? 

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

Re: [Xen-devel] [RFC PATCH 1/9] xen/device-tree: Add dt_count_phandle_with_args helper

[Julien Grall]

Hi Oleksandr,

On 03/15/2017 08:05 PM, Oleksandr Tyshchenko wrote:

From: Oleksandr Tyshchenko 

Port Linux helper of_count_phandle_with_args for counting
number of phandles in a property.

Signed-off-by: Oleksandr Tyshchenko 


Reviewed-by: Julien Grall 

Regards,

--
Julien Grall

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

Re: [Xen-devel] [RFC PATCH 0/9] "Non-shared" IOMMU support on ARM

[Julien Grall]

On 03/15/2017 08:05 PM, Oleksandr Tyshchenko wrote:

Hi, all.


Hi Oleksandr,

Thank you for looking at the support of "non-shared" page table IOMMU 
support.




The purpose of this patch series is to create a base for porting
any "Non-shared" IOMMUs to Xen on ARM. Saying "Non-shared" IOMMU I mean
the IOMMU that can't share the page table with the CPU.
Primarily, we are interested in IPMMU-VMSA and I hope that it will be the first 
candidate.
It is VMSA-compatible IOMMU that integrated in the newest Renesas R-Car Gen3 
SoCs (ARM).
And this IOMMU can't share the page table with the CPU since it uses
stage-1 page table unlike the CPU that uses stage-2 therefore I name it
"Non-shared" IOMMU.

I have already raised disscusion [2] about some generic problems I had faced
during porting IPMMU-VMSA Linux driver to Xen. And on this basis I made
patches you can see it in this request. Only the first patch is not related to
IOMMU. But, I decided to ship it with the current request since it is a generic 
change
which we will need in a moment.

The reason for this patch series to be RFC is that I still have some doubts 
about generic code I touched.
I hope that I haven't broken anything for x86, but confirmation is needed.

I didn't include IPMMU-VMSA driver in this request. Although, I am still in 
progress, I want to say
that passthrough use-cases (actually what this all are firstly needed for) work 
for me with some limitations.
I tested on Salvator-X board (R-Car H3) with the next devices that have DMA IPs
connected to IPMMU uTLBs (using current master branch):
1. AUDMA is assigned to dom0 (protected by IOMMU)
2. SDHC0 is assigned to dom1 (passthrough to domain)
3. SDHC3 is assigned to dom2 (passthrough to domain)


I am looking forward to see the support in Xen :).


During porting IPMMU-VMSA driver to Xen I was trying to be as close as possible 
to Linux [1]. But,
it was a little bit difficult). It would be really nice to have some feedback 
and get your feeling regarding this driver.
I am also interested in if I took the right direction or there are some other 
ideas on doing the same.
So, is it a right direction to move on?


I would be interested to know what was the difficulties to port Linux 
driver in Xen and how much you diverge from it.


My biggest concern is maintainability. It is fair to say that the Linux 
driver will be more exercised than the Xen driver. By keeping our own, 
we would potentially have hidden bug that may never be fixed.


By the way, I am not saying we should stick to Linux. I am happy to 
consider both solutions :).




You can find IPMMU-VMSA driver here.
repo: https://github.com/otyshchenko1/xen.git branch: ipmmu_ml
or
https://github.com/otyshchenko1/xen/commits/ipmmu_ml
It is located on top of "Unshared" IOMMU patch series and consist of 6 patches.


I will have a look.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 0/2] xen/arm32: Use alternative to skip the check of pending serrors

[Julien Grall]

Hi,

On 03/16/2017 09:53 AM, Wei Chen wrote:

We have provided an option to administrator to determine how to
handle the SErrors. In order to avoid add overhead to check the
option at every trap, we want to use the alternative to skip
this check.

In this series:
1. Introduce alternative patching support for ARM32.
2. Update the ARM32 SErrors handle code to use the alternative.


Stefano, this patch is relying on the bug fix "xen/arm: Register 
re-mapped Xen area as a temporary virtual region" 
<1489483637-27456-1-git-send-email-wei.c...@arm.com>. We should avoid to 
commit it before hand as it will break ARM platform.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 05/18] xen/arm: Save ESR_EL2 to avoid using mismatched value in syndrome check

[Stefano Stabellini]

On Thu, 16 Mar 2017, Julien Grall wrote:
> Hi Wei,
> 
> On 03/13/2017 10:55 AM, Wei Chen wrote:
> > Xen will do exception syndrome check while some types of exception
> > take place in EL2. The syndrome check code read the ESR_EL2 register
> > directly, but in some situation this register maybe overridden by
> > nested exception.
> > 
> > For example, if we re-enable IRQ before reading ESR_EL2 which means
> > Xen will enter in IRQ exception mode and return the processor with
> 
> s/will/may/
> 
> > clobbered ESR_EL2 (See ARM ARM DDI 0487A.j D7.2.25)
> > 
> > In this case the guest exception syndrome has been overridden, we will
> > check the syndrome for guest sync exception with a mismatched ESR_EL2
> 
> s/mismatched/incorrect/ I think
> 
> > value. So we want to save ESR_EL2 to cpu_user_regs as soon as the
> > exception takes place in EL2 to avoid using a mismatched syndrome value.
> 
> Ditto.

Please address Julien's comments. The code looks good.


> > 
> > Signed-off-by: Wei Chen 
> > ---
> >  xen/arch/arm/arm32/asm-offsets.c  |  1 +
> >  xen/arch/arm/arm32/entry.S|  3 +++
> >  xen/arch/arm/arm64/asm-offsets.c  |  1 +
> >  xen/arch/arm/arm64/entry.S| 13 +
> >  xen/arch/arm/traps.c  |  2 +-
> >  xen/include/asm-arm/arm32/processor.h |  2 +-
> >  xen/include/asm-arm/arm64/processor.h | 10 --
> >  7 files changed, 24 insertions(+), 8 deletions(-)
> > 
> > diff --git a/xen/arch/arm/arm32/asm-offsets.c
> > b/xen/arch/arm/arm32/asm-offsets.c
> > index f8e6b53..5b543ab 100644
> > --- a/xen/arch/arm/arm32/asm-offsets.c
> > +++ b/xen/arch/arm/arm32/asm-offsets.c
> > @@ -26,6 +26,7 @@ void __dummy__(void)
> > OFFSET(UREGS_lr, struct cpu_user_regs, lr);
> > OFFSET(UREGS_pc, struct cpu_user_regs, pc);
> > OFFSET(UREGS_cpsr, struct cpu_user_regs, cpsr);
> > +   OFFSET(UREGS_hsr, struct cpu_user_regs, hsr);
> > 
> > OFFSET(UREGS_LR_usr, struct cpu_user_regs, lr_usr);
> > OFFSET(UREGS_SP_usr, struct cpu_user_regs, sp_usr);
> > diff --git a/xen/arch/arm/arm32/entry.S b/xen/arch/arm/arm32/entry.S
> > index 2a6f4f0..2187226 100644
> > --- a/xen/arch/arm/arm32/entry.S
> > +++ b/xen/arch/arm/arm32/entry.S
> > @@ -23,6 +23,9 @@
> >  add r11, sp, #UREGS_kernel_sizeof+4;\
> >  str r11, [sp, #UREGS_sp];   \
> >  \
> > +mrc CP32(r11, HSR); /* Save exception syndrome */   \
> > +str r11, [sp, #UREGS_hsr];  \
> > +\
> >  mrs r11, SPSR_hyp;  \
> >  str r11, [sp, #UREGS_cpsr]; \
> >  and r11, #PSR_MODE_MASK;\
> > diff --git a/xen/arch/arm/arm64/asm-offsets.c
> > b/xen/arch/arm/arm64/asm-offsets.c
> > index 69ea92a..ce24e44 100644
> > --- a/xen/arch/arm/arm64/asm-offsets.c
> > +++ b/xen/arch/arm/arm64/asm-offsets.c
> > @@ -27,6 +27,7 @@ void __dummy__(void)
> > OFFSET(UREGS_SP, struct cpu_user_regs, sp);
> > OFFSET(UREGS_PC, struct cpu_user_regs, pc);
> > OFFSET(UREGS_CPSR, struct cpu_user_regs, cpsr);
> > +   OFFSET(UREGS_ESR_el2, struct cpu_user_regs, hsr);
> > 
> > OFFSET(UREGS_SPSR_el1, struct cpu_user_regs, spsr_el1);
> > 
> > diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
> > index c181b5e..02802c0 100644
> > --- a/xen/arch/arm/arm64/entry.S
> > +++ b/xen/arch/arm/arm64/entry.S
> > @@ -121,9 +121,13 @@ lr  .reqx30 // link register
> > 
> >  stp lr, x21, [sp, #UREGS_LR]
> > 
> > -mrs x22, elr_el2
> > -mrs x23, spsr_el2
> > -stp x22, x23, [sp, #UREGS_PC]
> > +mrs x21, elr_el2
> > +str x21, [sp, #UREGS_PC]
> 
> Please explain the commit message you modify the lines above ...
> 
> > +
> > +add x21, sp, #UREGS_CPSR
> > +mrs x22, spsr_el2
> > +mrs x23, esr_el2
> > +stp w22, w23, [x21]
> > 
> >  .endm
> > 
> > @@ -307,7 +311,8 @@ ENTRY(return_to_new_vcpu64)
> >  return_from_trap:
> >  msr daifset, #2 /* Mask interrupts */
> > 
> > -ldp x21, x22, [sp, #UREGS_PC]   // load ELR, SPSR
> > +ldr x21, [sp, #UREGS_PC]// load ELR
> > +ldr w22, [sp, #UREGS_CPSR]  // load SPSR
> 
> as long as those one.
> 
> > 
> >  pop x0, x1
> >  pop x2, x3
> 
> [...]
> 
> > diff --git a/xen/include/asm-arm/arm64/processor.h
> > b/xen/include/asm-arm/arm64/processor.h
> > index b0726ff..d381428 100644
> > --- a/xen/include/asm-arm/arm64/processor.h
> > +++ b/xen/include/asm-arm/arm64/processor.h
> > @@ -65,9 +65,15 @@ struct cpu_user_regs
> > 
> >  

Re: [Xen-devel] [PATCH 1/2] xen/arm32: Introduce alternative runtime patching

[Julien Grall]

Hi Wei,

On 03/16/2017 09:53 AM, Wei Chen wrote:

This patch is based on the implementation of ARM64, it introduces
alternative runtime patching to ARM32. This allows to patch assembly
instruction at runtime to either fix hardware bugs or optimize for
certain hardware features on ARM32 platform.

Xen hypervisor is using ARM execution state only on ARM32 platform,
Thumb is not used. So, the Thumb only branch instructions (CBZ, CBNZ,
TBB and TBH) are not considered in alternatives.

The left ARM32 branch instructions are BX, BLX, BL and B. The
instruction BX is taking a register in parameter, so we don't need to
rewrite it. The instructions BLX, BL and B are using the similar
encoding for the offset and will avoid specific case when extracting
and updating the offset.

In this patch, we include alternative.h header file to livepatch.c
directly for ARM32 compilation issues. When the alternative patching
config is enabled, the livepatch.c will use the alternative functions.
In this case, we should include the alternative header file to this
file. But for ARM64, it does not include this header file directly.
It includes this header file indirectly through:
sched.h->domain.h->page.h->alternative.h.
But, unfortunately, the page.h of ARM32 doesn't include alternative.h,
and we don't have the reason to include it to ARM32 page.h now. So we
have to include the alternative.h directly in livepatch.c.

Signed-off-by: Wei Chen 
---
 xen/arch/arm/Kconfig |  2 +-
 xen/arch/arm/arm32/Makefile  |  1 +
 xen/arch/arm/arm32/insn.c| 99 
 xen/common/livepatch.c   |  1 +


CC Ross and Konrad for the livepatch part.


 xen/include/asm-arm/arm32/insn.h | 57 +++
 xen/include/asm-arm/insn.h   |  2 +
 6 files changed, 161 insertions(+), 1 deletion(-)
 create mode 100644 xen/arch/arm/arm32/insn.c
 create mode 100644 xen/include/asm-arm/arm32/insn.h

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 2e023d1..43123e6 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -12,11 +12,11 @@ config ARM_32
 config ARM_64
def_bool y
depends on 64BIT
-   select HAS_ALTERNATIVE
select HAS_GICV3

 config ARM
def_bool y
+   select HAS_ALTERNATIVE
select HAS_ARM_HDLCD
select HAS_DEVICE_TREE
select HAS_MEM_ACCESS
diff --git a/xen/arch/arm/arm32/Makefile b/xen/arch/arm/arm32/Makefile
index 4395693..0ac254f 100644
--- a/xen/arch/arm/arm32/Makefile
+++ b/xen/arch/arm/arm32/Makefile
@@ -4,6 +4,7 @@ obj-$(EARLY_PRINTK) += debug.o
 obj-y += domctl.o
 obj-y += domain.o
 obj-y += entry.o
+obj-y += insn.o
 obj-$(CONFIG_LIVEPATCH) += livepatch.o
 obj-y += proc-v7.o proc-caxx.o
 obj-y += smpboot.o
diff --git a/xen/arch/arm/arm32/insn.c b/xen/arch/arm/arm32/insn.c
new file mode 100644
index 000..91a3010
--- /dev/null
+++ b/xen/arch/arm/arm32/insn.c
@@ -0,0 +1,99 @@
+/*
+  * Copyright (C) 2017 ARM Ltd.
+  *
+  * This program is free software; you can redistribute it and/or modify
+  * it under the terms of the GNU General Public License version 2 as
+  * published by the Free Software Foundation.
+  *
+  * This program is distributed in the hope that it will be useful,
+  * but WITHOUT ANY WARRANTY; without even the implied warranty of
+  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+  * GNU General Public License for more details.
+  *
+  * You should have received a copy of the GNU General Public License
+  * along with this program.  If not, see .
+  */
+#include 
+#include 
+#include 
+#include 


This is already included by xen/lib.h.


+#include 
+
+/* Mask of branch instructions' immediate. */
+#define BRANCH_INSN_IMM_MASKGENMASK(23, 0)
+/* Shift of branch instructions' immediate. */
+#define BRANCH_INSN_IMM_SHIFT   0
+
+static uint32_t branch_insn_encode_immediate(uint32_t insn, int32_t offset)
+{
+uint32_t imm;
+
+/*
+ * Encode the offset to imm. All ARM32 instructions must be word aligned.
+ * Therefore the offset value's bits [1:0] equal to zero.
+ * (see ARM DDI 0406C.b A8.8.18/A8.8.25 for more encode/decode details


DDI 0406C.b is an old version (July 2012) of the ARM ARM. Please try to 
use the latest version (e.g 0406C.c released in May 2014) when possible.



+ * about ARM32 branch instructions)
+ */
+imm = ((offset >> 2) & BRANCH_INSN_IMM_MASK) << BRANCH_INSN_IMM_SHIFT;
+
+/* Update the immediate field. */
+insn &= ~(BRANCH_INSN_IMM_MASK << BRANCH_INSN_IMM_SHIFT);
+insn |= imm;
+
+return insn;
+}
+
+/*
+ * Decode the branch offset from a branch instruction's imm field.
+ * The branch offset is a signed value, so it can be used to compute
+ * a new branch target.
+ */
+int32_t aarch32_get_branch_offset(uint32_t insn)
+{
+uint32_t imm;
+
+/* Retrieve imm from branch instruction. */
+imm = ( insn >> BRANCH_INSN_IMM_SHIFT ) & 

Re: [Xen-devel] Bug#852324: x86/mm: Found insecure W+X mapping

[Andrew Cooper]

On 16/03/2017 21:05, Ben Hutchings wrote:
> On Thu, 2017-03-16 at 00:50 +, Ben Hutchings wrote:
>> On Wed, 2017-03-15 at 22:24 +, Ben Hutchings wrote:
>>> Control: retitle -1 [xen] x86/mm: Found insecure W+X mapping
>>> Control: tag -1 upstream confirmed
>>> Control: found -1 4.9.13-1
>>>
>>> I can reproduce this with a current Debian kernel on top of Xen 4.4. 
>>> It doesn't happen with the same hardware booting the kernel directly.
>> With CONFIG_X86_PTDUMP enabled, I can see that the first 16 MiB of the
>> low kernel mapping is mapped with W+X permissions, with a few
>> exceptions:
>>
>> 0x8800-0x88099000 612K USR RW
>>  x  pte
>> 0x88099000-0x8809a000   4K USR ro
>>  NX pte
>> 0x8809a000-0x8809b000   4K USR ro
>>  x  pte
>> 0x8809b000-0x8809f000  16K USR RW
>>  NX pte
>> 0x8809f000-0x8810 388K USR RW PWT PCD
>>  x  pte
>> 0x8810-0x88102000   8K USR RW
>>  x  pte
>> 0x88102000-0x88000100   15352K USR RW
>>  x  pte
>>
>> This accounts for all the 4090 pages reported at boot.
> I see this same mapping when running Linux 4.9 under either Xen 4.4 or
> 4.8 (from Debian stable or unstable).
>
> I don't really understand how the PV MMU page tables are set up.  I did
> try setting the NX flag in make_lowmem_page_readwrite() and that didn't
> make any difference to the number of W+X pages.

64bit PV guests have some rather special pagetable set up.  For one, the
USR bit will be unconditionally set and Xen doesn't tolerate some
mappings being writeable, but these RWX areas are clearly ok in Xens eyes.

Everything from 0x8800 upwards belongs to the guest kernel
per the PV ABI.  The initial layout will be constructed by the domain
builder on behalf of the kernel, but it is Linux's to arbitrarily alter
later on.

Can you boot a debug hypervisor and look at `xl dmesg` starting at the
"*** LOADING DOMAIN 0 ***" line?  This should dump the state that the
domain builder leaves dom0 in, which would help identify whether those
regions are leftovers from the domain builder, or something constructed
by the Linux PV early boot code.

~Andrew


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

[Xen-devel] [xen-unstable-smoke test] 106726: tolerable trouble: broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  c6e2216783b2572912ee5a7938166a29e244fa37
baseline version:
 xen  0a1b7f4e37e17f532a00a1bf732a072b40ca2a1b

Last test of basis   106723  2017-03-16 17:01:17 Z0 days
Testing same since   106726  2017-03-16 20:01:26 Z0 days1 attempts


People who touched revisions under test:
  Wei Liu 
  Zhang Chen 

jobs:
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=c6e2216783b2572912ee5a7938166a29e244fa37
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
c6e2216783b2572912ee5a7938166a29e244fa37
+ branch=xen-unstable-smoke
+ revision=c6e2216783b2572912ee5a7938166a29e244fa37
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' xc6e2216783b2572912ee5a7938166a29e244fa37 = 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
++ : 

[Xen-devel] [PATCH] xen: sched: don't call hooks of the wrong scheduler via VCPU2OP

[Dario Faggioli]

Within context_saved(), we call the context_saved hook,
and we use VCPU2OP() to determine from what scheduler.
VCPU2OP uses DOM2OP, which uses d->cpupool, which is
NULL when d is the idle domain. And in that case,
DOM2OP just returns ops, the scheduler of cpupool0.

Therefore, if:
- cpupool0's scheduler defines context_saved (like
  Credit2 and RTDS do),
- we are not in cpupool0 (i.e., our scheduler is
  not ops),
- we are context switching from idle,

we call VCPU2OP(idle_vcpu), which means
DOM2OP(idle->cpupool), which is ops.

Therefore, we both:
- check if context_saved is defined in the wrong
  scheduler;
- if yes, call the wrong one.

When using Credit2 at boot, and also Credit2 in
the other cpupool, this is wrong but innocuous,
because it only involves the idle vcpus.

When using Credit2 at boot, and Credit1 in the
other cpupool, this is *totally* wrong, and
it's by chance it does not explode!

When using Credit2 and other schedulers I'm
developping, I hit the following assert (in
sched_credit2.c, on a CPU inside a cpupool that
does not use Credit2):

csched2_context_saved()
{
 ...
 ASSERT(!vcpu_on_runq(svc));
 ...
}

Fix this by taking care, in VCPU2OP, of the case
when the vcpu is an idle one.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Juergen Gross 
Cc: Jan Beulich 
---
Cc-ing Jan, as this should be backported at least to 4.8, but, IMO, as back as
possible.
---
 xen/common/schedule.c |   14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index 223a120..d12f346 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -78,7 +78,19 @@ static struct scheduler __read_mostly ops;
   : (typeof((opsptr)->fn(opsptr, ##__VA_ARGS__)))0 )
 
 #define DOM2OP(_d)(((_d)->cpupool == NULL) ?  : ((_d)->cpupool->sched))
-#define VCPU2OP(_v)   (DOM2OP((_v)->domain))
+static inline struct scheduler* VCPU2OP(const struct vcpu *v)
+{
+struct domain *d = v->domain;
+
+if ( likely(d->cpupool != NULL) )
+return d->cpupool->sched;
+
+/* v->processor never changes for idle vcpus, so using it here is safe */
+if ( likely(is_idle_domain(d)) )
+return per_cpu(scheduler, v->processor);
+else
+return 
+}
 #define VCPU2ONLINE(_v) cpupool_domain_cpumask((_v)->domain)
 
 static inline void trace_runstate_change(struct vcpu *v, int new_state)


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

Re: [Xen-devel] Bug#852324: x86/mm: Found insecure W+X mapping

[Ben Hutchings]

On Thu, 2017-03-16 at 00:50 +, Ben Hutchings wrote:
> On Wed, 2017-03-15 at 22:24 +, Ben Hutchings wrote:
> > Control: retitle -1 [xen] x86/mm: Found insecure W+X mapping
> > Control: tag -1 upstream confirmed
> > Control: found -1 4.9.13-1
> > 
> > I can reproduce this with a current Debian kernel on top of Xen 4.4. 
> > It doesn't happen with the same hardware booting the kernel directly.
> 
> With CONFIG_X86_PTDUMP enabled, I can see that the first 16 MiB of the
> low kernel mapping is mapped with W+X permissions, with a few
> exceptions:
> 
> 0x8800-0x88099000 612K USR RW 
> x  pte
> 0x88099000-0x8809a000   4K USR ro 
> NX pte
> 0x8809a000-0x8809b000   4K USR ro 
> x  pte
> 0x8809b000-0x8809f000  16K USR RW 
> NX pte
> 0x8809f000-0x8810 388K USR RW PWT PCD 
> x  pte
> 0x8810-0x88102000   8K USR RW 
> x  pte
> 0x88102000-0x88000100   15352K USR RW 
> x  pte
> 
> This accounts for all the 4090 pages reported at boot.

I see this same mapping when running Linux 4.9 under either Xen 4.4 or
4.8 (from Debian stable or unstable).

I don't really understand how the PV MMU page tables are set up.  I did
try setting the NX flag in make_lowmem_page_readwrite() and that didn't
make any difference to the number of W+X pages.

Ben.

> When booting without Xen, the first 512 MiB is mapped like this:
> 
> 0x9c2e4000-0x9c2e40097000 604K RW GLB 
> NX pte
> 0x9c2e40097000-0x9c2e40098000   4K ro GLB 
> NX pte
> 0x9c2e40098000-0x9c2e40099000   4K ro GLB 
> x  pte
> 0x9c2e40099000-0x9c2e40201436K RW GLB 
> NX pte
> 0x9c2e4020-0x9c2e6000 510M RW PSE GLB 
> NX pmd
> 
> (looks like Xen inhibited kASLR too...).
> 
> Ben.
> 
-- 
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.


signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/2] configure: use pkg-config for obtaining xen version

[Stefano Stabellini]

On Thu, 16 Mar 2017, Juergen Gross wrote:
> Instead of trying to guess the Xen version to use by compiling various
> test programs first just ask the system via pkg-config. Only if it
> can't return the version fall back to the test program scheme.

That's OK, but why did you remove the Xen unstable test?


> Signed-off-by: Juergen Gross 
> ---
>  configure | 31 +++
>  1 file changed, 11 insertions(+), 20 deletions(-)
> 
> diff --git a/configure b/configure
> index aabf098..b43fbd5 100755
> --- a/configure
> +++ b/configure
> @@ -1983,26 +1983,12 @@ EOF
>  fi
>  xen=no
>  
> -  # Xen unstable
> -  elif
> -  cat > $TMPC < -#undef XC_WANT_COMPAT_DEVICEMODEL_API
> -#define __XEN_TOOLS__
> -#include 
> -int main(void) {
> -  xendevicemodel_handle *xd;
> -
> -  xd = xendevicemodel_open(0, 0);
> -  xendevicemodel_close(xd);
> -
> -  return 0;
> -}
> -EOF
> -  compile_prog "" "$xen_libs $xen_stable_libs -lxendevicemodel"
> -then
> -xen_stable_libs="$xen_stable_libs -lxendevicemodel"
> -xen_ctrl_version=40900
> +  # Xen version via pkg-config (Xen 4.9.0 and newer)
> +  elif $pkg_config --exists xencontrol ; then
> +xen_ctrl_version="$(printf '%d%02d%02d' \
> +  $($pkg_config --modversion xencontrol | sed 's/\./ /g') )"
>  xen=yes
> +
>elif
>cat > $TMPC <  /*
> @@ -2214,7 +2200,12 @@ EOF
>fi
>  
>if test "$xen" = yes; then
> -if test $xen_ctrl_version -ge 40701  ; then
> +if test $xen_ctrl_version -ge 40900 ; then
> +  xen_pc="xencontrol xenstore xenguest xenforeignmemory xengnttab 
> xenevtchn"
> +  xen_pc="$xen_pc xendevicemodel"
> +  xen_libs="$($pkg_config --libs $xen_pc)"
> +  QEMU_CFLAGS="$QEMU_CFLAGS $($pkg_config --cflags $xen_pc)"
> +elif test $xen_ctrl_version -ge 40701 ; then
>libs_softmmu="$xen_stable_libs $libs_softmmu"
>  fi
>  libs_softmmu="$xen_libs $libs_softmmu"

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

Re: [Xen-devel] [PATCH 1/2] xen: use 5 digit xen versions

[Stefano Stabellini]

On Thu, 16 Mar 2017, Juergen Gross wrote:
> Today qemu is using e.g. the value 480 for Xen version 4.8.0. As some
> Xen version tests are using ">" relations this scheme will lead to
> problems when Xen version 4.10.0 is being reached.
> 
> Instead of the 3 digit schem use a 5 digit scheme (e.g. 40800 for
> version 4.8.0).
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Stefano Stabellini 


> ---
>  configure   | 16 
>  hw/block/xen_disk.c |  2 +-
>  include/hw/xen/xen_common.h | 22 +++---
>  3 files changed, 20 insertions(+), 20 deletions(-)
> 
> diff --git a/configure b/configure
> index b187222..aabf098 100755
> --- a/configure
> +++ b/configure
> @@ -2001,7 +2001,7 @@ EOF
>compile_prog "" "$xen_libs $xen_stable_libs -lxendevicemodel"
>  then
>  xen_stable_libs="$xen_stable_libs -lxendevicemodel"
> -xen_ctrl_version=490
> +xen_ctrl_version=40900
>  xen=yes
>elif
>cat > $TMPC < @@ -2056,7 +2056,7 @@ int main(void) {
>  EOF
>compile_prog "" "$xen_libs $xen_stable_libs"
>  then
> -xen_ctrl_version=480
> +xen_ctrl_version=40800
>  xen=yes
>elif
>cat > $TMPC < @@ -2107,7 +2107,7 @@ int main(void) {
>  EOF
>compile_prog "" "$xen_libs $xen_stable_libs"
>  then
> -xen_ctrl_version=471
> +xen_ctrl_version=40701
>  xen=yes
>elif
>cat > $TMPC < @@ -2122,7 +2122,7 @@ int main(void) {
>  EOF
>compile_prog "" "$xen_libs"
>  then
> -xen_ctrl_version=470
> +xen_ctrl_version=40700
>  xen=yes
>  
># Xen 4.6
> @@ -2150,7 +2150,7 @@ int main(void) {
>  EOF
>compile_prog "" "$xen_libs"
>  then
> -xen_ctrl_version=460
> +xen_ctrl_version=40600
>  xen=yes
>  
># Xen 4.5
> @@ -2177,7 +2177,7 @@ int main(void) {
>  EOF
>compile_prog "" "$xen_libs"
>  then
> -xen_ctrl_version=450
> +xen_ctrl_version=40500
>  xen=yes
>  
>elif
> @@ -2202,7 +2202,7 @@ int main(void) {
>  EOF
>compile_prog "" "$xen_libs"
>  then
> -xen_ctrl_version=420
> +xen_ctrl_version=40200
>  xen=yes
>  
>else
> @@ -2214,7 +2214,7 @@ EOF
>fi
>  
>if test "$xen" = yes; then
> -if test $xen_ctrl_version -ge 471  ; then
> +if test $xen_ctrl_version -ge 40701  ; then
>libs_softmmu="$xen_stable_libs $libs_softmmu"
>  fi
>  libs_softmmu="$xen_libs $libs_softmmu"
> diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
> index 456a2d5..27df048 100644
> --- a/hw/block/xen_disk.c
> +++ b/hw/block/xen_disk.c
> @@ -492,7 +492,7 @@ static int ioreq_map(struct ioreq *ioreq)
>  return 0;
>  }
>  
> -#if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 480
> +#if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 40800
>  
>  static void ioreq_free_copy_buffers(struct ioreq *ioreq)
>  {
> diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
> index 274accc..df098c7 100644
> --- a/include/hw/xen/xen_common.h
> +++ b/include/hw/xen/xen_common.h
> @@ -27,7 +27,7 @@ extern xc_interface *xen_xc;
>   * We don't support Xen prior to 4.2.0.
>   */
>  
> -#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 490
> +#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40900
>  
>  typedef xc_interface xendevicemodel_handle;
>  
> @@ -37,7 +37,7 @@ static inline xendevicemodel_handle *xendevicemodel_open(
>  return xen_xc;
>  }
>  
> -#if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 450
> +#if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 40500
>  
>  static inline int xendevicemodel_create_ioreq_server(
>  xendevicemodel_handle *dmod, domid_t domid, int handle_bufioreq,
> @@ -100,7 +100,7 @@ static inline int xendevicemodel_set_ioreq_server_state(
>  return xc_hvm_set_ioreq_server_state(dmod, domid, id, enabled);
>  }
>  
> -#endif /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 450 */
> +#endif /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 40500 */
>  
>  static inline int xendevicemodel_set_pci_intx_level(
>  xendevicemodel_handle *dmod, domid_t domid, uint16_t segment,
> @@ -152,7 +152,7 @@ static inline int xendevicemodel_set_mem_type(
>  return xc_hvm_set_mem_type(dmod, domid, mem_type, first_pfn, nr);
>  }
>  
> -#else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 490 */
> +#else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 40900 */
>  
>  #include 
>  
> @@ -207,7 +207,7 @@ static inline int xen_modified_memory(domid_t domid, 
> uint64_t first_pfn,
>  }
>  
>  /* Xen 4.2 through 4.6 */
> -#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 471
> +#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40701
>  
>  typedef xc_interface xenforeignmemory_handle;
>  typedef xc_evtchn xenevtchn_handle;
> @@ -248,7 +248,7 @@ static inline void *xenforeignmemory_map(xc_interface *h, 
> uint32_t dom,
>  
>  #define xenforeignmemory_unmap(h, p, s) munmap(p, s * XC_PAGE_SIZE)
>  
> -#else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 471 */
> +#else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 40701 */
>  
>  #include 
>  

[Xen-devel] [PATCH v3 9/9] xen/9pfs: build and register Xen 9pfs backend

[Stefano Stabellini]

Signed-off-by: Stefano Stabellini 
Reviewed-by: Greg Kurz 
CC: anthony.per...@citrix.com
CC: jgr...@suse.com
CC: Aneesh Kumar K.V 
CC: Greg Kurz 
---
 hw/9pfs/Makefile.objs| 1 +
 hw/xen/xen_backend.c | 3 +++
 include/hw/xen/xen_backend.h | 3 +++
 3 files changed, 7 insertions(+)

diff --git a/hw/9pfs/Makefile.objs b/hw/9pfs/Makefile.objs
index da0ae0c..1a89850 100644
--- a/hw/9pfs/Makefile.objs
+++ b/hw/9pfs/Makefile.objs
@@ -5,5 +5,6 @@ common-obj-y += coth.o cofs.o codir.o cofile.o
 common-obj-y += coxattr.o 9p-synth.o
 common-obj-$(CONFIG_OPEN_BY_HANDLE) +=  9p-handle.o
 common-obj-y += 9p-proxy.o
+common-obj-$(CONFIG_XEN) += xen-9p-backend.o
 
 obj-y += virtio-9p-device.o
diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index 6c21c37..fe737e9 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -585,6 +585,9 @@ void xen_be_register_common(void)
 xen_be_register("console", _console_ops);
 xen_be_register("vkbd", _kbdmouse_ops);
 xen_be_register("qdisk", _blkdev_ops);
+#ifdef CONFIG_VIRTFS
+xen_be_register("9pfs", _9pfs_ops);
+#endif
 #ifdef CONFIG_USB_LIBUSB
 xen_be_register("qusb", _usb_ops);
 #endif
diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
index 4f4799a..7b72f1a 100644
--- a/include/hw/xen/xen_backend.h
+++ b/include/hw/xen/xen_backend.h
@@ -49,6 +49,9 @@ extern struct XenDevOps xen_console_ops;  /* 
xen_console.c */
 extern struct XenDevOps xen_kbdmouse_ops; /* xen_framebuffer.c */
 extern struct XenDevOps xen_framebuffer_ops;  /* xen_framebuffer.c */
 extern struct XenDevOps xen_blkdev_ops;   /* xen_disk.c*/
+#ifdef CONFIG_VIRTFS
+extern struct XenDevOps xen_9pfs_ops;   /* xen-9p-backend.c*/
+#endif
 extern struct XenDevOps xen_netdev_ops;   /* xen_nic.c */
 #ifdef CONFIG_USB_LIBUSB
 extern struct XenDevOps xen_usb_ops;  /* xen-usb.c */
-- 
1.9.1


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

[Xen-devel] [PATCH v3 8/9] xen/9pfs: send responses back to the frontend

[Stefano Stabellini]

Once a request is completed, xen_9pfs_push_and_notify gets called. In
xen_9pfs_push_and_notify, update the indexes (data has already been
copied to the sg by the common code) and send a notification to the
frontend.

Schedule the bottom-half to check if we already have any other requests
pending.

Signed-off-by: Stefano Stabellini 
CC: anthony.per...@citrix.com
CC: jgr...@suse.com
CC: Aneesh Kumar K.V 
CC: Greg Kurz 
---
 hw/9pfs/xen-9p-backend.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c
index 0a1eb34..c7b748a 100644
--- a/hw/9pfs/xen-9p-backend.c
+++ b/hw/9pfs/xen-9p-backend.c
@@ -177,6 +177,22 @@ static void xen_9pfs_init_in_iov_from_pdu(V9fsPDU *pdu,
 
 static void xen_9pfs_push_and_notify(V9fsPDU *pdu)
 {
+RING_IDX prod;
+Xen9pfsDev *priv = container_of(pdu->s, Xen9pfsDev, state);
+Xen9pfsRing *ring = >rings[pdu->tag % priv->num_rings];
+
+ring->intf->out_cons = ring->out_cons;
+xen_wmb();
+
+prod = ring->intf->in_prod;
+xen_rmb();
+ring->intf->in_prod = prod + pdu->size;
+xen_wmb();
+
+ring->inprogress = false;
+xenevtchn_notify(ring->evtchndev, ring->local_port);
+
+qemu_bh_schedule(ring->bh);
 }
 
 static const struct V9fsTransport xen_9p_transport = {
-- 
1.9.1


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

[Xen-devel] [PATCH v3 6/9] xen/9pfs: receive requests from the frontend

[Stefano Stabellini]

Upon receiving an event channel notification from the frontend, schedule
the bottom half. From the bottom half, read one request from the ring,
create a pdu and call pdu_submit to handle it.

For now, only handle one request per ring at a time.

Signed-off-by: Stefano Stabellini 
CC: anthony.per...@citrix.com
CC: jgr...@suse.com
CC: Aneesh Kumar K.V 
CC: Greg Kurz 
---
 hw/9pfs/xen-9p-backend.c | 48 
 1 file changed, 48 insertions(+)

diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c
index 3fd20ff..f757591 100644
--- a/hw/9pfs/xen-9p-backend.c
+++ b/hw/9pfs/xen-9p-backend.c
@@ -104,12 +104,60 @@ static int xen_9pfs_init(struct XenDevice *xendev)
 return 0;
 }
 
+static int xen_9pfs_receive(Xen9pfsRing *ring)
+{
+P9MsgHeader h;
+RING_IDX cons, prod, masked_prod, masked_cons;
+V9fsPDU *pdu;
+
+if (ring->inprogress) {
+return 0;
+}
+
+cons = ring->intf->out_cons;
+prod = ring->intf->out_prod;
+xen_rmb();
+
+if (xen_9pfs_queued(prod, cons, XEN_9PFS_RING_SIZE) < sizeof(h)) {
+return 0;
+}
+ring->inprogress = true;
+
+masked_prod = xen_9pfs_mask(prod, XEN_9PFS_RING_SIZE);
+masked_cons = xen_9pfs_mask(cons, XEN_9PFS_RING_SIZE);
+
+xen_9pfs_read_packet(ring->ring.out, masked_prod, _cons,
+ XEN_9PFS_RING_SIZE, (uint8_t *) , sizeof(h));
+
+/* cannot fail, because we only handle one request per ring at a time */
+pdu = pdu_alloc(>priv->state);
+pdu->size = le32_to_cpu(h.size_le);
+pdu->id = h.id;
+pdu->tag = le32_to_cpu(h.tag_le);
+ring->out_size = le32_to_cpu(h.size_le);
+ring->out_cons = cons + le32_to_cpu(h.size_le);
+
+qemu_co_queue_init(>complete);
+pdu_submit(pdu);
+
+return 0;
+}
+
 static void xen_9pfs_bh(void *opaque)
 {
+Xen9pfsRing *ring = opaque;
+xen_9pfs_receive(ring);
 }
 
 static void xen_9pfs_evtchn_event(void *opaque)
 {
+Xen9pfsRing *ring = opaque;
+evtchn_port_t port;
+
+port = xenevtchn_pending(ring->evtchndev);
+xenevtchn_unmask(ring->evtchndev, port);
+
+qemu_bh_schedule(ring->bh);
 }
 
 static int xen_9pfs_free(struct XenDevice *xendev)
-- 
1.9.1


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

[Xen-devel] [PATCH v3 7/9] xen/9pfs: implement in/out_iov_from_pdu and vmarshal/vunmarshal

[Stefano Stabellini]

Implement xen_9pfs_init_in/out_iov_from_pdu and
xen_9pfs_pdu_vmarshal/vunmarshall by creating new sg pointing to the
data on the ring.

This is safe as we only handle one request per ring at any given time.

Signed-off-by: Stefano Stabellini 
CC: anthony.per...@citrix.com
CC: jgr...@suse.com
CC: Aneesh Kumar K.V 
CC: Greg Kurz 
---
 hw/9pfs/xen-9p-backend.c | 92 ++--
 1 file changed, 90 insertions(+), 2 deletions(-)

diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c
index f757591..0a1eb34 100644
--- a/hw/9pfs/xen-9p-backend.c
+++ b/hw/9pfs/xen-9p-backend.c
@@ -58,12 +58,78 @@ typedef struct Xen9pfsDev {
 Xen9pfsRing *rings;
 } Xen9pfsDev;
 
+static void xen_9pfs_in_sg(Xen9pfsRing *ring,
+   struct iovec *in_sg,
+   int *num,
+   uint32_t idx,
+   uint32_t size)
+{
+RING_IDX cons, prod, masked_prod, masked_cons;
+
+cons = ring->intf->in_cons;
+prod = ring->intf->in_prod;
+xen_rmb();
+masked_prod = xen_9pfs_mask(prod, XEN_9PFS_RING_SIZE);
+masked_cons = xen_9pfs_mask(cons, XEN_9PFS_RING_SIZE);
+
+if (masked_prod < masked_cons) {
+in_sg[0].iov_base = ring->ring.in + masked_prod;
+in_sg[0].iov_len = masked_cons - masked_prod;
+*num = 1;
+} else {
+in_sg[0].iov_base = ring->ring.in + masked_prod;
+in_sg[0].iov_len = XEN_9PFS_RING_SIZE - masked_prod;
+in_sg[1].iov_base = ring->ring.in;
+in_sg[1].iov_len = masked_cons;
+*num = 2;
+}
+}
+
+static void xen_9pfs_out_sg(Xen9pfsRing *ring,
+struct iovec *out_sg,
+int *num,
+uint32_t idx)
+{
+RING_IDX cons, prod, masked_prod, masked_cons;
+
+cons = ring->intf->out_cons;
+prod = ring->intf->out_prod;
+xen_rmb();
+masked_prod = xen_9pfs_mask(prod, XEN_9PFS_RING_SIZE);
+masked_cons = xen_9pfs_mask(cons, XEN_9PFS_RING_SIZE);
+
+if (masked_cons < masked_prod) {
+out_sg[0].iov_base = ring->ring.out + masked_cons;
+out_sg[0].iov_len = ring->out_size;
+*num = 1;
+} else {
+if (ring->out_size > (XEN_9PFS_RING_SIZE - masked_cons)) {
+out_sg[0].iov_base = ring->ring.out + masked_cons;
+out_sg[0].iov_len = XEN_9PFS_RING_SIZE - masked_cons;
+out_sg[1].iov_base = ring->ring.out;
+out_sg[1].iov_len = ring->out_size -
+(XEN_9PFS_RING_SIZE - masked_cons);
+*num = 2;
+} else {
+out_sg[0].iov_base = ring->ring.out + masked_cons;
+out_sg[0].iov_len = ring->out_size;
+*num = 1;
+}
+}
+}
+
 static ssize_t xen_9pfs_pdu_vmarshal(V9fsPDU *pdu,
  size_t offset,
  const char *fmt,
  va_list ap)
 {
-return 0;
+Xen9pfsDev *xen_9pfs = container_of(pdu->s, Xen9pfsDev, state);
+struct iovec in_sg[2];
+int num;
+
+xen_9pfs_in_sg(_9pfs->rings[pdu->tag % xen_9pfs->num_rings],
+   in_sg, , pdu->idx, ROUND_UP(offset + 128, 512));
+return v9fs_iov_vmarshal(in_sg, num, offset, 0, fmt, ap);
 }
 
 static ssize_t xen_9pfs_pdu_vunmarshal(V9fsPDU *pdu,
@@ -71,13 +137,27 @@ static ssize_t xen_9pfs_pdu_vunmarshal(V9fsPDU *pdu,
const char *fmt,
va_list ap)
 {
-return 0;
+Xen9pfsDev *xen_9pfs = container_of(pdu->s, Xen9pfsDev, state);
+struct iovec out_sg[2];
+int num;
+
+xen_9pfs_out_sg(_9pfs->rings[pdu->tag % xen_9pfs->num_rings],
+out_sg, , pdu->idx);
+return v9fs_iov_vunmarshal(out_sg, num, offset, 0, fmt, ap);
 }
 
 static void xen_9pfs_init_out_iov_from_pdu(V9fsPDU *pdu,
struct iovec **piov,
unsigned int *pniov)
 {
+Xen9pfsDev *xen_9pfs = container_of(pdu->s, Xen9pfsDev, state);
+Xen9pfsRing *ring = _9pfs->rings[pdu->tag % xen_9pfs->num_rings];
+struct iovec *sg = g_malloc0(sizeof(*sg) * 2);
+int num;
+
+xen_9pfs_out_sg(ring, sg, , pdu->idx);
+*piov = sg;
+*pniov = num;
 }
 
 static void xen_9pfs_init_in_iov_from_pdu(V9fsPDU *pdu,
@@ -85,6 +165,14 @@ static void xen_9pfs_init_in_iov_from_pdu(V9fsPDU *pdu,
   unsigned int *pniov,
   size_t size)
 {
+Xen9pfsDev *xen_9pfs = container_of(pdu->s, Xen9pfsDev, state);
+Xen9pfsRing *ring = _9pfs->rings[pdu->tag % xen_9pfs->num_rings];
+struct iovec *sg = g_malloc0(sizeof(*sg) * 2);
+int num;
+
+xen_9pfs_in_sg(ring, sg, , pdu->idx, size);
+*piov = sg;
+*pniov = num;
 }

[Xen-devel] [PATCH v3 5/9] xen/9pfs: connect to the frontend

[Stefano Stabellini]

Write the limits of the backend to xenstore. Connect to the frontend.
Upon connection, allocate the rings according to the protocol
specification.

Initialize a QEMUBH to schedule work upon receiving an event channel
notification from the frontend.

Signed-off-by: Stefano Stabellini 
CC: anthony.per...@citrix.com
CC: jgr...@suse.com
CC: Aneesh Kumar K.V 
CC: Greg Kurz 
---
 hw/9pfs/xen-9p-backend.c | 182 ++-
 1 file changed, 181 insertions(+), 1 deletion(-)

diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c
index 92bb805..3fd20ff 100644
--- a/hw/9pfs/xen-9p-backend.c
+++ b/hw/9pfs/xen-9p-backend.c
@@ -23,8 +23,39 @@
 #define XEN_9PFS_RING_SIZE  XEN_FLEX_RING_SIZE(XEN_9PFS_RING_ORDER)
 DEFINE_XEN_FLEX_RING_AND_INTF(xen_9pfs);
 
+#define VERSIONS "1"
+#define MAX_RINGS 8
+#define MAX_RING_ORDER 8
+
+typedef struct Xen9pfsRing {
+struct Xen9pfsDev *priv;
+
+int ref;
+xenevtchn_handle   *evtchndev;
+int evtchn;
+int local_port;
+struct xen_9pfs_data_intf *intf;
+unsigned char *data;
+struct xen_9pfs_data ring;
+
+QEMUBH *bh;
+
+/* local copies, so that we can read/write PDU data directly from
+ * the ring */
+RING_IDX out_cons, out_size, in_cons;
+bool inprogress;
+} Xen9pfsRing;
+
 typedef struct Xen9pfsDev {
 struct XenDevice xendev;  /* must be first */
+V9fsState state;
+char *path;
+char *security_model;
+char *tag;
+char *id;
+
+int num_rings;
+Xen9pfsRing *rings;
 } Xen9pfsDev;
 
 static ssize_t xen_9pfs_pdu_vmarshal(V9fsPDU *pdu,
@@ -73,22 +104,171 @@ static int xen_9pfs_init(struct XenDevice *xendev)
 return 0;
 }
 
+static void xen_9pfs_bh(void *opaque)
+{
+}
+
+static void xen_9pfs_evtchn_event(void *opaque)
+{
+}
+
 static int xen_9pfs_free(struct XenDevice *xendev)
 {
-return -1;
+int i;
+Xen9pfsDev *xen_9pdev = container_of(xendev, Xen9pfsDev, xendev);
+
+if (xen_9pdev->id != NULL) {
+g_free(xen_9pdev->id);
+}
+if (xen_9pdev->tag != NULL) {
+g_free(xen_9pdev->tag);
+}
+if (xen_9pdev->path != NULL) {
+g_free(xen_9pdev->path);
+}
+if (xen_9pdev->security_model != NULL) {
+g_free(xen_9pdev->security_model);
+}
+
+for (i = 0; i < xen_9pdev->num_rings; i++) {
+if (xen_9pdev->rings[i].data != NULL) {
+xengnttab_unmap(xen_9pdev->xendev.gnttabdev,
+xen_9pdev->rings[i].data,
+(1 << XEN_9PFS_RING_ORDER));
+}
+if (xen_9pdev->rings[i].intf != NULL) {
+xengnttab_unmap(xen_9pdev->xendev.gnttabdev,
+xen_9pdev->rings[i].intf,
+1);
+}
+if (xen_9pdev->rings[i].evtchndev > 0) {
+qemu_set_fd_handler(xenevtchn_fd(xen_9pdev->rings[i].evtchndev),
+NULL, NULL, NULL);
+xenevtchn_unbind(xen_9pdev->rings[i].evtchndev,
+ xen_9pdev->rings[i].local_port);
+}
+if (xen_9pdev->rings[i].bh != NULL) {
+qemu_bh_delete(xen_9pdev->rings[i].bh);
+}
+}
+g_free(xen_9pdev->rings);
+return 0;
 }
 
 static int xen_9pfs_connect(struct XenDevice *xendev)
 {
+int i;
+Xen9pfsDev *xen_9pdev = container_of(xendev, Xen9pfsDev, xendev);
+V9fsState *s = _9pdev->state;
+QemuOpts *fsdev;
+
+if (xenstore_read_fe_int(_9pdev->xendev, "num-rings",
+ _9pdev->num_rings) == -1 ||
+xen_9pdev->num_rings > MAX_RINGS || xen_9pdev->num_rings < 1) {
+return -1;
+}
+
+xen_9pdev->rings = g_malloc0(xen_9pdev->num_rings * sizeof(Xen9pfsRing));
+for (i = 0; i < xen_9pdev->num_rings; i++) {
+char *str;
+
+xen_9pdev->rings[i].priv = xen_9pdev;
+xen_9pdev->rings[i].evtchn = -1;
+xen_9pdev->rings[i].local_port = -1;
+
+str = g_strdup_printf("ring-ref%u", i);
+if (xenstore_read_fe_int(_9pdev->xendev, str,
+ _9pdev->rings[i].ref) == -1) {
+goto out;
+}
+g_free(str);
+str = g_strdup_printf("event-channel-%u", i);
+if (xenstore_read_fe_int(_9pdev->xendev, str,
+ _9pdev->rings[i].evtchn) == -1) {
+goto out;
+}
+g_free(str);
+
+xen_9pdev->rings[i].intf =  xengnttab_map_grant_ref(
+xen_9pdev->xendev.gnttabdev,
+xen_9pdev->xendev.dom,
+xen_9pdev->rings[i].ref,
+PROT_READ | PROT_WRITE);
+if (!xen_9pdev->rings[i].intf) {
+goto out;
+}
+xen_9pdev->rings[i].data = xengnttab_map_domain_grant_refs(
+xen_9pdev->xendev.gnttabdev,
+(1 << XEN_9PFS_RING_ORDER),
+xen_9pdev->xendev.dom,
+xen_9pdev->rings[i].intf->ref,

[Xen-devel] [PATCH v3 4/9] xen/9pfs: introduce Xen 9pfs backend

[Stefano Stabellini]

Introduce the Xen 9pfs backend: add struct XenDevOps to register as a
Xen backend and add struct V9fsTransport to register as v9fs transport.

All functions are empty stubs for now.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Greg Kurz 
CC: anthony.per...@citrix.com
CC: jgr...@suse.com
CC: Aneesh Kumar K.V 
CC: Greg Kurz 
---
 hw/9pfs/xen-9p-backend.c | 102 +++
 1 file changed, 102 insertions(+)
 create mode 100644 hw/9pfs/xen-9p-backend.c

diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c
new file mode 100644
index 000..92bb805
--- /dev/null
+++ b/hw/9pfs/xen-9p-backend.c
@@ -0,0 +1,102 @@
+/*
+ * Xen 9p backend
+ *
+ * Copyright Aporeto 2017
+ *
+ * Authors:
+ *  Stefano Stabellini 
+ *
+ */
+
+#include "qemu/osdep.h"
+
+#include "hw/hw.h"
+#include "hw/9pfs/9p.h"
+#include "hw/xen/xen_backend.h"
+#include "hw/xen/io/ring.h"
+#include "qemu/config-file.h"
+#include "fsdev/qemu-fsdev.h"
+#include 
+
+#define PAGE_SHIFT XC_PAGE_SHIFT
+#define XEN_9PFS_RING_ORDER 6
+#define XEN_9PFS_RING_SIZE  XEN_FLEX_RING_SIZE(XEN_9PFS_RING_ORDER)
+DEFINE_XEN_FLEX_RING_AND_INTF(xen_9pfs);
+
+typedef struct Xen9pfsDev {
+struct XenDevice xendev;  /* must be first */
+} Xen9pfsDev;
+
+static ssize_t xen_9pfs_pdu_vmarshal(V9fsPDU *pdu,
+ size_t offset,
+ const char *fmt,
+ va_list ap)
+{
+return 0;
+}
+
+static ssize_t xen_9pfs_pdu_vunmarshal(V9fsPDU *pdu,
+   size_t offset,
+   const char *fmt,
+   va_list ap)
+{
+return 0;
+}
+
+static void xen_9pfs_init_out_iov_from_pdu(V9fsPDU *pdu,
+   struct iovec **piov,
+   unsigned int *pniov)
+{
+}
+
+static void xen_9pfs_init_in_iov_from_pdu(V9fsPDU *pdu,
+  struct iovec **piov,
+  unsigned int *pniov,
+  size_t size)
+{
+}
+
+static void xen_9pfs_push_and_notify(V9fsPDU *pdu)
+{
+}
+
+static const struct V9fsTransport xen_9p_transport = {
+.pdu_vmarshal = xen_9pfs_pdu_vmarshal,
+.pdu_vunmarshal = xen_9pfs_pdu_vunmarshal,
+.init_in_iov_from_pdu = xen_9pfs_init_in_iov_from_pdu,
+.init_out_iov_from_pdu = xen_9pfs_init_out_iov_from_pdu,
+.push_and_notify = xen_9pfs_push_and_notify,
+};
+
+static int xen_9pfs_init(struct XenDevice *xendev)
+{
+return 0;
+}
+
+static int xen_9pfs_free(struct XenDevice *xendev)
+{
+return -1;
+}
+
+static int xen_9pfs_connect(struct XenDevice *xendev)
+{
+return 0;
+}
+
+static void xen_9pfs_alloc(struct XenDevice *xendev)
+{
+}
+
+static void xen_9pfs_disconnect(struct XenDevice *xendev)
+{
+}
+
+struct XenDevOps xen_9pfs_ops = {
+.size   = sizeof(Xen9pfsDev),
+.flags  = DEVOPS_FLAG_NEED_GNTDEV,
+.alloc  = xen_9pfs_alloc,
+.init   = xen_9pfs_init,
+.initialise = xen_9pfs_connect,
+.disconnect = xen_9pfs_disconnect,
+.free   = xen_9pfs_free,
+};
-- 
1.9.1


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

[Xen-devel] [PATCH v3 3/9] 9p: introduce a type for the 9p header

[Stefano Stabellini]

Use the new type in virtio-9p-device.

Signed-off-by: Stefano Stabellini 
CC: anthony.per...@citrix.com
CC: jgr...@suse.com
CC: Aneesh Kumar K.V 
CC: Greg Kurz 
---
 hw/9pfs/9p.h   | 6 ++
 hw/9pfs/virtio-9p-device.c | 6 +-
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/hw/9pfs/9p.h b/hw/9pfs/9p.h
index b7e8362..5312d8a 100644
--- a/hw/9pfs/9p.h
+++ b/hw/9pfs/9p.h
@@ -119,6 +119,12 @@ static inline char *rpath(FsContext *ctx, const char *path)
 typedef struct V9fsPDU V9fsPDU;
 struct V9fsState;
 
+typedef struct {
+uint32_t size_le;
+uint8_t id;
+uint16_t tag_le;
+} QEMU_PACKED P9MsgHeader;
+
 struct V9fsPDU
 {
 uint32_t size;
diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
index 27a4a32..3782f43 100644
--- a/hw/9pfs/virtio-9p-device.c
+++ b/hw/9pfs/virtio-9p-device.c
@@ -46,11 +46,7 @@ static void handle_9p_output(VirtIODevice *vdev, VirtQueue 
*vq)
 VirtQueueElement *elem;
 
 while ((pdu = pdu_alloc(s))) {
-struct {
-uint32_t size_le;
-uint8_t id;
-uint16_t tag_le;
-} QEMU_PACKED out;
+P9MsgHeader out;
 
 elem = virtqueue_pop(vq, sizeof(VirtQueueElement));
 if (!elem) {
-- 
1.9.1


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

[Xen-devel] [PATCH v3 1/9] xen: do not build backends for targets that do not support xen

[Stefano Stabellini]

Change Makefile.objs to use CONFIG_XEN instead of CONFIG_XEN_BACKEND, so
that the Xen backends are only built for targets that support Xen.

Set CONFIG_XEN in the toplevel Makefile to ensure that files that are
built only once pick up Xen support properly.

Signed-off-by: Stefano Stabellini 
CC: gr...@kaod.org
CC: pbonz...@redhat.com
CC: peter.mayd...@linaro.org
CC: r...@twiddle.net
CC: stefa...@redhat.com
---
 Makefile | 1 +
 hw/block/Makefile.objs   | 2 +-
 hw/char/Makefile.objs| 2 +-
 hw/display/Makefile.objs | 2 +-
 hw/net/Makefile.objs | 2 +-
 hw/usb/Makefile.objs | 2 +-
 hw/xen/Makefile.objs | 2 +-
 7 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/Makefile b/Makefile
index 1c4c04f..b246138 100644
--- a/Makefile
+++ b/Makefile
@@ -26,6 +26,7 @@ endif
 
 CONFIG_SOFTMMU := $(if $(filter %-softmmu,$(TARGET_DIRS)),y)
 CONFIG_USER_ONLY := $(if $(filter %-user,$(TARGET_DIRS)),y)
+CONFIG_XEN := $(CONFIG_XEN_BACKEND)
 CONFIG_ALL=y
 -include config-all-devices.mak
 -include config-all-disas.mak
diff --git a/hw/block/Makefile.objs b/hw/block/Makefile.objs
index d4c3ab7..e0ed980 100644
--- a/hw/block/Makefile.objs
+++ b/hw/block/Makefile.objs
@@ -4,7 +4,7 @@ common-obj-$(CONFIG_SSI_M25P80) += m25p80.o
 common-obj-$(CONFIG_NAND) += nand.o
 common-obj-$(CONFIG_PFLASH_CFI01) += pflash_cfi01.o
 common-obj-$(CONFIG_PFLASH_CFI02) += pflash_cfi02.o
-common-obj-$(CONFIG_XEN_BACKEND) += xen_disk.o
+common-obj-$(CONFIG_XEN) += xen_disk.o
 common-obj-$(CONFIG_ECC) += ecc.o
 common-obj-$(CONFIG_ONENAND) += onenand.o
 common-obj-$(CONFIG_NVME_PCI) += nvme.o
diff --git a/hw/char/Makefile.objs b/hw/char/Makefile.objs
index 6ea76fe..725fdc4 100644
--- a/hw/char/Makefile.objs
+++ b/hw/char/Makefile.objs
@@ -7,7 +7,7 @@ common-obj-$(CONFIG_SERIAL_ISA) += serial-isa.o
 common-obj-$(CONFIG_SERIAL_PCI) += serial-pci.o
 common-obj-$(CONFIG_VIRTIO) += virtio-console.o
 common-obj-$(CONFIG_XILINX) += xilinx_uartlite.o
-common-obj-$(CONFIG_XEN_BACKEND) += xen_console.o
+common-obj-$(CONFIG_XEN) += xen_console.o
 common-obj-$(CONFIG_CADENCE) += cadence_uart.o
 
 obj-$(CONFIG_EXYNOS4) += exynos4210_uart.o
diff --git a/hw/display/Makefile.objs b/hw/display/Makefile.objs
index 063889b..3d02e8b 100644
--- a/hw/display/Makefile.objs
+++ b/hw/display/Makefile.objs
@@ -5,7 +5,7 @@ common-obj-$(CONFIG_JAZZ_LED) += jazz_led.o
 common-obj-$(CONFIG_PL110) += pl110.o
 common-obj-$(CONFIG_SSD0303) += ssd0303.o
 common-obj-$(CONFIG_SSD0323) += ssd0323.o
-common-obj-$(CONFIG_XEN_BACKEND) += xenfb.o
+common-obj-$(CONFIG_XEN) += xenfb.o
 
 common-obj-$(CONFIG_VGA_PCI) += vga-pci.o
 common-obj-$(CONFIG_VGA_ISA) += vga-isa.o
diff --git a/hw/net/Makefile.objs b/hw/net/Makefile.objs
index 610ed3e..6a95d92 100644
--- a/hw/net/Makefile.objs
+++ b/hw/net/Makefile.objs
@@ -1,5 +1,5 @@
 common-obj-$(CONFIG_DP8393X) += dp8393x.o
-common-obj-$(CONFIG_XEN_BACKEND) += xen_nic.o
+common-obj-$(CONFIG_XEN) += xen_nic.o
 
 # PCI network cards
 common-obj-$(CONFIG_NE2000_PCI) += ne2000.o
diff --git a/hw/usb/Makefile.objs b/hw/usb/Makefile.objs
index 98b5c9d..5958be8 100644
--- a/hw/usb/Makefile.objs
+++ b/hw/usb/Makefile.objs
@@ -40,5 +40,5 @@ common-obj-$(CONFIG_USB_REDIR) += redirect.o quirks.o
 common-obj-y += $(patsubst %,host-%.o,$(HOST_USB))
 
 ifeq ($(CONFIG_USB_LIBUSB),y)
-common-obj-$(CONFIG_XEN_BACKEND) += xen-usb.o
+common-obj-$(CONFIG_XEN) += xen-usb.o
 endif
diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
index 591cdc2..4be3ec9 100644
--- a/hw/xen/Makefile.objs
+++ b/hw/xen/Makefile.objs
@@ -1,5 +1,5 @@
 # xen backend driver support
-common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o xen_pvdev.o
+common-obj-$(CONFIG_XEN) += xen_backend.o xen_devconfig.o xen_pvdev.o
 
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o 
xen_pt_graphics.o xen_pt_msi.o
-- 
1.9.1


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

[Xen-devel] [PATCH v3 2/9] xen: import ring.h from xen

[Stefano Stabellini]

Do not use the ring.h header installed on the system. Instead, import
the header into the QEMU codebase. This avoids problems when QEMU is
built against a Xen version too old to provide all the ring macros.

Signed-off-by: Stefano Stabellini 
CC: anthony.per...@citrix.com
CC: jgr...@suse.com
---
NB: The new macros have not been committed to Xen yet. Do not apply this
patch until they do.
---
---
 hw/block/xen_blkif.h |   2 +-
 hw/usb/xen-usb.c |   2 +-
 include/hw/xen/io/ring.h | 455 +++
 3 files changed, 457 insertions(+), 2 deletions(-)
 create mode 100644 include/hw/xen/io/ring.h

diff --git a/hw/block/xen_blkif.h b/hw/block/xen_blkif.h
index 3300b6f..3e6e1ea 100644
--- a/hw/block/xen_blkif.h
+++ b/hw/block/xen_blkif.h
@@ -1,7 +1,7 @@
 #ifndef XEN_BLKIF_H
 #define XEN_BLKIF_H
 
-#include 
+#include "hw/xen/io/ring.h"
 #include 
 #include 
 
diff --git a/hw/usb/xen-usb.c b/hw/usb/xen-usb.c
index 8e676e6..370b3d9 100644
--- a/hw/usb/xen-usb.c
+++ b/hw/usb/xen-usb.c
@@ -33,7 +33,7 @@
 #include "qapi/qmp/qint.h"
 #include "qapi/qmp/qstring.h"
 
-#include 
+#include "hw/xen/io/ring.h"
 #include 
 
 /*
diff --git a/include/hw/xen/io/ring.h b/include/hw/xen/io/ring.h
new file mode 100644
index 000..cf01fc3
--- /dev/null
+++ b/include/hw/xen/io/ring.h
@@ -0,0 +1,455 @@
+/**
+ * ring.h
+ * 
+ * Shared producer-consumer ring macros.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Tim Deegan and Andrew Warfield November 2004.
+ */
+
+#ifndef __XEN_PUBLIC_IO_RING_H__
+#define __XEN_PUBLIC_IO_RING_H__
+
+#if __XEN_INTERFACE_VERSION__ < 0x00030208
+#define xen_mb()  mb()
+#define xen_rmb() rmb()
+#define xen_wmb() wmb()
+#endif
+
+typedef unsigned int RING_IDX;
+
+/* Round a 32-bit unsigned constant down to the nearest power of two. */
+#define __RD2(_x)  (((_x) & 0x0002) ? 0x2  : ((_x) & 0x1))
+#define __RD4(_x)  (((_x) & 0x000c) ? __RD2((_x)>>2)<<2: __RD2(_x))
+#define __RD8(_x)  (((_x) & 0x00f0) ? __RD4((_x)>>4)<<4: __RD4(_x))
+#define __RD16(_x) (((_x) & 0xff00) ? __RD8((_x)>>8)<<8: __RD8(_x))
+#define __RD32(_x) (((_x) & 0x) ? __RD16((_x)>>16)<<16 : __RD16(_x))
+
+/*
+ * Calculate size of a shared ring, given the total available space for the
+ * ring and indexes (_sz), and the name tag of the request/response structure.
+ * A ring contains as many entries as will fit, rounded down to the nearest 
+ * power of two (so we can mask with (size-1) to loop around).
+ */
+#define __CONST_RING_SIZE(_s, _sz) \
+(__RD32(((_sz) - offsetof(struct _s##_sring, ring)) / \
+   sizeof(((struct _s##_sring *)0)->ring[0])))
+/*
+ * The same for passing in an actual pointer instead of a name tag.
+ */
+#define __RING_SIZE(_s, _sz) \
+(__RD32(((_sz) - (long)(_s)->ring + (long)(_s)) / sizeof((_s)->ring[0])))
+
+/*
+ * Macros to make the correct C datatypes for a new kind of ring.
+ * 
+ * To make a new ring datatype, you need to have two message structures,
+ * let's say request_t, and response_t already defined.
+ *
+ * In a header where you want the ring datatype declared, you then do:
+ *
+ * DEFINE_RING_TYPES(mytag, request_t, response_t);
+ *
+ * These expand out to give you a set of types, as you can see below.
+ * The most important of these are:
+ * 
+ * mytag_sring_t  - The shared ring.
+ * mytag_front_ring_t - The 'front' half of the ring.
+ * mytag_back_ring_t  - The 'back' half of the ring.
+ *
+ * To initialize a ring in your code you need to know the location and size
+ * of the shared memory area (PAGE_SIZE, for instance). To initialise
+ * the front half:
+ *
+ * mytag_front_ring_t front_ring;
+ * SHARED_RING_INIT((mytag_sring_t *)shared_page);
+ * FRONT_RING_INIT(_ring, (mytag_sring_t *)shared_page, PAGE_SIZE);
+ *
+ * Initializing 

[Xen-devel] [PATCH v3 0/9] xen/9pfs: introduce the Xen 9pfs backend

[Stefano Stabellini]

Hi all,

This patch series implements a new transport for 9pfs, aimed at Xen
systems.

The transport is based on a traditional Xen frontend and backend drivers
pair. This patch series implements the backend, which typically runs in
Dom0. I sent another series to implement the frontend in Linux
(http://marc.info/?l=linux-kernel=148883047125960=2).

The backend complies to the Xen transport for 9pfs specification
version 1, available here:

http://xenbits.xen.org/gitweb/?p=xen.git;a=blob_plain;f=docs/misc/9pfs.markdown;hb=HEAD


Changes in v3:
- do not build backends for targets that do not support xen
- remove xen_9pfs.h, merge its content into xen-9p-backend.c
- remove xen_9pfs_header, introduce P9MsgHeader
- use le32_to_cpu to access P9MsgHeader fields
- many coding style fixes
- run checkpatch on all patches
- add check if num_rings < 1
- use g_strdup_printf
- free fsdev_id in xen_9pfs_free
- add comments

Changes in v2:
- fix coding style
- compile xen-9p-backend.c if CONFIG_XEN_BACKEND
- add patch to set CONFIG_XEN_BACKEND only for the right targets
- add review-bys


Stefano Stabellini (9):
  xen: do not build backends for targets that do not support xen
  xen: import ring.h from xen
  9p: introduce a type for the 9p header
  xen/9pfs: introduce Xen 9pfs backend
  xen/9pfs: connect to the frontend
  xen/9pfs: receive requests from the frontend
  xen/9pfs: implement in/out_iov_from_pdu and vmarshal/vunmarshal
  xen/9pfs: send responses back to the frontend
  xen/9pfs: build and register Xen 9pfs backend

 Makefile |   1 +
 hw/9pfs/9p.h |   6 +
 hw/9pfs/Makefile.objs|   1 +
 hw/9pfs/virtio-9p-device.c   |   6 +-
 hw/9pfs/xen-9p-backend.c | 434 +
 hw/block/Makefile.objs   |   2 +-
 hw/block/xen_blkif.h |   2 +-
 hw/char/Makefile.objs|   2 +-
 hw/display/Makefile.objs |   2 +-
 hw/net/Makefile.objs |   2 +-
 hw/usb/Makefile.objs |   2 +-
 hw/usb/xen-usb.c |   2 +-
 hw/xen/Makefile.objs |   2 +-
 hw/xen/xen_backend.c |   3 +
 include/hw/xen/io/ring.h | 455 +++
 include/hw/xen/xen_backend.h |   3 +
 16 files changed, 912 insertions(+), 13 deletions(-)
 create mode 100644 hw/9pfs/xen-9p-backend.c
 create mode 100644 include/hw/xen/io/ring.h

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

[Xen-devel] [PATCH v2] x86/time: Don't use virtual TSC if host and guest frequencies are equal

[Boris Ostrovsky]

Commit 82713ec8d2 ("x86: use native RDTSC(P) execution when guest and
host frequencies are the same") left out optimization for PV guests
when host and guest run at the same frequency.

For such a case we should be able not to use virtual TSC regardless
of whether we are runing before or after a migration (i.e. regardless
of incarnation value).

Signed-off-by: Boris Ostrovsky 
Suggested-by: Jan Beulich 
---
Changes in v2:
 * Replaced unnecessary incarnation test with an ASSERT

 xen/arch/x86/time.c | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index faa638b..46a00f6 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -2051,17 +2051,12 @@ void tsc_set_info(struct domain *d,
 d->arch.vtsc_offset = get_s_time() - elapsed_nsec;
 d->arch.tsc_khz = gtsc_khz ?: cpu_khz;
 set_time_scale(>arch.vtsc_to_ns, d->arch.tsc_khz * 1000);
-/*
- * In default mode use native TSC if the host has safe TSC and:
- *  HVM/PVH: host and guest frequencies are the same (either
- *   "naturally" or via TSC scaling)
- *  PV: guest has not migrated yet (and thus arch.tsc_khz == cpu_khz)
- */
+
+ASSERT(incarnation || d->arch.tsc_khz == cpu_khz);
 if ( tsc_mode == TSC_MODE_DEFAULT && host_tsc_is_safe() &&
- (has_hvm_container_domain(d) ?
-  (d->arch.tsc_khz == cpu_khz ||
-   hvm_get_tsc_scaling_ratio(d->arch.tsc_khz)) :
-  incarnation == 0) )
+ (d->arch.tsc_khz == cpu_khz ||
+  (has_hvm_container_domain(d) &&
+   hvm_get_tsc_scaling_ratio(d->arch.tsc_khz))) )
 {
 case TSC_MODE_NEVER_EMULATE:
 d->arch.vtsc = 0;
-- 
1.8.3.1


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

[Xen-devel] [xen-unstable-smoke test] 106723: tolerable trouble: broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  0a1b7f4e37e17f532a00a1bf732a072b40ca2a1b
baseline version:
 xen  bfd9a2095f1882e8c074b2d911bcb07d12cf6cf5

Last test of basis   106693  2017-03-15 13:00:59 Z1 days
Testing same since   106723  2017-03-16 17:01:17 Z0 days1 attempts


People who touched revisions under test:
  David Scott 
  Elena Ufimtseva 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Razvan Cojocaru 
  Roger Pau Monne 
  Roger Pau Monné 
  Tim Deegan 
  Wei Liu 

jobs:
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=0a1b7f4e37e17f532a00a1bf732a072b40ca2a1b
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
0a1b7f4e37e17f532a00a1bf732a072b40ca2a1b
+ branch=xen-unstable-smoke
+ revision=0a1b7f4e37e17f532a00a1bf732a072b40ca2a1b
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' x0a1b7f4e37e17f532a00a1bf732a072b40ca2a1b = 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
++ : 

[Xen-devel] [PATCH v4 07/14] golang/xenlight: Implement libxl_scheduler enumeration

[Ronald Rojas]

Include both constants and a Stringification for libxl_scheduler.

Signed-off-by: George Dunlap 
Signed-off-by: Ronald Rojas 
---
CC: xen-devel@lists.xen.org
CC: george.dun...@citrix.com
CC: ian.jack...@eu.citrix.com
CC: wei.l...@citrix.com
---
 tools/golang/xenlight/xenlight.go | 62 +++
 1 file changed, 62 insertions(+)

diff --git a/tools/golang/xenlight/xenlight.go 
b/tools/golang/xenlight/xenlight.go
index eb2b3cf..d4a6bc1 100644
--- a/tools/golang/xenlight/xenlight.go
+++ b/tools/golang/xenlight/xenlight.go
@@ -311,6 +311,68 @@ func (cdi *C.libxl_dominfo) toGo() (di *Dominfo) {
return
 }
 
+// # Consistent with values defined in domctl.h
+// # Except unknown which we have made up
+// libxl_scheduler = Enumeration("scheduler", [
+// (0, "unknown"),
+// (4, "sedf"),
+// (5, "credit"),
+// (6, "credit2"),
+// (7, "arinc653"),
+// (8, "rtds"),
+// ])
+type Scheduler int
+
+var (
+   SchedulerUnknown  Scheduler = C.LIBXL_SCHEDULER_UNKNOWN
+   SchedulerSedf Scheduler = C.LIBXL_SCHEDULER_SEDF
+   SchedulerCredit   Scheduler = C.LIBXL_SCHEDULER_CREDIT
+   SchedulerCredit2  Scheduler = C.LIBXL_SCHEDULER_CREDIT2
+   SchedulerArinc653 Scheduler = C.LIBXL_SCHEDULER_ARINC653
+   SchedulerRTDS Scheduler = C.LIBXL_SCHEDULER_RTDS
+)
+
+// const char *libxl_scheduler_to_string(libxl_scheduler p);
+func (s Scheduler) String() string {
+   cs := C.libxl_scheduler_to_string(C.libxl_scheduler(s))
+   // No need to free const return value
+
+   return C.GoString(cs)
+}
+
+// int libxl_scheduler_from_string(const char *s, libxl_scheduler *e);
+func (s *Scheduler) FromString(gstr string) (err error) {
+   cstr := C.CString(gstr)
+   defer C.free(unsafe.Pointer(cstr))
+
+   var cs C.libxl_scheduler
+   ret := C.libxl_scheduler_from_string(cstr, )
+   if ret != 0 {
+   err = Error(-ret)
+   return
+   }
+
+   *s = Scheduler(cs)
+   return
+}
+
+func SchedulerFromString(name string) (s Scheduler, err error) {
+   cname := C.CString(name)
+   defer C.free(unsafe.Pointer(cname))
+
+   var cs C.libxl_scheduler
+
+   ret := C.libxl_scheduler_from_string(cname, )
+   if ret != 0 {
+   err = Error(-ret)
+   return
+   }
+
+   s = Scheduler(cs)
+
+   return
+}
+
 /*
  * Bitmap operations
  */
-- 
2.7.3


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

[Xen-devel] [PATCH v4 09/14] golang/xenlight: Implement Domain operations

[Ronald Rojas]

Add calls for the following Domain related functionality
- libxl_domain_pause
- libxl_domain_shutdown
- libxl_domain_reboot
- libxl_list_domain

Signed-off-by: Ronald Rojas 
---
CC: xen-devel@lists.xen.org
CC: george.dun...@citrix.com
CC: ian.jack...@eu.citrix.com
CC: wei.l...@citrix.com
---
---
 tools/golang/xenlight/xenlight.go | 70 +++
 1 file changed, 70 insertions(+)

diff --git a/tools/golang/xenlight/xenlight.go 
b/tools/golang/xenlight/xenlight.go
index 85e4c78..5a1e273 100644
--- a/tools/golang/xenlight/xenlight.go
+++ b/tools/golang/xenlight/xenlight.go
@@ -956,3 +956,73 @@ func (Ctx *Context) DomainUnpause(Id Domid) (err error) {
}
return
 }
+
+//int libxl_domain_pause(libxl_ctx *ctx, uint32_t domain);
+func (Ctx *Context) DomainPause(id Domid) (err error) {
+   err = Ctx.CheckOpen()
+   if err != nil {
+   return
+   }
+
+   ret := C.libxl_domain_pause(Ctx.ctx, C.uint32_t(id))
+
+   if ret != 0 {
+   err = Error(-ret)
+   }
+   return
+}
+
+//int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
+func (Ctx *Context) DomainShutdown(id Domid) (err error) {
+   err = Ctx.CheckOpen()
+   if err != nil {
+   return
+   }
+
+   ret := C.libxl_domain_shutdown(Ctx.ctx, C.uint32_t(id))
+
+   if ret != 0 {
+   err = Error(-ret)
+   }
+   return
+}
+
+//int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
+func (Ctx *Context) DomainReboot(id Domid) (err error) {
+   err = Ctx.CheckOpen()
+   if err != nil {
+   return
+   }
+
+   ret := C.libxl_domain_reboot(Ctx.ctx, C.uint32_t(id))
+
+   if ret != 0 {
+   err = Error(-ret)
+   }
+   return
+}
+
+//libxl_dominfo * libxl_list_domain(libxl_ctx*, int *nb_domain_out);
+//void libxl_dominfo_list_free(libxl_dominfo *list, int nb_domain);
+func (Ctx *Context) ListDomain() (glist []Dominfo) {
+   err := Ctx.CheckOpen()
+   if err != nil {
+   return
+   }
+
+   var nbDomain C.int
+   clist := C.libxl_list_domain(Ctx.ctx, )
+   defer C.libxl_dominfo_list_free(clist, nbDomain)
+
+   if int(nbDomain) == 0 {
+   return
+   }
+
+   gslice := (*[1 << 
30]C.libxl_dominfo)(unsafe.Pointer(clist))[:nbDomain:nbDomain]
+   for i := range gslice {
+   info := gslice[i].toGo()
+   glist = append(glist, *info)
+   }
+
+   return
+}
-- 
2.7.3


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

[Xen-devel] [PATCH v4 13/14] golang/xenlight: Implement ActionOnShutdown and DomainConfig

[Ronald Rojas]

Applied enumeration and implemented toC method for ActionOnShutdown

Implemented struct and implemented toC method for DomainConfig

Signed-off-by: Ronald Rojas 
---
CC: xen-devel@lists.xen.org
CC: george.dun...@citrix.com
CC: ian.jack...@eu.citrix.com
CC: wei.l...@citrix.com
---
---
 tools/golang/xenlight/xenlight.go | 61 +++
 1 file changed, 61 insertions(+)

diff --git a/tools/golang/xenlight/xenlight.go 
b/tools/golang/xenlight/xenlight.go
index 8b5ca38..ed76fec 100644
--- a/tools/golang/xenlight/xenlight.go
+++ b/tools/golang/xenlight/xenlight.go
@@ -1299,3 +1299,64 @@ type DeviceUsbdev struct {
 func (gdu DeviceUsbdev) toC() (cdu C.libxl_device_usbdev) {
return
 }
+
+type ActionOnShutdown int
+
+const (
+   ActionOnShutdownDestroy = C.LIBXL_ACTION_ON_SHUTDOWN_DESTROY
+   ActionOnShutdownRestart = C.LIBXL_ACTION_ON_SHUTDOWN_RESTART
+   ActionOnShutdownRestartRename   = 
C.LIBXL_ACTION_ON_SHUTDOWN_RESTART_RENAME
+   ActionOnShutdownPreserve= C.LIBXL_ACTION_ON_SHUTDOWN_PRESERVE
+   ActionOnShutdownCoredumpDestroy = 
C.LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY
+   ActionOnShutdownCoredumRestart  = 
C.LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_RESTART
+   ActionOnShutdownSoftReset   = C.LIBXL_ACTION_ON_SHUTDOWN_SOFT_RESET
+)
+
+func (aos ActionOnShutdown) String() (str string) {
+   cstr := 
C.libxl_action_on_shutdown_to_string(C.libxl_action_on_shutdown(aos))
+
+   str = C.GoString(cstr)
+
+   return
+}
+
+func (gaos ActionOnShutdown) toC() (caos C.libxl_action_on_shutdown) {
+   caos = C.libxl_action_on_shutdown(gaos)
+   return
+}
+
+type DomainConfig struct {
+   CInfo DomainCreateInfo
+   BInfo DomainBuildInfo
+
+   Disks   []DeviceNic
+   Pcidevs []DevicePci
+   Rdms[]DeviceRdm
+   Dtdevs  []DeviceDtdev
+   Vftbs   []DeviceVfb
+   Vkbs[]DeviceVkb
+   Vtpms   []DeviceVtpm
+
+   Channels []DeviceChannel
+   Usbctrls []DeviceUsbctrl
+   Usbdevs  []DeviceUsbdev
+
+   OnPoweroff  ActionOnShutdown
+   OnRebootActionOnShutdown
+   OnWatchdog  ActionOnShutdown
+   OnCrash ActionOnShutdown
+   OnSoftReset ActionOnShutdown
+}
+
+func (gdc DomainConfig) toC() (cdc C.libxl_domain_config) {
+   cdc.c_info = gdc.CInfo.toC()
+   cdc.b_info = gdc.BInfo.toC()
+   //FIXME: Implement converting device information
+
+   cdc.on_poweroff = gdc.OnPoweroff.toC()
+   cdc.on_reboot = gdc.OnReboot.toC()
+   cdc.on_watchdog = gdc.OnWatchdog.toC()
+   cdc.on_crash = gdc.OnCrash.toC()
+   cdc.on_soft_reset = gdc.OnSoftReset.toC()
+   return
+}
-- 
2.7.3


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

[Xen-devel] [PATCH v4 11/14] golang/xenlight: Implement get console path operations

[Ronald Rojas]

Implement Golang enumeration of libxl_console_type
as ConsoleType

Implement the following libxl functions:
- libxl_console_get_tty
- libxl_primary_console_get_tty

Signed-off-by: Ronald Rojas 
---
CC: xen-devel@lists.xen.org
CC: george.dun...@citrix.com
CC: ian.jack...@eu.citrix.com
CC: wei.l...@citrix.com
---
---
 tools/golang/xenlight/xenlight.go | 57 +++
 1 file changed, 57 insertions(+)

diff --git a/tools/golang/xenlight/xenlight.go 
b/tools/golang/xenlight/xenlight.go
index 61d7f8f..d520f74 100644
--- a/tools/golang/xenlight/xenlight.go
+++ b/tools/golang/xenlight/xenlight.go
@@ -1080,3 +1080,60 @@ func (Ctx *Context) ListVcpu(id Domid) (glist 
[]Vcpuinfo) {
 
return
 }
+
+type ConsoleType int
+
+const (
+   ConsoleTypeUnknown = ConsoleType(C.LIBXL_CONSOLE_TYPE_UNKNOWN)
+   ConsoleTypeSerial  = ConsoleType(C.LIBXL_CONSOLE_TYPE_SERIAL)
+   ConsoleTypePV  = ConsoleType(C.LIBXL_CONSOLE_TYPE_PV)
+)
+
+func (ct ConsoleType) String() (str string) {
+   cstr := C.libxl_console_type_to_string(C.libxl_console_type(ct))
+   str = C.GoString(cstr)
+
+   return
+}
+
+//int libxl_console_get_tty(libxl_ctx *ctx, uint32_t domid, int cons_num,
+//libxl_console_type type, char **path);
+func (Ctx *Context) ConsoleGetTty(id Domid, consNum int, conType ConsoleType) 
(path string, err error) {
+   err = Ctx.CheckOpen()
+   if err != nil {
+   return
+   }
+
+   var cpath *C.char
+   defer C.free(cpath)
+   ret := C.libxl_console_get_tty(Ctx.ctx, C.uint32_t(id), C.int(consNum), 
C.libxl_console_type(conType), )
+
+   if ret != 0 {
+   err = Error(-ret)
+   return
+   }
+
+   path = C.GoString(cpath)
+   return
+}
+
+//int libxl_primary_console_get_tty(libxl_ctx *ctx, uint32_t domid_vm,
+// char **path);
+func (Ctx *Context) PrimaryConsoleGetTty(domid uint32) (path string, err 
error) {
+   err = Ctx.CheckOpen()
+   if err != nil {
+   return
+   }
+
+   var cpath *C.char
+   ret := C.libxl_primary_console_get_tty(Ctx.ctx, C.uint32_t(domid), 
)
+   defer C.free(cpath)
+
+   if ret != 0 {
+   err = Error(-ret)
+   return
+   }
+
+   path = C.GoString(cpath)
+   return
+}
-- 
2.7.3


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

[Xen-devel] [PATCH v4 12/14] golang/xenlight: Created boilerplate code for device related structs

[Ronald Rojas]

Created boilerplate struct and toC methods for the
following structs:
- KeyValueList
- DomainBuildInfo
- DeviceNic
- DevicePci
- DeviceRdm
- DeviceDtdev
- DeviceVfb
- DeviceVkb
- DeviceVtpm
- DeviceChannel
- DeviceUsbctrl
- DeviceUsbdev

Signed-off-by: Ronald Rojas 
---
This specific patch constains mostly boilerplate code
that will be implemented in patches later down the road.

CC: xen-devel@lists.xen.org
CC: george.dun...@citrix.com
CC: ian.jack...@eu.citrix.com
CC: wei.l...@citrix.com
---
---
 tools/golang/xenlight/xenlight.go | 162 ++
 1 file changed, 162 insertions(+)

diff --git a/tools/golang/xenlight/xenlight.go 
b/tools/golang/xenlight/xenlight.go
index d520f74..8b5ca38 100644
--- a/tools/golang/xenlight/xenlight.go
+++ b/tools/golang/xenlight/xenlight.go
@@ -1137,3 +1137,165 @@ func (Ctx *Context) PrimaryConsoleGetTty(domid uint32) 
(path string, err error)
path = C.GoString(cpath)
return
 }
+
+type Defbool string
+
+type KeyValueList []string
+
+type ckeyvaluelist struct {
+   clist C.libxl_key_value_list
+}
+
+func (clist ckeyvaluelist) toGo(glist KeyValueList) {
+   return
+}
+
+type DomainCreateInfo struct {
+   Type  DomainType
+   Hap   Defbool
+   Oos   Defbool
+   ssidref   uint32
+   ssid_labelstring
+   name  string
+   uuid  Uuid
+   XsdataKeyValueList
+   Platformdata  KeyValueList
+   Pooliduint32
+   PoolName  string
+   RunHotplugScripts Defbool
+   Pvh   Defbool
+   DriverDomain  Defbool
+}
+
+func (dci DomainCreateInfo) toC() (cci C.libxl_domain_create_info) {
+
+   return
+}
+
+type TscMode int
+
+const (
+   TscModeDefault= TscMode(C.LIBXL_TSC_MODE_DEFAULT)
+   TscModeAlwaysEmulate  = TscMode(C.LIBXL_TSC_MODE_ALWAYS_EMULATE)
+   TscModeNative = TscMode(C.LIBXL_TSC_MODE_NATIVE)
+   TscModeNativeParavirt = TscMode(C.LIBXL_TSC_MODE_NATIVE_PARAVIRT)
+)
+
+func (tm TscMode) String() (str string) {
+   cstr := C.libxl_tsc_mode_to_string(C.libxl_tsc_mode(tm))
+   str = C.GoString(cstr)
+
+   return
+}
+
+type CpuidPolicy struct {
+   //FIXME: Implement struct
+}
+
+//FIXME Create toGo function for CpuidPolicy
+
+type DomainBuildInfo struct {
+   MaxVcpus int
+   AvailVcpus   Bitmap
+   Cpumap   Bitmap
+   Nodemap  Bitmap
+   VcpuHardAffinity []Bitmap
+   VcpuSoftAffinity []Bitmap
+   NumaPlacementDefbool
+   TscMode  TscMode
+   MaxMemkb MemKB
+   TargetMemkb  MemKB
+   VideoMemkb   MemKB
+   ShadowMemkb  MemKB
+   RtcTimeoffsetuint32
+   ExecSsidref  uint32
+   ExecSsidLabelstring
+   localTimeDefbool
+   DisableMigrate   Defbool
+   Cpuid[]CpuidPolicy
+   blkdevStart  string
+}
+
+func (gdbi DomainBuildInfo) toC() (cdbi C.libxl_domain_build_info) {
+   return
+}
+
+type DeviceNic struct {
+   //FIXME: complete struct
+}
+
+func (gdn DeviceNic) toC() (cdn C.libxl_device_nic) {
+   return
+}
+
+type DevicePci struct {
+   //FIXME: complete struct
+}
+
+func (gdp DevicePci) toC() (cdp C.libxl_device_pci) {
+   return
+}
+
+type DeviceRdm struct {
+   //FIXME: complete struct
+}
+
+func (gdr DeviceRdm) toC() (cdr C.libxl_device_rdm) {
+   return
+}
+
+type DeviceDtdev struct {
+   //FIXME: complete struct
+}
+
+func (gdd DeviceDtdev) toC() (cdd C.libxl_device_dtdev) {
+   return
+}
+
+type DeviceVfb struct {
+   //FIXME: complete struct
+}
+
+func (gdv DeviceVfb) toC() (cdv C.libxl_device_vfb) {
+   return
+}
+
+type DeviceVkb struct {
+   //FIXME: complete struct
+}
+
+func (gdv DeviceVkb) toC() (cdv C.libxl_device_vkb) {
+   return
+}
+
+type DeviceVtpm struct {
+   //FIXME: complete struct
+}
+
+func (gdv DeviceVtpm) toC() (cdv C.libxl_device_vtpm) {
+   return
+}
+
+type DeviceChannel struct {
+   //FIXME: complete struct
+}
+
+func (gdc DeviceChannel) toC() (cdc C.libxl_device_channel) {
+   return
+}
+
+type DeviceUsbctrl struct {
+   //FIXME: complete struct
+}
+
+func (gdu DeviceUsbctrl) toC() (cdu C.libxl_device_usbctrl) {
+   return
+}
+
+type DeviceUsbdev struct {
+   //FIXME: complete struct
+}
+
+func (gdu DeviceUsbdev) toC() (cdu C.libxl_device_usbdev) {
+   return
+}
-- 
2.7.3


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

[Xen-devel] [PATCH v4 14/14] golang/xenlight: Implement domain create/destroy operations

[Ronald Rojas]

Implemented DomainCreateNew and DomainDestroy methods

Signed-off-by: Ronald Rojas 
---

CC: xen-devel@lists.xen.org
CC: george.dun...@citrix.com
CC: ian.jack...@eu.citrix.com
CC: wei.l...@citrix.com
---
---
 tools/golang/xenlight/xenlight.go | 43 +++
 1 file changed, 43 insertions(+)

diff --git a/tools/golang/xenlight/xenlight.go 
b/tools/golang/xenlight/xenlight.go
index ed76fec..c9774cf 100644
--- a/tools/golang/xenlight/xenlight.go
+++ b/tools/golang/xenlight/xenlight.go
@@ -1360,3 +1360,46 @@ func (gdc DomainConfig) toC() (cdc 
C.libxl_domain_config) {
cdc.on_soft_reset = gdc.OnSoftReset.toC()
return
 }
+
+//int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
+// uint32_t *domid,
+// const libxl_asyncop_how *ao_how,
+// const libxl_asyncprogress_how *aop_console_how)
+// LIBXL_EXTERNAL_CALLERS_ONLY;
+func (Ctx *Context) DomainCreateNew(dconfig DomainConfig) (id Domid, err 
error) {
+   err = Ctx.CheckOpen()
+   if err != nil {
+   return
+   }
+   cconfig := dconfig.toC()
+
+   var cid C.uint32_t
+   //FIXME: create async caller
+   ret := C.libxl_domain_create_new(Ctx.ctx, , , nil, nil)
+   if ret != 0 {
+   err = Error(-ret)
+   return
+   }
+   id = Domid(cid)
+
+   return
+}
+
+//int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
+// const libxl_asyncop_how *ao_how)
+// LIBXL_EXTERNAL_CALLERS_ONLY;
+func (Ctx *Context) DomainDestroy(id Domid) (err error) {
+   err = Ctx.CheckOpen()
+   if err != nil {
+   return
+   }
+
+   //FIXME: create async caller
+   ret := C.libxl_domain_destroy(Ctx.ctx, C.uint32_t(id), nil)
+   if ret != 0 {
+   err = Error(-ret)
+   return
+   }
+   return
+
+}
-- 
2.7.3


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

[Xen-devel] [PATCH v4 10/14] golang/xenlight: Implement Vcpuinfo and ListVcpu

[Ronald Rojas]

Include Golang version of libxl_vcpu_info
as VcpuInfo

Add a Golang call for libxl_list_vcpu as
ListVcpu

Signed-off-by: Ronald Rojas 
---
CC: xen-devel@lists.xen.org
CC: george.dun...@citrix.com
CC: ian.jack...@eu.citrix.com
CC: wei.l...@citrix.com
---
---
 tools/golang/xenlight/xenlight.go | 54 +++
 1 file changed, 54 insertions(+)

diff --git a/tools/golang/xenlight/xenlight.go 
b/tools/golang/xenlight/xenlight.go
index 5a1e273..61d7f8f 100644
--- a/tools/golang/xenlight/xenlight.go
+++ b/tools/golang/xenlight/xenlight.go
@@ -1026,3 +1026,57 @@ func (Ctx *Context) ListDomain() (glist []Dominfo) {
 
return
 }
+
+type Vcpuinfo struct {
+   Vcpuid uint32
+   Cpuuint32
+   Online bool
+   Blockedbool
+   Runningbool
+   VCpuTime   time.Duration
+   Cpumap Bitmap
+   CpumapSoft Bitmap
+}
+
+func (cvci C.libxl_vcpuinfo) toGo() (gvci Vcpuinfo) {
+   gvci.Vcpuid = uint32(cvci.vcpuid)
+   gvci.Cpu = uint32(cvci.cpu)
+   gvci.Online = bool(cvci.online)
+   gvci.Blocked = bool(cvci.blocked)
+   gvci.Running = bool(cvci.running)
+   gvci.VCpuTime = time.Duration(cvci.vcpu_time)
+   gvci.Cpumap = cvci.cpumap.toGo()
+   gvci.CpumapSoft = cvci.cpumap_soft.toGo()
+
+   return
+}
+
+//libxl_vcpuinfo *libxl_list_vcpu(libxl_ctx *ctx, uint32_t domid,
+// int *nb_vcpu, int *nr_cpus_out);
+//void libxl_vcpuinfo_list_free(libxl_vcpuinfo *, int nr_vcpus);
+func (Ctx *Context) ListVcpu(id Domid) (glist []Vcpuinfo) {
+   err := Ctx.CheckOpen()
+   if err != nil {
+   return
+   }
+
+   var nbVcpu C.int
+   var nrCpu C.int
+
+   clist := C.libxl_list_vcpu(Ctx.ctx, C.uint32_t(id), , )
+   defer C.libxl_vcpuinfo_list_free(clist, nbVcpu)
+
+   if int(nbVcpu) == 0 {
+   return
+   }
+
+   gslice := (*[1 << 
30]C.libxl_vcpuinfo)(unsafe.Pointer(clist))[:nbVcpu:nbVcpu]
+
+   for i := range gslice {
+   info := gslice[i].toGo()
+
+   glist = append(glist, info)
+   }
+
+   return
+}
-- 
2.7.3


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

[Xen-devel] [PATCH v4 08/14] golang/xenlight: Implement cpupool operations

[Ronald Rojas]

Include some useful "Utility" functions:
- CpupoolFindByName
- CpupoolMakeFree

Still need to implement the following functions:
- libxl_cpupool_rename
- libxl_cpupool_cpuadd_node
- libxl_cpupool_cpuremove_node
- libxl_cpupool_movedomain

Signed-off-by: George Dunlap 
Signed-off-by: Ronald Rojas 

---

Changes

- Renamed CToGo functions as toGo

CC: xen-devel@lists.xen.org
CC: george.dun...@citrix.com
CC: ian.jack...@eu.citrix.com
CC: wei.l...@citrix.com
---
---
 tools/golang/xenlight/xenlight.go | 237 ++
 1 file changed, 237 insertions(+)

diff --git a/tools/golang/xenlight/xenlight.go 
b/tools/golang/xenlight/xenlight.go
index d4a6bc1..85e4c78 100644
--- a/tools/golang/xenlight/xenlight.go
+++ b/tools/golang/xenlight/xenlight.go
@@ -373,6 +373,243 @@ func SchedulerFromString(name string) (s Scheduler, err 
error) {
return
 }
 
+// libxl_cpupoolinfo = Struct("cpupoolinfo", [
+// ("poolid",  uint32),
+// ("pool_name",   string),
+// ("sched",   libxl_scheduler),
+// ("n_dom",   uint32),
+// ("cpumap",  libxl_bitmap)
+// ], dir=DIR_OUT)
+
+type CpupoolInfo struct {
+   Poolid  uint32
+   PoolNamestring
+   Scheduler   Scheduler
+   DomainCount int
+   Cpumap  Bitmap
+}
+
+func (cci C.libxl_cpupoolinfo) toGo() (gci CpupoolInfo) {
+   gci.Poolid = uint32(cci.poolid)
+   gci.PoolName = C.GoString(cci.pool_name)
+   gci.Scheduler = Scheduler(cci.sched)
+   gci.DomainCount = int(cci.n_dom)
+   gci.Cpumap = cci.cpumap.toGo()
+
+   return
+}
+
+// libxl_cpupoolinfo * libxl_list_cpupool(libxl_ctx*, int *nb_pool_out);
+// void libxl_cpupoolinfo_list_free(libxl_cpupoolinfo *list, int nb_pool);
+func (Ctx *Context) ListCpupool() (list []CpupoolInfo) {
+   err := Ctx.CheckOpen()
+   if err != nil {
+   return
+   }
+
+   var nbPool C.int
+
+   c_cpupool_list := C.libxl_list_cpupool(Ctx.ctx, )
+
+   defer C.libxl_cpupoolinfo_list_free(c_cpupool_list, nbPool)
+
+   if int(nbPool) == 0 {
+   return
+   }
+
+   // Magic
+   cpupoolListSlice := (*[1 << 
30]C.libxl_cpupoolinfo)(unsafe.Pointer(c_cpupool_list))[:nbPool:nbPool]
+
+   for i := range cpupoolListSlice {
+   info := cpupoolListSlice[i].toGo()
+
+   list = append(list, info)
+   }
+
+   return
+}
+
+// int libxl_cpupool_info(libxl_ctx *ctx, libxl_cpupoolinfo *info, uint32_t 
poolid);
+func (Ctx *Context) CpupoolInfo(Poolid uint32) (pool CpupoolInfo) {
+   err := Ctx.CheckOpen()
+   if err != nil {
+   return
+   }
+
+   var c_cpupool C.libxl_cpupoolinfo
+
+   ret := C.libxl_cpupool_info(Ctx.ctx, _cpupool, C.uint32_t(Poolid))
+   if ret != 0 {
+   err = Error(-ret)
+   return
+   }
+   defer C.libxl_cpupoolinfo_dispose(_cpupool)
+
+   pool = c_cpupool.toGo()
+
+   return
+}
+
+// int libxl_cpupool_create(libxl_ctx *ctx, const char *name,
+//  libxl_scheduler sched,
+//  libxl_bitmap cpumap, libxl_uuid *uuid,
+//  uint32_t *poolid);
+// FIXME: uuid
+// FIXME: Setting poolid
+func (Ctx *Context) CpupoolCreate(Name string, Scheduler Scheduler, Cpumap 
Bitmap) (err error, Poolid uint32) {
+   err = Ctx.CheckOpen()
+   if err != nil {
+   return
+   }
+
+   poolid := C.uint32_t(0)
+   name := C.CString(Name)
+   defer C.free(unsafe.Pointer(name))
+
+   // For now, just do what xl does, and make a new uuid every time we 
create the pool
+   var uuid C.libxl_uuid
+   C.libxl_uuid_generate()
+
+   cbm := Cpumap.toC()
+   defer C.libxl_bitmap_dispose()
+
+   ret := C.libxl_cpupool_create(Ctx.ctx, name, 
C.libxl_scheduler(Scheduler),
+   cbm, , )
+   if ret != 0 {
+   err = Error(-ret)
+   return
+   }
+
+   Poolid = uint32(poolid)
+
+   return
+}
+
+// int libxl_cpupool_destroy(libxl_ctx *ctx, uint32_t poolid);
+func (Ctx *Context) CpupoolDestroy(Poolid uint32) (err error) {
+   err = Ctx.CheckOpen()
+   if err != nil {
+   return
+   }
+
+   ret := C.libxl_cpupool_destroy(Ctx.ctx, C.uint32_t(Poolid))
+   if ret != 0 {
+   err = Error(-ret)
+   return
+   }
+
+   return
+}
+
+// int libxl_cpupool_cpuadd(libxl_ctx *ctx, uint32_t poolid, int cpu);
+func (Ctx *Context) CpupoolCpuadd(Poolid uint32, Cpu int) (err error) {
+   err = Ctx.CheckOpen()
+   if err != nil {
+   return
+   }
+
+   ret := C.libxl_cpupool_cpuadd(Ctx.ctx, C.uint32_t(Poolid), C.int(Cpu))
+   if ret != 0 {
+   err = Error(-ret)
+   return
+   }
+
+   return
+}
+
+// int libxl_cpupool_cpuadd_cpumap(libxl_ctx *ctx, uint32_t poolid,
+//   

[Xen-devel] [PATCH v4 06/14] golang/xenlight: Implement libxl_bitmap and helper operations

[Ronald Rojas]

Implement Bitmap type, along with helper functions.

The Bitmap type is implemented interllay in a way which makes it
easy to copy into and out of the C libxl_bitmap type.

Signed-off-by: George Dunlap 
Signed-off-by: Ronald Rojas 

---

CC: xen-devel@lists.xen.org
CC: george.dun...@citrix.com
CC: ian.jack...@eu.citrix.com
CC: wei.l...@citrix.com

---
---
 tools/golang/xenlight/xenlight.go | 167 ++
 1 file changed, 167 insertions(+)

diff --git a/tools/golang/xenlight/xenlight.go 
b/tools/golang/xenlight/xenlight.go
index 34c3050..eb2b3cf 100644
--- a/tools/golang/xenlight/xenlight.go
+++ b/tools/golang/xenlight/xenlight.go
@@ -129,6 +129,20 @@ func (chwcap C.libxl_hwcap) toGo() (ghwcap Hwcap) {
return
 }
 
+// typedef struct {
+// uint32_t size;  /* number of bytes in map */
+// uint8_t *map;
+// } libxl_bitmap;
+
+// Implement the Go bitmap type such that the underlying data can
+// easily be copied in and out.  NB that we still have to do copies
+// both directions, because cgo runtime restrictions forbid passing to
+// a C function a pointer to a Go-allocated structure which contains a
+// pointer.
+type Bitmap struct {
+   bitmap []C.uint8_t
+}
+
 /*
  * Types: IDL
  *
@@ -298,6 +312,159 @@ func (cdi *C.libxl_dominfo) toGo() (di *Dominfo) {
 }
 
 /*
+ * Bitmap operations
+ */
+
+// Return a Go bitmap which is a copy of the referred C bitmap.
+func (cbm C.libxl_bitmap) toGo() (gbm Bitmap) {
+   // Alloc a Go slice for the bytes
+   size := int(cbm.size)
+   gbm.bitmap = make([]C.uint8_t, size)
+
+   // Make a slice pointing to the C array
+   mapslice := (*[1 << 30]C.uint8_t)(unsafe.Pointer(cbm._map))[:size:size]
+
+   // And copy the C array into the Go array
+   copy(gbm.bitmap, mapslice)
+
+   return
+}
+
+// Must be C.libxl_bitmap_dispose'd of afterwards
+func (gbm Bitmap) toC() (cbm C.libxl_bitmap) {
+   C.libxl_bitmap_init()
+
+   size := len(gbm.bitmap)
+   cbm._map = (*C.uint8_t)(C.malloc(C.size_t(size)))
+   cbm.size = C.uint32_t(size)
+   if cbm._map == nil {
+   panic("C.calloc failed!")
+   }
+
+   // Make a slice pointing to the C array
+   mapslice := (*[1 << 30]C.uint8_t)(unsafe.Pointer(cbm._map))[:size:size]
+
+   // And copy the Go array into the C array
+   copy(mapslice, gbm.bitmap)
+
+   return
+}
+
+func (bm *Bitmap) Test(bit int) bool {
+   ubit := uint(bit)
+   if bit > bm.Max() || bm.bitmap == nil {
+   return false
+   }
+
+   return (bm.bitmap[bit/8] & (1 << (ubit & 7))) != 0
+}
+
+func (bm *Bitmap) Set(bit int) {
+   ibit := bit / 8
+   if ibit+1 > len(bm.bitmap) {
+   bm.bitmap = append(bm.bitmap, make([]C.uint8_t, 
ibit+1-len(bm.bitmap))...)
+   }
+
+   bm.bitmap[ibit] |= 1 << (uint(bit) & 7)
+}
+
+func (bm *Bitmap) SetRange(start int, end int) {
+   for i := start; i <= end; i++ {
+   bm.Set(i)
+   }
+}
+
+func (bm *Bitmap) Clear(bit int) {
+   ubit := uint(bit)
+   if bit > bm.Max() || bm.bitmap == nil {
+   return
+   }
+
+   bm.bitmap[bit/8] &= ^(1 << (ubit & 7))
+}
+
+func (bm *Bitmap) ClearRange(start int, end int) {
+   for i := start; i <= end; i++ {
+   bm.Clear(i)
+   }
+}
+
+func (bm *Bitmap) Max() int {
+   return len(bm.bitmap)*8 - 1
+}
+
+func (bm *Bitmap) IsEmpty() bool {
+   for i := 0; i < len(bm.bitmap); i++ {
+   if bm.bitmap[i] != 0 {
+   return false
+   }
+   }
+   return true
+}
+
+func (a Bitmap) And(b Bitmap) (c Bitmap) {
+   var max, min int
+   if len(a.bitmap) > len(b.bitmap) {
+   max = len(a.bitmap)
+   min = len(b.bitmap)
+   } else {
+   max = len(b.bitmap)
+   min = len(a.bitmap)
+   }
+   c.bitmap = make([]C.uint8_t, max)
+
+   for i := 0; i < min; i++ {
+   c.bitmap[i] = a.bitmap[i] & b.bitmap[i]
+   }
+   return
+}
+
+func (bm Bitmap) String() (s string) {
+   lastOnline := false
+   crange := false
+   printed := false
+   var i int
+   /// --x-x-x -> 2,4-8,10
+   /// --x-xxx -> 2,4-10
+   for i = 0; i <= bm.Max(); i++ {
+   if bm.Test(i) {
+   if !lastOnline {
+   // Switching offline -> online, print this cpu
+   if printed {
+   s += ","
+   }
+   s += fmt.Sprintf("%d", i)
+   printed = true
+   } else if !crange {
+   // last was online, but we're not in a range; 
print -
+   crange = true
+   s += "-"
+   

[Xen-devel] [PATCH v4 04/14] golang/xenlight: Implement libxl_domain_info and libxl_domain_unpause

[Ronald Rojas]

Add calls for the following host-related functionality:
- libxl_domain_info
- libxl_domain_unpause

Include Golang version for the libxl_domain_info as
DomainInfo.

Signed-off-by: George Dunlap 
Signed-off-by: Ronald Rojas 
---
Changes since last version

- Formating fixes

- used defer for libxl_dominfo_dispose

- Removed unnessary unsafe.Pointer() casts.

CC: xen-devel@lists.xen.org
CC: george.dun...@citrix.com
CC: ian.jack...@eu.citrix.com
CC: wei.l...@citrix.com

---
---
 tools/golang/xenlight/xenlight.go | 136 +-
 1 file changed, 133 insertions(+), 3 deletions(-)

diff --git a/tools/golang/xenlight/xenlight.go 
b/tools/golang/xenlight/xenlight.go
index 785eaaf..34c3050 100644
--- a/tools/golang/xenlight/xenlight.go
+++ b/tools/golang/xenlight/xenlight.go
@@ -33,6 +33,7 @@ import "C"
 
 import (
"fmt"
+   "time"
"unsafe"
 )
 
@@ -102,13 +103,19 @@ var errors = [...]string{
  * Types: Builtins
  */
 
+type Domid uint32
+
+type MemKB uint64
+
+type Uuid C.libxl_uuid
+
 type Context struct {
ctx *C.libxl_ctx
 }
 
 type Hwcap []C.uint32_t
 
-func (chwcap C.libxl_hwcap) CToGo() (ghwcap Hwcap) {
+func (chwcap C.libxl_hwcap) toGo() (ghwcap Hwcap) {
// Alloc a Go slice for the bytes
size := 8
ghwcap = make([]C.uint32_t, size)
@@ -161,7 +168,7 @@ func (cphys *C.libxl_physinfo) toGo() (physinfo *Physinfo) {
physinfo.SharingFreedPages = uint64(cphys.sharing_freed_pages)
physinfo.SharingUsedFrames = uint64(cphys.sharing_used_frames)
physinfo.NrNodes = uint32(cphys.nr_nodes)
-   physinfo.HwCap = cphys.hw_cap.CToGo()
+   physinfo.HwCap = cphys.hw_cap.toGo()
physinfo.CapHvm = bool(cphys.cap_hvm)
physinfo.CapHvmDirectio = bool(cphys.cap_hvm_directio)
 
@@ -203,6 +210,93 @@ func (cinfo *C.libxl_version_info) toGo() (info 
*VersionInfo) {
return
 }
 
+type ShutdownReason int32
+
+const (
+   ShutdownReasonUnknown   = 
ShutdownReason(C.LIBXL_SHUTDOWN_REASON_UNKNOWN)
+   ShutdownReasonPoweroff  = 
ShutdownReason(C.LIBXL_SHUTDOWN_REASON_POWEROFF)
+   ShutdownReasonReboot= ShutdownReason(C.LIBXL_SHUTDOWN_REASON_REBOOT)
+   ShutdownReasonSuspend   = 
ShutdownReason(C.LIBXL_SHUTDOWN_REASON_SUSPEND)
+   ShutdownReasonCrash = ShutdownReason(C.LIBXL_SHUTDOWN_REASON_CRASH)
+   ShutdownReasonWatchdog  = 
ShutdownReason(C.LIBXL_SHUTDOWN_REASON_WATCHDOG)
+   ShutdownReasonSoftReset = 
ShutdownReason(C.LIBXL_SHUTDOWN_REASON_SOFT_RESET)
+)
+
+func (sr ShutdownReason) String() (str string) {
+   cstr := C.libxl_shutdown_reason_to_string(C.libxl_shutdown_reason(sr))
+   str = C.GoString(cstr)
+
+   return
+}
+
+type DomainType int32
+
+const (
+   DomainTypeInvalid = DomainType(C.LIBXL_DOMAIN_TYPE_INVALID)
+   DomainTypeHvm = DomainType(C.LIBXL_DOMAIN_TYPE_HVM)
+   DomainTypePv  = DomainType(C.LIBXL_DOMAIN_TYPE_PV)
+)
+
+func (dt DomainType) String() (str string) {
+   cstr := C.libxl_domain_type_to_string(C.libxl_domain_type(dt))
+   str = C.GoString(cstr)
+
+   return
+}
+
+type Dominfo struct {
+   Uuid  Uuid
+   Domid Domid
+   Ssidref   uint32
+   SsidLabel string
+   Running   bool
+   Blocked   bool
+   Pausedbool
+   Shutdown  bool
+   Dying bool
+   NeverStop bool
+
+   ShutdownReason   int32
+   OutstandingMemkb MemKB
+   CurrentMemkb MemKB
+   SharedMemkb  MemKB
+   PagedMemkb   MemKB
+   MaxMemkb MemKB
+   CpuTime  time.Duration
+   VcpuMaxIduint32
+   VcpuOnline   uint32
+   Cpupool  uint32
+   DomainType   int32
+}
+
+func (cdi *C.libxl_dominfo) toGo() (di *Dominfo) {
+
+   di = {}
+   di.Uuid = Uuid(cdi.uuid)
+   di.Domid = Domid(cdi.domid)
+   di.Ssidref = uint32(cdi.ssidref)
+   di.SsidLabel = C.GoString(cdi.ssid_label)
+   di.Running = bool(cdi.running)
+   di.Blocked = bool(cdi.blocked)
+   di.Paused = bool(cdi.paused)
+   di.Shutdown = bool(cdi.shutdown)
+   di.Dying = bool(cdi.dying)
+   di.NeverStop = bool(cdi.never_stop)
+   di.ShutdownReason = int32(cdi.shutdown_reason)
+   di.OutstandingMemkb = MemKB(cdi.outstanding_memkb)
+   di.CurrentMemkb = MemKB(cdi.current_memkb)
+   di.SharedMemkb = MemKB(cdi.shared_memkb)
+   di.PagedMemkb = MemKB(cdi.paged_memkb)
+   di.MaxMemkb = MemKB(cdi.max_memkb)
+   di.CpuTime = time.Duration(cdi.cpu_time)
+   di.VcpuMaxId = uint32(cdi.vcpu_max_id)
+   di.VcpuOnline = uint32(cdi.vcpu_online)
+   di.Cpupool = uint32(cdi.cpupool)
+   di.DomainType = int32(cdi.domain_type)
+
+   return
+}
+
 /*
  * Context
  */
@@ -332,6 +426,7 @@ func (Ctx *Context) GetPhysinfo() (physinfo *Physinfo, err 
error) {
}
var cphys C.libxl_physinfo
C.libxl_physinfo_init()
+   

[Xen-devel] [PATCH v4 01/14] golang/xenlight: Create stub package

[Ronald Rojas]

Create a basic Makefile to build and install libxenlight Golang
bindings. Also add a stub package which only opens libxl context.

Include a global xenlight.Ctx variable which can be used as the
default context by the entire program if desired.

For now, return simple errors. Proper error handling will be
added in next patch.

Signed-off-by: Ronald Rojas 
Signed-off-by: George Dunlap 
---

Changes:

- Added global logger variable and destroyed the logger instance
when closing the context.

- Whitespace fixes

- Commented out CONFIG_GOLANG

CC: xen-devel@lists.xen.org
CC: george.dun...@citrix.com
CC: ian.jack...@eu.citrix.com
CC: wei.l...@citrix.com
---
---
 tools/Makefile|  1 +
 tools/Rules.mk|  7 
 tools/golang/Makefile | 27 
 tools/golang/xenlight/Makefile| 49 ++
 tools/golang/xenlight/xenlight.go | 88 +++
 5 files changed, 172 insertions(+)
 create mode 100644 tools/golang/Makefile
 create mode 100644 tools/golang/xenlight/Makefile
 create mode 100644 tools/golang/xenlight/xenlight.go

diff --git a/tools/Makefile b/tools/Makefile
index 77e0723..df1fda1 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -31,6 +31,7 @@ endif
 
 SUBDIRS-y += xenpmd
 SUBDIRS-y += libxl
+SUBDIRS-$(CONFIG_GOLANG) += golang
 SUBDIRS-y += helpers
 SUBDIRS-$(CONFIG_X86) += xenpaging
 SUBDIRS-$(CONFIG_X86) += debugger/gdbsx
diff --git a/tools/Rules.mk b/tools/Rules.mk
index b35999b..4edffbe 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -30,6 +30,13 @@ XENSTORE_XENSTORED ?= y
 debug ?= y
 debug_symbols ?= $(debug)
 
+# Uncomment to compile with Go
+#CONFIG_GOLANG ?= y
+ifeq ($(CONFIG_GOLANG),y)
+XEN_GOPATH= $(XEN_ROOT)/tools/golang
+XEN_GOCODE_URL= golang.xenproject.org
+endif
+
 ifeq ($(debug_symbols),y)
 CFLAGS += -g3
 endif
diff --git a/tools/golang/Makefile b/tools/golang/Makefile
new file mode 100644
index 000..47a9235
--- /dev/null
+++ b/tools/golang/Makefile
@@ -0,0 +1,27 @@
+XEN_ROOT=$(CURDIR)/../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+# In order to link against a package in Go, the package must live in a
+# directory tree in the way that Go expects.  To make this possible,
+# there must be a directory such that we can set GOPATH=${dir}, and
+# the package will be under $GOPATH/src/${full-package-path}.
+
+# So we set XEN_GOPATH to $XEN_ROOT/tools/golang.  The xenlight
+# "package build" directory ($PWD/xenlight) will create the "package
+# source" directory in the proper place.  Go programs can use this
+# package by setting GOPATH=$(XEN_GOPATH).
+
+SUBDIRS-y = xenlight
+
+.PHONY: build all
+all build: subdirs-all
+
+.PHONY: install
+install: subdirs-install
+
+.PHONY: clean
+clean: subdirs-clean
+   $(RM) -r src pkg
+
+.PHONY: distclean
+distclean: clean
diff --git a/tools/golang/xenlight/Makefile b/tools/golang/xenlight/Makefile
new file mode 100644
index 000..5db665d
--- /dev/null
+++ b/tools/golang/xenlight/Makefile
@@ -0,0 +1,49 @@
+XEN_ROOT=$(CURDIR)/../../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+# Standing boldly against convention, we insist on installing the
+# package source under $(prefix)/share/gocode
+GOCODE_DIR ?= $(prefix)/share/gocode/
+GOXL_PKG_DIR = /src/$(XEN_GOCODE_URL)/xenlight/
+GOXL_INSTALL_DIR = $(GOCODE_DIR)$(GOXL_PKG_DIR)
+
+# PKGSOURCES: Files which comprise the distributed source package
+PKGSOURCES = xenlight.go
+
+GO ?= go
+
+.PHONY: all
+all: build
+
+.PHONY: package
+package: $(XEN_GOPATH)$(GOXL_PKG_DIR)$(PKGSOURCES)
+
+$(XEN_GOPATH)/src/$(XEN_GOCODE_URL)/xenlight/$(PKGSOURCES): $(PKGSOURCES)
+   $(INSTALL_DIR) $(XEN_GOPATH)$(GOXL_PKG_DIR)
+   $(INSTALL_DATA) $(PKGSOURCES) $(XEN_GOPATH)$(GOXL_PKG_DIR)
+
+# Go will do its own dependency checking, and not actuall go through
+# with the build if none of the input files have changed.
+#
+# NB that because the users of this library need to be able to
+# recompile the library from source, it needs to include '-lxenlight'
+# in the LDFLAGS; and thus we need to add -L$(XEN_XENLIGHT) here
+# so that it can find the actual library.
+.PHONY: build
+build: package
+   CGO_CFLAGS="$(CFLAGS_libxenlight) $(CFLAGS_libxentoollog)" 
CGO_LDFLAGS="$(LDLIBS_libxenlight) $(LDLIBS_libxentoollog)-L$(XEN_XENLIGHT) 
-L$(XEN_LIBXENTOOLLOG)" GOPATH=$(XEN_GOPATH) $(GO) install -x 
$(XEN_GOCODE_URL)/xenlight
+
+.PHONY: install
+install: build
+   $(INSTALL_DIR) $(DESTDIR)$(GOXL_INSTALL_DIR)
+   $(INSTALL_DATA) $(XEN_GOPATH)$(GOXL_PKG_DIR)$(PKGSOURCES) 
$(DESTDIR)$(GOXL_INSTALL_DIR)
+
+.PHONY: clean
+clean:
+   $(RM) -r $(XEN_GOPATH)$(GOXL_PKG_DIR)
+   $(RM) $(XEN_GOPATH)/pkg/*/$(XEN_GOCODE_URL)/xenlight.a
+
+.PHONY: distclean
+distclean: clean
+
+-include $(DEPS)
diff --git a/tools/golang/xenlight/xenlight.go 
b/tools/golang/xenlight/xenlight.go
new file mode 100644
index 000..b025961
--- /dev/null
+++ 

[Xen-devel] [PATCH v4 02/14] golang/xenlight: Add error constants and standard handling

[Ronald Rojas]

Create error type Errorxl for throwing proper xenlight
errors.

Update Ctx functions to throw Errorxl errors.

Signed-off-by: Ronald Rojas 
---

CC: xen-devel@lists.xen.org
CC: george.dun...@citrix.com
CC: ian.jack...@eu.citrix.com
CC: wei.l...@citrix.com
---
---
 tools/golang/xenlight/xenlight.go | 78 ++-
 1 file changed, 76 insertions(+), 2 deletions(-)

diff --git a/tools/golang/xenlight/xenlight.go 
b/tools/golang/xenlight/xenlight.go
index b025961..a99d9d3 100644
--- a/tools/golang/xenlight/xenlight.go
+++ b/tools/golang/xenlight/xenlight.go
@@ -37,8 +37,71 @@ import (
 )
 
 /*
+ * Errors
+ */
+
+type Error int
+
+const (
+   ErrorNonspecific  = Error(-C.ERROR_NONSPECIFIC)
+   ErrorVersion  = Error(-C.ERROR_VERSION)
+   ErrorFail = Error(-C.ERROR_FAIL)
+   ErrorNi   = Error(-C.ERROR_NI)
+   ErrorNomem= Error(-C.ERROR_NOMEM)
+   ErrorInval= Error(-C.ERROR_INVAL)
+   ErrorBadfail  = Error(-C.ERROR_BADFAIL)
+   ErrorGuestTimedout= Error(-C.ERROR_GUEST_TIMEDOUT)
+   ErrorTimedout = Error(-C.ERROR_TIMEDOUT)
+   ErrorNoparavirt   = Error(-C.ERROR_NOPARAVIRT)
+   ErrorNotReady = Error(-C.ERROR_NOT_READY)
+   ErrorOseventRegFail   = Error(-C.ERROR_OSEVENT_REG_FAIL)
+   ErrorBufferfull   = Error(-C.ERROR_BUFFERFULL)
+   ErrorUnknownChild = Error(-C.ERROR_UNKNOWN_CHILD)
+   ErrorLockFail = Error(-C.ERROR_LOCK_FAIL)
+   ErrorJsonConfigEmpty  = Error(-C.ERROR_JSON_CONFIG_EMPTY)
+   ErrorDeviceExists = Error(-C.ERROR_DEVICE_EXISTS)
+   ErrorCheckpointDevopsDoesNotMatch = 
Error(-C.ERROR_CHECKPOINT_DEVOPS_DOES_NOT_MATCH)
+   ErrorCheckpointDeviceNotSupported = 
Error(-C.ERROR_CHECKPOINT_DEVICE_NOT_SUPPORTED)
+   ErrorVnumaConfigInvalid   = Error(-C.ERROR_VNUMA_CONFIG_INVALID)
+   ErrorDomainNotfound   = Error(-C.ERROR_DOMAIN_NOTFOUND)
+   ErrorAborted  = Error(-C.ERROR_ABORTED)
+   ErrorNotfound = Error(-C.ERROR_NOTFOUND)
+   ErrorDomainDestroyed  = Error(-C.ERROR_DOMAIN_DESTROYED)
+   ErrorFeatureRemoved   = Error(-C.ERROR_FEATURE_REMOVED)
+)
+
+var errors = [...]string{
+   ErrorNonspecific:  "Non-specific error",
+   ErrorVersion:  "Wrong version",
+   ErrorFail: "Failed",
+   ErrorNi:   "Not Implemented",
+   ErrorNomem:"No memory",
+   ErrorInval:"Invalid argument",
+   ErrorBadfail:  "Bad Fail",
+   ErrorGuestTimedout:"Guest timed out",
+   ErrorTimedout: "Timed out",
+   ErrorNoparavirt:   "No Paravirtualization",
+   ErrorNotReady: "Not ready",
+   ErrorOseventRegFail:   "OS event registration failed",
+   ErrorBufferfull:   "Buffer full",
+   ErrorUnknownChild: "Unknown child",
+   ErrorLockFail: "Lock failed",
+   ErrorJsonConfigEmpty:  "JSON config empty",
+   ErrorDeviceExists: "Device exists",
+   ErrorCheckpointDevopsDoesNotMatch: "Checkpoint devops does not match",
+   ErrorCheckpointDeviceNotSupported: "Checkpoint device not supported",
+   ErrorVnumaConfigInvalid:   "VNUMA config invalid",
+   ErrorDomainNotfound:   "Domain not found",
+   ErrorAborted:  "Aborted",
+   ErrorNotfound: "Not found",
+   ErrorDomainDestroyed:  "Domain destroyed",
+   ErrorFeatureRemoved:   "Feature removed",
+}
+
+/*
  * Types: Builtins
  */
+
 type Context struct {
ctx *C.libxl_ctx
 }
@@ -50,6 +113,17 @@ var Ctx Context
 
 var logger *C.xentoollog_logger_stdiostream
 
+func (e Error) Error() string {
+   if 0 < int(e) && int(e) < len(errors) {
+   s := errors[e]
+   if s != "" {
+   return s
+   }
+   }
+   return fmt.Sprintf("libxl error: %d", -e)
+
+}
+
 func (Ctx *Context) IsOpen() bool {
return Ctx.ctx != nil
 }
@@ -64,7 +138,7 @@ func (Ctx *Context) Open() (err error) {
0, unsafe.Pointer(logger))
 
if ret != 0 {
-   err = fmt.Errorf("Error: %d", -ret)
+   err = Error(-ret)
}
return
 }
@@ -74,7 +148,7 @@ func (Ctx *Context) Close() (err error) {
Ctx.ctx = nil
 
if ret != 0 {
-   err = fmt.Errorf("Error: 

Re: [Xen-devel] [PATCH v2 2/4] x86: split PV dom0 builder to pv/dom0_builder.c

[Wei Liu]

On Thu, Mar 16, 2017 at 06:15:01PM +, Andrew Cooper wrote:
> On 16/03/17 18:12, Roger Pau Monné wrote:
> > On Thu, Mar 16, 2017 at 05:54:56PM +, Wei Liu wrote:
> > [...]
> >> +/*
> >> + * PVH Fixme: XENFEAT_supervisor_mode_kernel has been reused in PVH 
> >> with a
> >> + * different meaning.
> > Crap, I've forgot to remove this PVH fixme!
> 
> And
> 
> andrewcoop@andrewcoop:/local/xen.git/xen$ git grep -l has_hvm_container
> -- :/
> ../docs/designs/dmop.markdown
> include/xen/sched.h
> 
> if you are feeling like fixing up other stray bits :)
> 

There are two more "PVH fixme" in code. I think I will write another
series to remove all the stale bits.

Wei.

> ~Andrew

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

[Xen-devel] [xen-unstable test] 106711: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail REGR. vs. 
106652

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-rumprun-amd64 16 rumprun-demo-xenstorels/xenstorels.repeat 
fail in 106698 pass in 106711
 test-amd64-amd64-migrupgrade  8 xen-install/dst_host   fail pass in 106698
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat  fail pass in 106698

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 106642
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 106652
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106652
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 106652
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 106652
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 106652
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 106652
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 106652

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 build-arm64   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-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-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-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-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 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
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 xen  bfd9a2095f1882e8c074b2d911bcb07d12cf6cf5
baseline version:
 xen  bd8ad2a52aba4911ada897c72f8795172a09a193

Last test of basis   106652  2017-03-14 08:24:37 Z2 days
Failing since106671  2017-03-14 20:44:11 Z1 days3 attempts
Testing same since   106698  2017-03-15 17:48:34 Z1 

Re: [Xen-devel] [PATCH] common/mem_access: merged mem_access setting interfaces

[Razvan Cojocaru]

On 03/16/2017 08:10 PM, Tamas K Lengyel wrote:
> 
> 
> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> index 6eee0c8..ca53a0c 100644
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -444,6 +444,8 @@ struct xen_mem_access_op {
>  /* xenmem_access_t */
>  uint8_t access;
>  domid_t domid;
> +uint16_t view_id;
> +uint16_t pad;
> 
> 
> I think this will mess with the next uint32_t struct member, so either
> this pad should be uint16_t pad[3], or another pad needs to be added
> after the following uint32_t nr.

Fair enough, I'll need to send V2 anyway as Roger's "x86: remove PVHv1
code" has also bumped XEN_DOMCTL_INTERFACE_VERSION and I now need to
take it out.


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH] common/mem_access: merged mem_access setting interfaces

[Tamas K Lengyel]

On Thu, Mar 16, 2017 at 12:33 PM, Razvan Cojocaru  wrote:

> On 03/16/2017 08:10 PM, Tamas K Lengyel wrote:
> >
> >
> > diff --git a/xen/include/public/memory.h
> b/xen/include/public/memory.h
> > index 6eee0c8..ca53a0c 100644
> > --- a/xen/include/public/memory.h
> > +++ b/xen/include/public/memory.h
> > @@ -444,6 +444,8 @@ struct xen_mem_access_op {
> >  /* xenmem_access_t */
> >  uint8_t access;
> >  domid_t domid;
> > +uint16_t view_id;
> > +uint16_t pad;
> >
> >
> > I think this will mess with the next uint32_t struct member, so either
> > this pad should be uint16_t pad[3], or another pad needs to be added
> > after the following uint32_t nr.
>
> Fair enough, I'll need to send V2 anyway as Roger's "x86: remove PVHv1
> code" has also bumped XEN_DOMCTL_INTERFACE_VERSION and I now need to
> take it out.
>

Sounds good. The patch looks good to me otherwise.

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

Re: [Xen-devel] [PATCH v1 3/3] x86/vvmx: add a shadow vmcs check to vmlaunch

[Krish Sadhukhan]

Acknowledging it formally...

Reviewed-by: Krish Sadhukhan 

The review was based on Intel SDM chapters 24 and 30.

-Krish

On 03/16/2017 11:24 AM, Krish Sadhukhan wrote:

This one looks good to me.

-Krish

On 03/13/2017 03:51 AM, Sergey Dyasli wrote:

Intel SDM states that if the current VMCS is a shadow VMCS,
VMFailInvalid occurs and control passes to the next instruction.

Implement such behaviour for nested vmlaunch.

Signed-off-by: Sergey Dyasli 
---
  xen/arch/x86/hvm/vmx/vvmx.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 3017849..173ec74 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -1630,6 +1630,13 @@ int nvmx_handle_vmlaunch(struct cpu_user_regs 
*regs)

  return X86EMUL_OKAY;
  }
  +/* Check that guest is not using a shadow vmcs for vmentry */
+if ( nvmx->shadow_vmcs )
+{
+vmfail_invalid(regs);
+return X86EMUL_OKAY;
+}
+
  __vmread(GUEST_INTERRUPTIBILITY_INFO, _shadow);
  if ( intr_shadow & VMX_INTR_SHADOW_MOV_SS )
  {



___
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 v1 3/3] x86/vvmx: add a shadow vmcs check to vmlaunch

[Krish Sadhukhan]

This one looks good to me.

-Krish

On 03/13/2017 03:51 AM, Sergey Dyasli wrote:

Intel SDM states that if the current VMCS is a shadow VMCS,
VMFailInvalid occurs and control passes to the next instruction.

Implement such behaviour for nested vmlaunch.

Signed-off-by: Sergey Dyasli 
---
  xen/arch/x86/hvm/vmx/vvmx.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 3017849..173ec74 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -1630,6 +1630,13 @@ int nvmx_handle_vmlaunch(struct cpu_user_regs *regs)
  return X86EMUL_OKAY;
  }
  
+/* Check that guest is not using a shadow vmcs for vmentry */

+if ( nvmx->shadow_vmcs )
+{
+vmfail_invalid(regs);
+return X86EMUL_OKAY;
+}
+
  __vmread(GUEST_INTERRUPTIBILITY_INFO, _shadow);
  if ( intr_shadow & VMX_INTR_SHADOW_MOV_SS )
  {



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

Re: [Xen-devel] [PATCH v1 1/3] x86/vvmx: add mov-ss blocking check to vmentry

[Krish Sadhukhan]

The Intel SDM also mentions POP-SS. Are you planning to do it via 
another patch ?


Also, I was wondering if it makes more sense to rename the new enum code as

VMX_INSN_VMENTRY_BLOCKED

since it can then also be used for POP-SS.


-Krish

On 03/13/2017 03:51 AM, Sergey Dyasli wrote:

Intel SDM states that if there is a current VMCS and there is MOV-SS
blocking, VMFailValid occurs and control passes to the next instruction.

Implement such behaviour for nested vmlaunch and vmresume.

Signed-off-by: Sergey Dyasli 
---
  xen/arch/x86/hvm/vmx/vvmx.c| 16 
  xen/include/asm-x86/hvm/vmx/vmcs.h |  1 +
  2 files changed, 17 insertions(+)

diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index e2c0951..09e4250 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -1572,6 +1572,7 @@ int nvmx_handle_vmresume(struct cpu_user_regs *regs)
  bool_t launched;
  struct vcpu *v = current;
  struct nestedvmx *nvmx = _2_nvmx(v);
+unsigned long intr_shadow;
  int rc = vmx_inst_check_privilege(regs, 0);
  
  if ( rc != X86EMUL_OKAY )

@@ -1583,6 +1584,13 @@ int nvmx_handle_vmresume(struct cpu_user_regs *regs)
  return X86EMUL_OKAY;
  }
  
+__vmread(GUEST_INTERRUPTIBILITY_INFO, _shadow);

+if ( intr_shadow & VMX_INTR_SHADOW_MOV_SS )
+{
+vmfail_valid(regs, VMX_INSN_VMENTRY_BLOCKED_BY_MOV_SS);
+return X86EMUL_OKAY;
+}
+
  launched = vvmcs_launched(>launched_list,
PFN_DOWN(v->arch.hvm_vmx.vmcs_shadow_maddr));
  if ( !launched )
@@ -1598,6 +1606,7 @@ int nvmx_handle_vmlaunch(struct cpu_user_regs *regs)
  bool_t launched;
  struct vcpu *v = current;
  struct nestedvmx *nvmx = _2_nvmx(v);
+unsigned long intr_shadow;
  int rc = vmx_inst_check_privilege(regs, 0);
  
  if ( rc != X86EMUL_OKAY )

@@ -1609,6 +1618,13 @@ int nvmx_handle_vmlaunch(struct cpu_user_regs *regs)
  return X86EMUL_OKAY;
  }
  
+__vmread(GUEST_INTERRUPTIBILITY_INFO, _shadow);

+if ( intr_shadow & VMX_INTR_SHADOW_MOV_SS )
+{
+vmfail_valid(regs, VMX_INSN_VMENTRY_BLOCKED_BY_MOV_SS);
+return X86EMUL_OKAY;
+}
+
  launched = vvmcs_launched(>launched_list,
PFN_DOWN(v->arch.hvm_vmx.vmcs_shadow_maddr));
  if ( launched )
diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h 
b/xen/include/asm-x86/hvm/vmx/vmcs.h
index f465fff..dc5d91f 100644
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -515,6 +515,7 @@ enum vmx_insn_errno
  VMX_INSN_VMPTRLD_INCORRECT_VMCS_ID = 11,
  VMX_INSN_UNSUPPORTED_VMCS_COMPONENT= 12,
  VMX_INSN_VMXON_IN_VMX_ROOT = 15,
+VMX_INSN_VMENTRY_BLOCKED_BY_MOV_SS = 26,
  VMX_INSN_FAIL_INVALID  = ~0,
  };
  



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

Re: [Xen-devel] [PATCH v2 3/4] x86: split PVH dom0 builder to hvm/dom0_build.c

[Wei Liu]

On Thu, Mar 16, 2017 at 06:16:26PM +, Roger Pau Monné wrote:
> On Thu, Mar 16, 2017 at 05:54:57PM +, Wei Liu wrote:
> [...]
> > diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
> > index c74f9b52e0..772f077d5a 100644
> > --- a/xen/arch/x86/dom0_build.c
> > +++ b/xen/arch/x86/dom0_build.c
> [...]
> > @@ -261,8 +240,8 @@ boolean_param("ro-hpet", ro_hpet);
> >  
> >  unsigned int __initdata dom0_memflags = MEMF_no_dma|MEMF_exact_node;
> >  
> > -static unsigned long __init dom0_paging_pages(const struct domain *d,
> > -  unsigned long nr_pages)
> > +unsigned long __init dom0_paging_pages(const struct domain *d,
> > +   unsigned long nr_pages)
> >  {
> >  /* Copied from: libxl_get_required_shadow_memory() */
> >  unsigned long memkb = nr_pages * (PAGE_SIZE / 1024);
> 
> Shouldn't this be moved to the PVH Dom0 file? AFAICT this is not used by the 
> PV
> Dom0, or else you would have made that global in the previous patch.
> 

It is needed by dom0_compute_nr_pages which is used by PV dom0 builder
and PVH dom0 builder, plus it is directly called by PVH dom0 builder.
It's best to leave it here.

> Roger.

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

Re: [Xen-devel] [PATCH v2 3/4] x86: split PVH dom0 builder to hvm/dom0_build.c

[Roger Pau Monné]

On Thu, Mar 16, 2017 at 05:54:57PM +, Wei Liu wrote:
[...]
> diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
> index c74f9b52e0..772f077d5a 100644
> --- a/xen/arch/x86/dom0_build.c
> +++ b/xen/arch/x86/dom0_build.c
[...]
> @@ -261,8 +240,8 @@ boolean_param("ro-hpet", ro_hpet);
>  
>  unsigned int __initdata dom0_memflags = MEMF_no_dma|MEMF_exact_node;
>  
> -static unsigned long __init dom0_paging_pages(const struct domain *d,
> -  unsigned long nr_pages)
> +unsigned long __init dom0_paging_pages(const struct domain *d,
> +   unsigned long nr_pages)
>  {
>  /* Copied from: libxl_get_required_shadow_memory() */
>  unsigned long memkb = nr_pages * (PAGE_SIZE / 1024);

Shouldn't this be moved to the PVH Dom0 file? AFAICT this is not used by the PV
Dom0, or else you would have made that global in the previous patch.

Roger.

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

Re: [Xen-devel] [PATCH v2 2/4] x86: split PV dom0 builder to pv/dom0_builder.c

[Andrew Cooper]

On 16/03/17 18:12, Roger Pau Monné wrote:
> On Thu, Mar 16, 2017 at 05:54:56PM +, Wei Liu wrote:
> [...]
>> +/*
>> + * PVH Fixme: XENFEAT_supervisor_mode_kernel has been reused in PVH 
>> with a
>> + * different meaning.
> Crap, I've forgot to remove this PVH fixme!

And

andrewcoop@andrewcoop:/local/xen.git/xen$ git grep -l has_hvm_container
-- :/
../docs/designs/dmop.markdown
include/xen/sched.h

if you are feeling like fixing up other stray bits :)

~Andrew

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

Re: [Xen-devel] [PATCH v2 2/4] x86: split PV dom0 builder to pv/dom0_builder.c

[Roger Pau Monné]

On Thu, Mar 16, 2017 at 05:54:56PM +, Wei Liu wrote:
[...]
> +/*
> + * PVH Fixme: XENFEAT_supervisor_mode_kernel has been reused in PVH with 
> a
> + * different meaning.

Crap, I've forgot to remove this PVH fixme!

[...]
> diff --git a/xen/include/asm-x86/dom0_build.h 
> b/xen/include/asm-x86/dom0_build.h
> new file mode 100644
> index 00..2ba349e445
> --- /dev/null
> +++ b/xen/include/asm-x86/dom0_build.h
> @@ -0,0 +1,32 @@
> +#ifndef _DOM0_BUILD_H_
> +#define _DOM0_BUILD_H_
> +
> +#include 
> +
> +extern unsigned int dom0_memflags;
> +extern cpumask_t dom0_cpus;
> +
> +unsigned long dom0_compute_nr_pages(
> +struct domain *d, struct elf_dom_parms *parms, unsigned long initrd_len);
> +struct vcpu *dom0_setup_vcpu(struct domain *d, unsigned int vcpu_id,
> +unsigned int cpu);
> +int dom0_setup_permissions(struct domain *d);
> +
> +int dom0_construct_pv(
> +struct domain *d,
> +const module_t *image, unsigned long image_headroom,
> +module_t *initrd,
> +void *(*bootstrap_map)(const module_t *),
> +char *cmdline);

Since this is kind of new code, could you fix the indentation of the
prototypes?

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

Re: [Xen-devel] [PATCH v2 2/4] x86: split PV dom0 builder to pv/dom0_builder.c

[Wei Liu]

On Thu, Mar 16, 2017 at 06:12:08PM +, Roger Pau Monné wrote:
> On Thu, Mar 16, 2017 at 05:54:56PM +, Wei Liu wrote:
> [...]
> > +/*
> > + * PVH Fixme: XENFEAT_supervisor_mode_kernel has been reused in PVH 
> > with a
> > + * different meaning.
> 
> Crap, I've forgot to remove this PVH fixme!

Don't worry, I will take care of it.

> 
> [...]
> > diff --git a/xen/include/asm-x86/dom0_build.h 
> > b/xen/include/asm-x86/dom0_build.h
> > new file mode 100644
> > index 00..2ba349e445
> > --- /dev/null
> > +++ b/xen/include/asm-x86/dom0_build.h
> > @@ -0,0 +1,32 @@
> > +#ifndef _DOM0_BUILD_H_
> > +#define _DOM0_BUILD_H_
> > +
> > +#include 
> > +
> > +extern unsigned int dom0_memflags;
> > +extern cpumask_t dom0_cpus;
> > +
> > +unsigned long dom0_compute_nr_pages(
> > +struct domain *d, struct elf_dom_parms *parms, unsigned long 
> > initrd_len);
> > +struct vcpu *dom0_setup_vcpu(struct domain *d, unsigned int vcpu_id,
> > +unsigned int cpu);
> > +int dom0_setup_permissions(struct domain *d);
> > +
> > +int dom0_construct_pv(
> > +struct domain *d,
> > +const module_t *image, unsigned long image_headroom,
> > +module_t *initrd,
> > +void *(*bootstrap_map)(const module_t *),
> > +char *cmdline);
> 
> Since this is kind of new code, could you fix the indentation of the
> prototypes?

Sure. I also notice there is something wrong with the indentation of
dom0_setup_vcpu. I will fix them.

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

Re: [Xen-devel] [PATCH] common/mem_access: merged mem_access setting interfaces

[Tamas K Lengyel]

diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> index 6eee0c8..ca53a0c 100644
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -444,6 +444,8 @@ struct xen_mem_access_op {
>  /* xenmem_access_t */
>  uint8_t access;
>  domid_t domid;
> +uint16_t view_id;
> +uint16_t pad;
>

I think this will mess with the next uint32_t struct member, so either this
pad should be uint16_t pad[3], or another pad needs to be added after the
following uint32_t nr.


>  /*
>   * Number of pages for set op (or size of pfn_list for
>   * XENMEM_access_op_set_access_multi)
> --
> 1.9.1
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 4/7] xen/9pfs: connect to the backend

[Stefano Stabellini]

On Thu, 16 Mar 2017, Juergen Gross wrote:
> On 15/03/17 20:23, Stefano Stabellini wrote:
> > Implement functions to handle the xenbus handshake. Upon connection,
> > allocate the rings according to the protocol specification.
> > 
> > Initialize a work_struct and a wait_queue. The work_struct will be used
> > to schedule work upon receiving an event channel notification from the
> > backend. The wait_queue will be used to wait when the ring is full and
> > we need to send a new request.
> > 
> > Signed-off-by: Stefano Stabellini 
> > CC: gr...@kaod.org
> > CC: boris.ostrov...@oracle.com
> > CC: jgr...@suse.com
> > CC: Eric Van Hensbergen 
> > CC: Ron Minnich 
> > CC: Latchesar Ionkov 
> > CC: v9fs-develo...@lists.sourceforge.net
> > ---
> >  net/9p/trans_xen.c | 248 
> > +
> >  1 file changed, 248 insertions(+)
> > 
> > diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
> > index b1333b2..ada2b0c 100644
> > --- a/net/9p/trans_xen.c
> > +++ b/net/9p/trans_xen.c
> >  static int xen_9pfs_front_probe(struct xenbus_device *dev,
> > const struct xenbus_device_id *id)
> >  {
> > +   int ret, i;
> > +   struct xenbus_transaction xbt;
> > +   struct xen_9pfs_front_priv *priv = NULL;
> > +   char *versions;
> > +   unsigned int max_rings, max_ring_order, len;
> > +
> > +   versions = xenbus_read(XBT_NIL, dev->otherend, "versions", );
> > +   if (!len)
> > +   return -EINVAL;
> > +   if (strcmp(versions, "1")) {
> > +   kfree(versions);
> > +   return -EINVAL;
> > +   }
> > +   kfree(versions);
> > +   max_rings = xenbus_read_unsigned(dev->otherend, "max-rings", 0);
> > +   if (max_rings < XEN_9PFS_NUM_RINGS)
> > +   return -EINVAL;
> > +   max_ring_order = xenbus_read_unsigned(dev->otherend, 
> > "max-ring-page-order", 0);
> > +   if (max_ring_order < XEN_9PFS_RING_ORDER)
> > +   return -EINVAL;
> > +
> > +
> > +   priv = kzalloc(sizeof(struct xen_9pfs_front_priv), GFP_KERNEL);
> > +   if (!priv)
> > +   return -ENOMEM;
> > +
> > +   priv->dev = dev;
> > +   priv->num_rings = XEN_9PFS_NUM_RINGS;
> > +   priv->rings = kzalloc(sizeof(struct xen_9pfs_dataring) * 
> > priv->num_rings,
> > + GFP_KERNEL);
> > +   if (!priv->rings) {
> > +   kfree(priv);
> > +   return -ENOMEM;
> > +   }
> > +
> > +   for (i = 0; i < priv->num_rings; i++) {
> > +   priv->rings[i].priv = priv;
> > +   ret = xen_9pfs_front_alloc_dataring(dev, >rings[i]);
> > +   if (ret < 0)
> > +   goto error;
> > +   }
> > +
> > + again:
> > +   ret = xenbus_transaction_start();
> > +   if (ret) {
> > +   xenbus_dev_fatal(dev, ret, "starting transaction");
> > +   goto error;
> > +   }
> > +   ret = xenbus_printf(xbt, dev->nodename, "version", "%u", 1);
> > +   if (ret)
> > +   goto error_xenbus;
> > +   ret = xenbus_printf(xbt, dev->nodename, "num-rings", "%u", 
> > priv->num_rings);
> > +   if (ret)
> > +   goto error_xenbus;
> > +   for (i = 0; i < priv->num_rings; i++) {
> > +   char str[16];
> > +
> > +   BUILD_BUG_ON(XEN_9PFS_NUM_RINGS > 9);
> > +   sprintf(str, "ring-ref%u", i);
> > +   ret = xenbus_printf(xbt, dev->nodename, str, "%d", 
> > priv->rings[i].ref);
> > +   if (ret)
> > +   goto error_xenbus;
> > +
> > +   sprintf(str, "event-channel-%u", i);
> > +   ret = xenbus_printf(xbt, dev->nodename, str, "%u", 
> > priv->rings[i].evtchn);
> > +   if (ret)
> > +   goto error_xenbus;
> > +   }
> > +   priv->tag = xenbus_read(xbt, dev->nodename, "tag", NULL);
> > +   if (ret)
> > +   goto error_xenbus;
> 
> Shouldn't you test priv->tag instead?

well spotted, thanks!

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

Re: [Xen-devel] [PATCH v3 4/7] xen/9pfs: connect to the backend

[Stefano Stabellini]

On Thu, 16 Mar 2017, Juergen Gross wrote:
> On 15/03/17 19:44, Stefano Stabellini wrote:
> > On Wed, 15 Mar 2017, Juergen Gross wrote:
> >> On 14/03/17 22:22, Stefano Stabellini wrote:
> >>> Hi Juergen,
> >>>
> >>> thank you for the review!
> >>>
> >>> On Tue, 14 Mar 2017, Juergen Gross wrote:
>  On 14/03/17 00:50, Stefano Stabellini wrote:
> > Implement functions to handle the xenbus handshake. Upon connection,
> > allocate the rings according to the protocol specification.
> >
> > Initialize a work_struct and a wait_queue. The work_struct will be used
> > to schedule work upon receiving an event channel notification from the
> > backend. The wait_queue will be used to wait when the ring is full and
> > we need to send a new request.
> >
> > Signed-off-by: Stefano Stabellini 
> > CC: boris.ostrov...@oracle.com
> > CC: jgr...@suse.com
> > CC: Eric Van Hensbergen 
> > CC: Ron Minnich 
> > CC: Latchesar Ionkov 
> > CC: v9fs-develo...@lists.sourceforge.net
> > ---
> >>
>  Did you think about using request_threaded_irq() instead of a workqueue?
>  For an example see e.g. drivers/scsi/xen-scsifront.c
> >>>
> >>> I like workqueues :-)  It might come down to personal preferences, but I
> >>> think workqueues are more flexible and a better fit for this use case.
> >>> Not only it is easy to schedule work in a workqueue from the interrupt
> >>> handler, but also they can be used for sleeping in the request function
> >>> if there is not enough room on the ring. Besides, they can easily be
> >>> configured to share a single thread or to have multiple independent
> >>> threads.
> >>
> >> I'm fine with the workqueues as long as you have decided to use them
> >> considering the alternatives. :-)
> >>
>  Can't you use xenbus_read_unsigned() instead of xenbus_read()?
> >>>
> >>> I can use xenbus_read_unsigned in the other cases below, but not here,
> >>> because versions is in the form: "1,3,4"
> >>
> >> Is this documented somewhere?
> >>
> >> Hmm, are any of the Xenstore entries documented? Shouldn't this be done
> >> in xen_9pfs.h ?
> >  
> > They are documented in docs/misc/9pfs.markdown, under "Xenstore". Given
> > that it's all written there, especially the semantics, I didn't repeat
> > it in xen_9pfs.h
> 
> Looking at it from the Linux kernel perspective this documentation is
> not really highly visible. For me it is okay, but there have been
> multiple examples in the past where documentation in the Xen repository
> wasn't regarded as being sufficient.
> 
> I recommend moving the documentation regarding the interface into the
> header file like for the other pv interfaces.

What about adding a link such as:

http://xenbits.xen.org/gitweb/?p=xen.git;a=blob_plain;f=docs/misc/9pfs.markdown;hb=HEAD

that should be easily accessible, right? For other specifications, such
as 9p, only links are provided (see Documentation/filesystems/9p.txt).
I am suggesting a link, because then we are sure the specs don't go out
of sync. I realize that older PV protocols were described in header
files, but that was before Xen Project had a formal process for getting
new specifications accepted, and a formal place where to publish them.

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

Re: [Xen-devel] [PATCH v2 1/4] x86: rename domain_build.c to dom0_build.c

[Andrew Cooper]

On 16/03/17 17:54, Wei Liu wrote:
> To reflect the true nature of this file. No functional change.
>
> Signed-off-by: Wei Liu 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t

[Reshetova, Elena]

> On Tue, 2017-03-14 at 12:29 +, Reshetova, Elena wrote:
> > > Elena Reshetova  writes:
> > >
> > > > refcount_t type and corresponding API should be
> > > > used instead of atomic_t when the variable is used as
> > > > a reference counter. This allows to avoid accidental
> > > > refcounter overflows that might lead to use-after-free
> > > > situations.
> > > >
> > > > Signed-off-by: Elena Reshetova 
> > > > Signed-off-by: Hans Liljestrand 
> > > > Signed-off-by: Kees Cook 
> > > > Signed-off-by: David Windsor 
> > > > ---
> > > >  drivers/md/md.c | 6 +++---
> > > >  drivers/md/md.h | 3 ++-
> > > >  2 files changed, 5 insertions(+), 4 deletions(-)
> > >
> > > When booting linux-next (specifically 5be4921c9958ec) I'm seeing
> > > the
> > > backtrace below. I suspect this patch is just exposing an existing
> > > issue?
> >
> > Yes, we have actually been following this issue in the another
> > thread.
> > It looks like the object is re-used somehow, but I can't quite
> > understand how just by reading the code.
> > This was what I put into the previous thread:
> >
> > "The log below indicates that you are using your refcounter in a bit
> > weird way in mddev_find().
> > However, I can't find the place (just by reading the code) where you
> > would increment refcounter from zero (vs. setting it to one).
> > It looks like you either iterate over existing nodes (and increment
> > their counters, which should be >= 1 at the time of increment) or
> > create a new node, but then mddev_init() sets the counter to 1. "
> >
> > If you can help to understand what is going on with the object
> > creation/destruction, would be appreciated!
> >
> > Also Shaohua Li stopped this patch coming from his tree since the
> > issue was caught at that time, so we are not going to merge this
> > until we figure it out.
> 
> Asking on the correct list (dm-devel) would have got you the easy
> answer:  The refcount behind mddev->active is a genuine atomic.  It has
> refcount properties but only if the array fails to initialise (in that
> case, final put kills it).  Once it's added to the system as a gendisk,
> it cannot be freed until md_free().  Thus its ->active count can go to
> zero (when it becomes inactive; usually because of an unmount). On a
> simple allocation regardless of outcome, the last executed statement in
> md_alloc is mddev_put(): that destroys the device if we didn't manage
> to create it or returns 0 and adds an inactive device to the system
> which the user can get with mddev_find().

Thank you James for explaining this! I guess in this case, the conversion 
doesn't make sense. 
And sorry about not asking in a correct place: we are handling many similar 
patches now and while I try to reach the right audience using get_maintainer 
script, it doesn't always succeeds. 

Best Regards,
Elena.

> 
> James
> 

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

[Xen-devel] [PATCH v2 3/4] x86: split PVH dom0 builder to hvm/dom0_build.c

[Wei Liu]

Long term we want to be able to disentangle PV and HVM code. Move
the PVH domain builder to a dedicated file.

Lift function declarations to dom0_build.h and rename them when
necessary.

No functional change.

Signed-off-by: Wei Liu 
---
v2:
1. add copyright header
---
 xen/arch/x86/dom0_build.c| 1069 +---
 xen/arch/x86/hvm/Makefile|1 +
 xen/arch/x86/hvm/dom0_build.c| 1112 ++
 xen/include/asm-x86/dom0_build.h |9 +
 4 files changed, 1125 insertions(+), 1066 deletions(-)
 create mode 100644 xen/arch/x86/hvm/dom0_build.c

diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index c74f9b52e0..772f077d5a 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -50,27 +50,6 @@ static long __initdata dom0_nrpages;
 static long __initdata dom0_min_nrpages;
 static long __initdata dom0_max_nrpages = LONG_MAX;
 
-/*
- * Have the TSS cover the ISA port range, which makes it
- * - 104 bytes base structure
- * - 32 bytes interrupt redirection bitmap
- * - 128 bytes I/O bitmap
- * - one trailing byte
- * or a total of 265 bytes.
- *
- * NB: as PVHv2 Dom0 doesn't have legacy devices (ISA), it shouldn't have any
- * business in accessing the ISA port range, much less in real mode, and due to
- * the lack of firmware it shouldn't also execute any INT instruction. This is
- * done just for consistency with what hvmloader does.
- */
-#define HVM_VM86_TSS_SIZE 265
-
-static unsigned int __initdata acpi_intr_overrides;
-static struct acpi_madt_interrupt_override __initdata *intsrcovr;
-
-static unsigned int __initdata acpi_nmi_sources;
-static struct acpi_madt_nmi_source __initdata *nmisrc;
-
 /*
  * dom0_mem=[min:,][max:,][]
  * 
@@ -261,8 +240,8 @@ boolean_param("ro-hpet", ro_hpet);
 
 unsigned int __initdata dom0_memflags = MEMF_no_dma|MEMF_exact_node;
 
-static unsigned long __init dom0_paging_pages(const struct domain *d,
-  unsigned long nr_pages)
+unsigned long __init dom0_paging_pages(const struct domain *d,
+   unsigned long nr_pages)
 {
 /* Copied from: libxl_get_required_shadow_memory() */
 unsigned long memkb = nr_pages * (PAGE_SIZE / 1024);
@@ -492,1048 +471,6 @@ int __init dom0_setup_permissions(struct domain *d)
 }
 
 
-static int __init modify_identity_mmio(struct domain *d, unsigned long pfn,
-   unsigned long nr_pages, const bool map)
-{
-int rc;
-
-for ( ; ; )
-{
-rc = (map ? map_mmio_regions : unmap_mmio_regions)
- (d, _gfn(pfn), nr_pages, _mfn(pfn));
-if ( rc == 0 )
-break;
-if ( rc < 0 )
-{
-printk(XENLOG_WARNING
-   "Failed to identity %smap [%#lx,%#lx) for d%d: %d\n",
-   map ? "" : "un", pfn, pfn + nr_pages, d->domain_id, rc);
-break;
-}
-nr_pages -= rc;
-pfn += rc;
-process_pending_softirqs();
-}
-
-return rc;
-}
-
-/* Populate a HVM memory range using the biggest possible order. */
-static int __init pvh_populate_memory_range(struct domain *d,
-unsigned long start,
-unsigned long nr_pages)
-{
-unsigned int order, i = 0;
-struct page_info *page;
-int rc;
-#define MAP_MAX_ITER 64
-
-order = MAX_ORDER;
-while ( nr_pages != 0 )
-{
-unsigned int range_order = get_order_from_pages(nr_pages + 1);
-
-order = min(range_order ? range_order - 1 : 0, order);
-page = alloc_domheap_pages(d, order, dom0_memflags);
-if ( page == NULL )
-{
-if ( order == 0 && dom0_memflags )
-{
-/* Try again without any dom0_memflags. */
-dom0_memflags = 0;
-order = MAX_ORDER;
-continue;
-}
-if ( order == 0 )
-{
-printk("Unable to allocate memory with order 0!\n");
-return -ENOMEM;
-}
-order--;
-continue;
-}
-
-rc = guest_physmap_add_page(d, _gfn(start), _mfn(page_to_mfn(page)),
-order);
-if ( rc != 0 )
-{
-printk("Failed to populate memory: [%#lx,%lx): %d\n",
-   start, start + (1UL << order), rc);
-return -ENOMEM;
-}
-start += 1UL << order;
-nr_pages -= 1UL << order;
-if ( (++i % MAP_MAX_ITER) == 0 )
-process_pending_softirqs();
-}
-
-return 0;
-#undef MAP_MAX_ITER
-}
-
-/* Steal RAM from the end of a memory region. */
-static int __init pvh_steal_ram(struct domain *d, unsigned long size,
-unsigned long align, paddr_t limit,
-paddr_t *addr)
-{
-  

[Xen-devel] [PATCH v2 4/4] x86: clean up header files in dom0_build.c

[Wei Liu]

Remove the ones that are no longer needed and sort them.

Signed-off-by: Wei Liu 
Acked-by: Jan Beulich 
---
 xen/arch/x86/dom0_build.c | 40 ++--
 1 file changed, 6 insertions(+), 34 deletions(-)

diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 772f077d5a..7dc86999fd 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -5,46 +5,18 @@
  */
 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
-#include 
-#include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
+#include 
+#include 
+#include 
+
 #include 
-#include 
-#include 
+#include 
+#include 
 #include 
-#include 
-#include 
 #include 
-#include  /* for bzimage_parse */
-#include 
-#include 
-
-#include 
-
-#include 
-#include 
-#include 
-#include 
 
 static long __initdata dom0_nrpages;
 static long __initdata dom0_min_nrpages;
-- 
2.11.0


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

[Xen-devel] [PATCH v2 1/4] x86: rename domain_build.c to dom0_build.c

[Wei Liu]

To reflect the true nature of this file. No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/Makefile | 2 +-
 xen/arch/x86/{domain_build.c => dom0_build.c} | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
 rename xen/arch/x86/{domain_build.c => dom0_build.c} (99%)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index f75eca07f7..adc768f0a8 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -23,7 +23,7 @@ obj-y += delay.o
 obj-bin-y += dmi_scan.init.o
 obj-y += domctl.o
 obj-y += domain.o
-obj-bin-y += domain_build.init.o
+obj-bin-y += dom0_build.init.o
 obj-y += domain_page.o
 obj-y += e820.o
 obj-y += extable.o
diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/dom0_build.c
similarity index 99%
rename from xen/arch/x86/domain_build.c
rename to xen/arch/x86/dom0_build.c
index 00ce5f24e9..1c723c9ef1 100644
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -1,5 +1,5 @@
 /**
- * domain_build.c
+ * dom0_build.c
  * 
  * Copyright (c) 2002-2005, K A Fraser
  */
-- 
2.11.0


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

[Xen-devel] [PATCH v2 2/4] x86: split PV dom0 builder to pv/dom0_builder.c

[Wei Liu]

Long term we want to be able to disentangle PV and HVM code. Move the PV
domain builder to a dedicated file.

This in turn requires exposing a few functions and variables via a new
header dom0_build.h. These functions and variables are now prefixed with
"dom0_" if they weren't already so.

No functional change.

Signed-off-by: Wei Liu 
---
v2:
1. put file under pv directory
2. use dom0_ prefix
3. header now in asm-x86
---
 xen/arch/x86/dom0_build.c| 911 +--
 xen/arch/x86/pv/Makefile |   1 +
 xen/arch/x86/pv/dom0_build.c | 910 ++
 xen/include/asm-x86/dom0_build.h |  32 ++
 4 files changed, 960 insertions(+), 894 deletions(-)
 create mode 100644 xen/arch/x86/pv/dom0_build.c
 create mode 100644 xen/include/asm-x86/dom0_build.h

diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 1c723c9ef1..c74f9b52e0 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -154,11 +155,11 @@ static void __init parse_dom0_nodes(const char *s)
 }
 custom_param("dom0_nodes", parse_dom0_nodes);
 
-static cpumask_t __initdata dom0_cpus;
+cpumask_t __initdata dom0_cpus;
 
-static struct vcpu *__init setup_dom0_vcpu(struct domain *d,
-   unsigned int vcpu_id,
-   unsigned int cpu)
+struct vcpu *__init dom0_setup_vcpu(struct domain *d,
+unsigned int vcpu_id,
+unsigned int cpu)
 {
 struct vcpu *v = alloc_vcpu(d, vcpu_id, cpu);
 
@@ -215,7 +216,7 @@ struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
 return NULL;
 dom0->max_vcpus = max_vcpus;
 
-return setup_dom0_vcpu(dom0, 0, cpumask_first(_cpus));
+return dom0_setup_vcpu(dom0, 0, cpumask_first(_cpus));
 }
 
 #ifdef CONFIG_SHADOW_PAGING
@@ -258,66 +259,7 @@ string_param("dom0_ioports_disable", 
opt_dom0_ioports_disable);
 static bool_t __initdata ro_hpet = 1;
 boolean_param("ro-hpet", ro_hpet);
 
-/* Allow ring-3 access in long mode as guest cannot use ring 1 ... */
-#define BASE_PROT (_PAGE_PRESENT|_PAGE_RW|_PAGE_ACCESSED|_PAGE_USER)
-#define L1_PROT (BASE_PROT|_PAGE_GUEST_KERNEL)
-/* ... except for compatibility mode guests. */
-#define COMPAT_L1_PROT (_PAGE_PRESENT|_PAGE_RW|_PAGE_ACCESSED)
-#define L2_PROT (BASE_PROT|_PAGE_DIRTY)
-#define L3_PROT (BASE_PROT|_PAGE_DIRTY)
-#define L4_PROT (BASE_PROT|_PAGE_DIRTY)
-
-static unsigned int __initdata memflags = MEMF_no_dma|MEMF_exact_node;
-
-static struct page_info * __init alloc_chunk(
-struct domain *d, unsigned long max_pages)
-{
-static unsigned int __initdata last_order = MAX_ORDER;
-struct page_info *page;
-unsigned int order = get_order_from_pages(max_pages), free_order;
-
-if ( order > last_order )
-order = last_order;
-else if ( max_pages & (max_pages - 1) )
---order;
-while ( (page = alloc_domheap_pages(d, order, memflags)) == NULL )
-if ( order-- == 0 )
-break;
-if ( page )
-last_order = order;
-else if ( memflags )
-{
-/*
- * Allocate up to 2MB at a time: It prevents allocating very large
- * chunks from DMA pools before the >4GB pool is fully depleted.
- */
-last_order = 21 - PAGE_SHIFT;
-memflags = 0;
-return alloc_chunk(d, max_pages);
-}
-
-/*
- * Make a reasonable attempt at finding a smaller chunk at a higher
- * address, to avoid allocating from low memory as much as possible.
- */
-for ( free_order = order; !memflags && page && order--; )
-{
-struct page_info *pg2;
-
-if ( d->tot_pages + (1 << order) > d->max_pages )
-continue;
-pg2 = alloc_domheap_pages(d, order, MEMF_exact_node);
-if ( pg2 > page )
-{
-free_domheap_pages(page, free_order);
-page = pg2;
-free_order = order;
-}
-else if ( pg2 )
-free_domheap_pages(pg2, order);
-}
-return page;
-}
+unsigned int __initdata dom0_memflags = MEMF_no_dma|MEMF_exact_node;
 
 static unsigned long __init dom0_paging_pages(const struct domain *d,
   unsigned long nr_pages)
@@ -330,7 +272,7 @@ static unsigned long __init dom0_paging_pages(const struct 
domain *d,
 return ((memkb + 1023) / 1024) << (20 - PAGE_SHIFT);
 }
 
-static unsigned long __init compute_dom0_nr_pages(
+unsigned long __init dom0_compute_nr_pages(
 struct domain *d, struct elf_dom_parms *parms, unsigned long initrd_len)
 {
 nodeid_t node;
@@ -467,199 +409,7 @@ static void __init process_dom0_ioports_disable(struct 
domain *dom0)
 }
 }
 
-static __init void dom0_update_physmap(struct domain *d, unsigned long pfn,
-   

[Xen-devel] [PATCH v2 0/4] Refactor x86 dom0 builder

[Wei Liu]

Wei Liu (4):
  x86: rename domain_build.c to dom0_build.c
  x86: split PV dom0 builder to pv/dom0_builder.c
  x86: split PVH dom0 builder to hvm/dom0_build.c
  x86: clean up header files in dom0_build.c

 xen/arch/x86/Makefile|2 +-
 xen/arch/x86/dom0_build.c|  470 
 xen/arch/x86/domain_build.c  | 2438 --
 xen/arch/x86/hvm/Makefile|1 +
 xen/arch/x86/hvm/dom0_build.c| 1112 +
 xen/arch/x86/pv/Makefile |1 +
 xen/arch/x86/pv/dom0_build.c |  910 ++
 xen/include/asm-x86/dom0_build.h |   41 +
 8 files changed, 2536 insertions(+), 2439 deletions(-)
 create mode 100644 xen/arch/x86/dom0_build.c
 delete mode 100644 xen/arch/x86/domain_build.c
 create mode 100644 xen/arch/x86/hvm/dom0_build.c
 create mode 100644 xen/arch/x86/pv/dom0_build.c
 create mode 100644 xen/include/asm-x86/dom0_build.h

-- 
2.11.0


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

Re: [Xen-devel] [PATCH v4 0/7] Xen transport for 9pfs frontend driver

[Stefano Stabellini]

On Thu, 16 Mar 2017, Juergen Gross wrote:
> On 15/03/17 20:23, Stefano Stabellini wrote:
> > Hi all,
> > 
> > This patch series implements a new transport for 9pfs, aimed at Xen
> > systems.
> > 
> > The transport is based on a traditional Xen frontend and backend drivers
> > pair. This patch series implements the frontend, which typically runs in
> > a regular unprivileged guest.
> > 
> > I also sent a series that implements the backend in userspace in QEMU,
> > which typically runs in Dom0 (but could also run in a another guest).
> > 
> > The frontend complies to the Xen transport for 9pfs specification
> > version 1, available here:
> > 
> > http://xenbits.xen.org/gitweb/?p=xen.git;a=blob_plain;f=docs/misc/9pfs.markdown;hb=HEAD
> > 
> > 
> > Changes in v4:
> > - code style improvements
> > - use xenbus_read_unsigned when possible
> > - do not leak "versions"
> > - introduce BUILD_BUG_ON
> > - introduce rwlock to protect the xen_9pfs_devs list
> > - add review-by
> > 
> > Changes in v3:
> > - add full copyright header to trans_xen.c
> > - rename ring->ring to ring->data
> > - handle gnttab_grant_foreign_access errors
> > - remove ring->bytes
> > - wrap long lines
> > - add reviewed-by
> > 
> > Changes in v2:
> > - use XEN_PAGE_SHIFT instead of PAGE_SHIFT
> > - remove unnecessary initializations
> > - fix error paths
> > - fix memory allocations for 64K kernels
> > - simplify p9_xen_create and p9_xen_close
> > - use virt_XXX barriers
> > - set status = REQ_STATUS_ERROR inside the p9_xen_response loop
> > - add in-code comments
> > 
> > 
> > Stefano Stabellini (7):
> >   xen: import new ring macros in ring.h
> >   xen: introduce the header file for the Xen 9pfs transport protocol
> >   xen/9pfs: introduce Xen 9pfs transport driver
> >   xen/9pfs: connect to the backend
> >   xen/9pfs: send requests to the backend
> >   xen/9pfs: receive responses
> >   xen/9pfs: build 9pfs Xen transport driver
> > 
> >  include/xen/interface/io/9pfs.h |  40 
> >  include/xen/interface/io/ring.h | 131 ++
> >  net/9p/Kconfig  |   8 +
> >  net/9p/Makefile |   4 +
> >  net/9p/trans_xen.c  | 513 
> > 
> >  5 files changed, 696 insertions(+)
> >  create mode 100644 include/xen/interface/io/9pfs.h
> >  create mode 100644 net/9p/trans_xen.c
> 
> I strongly recommend running checkpatch.pl to avoid style problems. This
> will save us some more rounds, I guess: there are multiple style
> violations in the patches which are not related to the header import
> from Xen.

Yes, you are right. FWIW I have just ran checkpatch.pl for the QEMU
series, I'll do that for Linux too.

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

Re: [Xen-devel] [PATCH v2 7/9] x86/shadow: Use the pagewalk reserved bits helpers

[Andrew Cooper]

On 16/03/17 16:31, Andrew Cooper wrote:
> The shadow logic should not create a valid/present shadow of a guest PTE which
> contains reserved bits from the guests point of view.  It is not guaranteed
> that the hardware pagewalk will come to the same conclusion, and raise a
> pagefault.
>
> Shadows created on demand from the pagefault handler are fine because the
> pagewalk over the guest tables will have injected the fault into the guest
> rather than creating a shadow.
>
> However, shadows created by sh_resync_l1() and sh_prefetch() haven't undergone
> a pagewalk and need to account for reserved bits before creating the shadow.
>
> In practice, this means a 3-level guest could previously cause PTEs with bits
> 63:52 set to be shadowed (and discarded).  This PTE should cause #PF[RSVD]
> when encountered by hardware, but the installed shadow is valid and hardware
> doesn't fault.
>
> Reuse the pagewalk reserved bits helpers, and assert in
> l?e_propagate_from_guest() that shadows are not attempted to be created with
> reserved bits set.
>
> Signed-off-by: Andrew Cooper 

The travis build running clang points out that p2mt might now be
uninitialised in the l1 cases.  In practice it doesn't matter because
INVALID_MFN will cause _sh_propagate() to head in an empty() direction,
but I have folded the following delta in.

diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 56114c7..627284d 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -2309,7 +2309,7 @@ static int validate_gl1e(struct vcpu *v, void
*new_ge, mfn_t sl1mfn, void *se)
 shadow_l1e_t *sl1p = se;
 gfn_t gfn;
 mfn_t gmfn = INVALID_MFN;
-p2m_type_t p2mt;
+p2m_type_t p2mt = p2m_invalid;
 int result = 0;
 #if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
 mfn_t gl1mfn;
@@ -2379,7 +2379,7 @@ void sh_resync_l1(struct vcpu *v, mfn_t gl1mfn,
mfn_t snpmfn)
 {
 gfn_t gfn;
 mfn_t gmfn = INVALID_MFN;
-p2m_type_t p2mt;
+p2m_type_t p2mt = p2m_invalid;
 shadow_l1e_t nsl1e;
 
 if ( (guest_l1e_get_flags(gl1e) & _PAGE_PRESENT) &&
@@ -2721,7 +2721,10 @@ static void sh_prefetch(struct vcpu *v, walk_t *gw,
 gmfn = get_gfn_query_unlocked(d, gfn_x(gfn), );
 }
 else
+{
 gmfn = INVALID_MFN;
+p2mt = p2m_invalid;
+}
 
 /* Propagate the entry.  */
 l1e_propagate_from_guest(v, gl1e, gmfn, , ft_prefetch, p2mt);

~Andrew

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

Re: [Xen-devel] [PATCH 2/2] xen/arm32: Use alternative to skip the check of pending serrors

[Julien Grall]

Hi Wei,

On 03/16/2017 09:53 AM, Wei Chen wrote:

We have provided an option to administrator to determine how to
handle the SErrors. In order to skip the check of pending SError,
in conventional way, we have to read the option every time before
we try to check the pending SError. This will add overhead to check
the option at every trap.

The ARM32 supports the alternative patching feature. We can use an
ALTERNATIVE to avoid checking option at every trap. We added a new
cpufeature named "SKIP_CHECK_PENDING_VSERROR". This feature will be
enabled when the option is not diverse.


Can you please squash this patch in #10 of the SError series?

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 05/18] xen/arm: Save ESR_EL2 to avoid using mismatched value in syndrome check

[Julien Grall]

Hi Wei,

On 03/13/2017 10:55 AM, Wei Chen wrote:

Xen will do exception syndrome check while some types of exception
take place in EL2. The syndrome check code read the ESR_EL2 register
directly, but in some situation this register maybe overridden by
nested exception.

For example, if we re-enable IRQ before reading ESR_EL2 which means
Xen will enter in IRQ exception mode and return the processor with


s/will/may/


clobbered ESR_EL2 (See ARM ARM DDI 0487A.j D7.2.25)

In this case the guest exception syndrome has been overridden, we will
check the syndrome for guest sync exception with a mismatched ESR_EL2


s/mismatched/incorrect/ I think


value. So we want to save ESR_EL2 to cpu_user_regs as soon as the
exception takes place in EL2 to avoid using a mismatched syndrome value.


Ditto.



Signed-off-by: Wei Chen 
---
 xen/arch/arm/arm32/asm-offsets.c  |  1 +
 xen/arch/arm/arm32/entry.S|  3 +++
 xen/arch/arm/arm64/asm-offsets.c  |  1 +
 xen/arch/arm/arm64/entry.S| 13 +
 xen/arch/arm/traps.c  |  2 +-
 xen/include/asm-arm/arm32/processor.h |  2 +-
 xen/include/asm-arm/arm64/processor.h | 10 --
 7 files changed, 24 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/arm32/asm-offsets.c b/xen/arch/arm/arm32/asm-offsets.c
index f8e6b53..5b543ab 100644
--- a/xen/arch/arm/arm32/asm-offsets.c
+++ b/xen/arch/arm/arm32/asm-offsets.c
@@ -26,6 +26,7 @@ void __dummy__(void)
OFFSET(UREGS_lr, struct cpu_user_regs, lr);
OFFSET(UREGS_pc, struct cpu_user_regs, pc);
OFFSET(UREGS_cpsr, struct cpu_user_regs, cpsr);
+   OFFSET(UREGS_hsr, struct cpu_user_regs, hsr);

OFFSET(UREGS_LR_usr, struct cpu_user_regs, lr_usr);
OFFSET(UREGS_SP_usr, struct cpu_user_regs, sp_usr);
diff --git a/xen/arch/arm/arm32/entry.S b/xen/arch/arm/arm32/entry.S
index 2a6f4f0..2187226 100644
--- a/xen/arch/arm/arm32/entry.S
+++ b/xen/arch/arm/arm32/entry.S
@@ -23,6 +23,9 @@
 add r11, sp, #UREGS_kernel_sizeof+4;\
 str r11, [sp, #UREGS_sp];   \
 \
+mrc CP32(r11, HSR); /* Save exception syndrome */   \
+str r11, [sp, #UREGS_hsr];  \
+\
 mrs r11, SPSR_hyp;  \
 str r11, [sp, #UREGS_cpsr]; \
 and r11, #PSR_MODE_MASK;\
diff --git a/xen/arch/arm/arm64/asm-offsets.c b/xen/arch/arm/arm64/asm-offsets.c
index 69ea92a..ce24e44 100644
--- a/xen/arch/arm/arm64/asm-offsets.c
+++ b/xen/arch/arm/arm64/asm-offsets.c
@@ -27,6 +27,7 @@ void __dummy__(void)
OFFSET(UREGS_SP, struct cpu_user_regs, sp);
OFFSET(UREGS_PC, struct cpu_user_regs, pc);
OFFSET(UREGS_CPSR, struct cpu_user_regs, cpsr);
+   OFFSET(UREGS_ESR_el2, struct cpu_user_regs, hsr);

OFFSET(UREGS_SPSR_el1, struct cpu_user_regs, spsr_el1);

diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
index c181b5e..02802c0 100644
--- a/xen/arch/arm/arm64/entry.S
+++ b/xen/arch/arm/arm64/entry.S
@@ -121,9 +121,13 @@ lr  .reqx30 // link register

 stp lr, x21, [sp, #UREGS_LR]

-mrs x22, elr_el2
-mrs x23, spsr_el2
-stp x22, x23, [sp, #UREGS_PC]
+mrs x21, elr_el2
+str x21, [sp, #UREGS_PC]


Please explain the commit message you modify the lines above ...


+
+add x21, sp, #UREGS_CPSR
+mrs x22, spsr_el2
+mrs x23, esr_el2
+stp w22, w23, [x21]

 .endm

@@ -307,7 +311,8 @@ ENTRY(return_to_new_vcpu64)
 return_from_trap:
 msr daifset, #2 /* Mask interrupts */

-ldp x21, x22, [sp, #UREGS_PC]   // load ELR, SPSR
+ldr x21, [sp, #UREGS_PC]// load ELR
+ldr w22, [sp, #UREGS_CPSR]  // load SPSR


as long as those one.



 pop x0, x1
 pop x2, x3


[...]


diff --git a/xen/include/asm-arm/arm64/processor.h 
b/xen/include/asm-arm/arm64/processor.h
index b0726ff..d381428 100644
--- a/xen/include/asm-arm/arm64/processor.h
+++ b/xen/include/asm-arm/arm64/processor.h
@@ -65,9 +65,15 @@ struct cpu_user_regs

 /* Return address and mode */
 __DECL_REG(pc,   pc32); /* ELR_EL2 */
+/*
+ * Be careful for 32-bit registers, if we use xN to save 32-bit register
+ * to stack, its next field on stack will be overridden.
+ * For example, if we use xN to save SPSR_EL2 to stack will override the
+ * hsr field on stack.
+ * So, it's better to use wN to save 32-bit registers to stack.
+ */


This comment is pointless. This is true for any 32-bit register, you 
should use wN unless you now that you 

Re: [Xen-devel] [PATCH 05/11] xen/arm: vpl011: Initialize nr_spis in vgic_init in Xen to atleast 1

[Julien Grall]

Hi Bhupinder,

On 03/16/2017 10:31 AM, Bhupinder Thakur wrote:

On 16 March 2017 at 13:54, Julien Grall  wrote:


The other option is to reserve a SPI for pl011 at compile time and use
that value. Let me know.



Whilst I am ok to have the pl011 SPI number hardcoded, I don't like the
approach taken in this patch because the toolstack is in charge of the guest
layout (interrupt, memory...) and not the hypervisor.

The values are hardcoded today because we decided to do a fix layout for
simplicity. It is likely to be changed in the future.

The toolstack knows how much memory the user requested, the list of devices
available... So it is the goal of the toolstack to bump the number of SPIs
before creating the domain if a PL011 will be exposed.

Also, the interaction between the pl011 and the parameter "irqs" in the
domain configuration file will need to be documented. By that I mean
explaining from which number the SPIs will be allocated when choosing a
pl011 enabling.

Note the probably want to allow the user to choose the pl011 IRQ and MMIO
region. If he doesn't provide any, we would use the default value.

Cheers,


We can follow the convention that when pl011 is enabled then the last
irq in the "irqs" list will be used as the pl011 irq. I believe that
the irqs mentioned in the "irqs" list will be reserved by the
hypervisor when the domain is created and we need not allocate a SPI
separately as we are doing currently.


I don't understand what you mean here. If you speak about the xl 
parameter "irqs", it is a list of physical IRQs and not virtual IRQs. 
Furthermore, we would like to keep to avoid a normal user to do more 
than specifying "pl011" or else on in the guest configuration file.


So could you clarify what you mean?

Cheers,

--
Julien Grall

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

[Xen-devel] [PATCH v2 6/9] x86/pagewalk: Re-implement the pagetable walker

[Andrew Cooper]

The existing pagetable walker has complicated return semantics, which squeeze
multiple pieces of information into single integer.  This would be fine if the
information didn't overlap, but it does.

Specifically, _PAGE_INVALID_BITS for 3-level guests alias _PAGE_PAGED and
_PAGE_SHARED.  A guest which constructs a PTE with bits 52 or 53 set (the
start of the upper software-available range) will create a virtual address
which, when walked by Xen, tricks Xen into believing the frame is paged or
shared.  This behaviour was introduced by XSA-173 (c/s 8b17648).

It is also complicated to turn rc back into a normal pagefault error code.
Instead, change the calling semantics to return a boolean indicating success,
and have the function accumulate a real pagefault error code as it goes
(including synthetic error codes, which do not alias hardware ones).  This
requires an equivalent adjustment to map_domain_gfn().

Issues fixed:
 * 2-level PSE36 superpages now return the correct translation.
 * 2-level L2 superpages without CR0.PSE now return the correct translation.
 * SMEP now inhibits a user instruction fetch even if NX isn't active.
 * Supervisor writes without CR0.WP now set the leaf dirty bit.
 * L4e._PAGE_GLOBAL is strictly reserved on AMD.
 * 3-level l3 entries have all reserved bits checked.
 * 3-level entries can no longer alias Xen's idea of paged or shared.

Signed-off-by: Andrew Cooper 
Reviewed-by: Tim Deegan 
Reviewed-by: George Dunlap 
Reviewed-by: Jan Beulich 
---
 xen/arch/x86/mm/guest_walk.c  | 449 --
 xen/arch/x86/mm/hap/guest_walk.c  |  21 +-
 xen/arch/x86/mm/hap/nested_ept.c  |   2 +-
 xen/arch/x86/mm/p2m.c |  17 +-
 xen/arch/x86/mm/shadow/multi.c|  27 +--
 xen/include/asm-x86/guest_pt.h|  62 --
 xen/include/asm-x86/p2m.h |   2 +-
 xen/include/asm-x86/page.h|   3 -
 xen/include/asm-x86/processor.h   |   2 +
 xen/include/asm-x86/x86_64/page.h |   6 -
 10 files changed, 303 insertions(+), 288 deletions(-)

diff --git a/xen/arch/x86/mm/guest_walk.c b/xen/arch/x86/mm/guest_walk.c
index 11f4c5d..bdb52d9 100644
--- a/xen/arch/x86/mm/guest_walk.c
+++ b/xen/arch/x86/mm/guest_walk.c
@@ -32,44 +32,6 @@ asm(".file \"" __OBJECT_FILE__ "\"");
 #include 
 #include 
 
-extern const uint32_t gw_page_flags[];
-#if GUEST_PAGING_LEVELS == CONFIG_PAGING_LEVELS
-const uint32_t gw_page_flags[] = {
-/* I/F -  Usr Wr */
-/* 0   0   0   0 */ _PAGE_PRESENT,
-/* 0   0   0   1 */ _PAGE_PRESENT|_PAGE_RW,
-/* 0   0   1   0 */ _PAGE_PRESENT|_PAGE_USER,
-/* 0   0   1   1 */ _PAGE_PRESENT|_PAGE_RW|_PAGE_USER,
-/* 0   1   0   0 */ _PAGE_PRESENT,
-/* 0   1   0   1 */ _PAGE_PRESENT|_PAGE_RW,
-/* 0   1   1   0 */ _PAGE_PRESENT|_PAGE_USER,
-/* 0   1   1   1 */ _PAGE_PRESENT|_PAGE_RW|_PAGE_USER,
-/* 1   0   0   0 */ _PAGE_PRESENT|_PAGE_NX_BIT,
-/* 1   0   0   1 */ _PAGE_PRESENT|_PAGE_RW|_PAGE_NX_BIT,
-/* 1   0   1   0 */ _PAGE_PRESENT|_PAGE_USER|_PAGE_NX_BIT,
-/* 1   0   1   1 */ _PAGE_PRESENT|_PAGE_RW|_PAGE_USER|_PAGE_NX_BIT,
-/* 1   1   0   0 */ _PAGE_PRESENT|_PAGE_NX_BIT,
-/* 1   1   0   1 */ _PAGE_PRESENT|_PAGE_RW|_PAGE_NX_BIT,
-/* 1   1   1   0 */ _PAGE_PRESENT|_PAGE_USER|_PAGE_NX_BIT,
-/* 1   1   1   1 */ _PAGE_PRESENT|_PAGE_RW|_PAGE_USER|_PAGE_NX_BIT,
-};
-#endif
-
-/* Flags that are needed in a pagetable entry, with the sense of NX inverted */
-static uint32_t mandatory_flags(struct vcpu *v, uint32_t pfec) 
-{
-/* Don't demand not-NX if the CPU wouldn't enforce it. */
-if ( !guest_supports_nx(v) )
-pfec &= ~PFEC_insn_fetch;
-
-/* Don't demand R/W if the CPU wouldn't enforce it. */
-if ( is_hvm_vcpu(v) && unlikely(!hvm_wp_enabled(v)) 
- && !(pfec & PFEC_user_mode) )
-pfec &= ~PFEC_write_access;
-
-return gw_page_flags[(pfec & 0x1f) >> 1] | _PAGE_INVALID_BITS;
-}
-
 /* Modify a guest pagetable entry to set the Accessed and Dirty bits.
  * Returns non-zero if it actually writes to guest memory. */
 static uint32_t set_ad_bits(void *guest_p, void *walk_p, int set_dirty)
@@ -90,62 +52,33 @@ static uint32_t set_ad_bits(void *guest_p, void *walk_p, 
int set_dirty)
 return 0;
 }
 
-#if GUEST_PAGING_LEVELS >= 4
-static bool_t pkey_fault(struct vcpu *vcpu, uint32_t pfec,
-uint32_t pte_flags, uint32_t pte_pkey)
-{
-uint32_t pkru;
-
-/* When page isn't present,  PKEY isn't checked. */
-if ( !(pfec & PFEC_page_present) || is_pv_vcpu(vcpu) )
-return 0;
-
-/*
- * PKU:  additional mechanism by which the paging controls
- * access to user-mode addresses based on the value in the
- * PKRU register. A fault is considered as a PKU violation if all
- * of the following conditions are true:
- * 1.CR4_PKE=1.
- * 2.EFER_LMA=1.
- * 3.Page is present with no reserved bit violations.
- * 4.The access is not an 

[Xen-devel] [PATCH v2 9/9] x86/pagewalk: non-functional cleanup

[Andrew Cooper]

 * Drop trailing whitespace
 * Consistently apply Xen style
 * Introduce a local variable block

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

v2:
 * New
---
 xen/arch/x86/mm/guest_walk.c | 82 
 1 file changed, 53 insertions(+), 29 deletions(-)

diff --git a/xen/arch/x86/mm/guest_walk.c b/xen/arch/x86/mm/guest_walk.c
index 4ba7602..a8b72b2 100644
--- a/xen/arch/x86/mm/guest_walk.c
+++ b/xen/arch/x86/mm/guest_walk.c
@@ -81,7 +81,7 @@ static bool set_ad_bits(void *_guest_p, void *_walk_p, bool 
set_dirty)
  */
 bool
 guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
-  unsigned long va, walk_t *gw, 
+  unsigned long va, walk_t *gw,
   uint32_t walk, mfn_t top_mfn, void *top_map)
 {
 struct domain *d = v->domain;
@@ -154,13 +154,13 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
 ar_or  |= gflags;
 
 /* Map the l3 table */
-l3p = map_domain_gfn(p2m, 
- guest_l4e_get_gfn(gw->l4e), 
+l3p = map_domain_gfn(p2m,
+ guest_l4e_get_gfn(gw->l4e),
  >l3mfn,
  ,
  qt,
- ); 
-if(l3p == NULL)
+ );
+if ( l3p == NULL )
 {
 gw->pfec |= rc & PFEC_synth_mask;
 goto out;
@@ -178,23 +178,29 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
 gw->pfec |= PFEC_reserved_bit | PFEC_page_present;
 goto out;
 }
-
+
 /* Accumulate l3e access rights. */
 ar_and &= gflags;
 ar_or  |= gflags;
 
 if ( gflags & _PAGE_PSE )
 {
-/* Generate a fake l1 table entry so callers don't all 
- * have to understand superpages. */
+/*
+ * Generate a fake l1 table entry so callers don't all
+ * have to understand superpages.
+ */
 gfn_t start = guest_l3e_get_gfn(gw->l3e);
-/* Grant full access in the l1e, since all the guest entry's
- * access controls are enforced in the l3e. */
+/*
+ * Grant full access in the l1e, since all the guest entry's
+ * access controls are enforced in the l3e.
+ */
 int flags = (_PAGE_PRESENT|_PAGE_USER|_PAGE_RW|
  _PAGE_ACCESSED|_PAGE_DIRTY);
-/* Import cache-control bits. Note that _PAGE_PAT is actually
+/*
+ * Import cache-control bits. Note that _PAGE_PAT is actually
  * _PAGE_PSE, and it is always set. We will clear it in case
- * _PAGE_PSE_PAT (bit 12, i.e. first bit of gfn) is clear. */
+ * _PAGE_PSE_PAT (bit 12, i.e. first bit of gfn) is clear.
+ */
 flags |= (guest_l3e_get_flags(gw->l3e)
   & (_PAGE_PAT|_PAGE_PWT|_PAGE_PCD));
 if ( !(gfn_x(start) & 1) )
@@ -227,13 +233,13 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
 #endif /* PAE or 64... */
 
 /* Map the l2 table */
-l2p = map_domain_gfn(p2m, 
- guest_l3e_get_gfn(gw->l3e), 
+l2p = map_domain_gfn(p2m,
+ guest_l3e_get_gfn(gw->l3e),
  >l2mfn,
- , 
+ ,
  qt,
- ); 
-if(l2p == NULL)
+ );
+if ( l2p == NULL )
 {
 gw->pfec |= rc & PFEC_synth_mask;
 goto out;
@@ -278,22 +284,28 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
 
 if ( gflags & _PAGE_PSE )
 {
-/* Special case: this guest VA is in a PSE superpage, so there's
+/*
+ * Special case: this guest VA is in a PSE superpage, so there's
  * no guest l1e.  We make one up so that the propagation code
- * can generate a shadow l1 table.  Start with the gfn of the 
- * first 4k-page of the superpage. */
+ * can generate a shadow l1 table.  Start with the gfn of the
+ * first 4k-page of the superpage.
+ */
 #if GUEST_PAGING_LEVELS == 2
 gfn_t start = _gfn(unfold_pse36(gw->l2e.l2) >> PAGE_SHIFT);
 #else
 gfn_t start = guest_l2e_get_gfn(gw->l2e);
 #endif
-/* Grant full access in the l1e, since all the guest entry's 
- * access controls are enforced in the shadow l2e. */
+/*
+ * Grant full access in the l1e, since all the guest entry's
+ * access controls are enforced in the shadow l2e.
+ */
 int flags = (_PAGE_PRESENT|_PAGE_USER|_PAGE_RW|
  _PAGE_ACCESSED|_PAGE_DIRTY);
-/* Import cache-control bits. Note that _PAGE_PAT is actually
+/*
+ * Import cache-control bits. Note that _PAGE_PAT is actually
  * _PAGE_PSE, and it is always set. We will clear it in 

[Xen-devel] [PATCH v2 8/9] x86/pagewalk: Improve the logic behind setting access and dirty bits

[Andrew Cooper]

The boolean pse2M is misnamed, because it might refer to a 4M superpage.

Switch the logic to be in terms of the level of the leaf entry, and rearrange
the calls to set_ad_bits() to be a fallthrough switch statement, to make it
easier to follow.

Alter set_ad_bits() to use properly use bool rather than integers.  Introduce
properly typed pointers rather than repeatedly casting away from void.  Use
ACCESS_ONCE() to ensure that *walk_p is only read once.

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

v2:
 * New
---
 xen/arch/x86/mm/guest_walk.c | 81 +---
 1 file changed, 47 insertions(+), 34 deletions(-)

diff --git a/xen/arch/x86/mm/guest_walk.c b/xen/arch/x86/mm/guest_walk.c
index bdb52d9..4ba7602 100644
--- a/xen/arch/x86/mm/guest_walk.c
+++ b/xen/arch/x86/mm/guest_walk.c
@@ -32,24 +32,28 @@ asm(".file \"" __OBJECT_FILE__ "\"");
 #include 
 #include 
 
-/* Modify a guest pagetable entry to set the Accessed and Dirty bits.
- * Returns non-zero if it actually writes to guest memory. */
-static uint32_t set_ad_bits(void *guest_p, void *walk_p, int set_dirty)
+/*
+ * Modify a guest pagetable entry to set the Accessed and Dirty bits.
+ * Returns non-zero if it actually writes to guest memory.
+ */
+static bool set_ad_bits(void *_guest_p, void *_walk_p, bool set_dirty)
 {
-guest_intpte_t old, new;
+guest_intpte_t *guest_p = _guest_p, *walk_p = _walk_p;
+guest_intpte_t new, old = ACCESS_ONCE(*walk_p);
 
-old = *(guest_intpte_t *)walk_p;
 new = old | _PAGE_ACCESSED | (set_dirty ? _PAGE_DIRTY : 0);
-if ( old != new ) 
+if ( old != new )
 {
-/* Write the new entry into the walk, and try to write it back
+/*
+ * Write the new entry into the walk, and try to write it back
  * into the guest table as well.  If the guest table has changed
- * under out feet then leave it alone. */
-*(guest_intpte_t *)walk_p = new;
-if ( cmpxchg(((guest_intpte_t *)guest_p), old, new) == old ) 
-return 1;
+ * under out feet then leave it alone.
+ */
+*walk_p = new;
+if ( cmpxchg(guest_p, old, new) == old )
+return true;
 }
-return 0;
+return false;
 }
 
 /*
@@ -89,7 +93,7 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
 guest_l4e_t *l4p;
 #endif
 uint32_t gflags, rc;
-bool_t pse1G = 0, pse2M = 0;
+unsigned int leaf_level;
 p2m_query_t qt = P2M_ALLOC | P2M_UNSHARE;
 
 #define AR_ACCUM_AND (_PAGE_USER | _PAGE_RW)
@@ -179,9 +183,7 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
 ar_and &= gflags;
 ar_or  |= gflags;
 
-pse1G = !!(gflags & _PAGE_PSE);
-
-if ( pse1G )
+if ( gflags & _PAGE_PSE )
 {
 /* Generate a fake l1 table entry so callers don't all 
  * have to understand superpages. */
@@ -204,6 +206,7 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
  ((va >> PAGE_SHIFT) & GUEST_L3_GFN_MASK));
 gw->l1e = guest_l1e_from_gfn(start, flags);
 gw->l2mfn = gw->l1mfn = INVALID_MFN;
+leaf_level = 3;
 goto leaf;
 }
 
@@ -273,9 +276,7 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
 ar_and &= gflags;
 ar_or  |= gflags;
 
-pse2M = !!(gflags & _PAGE_PSE);
-
-if ( pse2M )
+if ( gflags & _PAGE_PSE )
 {
 /* Special case: this guest VA is in a PSE superpage, so there's
  * no guest l1e.  We make one up so that the propagation code
@@ -309,6 +310,7 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
 gw->l1e = guest_l1e_from_gfn(start, flags);
 #endif
 gw->l1mfn = INVALID_MFN;
+leaf_level = 2;
 goto leaf;
 }
 
@@ -340,6 +342,8 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
 ar_and &= gflags;
 ar_or  |= gflags;
 
+leaf_level = 1;
+
  leaf:
 gw->pfec |= PFEC_page_present;
 
@@ -413,24 +417,33 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
  * success.  Although the PRMs say higher-level _PAGE_ACCESSED bits
  * get set whenever a lower-level PT is used, at least some hardware
  * walkers behave this way. */
-#if GUEST_PAGING_LEVELS == 4 /* 64-bit only... */
-if ( set_ad_bits(l4p + guest_l4_table_offset(va), >l4e, 0) )
-paging_mark_dirty(d, gw->l4mfn);
-if ( set_ad_bits(l3p + guest_l3_table_offset(va), >l3e,
- (pse1G && (walk & PFEC_write_access))) )
-paging_mark_dirty(d, gw->l3mfn);
-#endif
-if ( !pse1G )
+switch ( leaf_level )
 {
+default:
+ASSERT_UNREACHABLE();
+break;
+
+case 1:
+if ( set_ad_bits(l1p + guest_l1_table_offset(va), >l1e,
+ (walk & PFEC_write_access) && leaf_level == 1) )
+paging_mark_dirty(d, 

[Xen-devel] [PATCH v2 2/9] x86/pagewalk: Use pointer syntax for pfec parameter

[Andrew Cooper]

It is a pointer, not an array.

No functional change.

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

v2:
 * New
---
 xen/arch/x86/mm/hap/guest_walk.c | 24 
 xen/arch/x86/mm/shadow/multi.c   | 12 ++--
 xen/include/asm-x86/paging.h |  7 ---
 3 files changed, 22 insertions(+), 21 deletions(-)

diff --git a/xen/arch/x86/mm/hap/guest_walk.c b/xen/arch/x86/mm/hap/guest_walk.c
index 313f82f..e202c9a 100644
--- a/xen/arch/x86/mm/hap/guest_walk.c
+++ b/xen/arch/x86/mm/hap/guest_walk.c
@@ -65,7 +65,7 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PAGING_LEVELS)(
 if ( p2m_is_paging(p2mt) )
 {
 ASSERT(p2m_is_hostp2m(p2m));
-pfec[0] = PFEC_page_paged;
+*pfec = PFEC_page_paged;
 if ( top_page )
 put_page(top_page);
 p2m_mem_paging_populate(p2m->domain, cr3 >> PAGE_SHIFT);
@@ -73,14 +73,14 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PAGING_LEVELS)(
 }
 if ( p2m_is_shared(p2mt) )
 {
-pfec[0] = PFEC_page_shared;
+*pfec = PFEC_page_shared;
 if ( top_page )
 put_page(top_page);
 return gfn_x(INVALID_GFN);
 }
 if ( !top_page )
 {
-pfec[0] &= ~PFEC_page_present;
+*pfec &= ~PFEC_page_present;
 goto out_tweak_pfec;
 }
 top_mfn = _mfn(page_to_mfn(top_page));
@@ -91,7 +91,7 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PAGING_LEVELS)(
 #if GUEST_PAGING_LEVELS == 3
 top_map += (cr3 & ~(PAGE_MASK | 31));
 #endif
-missing = guest_walk_tables(v, p2m, ga, , pfec[0], top_mfn, top_map);
+missing = guest_walk_tables(v, p2m, ga, , *pfec, top_mfn, top_map);
 unmap_domain_page(top_map);
 put_page(top_page);
 
@@ -107,13 +107,13 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PAGING_LEVELS)(
 if ( p2m_is_paging(p2mt) )
 {
 ASSERT(p2m_is_hostp2m(p2m));
-pfec[0] = PFEC_page_paged;
+*pfec = PFEC_page_paged;
 p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
 return gfn_x(INVALID_GFN);
 }
 if ( p2m_is_shared(p2mt) )
 {
-pfec[0] = PFEC_page_shared;
+*pfec = PFEC_page_shared;
 return gfn_x(INVALID_GFN);
 }
 
@@ -124,19 +124,19 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PAGING_LEVELS)(
 }
 
 if ( missing & _PAGE_PRESENT )
-pfec[0] &= ~PFEC_page_present;
+*pfec &= ~PFEC_page_present;
 
 if ( missing & _PAGE_INVALID_BITS ) 
-pfec[0] |= PFEC_reserved_bit;
+*pfec |= PFEC_reserved_bit;
 
 if ( missing & _PAGE_PKEY_BITS )
-pfec[0] |= PFEC_prot_key;
+*pfec |= PFEC_prot_key;
 
 if ( missing & _PAGE_PAGED )
-pfec[0] = PFEC_page_paged;
+*pfec = PFEC_page_paged;
 
 if ( missing & _PAGE_SHARED )
-pfec[0] = PFEC_page_shared;
+*pfec = PFEC_page_shared;
 
  out_tweak_pfec:
 /*
@@ -144,7 +144,7 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PAGING_LEVELS)(
  * The PFEC_insn_fetch flag is set only when NX or SMEP are enabled.
  */
 if ( !hvm_nx_enabled(v) && !hvm_smep_enabled(v) )
-pfec[0] &= ~PFEC_insn_fetch;
+*pfec &= ~PFEC_insn_fetch;
 
 return gfn_x(INVALID_GFN);
 }
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 7ea9d81..d9bf212 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -3727,30 +3727,30 @@ sh_gva_to_gfn(struct vcpu *v, struct p2m_domain *p2m,
 
 #if (SHADOW_OPTIMIZATIONS & SHOPT_VIRTUAL_TLB)
 /* Check the vTLB cache first */
-unsigned long vtlb_gfn = vtlb_lookup(v, va, pfec[0]);
+unsigned long vtlb_gfn = vtlb_lookup(v, va, *pfec);
 if ( VALID_GFN(vtlb_gfn) )
 return vtlb_gfn;
 #endif /* (SHADOW_OPTIMIZATIONS & SHOPT_VIRTUAL_TLB) */
 
-if ( (missing = sh_walk_guest_tables(v, va, , pfec[0])) != 0 )
+if ( (missing = sh_walk_guest_tables(v, va, , *pfec)) != 0 )
 {
 if ( (missing & _PAGE_PRESENT) )
-pfec[0] &= ~PFEC_page_present;
+*pfec &= ~PFEC_page_present;
 if ( missing & _PAGE_INVALID_BITS )
-pfec[0] |= PFEC_reserved_bit;
+*pfec |= PFEC_reserved_bit;
 /*
  * SDM Intel 64 Volume 3, Chapter Paging, PAGE-FAULT EXCEPTIONS:
  * The PFEC_insn_fetch flag is set only when NX or SMEP are enabled.
  */
 if ( is_hvm_vcpu(v) && !hvm_nx_enabled(v) && !hvm_smep_enabled(v) )
-pfec[0] &= ~PFEC_insn_fetch;
+*pfec &= ~PFEC_insn_fetch;
 return gfn_x(INVALID_GFN);
 }
 gfn = guest_walk_to_gfn();
 
 #if (SHADOW_OPTIMIZATIONS & SHOPT_VIRTUAL_TLB)
 /* Remember this successful VA->GFN translation for later. */
-vtlb_insert(v, va >> PAGE_SHIFT, gfn_x(gfn), pfec[0]);
+vtlb_insert(v, 

[Xen-devel] [PATCH v2 5/9] x86/pagewalk: Helpers for reserved bit handling

[Andrew Cooper]

Some bits are unconditionally reserved in pagetable entries, or reserved
because of alignment restrictions.  Other bits are reserved because of control
register configuration.

Introduce helpers which take an individual vcpu and guest pagetable entry, and
calculates whether any reserved bits are set.

While here, add a couple of newlines to aid readability.

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

v2:
 * Cleanup split out to earlier patches.
 * Switch guest_supports_pse36() to take a domain, and inherit hardwares pse36
   setting.
---
 xen/include/asm-x86/cpufeature.h |  1 +
 xen/include/asm-x86/guest_pt.h   | 96 
 2 files changed, 97 insertions(+)

diff --git a/xen/include/asm-x86/cpufeature.h b/xen/include/asm-x86/cpufeature.h
index 5978783..84cc51d 100644
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -38,6 +38,7 @@
 #define cpu_has_mtrr1
 #define cpu_has_pge 1
 #define cpu_has_pat 1
+#define cpu_has_pse36   boot_cpu_has(X86_FEATURE_PSE36)
 #define cpu_has_clflush boot_cpu_has(X86_FEATURE_CLFLUSH)
 #define cpu_has_mmx 1
 #define cpu_has_htt boot_cpu_has(X86_FEATURE_HTT)
diff --git a/xen/include/asm-x86/guest_pt.h b/xen/include/asm-x86/guest_pt.h
index 43061b7..4e5018d 100644
--- a/xen/include/asm-x86/guest_pt.h
+++ b/xen/include/asm-x86/guest_pt.h
@@ -42,6 +42,18 @@ gfn_to_paddr(gfn_t gfn)
 #undef get_gfn
 #define get_gfn(d, g, t) get_gfn_type((d), gfn_x(g), (t), P2M_ALLOC)
 
+/* Mask covering the reserved bits from superpage alignment. */
+#define SUPERPAGE_RSVD(bit) \
+(((1ULL << (bit)) - 1) & ~(_PAGE_PSE_PAT | (_PAGE_PSE_PAT - 1)))
+
+static inline uint32_t fold_pse36(uint64_t val)
+{
+return (val & ~(0x1ffULL << 13)) | ((val & (0x1ffULL << 32)) >> (32 - 13));
+}
+static inline uint64_t unfold_pse36(uint32_t val)
+{
+return (val & ~(0x1ffULL << 13)) | ((val & (0x1ffULL << 13)) << (32 - 13));
+}
 
 /* Types of the guest's page tables and access functions for them */
 
@@ -49,9 +61,13 @@ gfn_to_paddr(gfn_t gfn)
 
 #define GUEST_L1_PAGETABLE_ENTRIES 1024
 #define GUEST_L2_PAGETABLE_ENTRIES 1024
+
 #define GUEST_L1_PAGETABLE_SHIFT 12
 #define GUEST_L2_PAGETABLE_SHIFT 22
 
+#define GUEST_L1_PAGETABLE_RSVD   0
+#define GUEST_L2_PAGETABLE_RSVD   0
+
 typedef uint32_t guest_intpte_t;
 typedef struct { guest_intpte_t l1; } guest_l1e_t;
 typedef struct { guest_intpte_t l2; } guest_l2e_t;
@@ -86,21 +102,39 @@ static inline guest_l2e_t guest_l2e_from_gfn(gfn_t gfn, 
u32 flags)
 #else /* GUEST_PAGING_LEVELS != 2 */
 
 #if GUEST_PAGING_LEVELS == 3
+
 #define GUEST_L1_PAGETABLE_ENTRIES  512
 #define GUEST_L2_PAGETABLE_ENTRIES  512
 #define GUEST_L3_PAGETABLE_ENTRIES4
+
 #define GUEST_L1_PAGETABLE_SHIFT 12
 #define GUEST_L2_PAGETABLE_SHIFT 21
 #define GUEST_L3_PAGETABLE_SHIFT 30
+
+#define GUEST_L1_PAGETABLE_RSVD0x7ff0UL
+#define GUEST_L2_PAGETABLE_RSVD0x7ff0UL
+#define GUEST_L3_PAGETABLE_RSVD  \
+(0xfff0UL | _PAGE_GLOBAL | _PAGE_PSE | _PAGE_DIRTY | \
+ _PAGE_ACCESSED | _PAGE_USER | _PAGE_RW)
+
 #else /* GUEST_PAGING_LEVELS == 4 */
+
 #define GUEST_L1_PAGETABLE_ENTRIES  512
 #define GUEST_L2_PAGETABLE_ENTRIES  512
 #define GUEST_L3_PAGETABLE_ENTRIES  512
 #define GUEST_L4_PAGETABLE_ENTRIES  512
+
 #define GUEST_L1_PAGETABLE_SHIFT 12
 #define GUEST_L2_PAGETABLE_SHIFT 21
 #define GUEST_L3_PAGETABLE_SHIFT 30
 #define GUEST_L4_PAGETABLE_SHIFT 39
+
+#define GUEST_L1_PAGETABLE_RSVD0
+#define GUEST_L2_PAGETABLE_RSVD0
+#define GUEST_L3_PAGETABLE_RSVD0
+/* NB L4e._PAGE_GLOBAL is reserved for AMD, but ignored for Intel. */
+#define GUEST_L4_PAGETABLE_RSVD_PAGE_PSE
+
 #endif
 
 typedef l1_pgentry_t guest_l1e_t;
@@ -182,6 +216,21 @@ static inline bool guest_supports_l2_superpages(const 
struct vcpu *v)
|| (v->arch.hvm_vcpu.guest_cr[4] & X86_CR4_PSE)));
 }
 
+static inline bool guest_supports_pse36(const struct domain *d)
+{
+/*
+ * Only called in the context of 2-level guests, after
+ * guest_supports_l2_superpages() has indicated true.
+ *
+ * Once L2 superpages are active, here are no control register settings
+ * for the hardware pagewalk on the subject of PSE36.  If the guest
+ * constructs a PSE36 superpage on capable hardware, it will function
+ * irrespective of whether the feature is advertised.  Xen's model of
+ * performing a pagewalk should match.
+ */
+return paging_mode_hap(d) && cpu_has_pse36;
+}
+
 static inline bool 

[Xen-devel] [PATCH v2 7/9] x86/shadow: Use the pagewalk reserved bits helpers

[Andrew Cooper]

The shadow logic should not create a valid/present shadow of a guest PTE which
contains reserved bits from the guests point of view.  It is not guaranteed
that the hardware pagewalk will come to the same conclusion, and raise a
pagefault.

Shadows created on demand from the pagefault handler are fine because the
pagewalk over the guest tables will have injected the fault into the guest
rather than creating a shadow.

However, shadows created by sh_resync_l1() and sh_prefetch() haven't undergone
a pagewalk and need to account for reserved bits before creating the shadow.

In practice, this means a 3-level guest could previously cause PTEs with bits
63:52 set to be shadowed (and discarded).  This PTE should cause #PF[RSVD]
when encountered by hardware, but the installed shadow is valid and hardware
doesn't fault.

Reuse the pagewalk reserved bits helpers, and assert in
l?e_propagate_from_guest() that shadows are not attempted to be created with
reserved bits set.

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

v2:
 * Reword commit message, and include sh_resync_l1/sh_prefetch
---
 xen/arch/x86/mm/shadow/multi.c | 56 +-
 1 file changed, 45 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 4762e15..56114c7 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -745,6 +745,10 @@ l4e_propagate_from_guest(struct vcpu *v,
  shadow_l4e_t *sl4e,
  fetch_type_t ft)
 {
+if ( !mfn_eq(sl3mfn, INVALID_MFN) &&
+ (guest_l4e_get_flags(gl4e) & _PAGE_PRESENT) )
+ASSERT(!guest_l4e_rsvd_bits(v, gl4e));
+
 _sh_propagate(v, gl4e.l4, sl3mfn, sl4e, 4, ft, p2m_ram_rw);
 }
 
@@ -755,6 +759,10 @@ l3e_propagate_from_guest(struct vcpu *v,
  shadow_l3e_t *sl3e,
  fetch_type_t ft)
 {
+if ( !mfn_eq(sl2mfn, INVALID_MFN) &&
+ (guest_l3e_get_flags(gl3e) & _PAGE_PRESENT) )
+ASSERT(!guest_l3e_rsvd_bits(v, gl3e));
+
 _sh_propagate(v, gl3e.l3, sl2mfn, sl3e, 3, ft, p2m_ram_rw);
 }
 #endif // GUEST_PAGING_LEVELS >= 4
@@ -766,6 +774,10 @@ l2e_propagate_from_guest(struct vcpu *v,
  shadow_l2e_t *sl2e,
  fetch_type_t ft)
 {
+if ( !mfn_eq(sl1mfn, INVALID_MFN) &&
+ (guest_l2e_get_flags(gl2e) & _PAGE_PRESENT) )
+ASSERT(!guest_l2e_rsvd_bits(v, gl2e));
+
 _sh_propagate(v, gl2e.l2, sl1mfn, sl2e, 2, ft, p2m_ram_rw);
 }
 
@@ -777,6 +789,10 @@ l1e_propagate_from_guest(struct vcpu *v,
  fetch_type_t ft,
  p2m_type_t p2mt)
 {
+if ( !mfn_eq(gmfn, INVALID_MFN) &&
+ (guest_l1e_get_flags(gl1e) & _PAGE_PRESENT) )
+ASSERT(!guest_l1e_rsvd_bits(v, gl1e));
+
 _sh_propagate(v, gl1e.l1, gmfn, sl1e, 1, ft, p2mt);
 }
 
@@ -2157,7 +2173,8 @@ static int validate_gl4e(struct vcpu *v, void *new_ge, 
mfn_t sl4mfn, void *se)
 
 perfc_incr(shadow_validate_gl4e_calls);
 
-if ( guest_l4e_get_flags(new_gl4e) & _PAGE_PRESENT )
+if ( (guest_l4e_get_flags(new_gl4e) & _PAGE_PRESENT) &&
+ !guest_l4e_rsvd_bits(v, new_gl4e) )
 {
 gfn_t gl3gfn = guest_l4e_get_gfn(new_gl4e);
 mfn_t gl3mfn = get_gfn_query_unlocked(d, gfn_x(gl3gfn), );
@@ -2215,7 +2232,8 @@ static int validate_gl3e(struct vcpu *v, void *new_ge, 
mfn_t sl3mfn, void *se)
 
 perfc_incr(shadow_validate_gl3e_calls);
 
-if ( guest_l3e_get_flags(new_gl3e) & _PAGE_PRESENT )
+if ( (guest_l3e_get_flags(new_gl3e) & _PAGE_PRESENT) &&
+ !guest_l3e_rsvd_bits(v, new_gl3e) )
 {
 gfn_t gl2gfn = guest_l3e_get_gfn(new_gl3e);
 mfn_t gl2mfn = get_gfn_query_unlocked(d, gfn_x(gl2gfn), );
@@ -2248,7 +2266,8 @@ static int validate_gl2e(struct vcpu *v, void *new_ge, 
mfn_t sl2mfn, void *se)
 
 perfc_incr(shadow_validate_gl2e_calls);
 
-if ( guest_l2e_get_flags(new_gl2e) & _PAGE_PRESENT )
+if ( (guest_l2e_get_flags(new_gl2e) & _PAGE_PRESENT) &&
+ !guest_l2e_rsvd_bits(v, new_gl2e) )
 {
 gfn_t gl1gfn = guest_l2e_get_gfn(new_gl2e);
 if ( guest_supports_l2_superpages(v) &&
@@ -2289,7 +2308,7 @@ static int validate_gl1e(struct vcpu *v, void *new_ge, 
mfn_t sl1mfn, void *se)
 guest_l1e_t new_gl1e = *(guest_l1e_t *)new_ge;
 shadow_l1e_t *sl1p = se;
 gfn_t gfn;
-mfn_t gmfn;
+mfn_t gmfn = INVALID_MFN;
 p2m_type_t p2mt;
 int result = 0;
 #if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
@@ -2298,8 +2317,12 @@ static int validate_gl1e(struct vcpu *v, void *new_ge, 
mfn_t sl1mfn, void *se)
 
 perfc_incr(shadow_validate_gl1e_calls);
 
-gfn = guest_l1e_get_gfn(new_gl1e);
-gmfn = get_gfn_query_unlocked(d, gfn_x(gfn), );
+if ( (guest_l1e_get_flags(new_gl1e) & 

[Xen-devel] [PATCH v2 1/9] x86/cpuid: Sort cpu_has_* predicates by feature number

[Andrew Cooper]

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 

v2:
 * New
---
 xen/include/asm-x86/cpufeature.h | 117 ++-
 1 file changed, 66 insertions(+), 51 deletions(-)

diff --git a/xen/include/asm-x86/cpufeature.h b/xen/include/asm-x86/cpufeature.h
index b3d613f..5978783 100644
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -29,65 +29,80 @@
 #define CPUID_PM_LEAF6
 #define CPUID6_ECX_APERFMPERF_CAPABILITY 0x1
 
-#define cpu_has_fpu1
-#define cpu_has_de 1
-#define cpu_has_pse1
-#define cpu_has_pge1
-#define cpu_has_pat1
-#define cpu_has_apic   boot_cpu_has(X86_FEATURE_APIC)
-#define cpu_has_sepboot_cpu_has(X86_FEATURE_SEP)
-#define cpu_has_mtrr   1
-#define cpu_has_mmx1
-#define cpu_has_sse3   boot_cpu_has(X86_FEATURE_SSE3)
-#define cpu_has_ssse3  boot_cpu_has(X86_FEATURE_SSSE3)
-#define cpu_has_sse4_1 boot_cpu_has(X86_FEATURE_SSE4_1)
-#define cpu_has_sse4_2 boot_cpu_has(X86_FEATURE_SSE4_2)
-#define cpu_has_pclmulqdq  boot_cpu_has(X86_FEATURE_PCLMULQDQ)
-#define cpu_has_popcnt boot_cpu_has(X86_FEATURE_POPCNT)
-#define cpu_has_aesni  boot_cpu_has(X86_FEATURE_AESNI)
-#define cpu_has_httboot_cpu_has(X86_FEATURE_HTT)
-#define cpu_has_nx boot_cpu_has(X86_FEATURE_NX)
-#define cpu_has_clflushboot_cpu_has(X86_FEATURE_CLFLUSH)
-#define cpu_has_page1gbboot_cpu_has(X86_FEATURE_PAGE1GB)
-#define cpu_has_fsgsbase   boot_cpu_has(X86_FEATURE_FSGSBASE)
-#define cpu_has_aperfmperf boot_cpu_has(X86_FEATURE_APERFMPERF)
-#define cpu_has_smepboot_cpu_has(X86_FEATURE_SMEP)
-#define cpu_has_smapboot_cpu_has(X86_FEATURE_SMAP)
-#define cpu_has_fpu_sel (!boot_cpu_has(X86_FEATURE_NO_FPU_SEL))
-#define cpu_has_ffxsr   ((boot_cpu_data.x86_vendor == X86_VENDOR_AMD) \
- && boot_cpu_has(X86_FEATURE_FFXSR))
-#define cpu_has_x2apic  boot_cpu_has(X86_FEATURE_X2APIC)
+/* CPUID level 0x0001.edx */
+#define cpu_has_fpu 1
+#define cpu_has_de  1
+#define cpu_has_pse 1
+#define cpu_has_apicboot_cpu_has(X86_FEATURE_APIC)
+#define cpu_has_sep boot_cpu_has(X86_FEATURE_SEP)
+#define cpu_has_mtrr1
+#define cpu_has_pge 1
+#define cpu_has_pat 1
+#define cpu_has_clflush boot_cpu_has(X86_FEATURE_CLFLUSH)
+#define cpu_has_mmx 1
+#define cpu_has_htt boot_cpu_has(X86_FEATURE_HTT)
+
+/* CPUID level 0x0001.ecx */
+#define cpu_has_sse3boot_cpu_has(X86_FEATURE_SSE3)
+#define cpu_has_pclmulqdq   boot_cpu_has(X86_FEATURE_PCLMULQDQ)
+#define cpu_has_monitor boot_cpu_has(X86_FEATURE_MONITOR)
+#define cpu_has_vmx boot_cpu_has(X86_FEATURE_VMX)
+#define cpu_has_eistboot_cpu_has(X86_FEATURE_EIST)
+#define cpu_has_ssse3   boot_cpu_has(X86_FEATURE_SSSE3)
+#define cpu_has_cx16boot_cpu_has(X86_FEATURE_CX16)
+#define cpu_has_pdcmboot_cpu_has(X86_FEATURE_PDCM)
 #define cpu_has_pcidboot_cpu_has(X86_FEATURE_PCID)
+#define cpu_has_sse4_1  boot_cpu_has(X86_FEATURE_SSE4_1)
+#define cpu_has_sse4_2  boot_cpu_has(X86_FEATURE_SSE4_2)
+#define cpu_has_x2apic  boot_cpu_has(X86_FEATURE_X2APIC)
+#define cpu_has_popcnt  boot_cpu_has(X86_FEATURE_POPCNT)
+#define cpu_has_aesni   boot_cpu_has(X86_FEATURE_AESNI)
 #define cpu_has_xsave   boot_cpu_has(X86_FEATURE_XSAVE)
 #define cpu_has_avx boot_cpu_has(X86_FEATURE_AVX)
+#define cpu_has_rdrand  boot_cpu_has(X86_FEATURE_RDRAND)
+#define cpu_has_hypervisor  boot_cpu_has(X86_FEATURE_HYPERVISOR)
+
+/* CPUID level 0x8001.edx */
+#define cpu_has_nx  boot_cpu_has(X86_FEATURE_NX)
+#define cpu_has_ffxsr   ((boot_cpu_data.x86_vendor == X86_VENDOR_AMD) \
+ && boot_cpu_has(X86_FEATURE_FFXSR))
+#define cpu_has_page1gb boot_cpu_has(X86_FEATURE_PAGE1GB)
+#define cpu_has_rdtscp  boot_cpu_has(X86_FEATURE_RDTSCP)
+
+/* CPUID level 0x8001.ecx */
+#define cpu_has_cmp_legacy  boot_cpu_has(X86_FEATURE_CMP_LEGACY)
+#define cpu_has_svm boot_cpu_has(X86_FEATURE_SVM)
+#define cpu_has_sse4a   boot_cpu_has(X86_FEATURE_SSE4A)
 #define cpu_has_lwp boot_cpu_has(X86_FEATURE_LWP)
+#define cpu_has_tbm boot_cpu_has(X86_FEATURE_TBM)
+
+/* CPUID level 0x000D:1.eax */
+#define cpu_has_xsaveoptboot_cpu_has(X86_FEATURE_XSAVEOPT)
+#define cpu_has_xsavec  boot_cpu_has(X86_FEATURE_XSAVEC)
+#define cpu_has_xgetbv1 boot_cpu_has(X86_FEATURE_XGETBV1)
+#define cpu_has_xsaves  boot_cpu_has(X86_FEATURE_XSAVES)
+
+/* CPUID 

[Xen-devel] [PATCH v2 0/9] Fixes to pagetable handling

[Andrew Cooper]

This series has been a long time in preparation (i.e. most of the 4.8 and 4.9
dev cycles).  It started when I tried to make an XTF PoC for XSA-176, and
stumbled upon the the _PAGE_PAGED aliasing issue (see patch 7) which caused by
PoC to be descheduled waiting for (a non-existent) paging agent to respond.

This series is built upon:
  1) The switch to using _Bool. I spent rather too long trying to debug why
 CR0.WP wasn't behaving properly, and it was down to static inline bool_t
 guest_wp_enabled().
  2) The series to switch emulation to using system-segment relative memory
 accesses (directly relevant to patches 1 and 2), which in turn resulted
 in the discovery of XSA-191.
  3) The CPUID improvement work to get maxphysaddr into a sensibly audited
 state, and sensibly accessible location.

Patches 1-4 and 8-9 are new in v2, mostly items requested to be split out in
review from v1.

Andrew Cooper (9):
  x86/cpuid: Sort cpu_has_* predicates by feature number
  x86/pagewalk: Use pointer syntax for pfec parameter
  x86/shadow: Drop VALID_GFN()
  x86/pagewalk: Clean up guest_supports_* predicates
  x86/pagewalk: Helpers for reserved bit handling
  x86/pagewalk: Re-implement the pagetable walker
  x86/shadow: Use the pagewalk reserved bits helpers
  x86/pagewalk: Improve the logic behind setting access and dirty bits
  x86/pagewalk: non-functional cleanup

 xen/arch/x86/mm/guest_walk.c  | 574 +-
 xen/arch/x86/mm/hap/guest_walk.c  |  33 +--
 xen/arch/x86/mm/hap/nested_ept.c  |   2 +-
 xen/arch/x86/mm/p2m.c |  17 +-
 xen/arch/x86/mm/shadow/multi.c|  99 ---
 xen/include/asm-x86/cpufeature.h  | 118 
 xen/include/asm-x86/guest_pt.h| 215 +++---
 xen/include/asm-x86/hvm/hvm.h |   4 -
 xen/include/asm-x86/p2m.h |   2 +-
 xen/include/asm-x86/page.h|   3 -
 xen/include/asm-x86/paging.h  |   7 +-
 xen/include/asm-x86/processor.h   |   2 +
 xen/include/asm-x86/x86_64/page.h |   6 -
 13 files changed, 642 insertions(+), 440 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH v2 3/9] x86/shadow: Drop VALID_GFN()

[Andrew Cooper]

There is only one single user of VALID_GFN().  Inline the macro to remove the
added layer of indirection in sh_gva_to_gfn()

Signed-off-by: Andrew Cooper 
---
CC: Tim Deegan 

v2:
 * New
---
 xen/arch/x86/mm/shadow/multi.c | 2 +-
 xen/include/asm-x86/guest_pt.h | 2 --
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index d9bf212..63c7ab5 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -3728,7 +3728,7 @@ sh_gva_to_gfn(struct vcpu *v, struct p2m_domain *p2m,
 #if (SHADOW_OPTIMIZATIONS & SHOPT_VIRTUAL_TLB)
 /* Check the vTLB cache first */
 unsigned long vtlb_gfn = vtlb_lookup(v, va, *pfec);
-if ( VALID_GFN(vtlb_gfn) )
+if ( vtlb_gfn != gfn_x(INVALID_GFN) )
 return vtlb_gfn;
 #endif /* (SHADOW_OPTIMIZATIONS & SHOPT_VIRTUAL_TLB) */
 
diff --git a/xen/include/asm-x86/guest_pt.h b/xen/include/asm-x86/guest_pt.h
index 6a06ba0..bedc771 100644
--- a/xen/include/asm-x86/guest_pt.h
+++ b/xen/include/asm-x86/guest_pt.h
@@ -32,8 +32,6 @@
 #error GUEST_PAGING_LEVELS not defined
 #endif
 
-#define VALID_GFN(m) (m != gfn_x(INVALID_GFN))
-
 static inline paddr_t
 gfn_to_paddr(gfn_t gfn)
 {
-- 
2.1.4


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

[Xen-devel] [PATCH v2 4/9] x86/pagewalk: Clean up guest_supports_* predicates

[Andrew Cooper]

Switch them to returning bool, and taking const parameters.

Rename guest_supports_superpages() to guest_supports_l2_superpages() to
indicate which level of pagetables it is actually referring to, and rename
guest_supports_1G_superpages() to guest_supports_l3_superpages() for
consistency.

guest_supports_l3_superpages() is a static property of the domain, rather than
control register settings, so is switched to take a domain pointer.
hvm_pse1gb_supported() is inlined into its sole user because it isn't strictly
hvm-specific (it is hap-specific) and really should be beside a comment
explaining why the cpuid policy is ignored.

While cleaning up part of the file, clean up all trailing whilespace, and fix
one comment which accidently refered to PG living in CR4 rather than CR0.

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

v2:
 * New
---
 xen/arch/x86/mm/guest_walk.c   |  4 +--
 xen/arch/x86/mm/shadow/multi.c | 10 +++
 xen/include/asm-x86/guest_pt.h | 61 --
 xen/include/asm-x86/hvm/hvm.h  |  4 ---
 4 files changed, 42 insertions(+), 37 deletions(-)

diff --git a/xen/arch/x86/mm/guest_walk.c b/xen/arch/x86/mm/guest_walk.c
index 8187226..11f4c5d 100644
--- a/xen/arch/x86/mm/guest_walk.c
+++ b/xen/arch/x86/mm/guest_walk.c
@@ -272,7 +272,7 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
 /* _PAGE_PSE_PAT not set: remove _PAGE_PAT from flags. */
 flags &= ~_PAGE_PAT;
 
-if ( !guest_supports_1G_superpages(v) )
+if ( !guest_supports_l3_superpages(d) )
 rc |= _PAGE_PSE | _PAGE_INVALID_BIT;
 if ( gfn_x(start) & GUEST_L3_GFN_MASK & ~0x1 )
 rc |= _PAGE_INVALID_BITS;
@@ -326,7 +326,7 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
 }
 rc |= ((gflags & mflags) ^ mflags);
 
-pse2M = (gflags & _PAGE_PSE) && guest_supports_superpages(v); 
+pse2M = (gflags & _PAGE_PSE) && guest_supports_l2_superpages(v);
 
 if ( pse2M )
 {
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 63c7ab5..52cef46 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -238,7 +238,7 @@ shadow_check_gwalk(struct vcpu *v, unsigned long va, walk_t 
*gw, int version)
 l2p = (guest_l2e_t *)v->arch.paging.shadow.guest_vtable;
 mismatch |= (gw->l2e.l2 != l2p[guest_l2_table_offset(va)].l2);
 #endif
-if ( !(guest_supports_superpages(v) &&
+if ( !(guest_supports_l2_superpages(v) &&
(guest_l2e_get_flags(gw->l2e) & _PAGE_PSE)) )
 {
 l1p = map_domain_page(gw->l1mfn);
@@ -310,7 +310,7 @@ gw_remove_write_accesses(struct vcpu *v, unsigned long va, 
walk_t *gw)
 rc |= GW_RMWR_FLUSHTLB;
 #endif /* GUEST_PAGING_LEVELS >= 3 */
 
-if ( !(guest_supports_superpages(v) &&
+if ( !(guest_supports_l2_superpages(v) &&
(guest_l2e_get_flags(gw->l2e) & _PAGE_PSE))
 #if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
  && !mfn_is_out_of_sync(gw->l1mfn)
@@ -660,7 +660,7 @@ _sh_propagate(struct vcpu *v,
 if ( unlikely(((level == 1) ||
((level == 2) &&
 (gflags & _PAGE_PSE) &&
-guest_supports_superpages(v)))
+guest_supports_l2_superpages(v)))
   && !(gflags & _PAGE_DIRTY)) )
 sflags &= ~_PAGE_RW;
 
@@ -1846,7 +1846,7 @@ static shadow_l1e_t * shadow_get_and_create_l1e(struct 
vcpu *v,
 /* No l1 shadow installed: find and install it. */
 if ( !(flags & _PAGE_PRESENT) )
 return NULL; /* No guest page. */
-if ( guest_supports_superpages(v) && (flags & _PAGE_PSE) )
+if ( guest_supports_l2_superpages(v) && (flags & _PAGE_PSE) )
 {
 /* Splintering a superpage */
 gfn_t l2gfn = guest_l2e_get_gfn(gw->l2e);
@@ -2251,7 +2251,7 @@ static int validate_gl2e(struct vcpu *v, void *new_ge, 
mfn_t sl2mfn, void *se)
 if ( guest_l2e_get_flags(new_gl2e) & _PAGE_PRESENT )
 {
 gfn_t gl1gfn = guest_l2e_get_gfn(new_gl2e);
-if ( guest_supports_superpages(v) &&
+if ( guest_supports_l2_superpages(v) &&
  (guest_l2e_get_flags(new_gl2e) & _PAGE_PSE) )
 {
 // superpage -- need to look up the shadow L1 which holds the
diff --git a/xen/include/asm-x86/guest_pt.h b/xen/include/asm-x86/guest_pt.h
index bedc771..43061b7 100644
--- a/xen/include/asm-x86/guest_pt.h
+++ b/xen/include/asm-x86/guest_pt.h
@@ -2,7 +2,7 @@
  * xen/asm-x86/guest_pt.h
  *
  * Types and accessors for guest pagetable entries, as distinct from
- * Xen's pagetable types. 
+ * Xen's pagetable types.
  *
  * Users must #define GUEST_PAGING_LEVELS to 2, 3 or 4 before including
  * this file.
@@ -10,17 +10,17 @@
  * Parts of this code are 

Re: [Xen-devel] [GSoC] GSoC Introduction : Fuzzing Xen hypercall interface

[Wei Liu]

On Thu, Mar 16, 2017 at 04:53:38PM +0100, Felix Schmoll wrote:
[...]
> 
> Hi,
> 
> I installed Xen from source and I figured out that for the hypercall I have
> to make a two-line change in xen/xen/common/kernel.c and a couple of
> headers. I mostly went with what I got by grepping for the
> "xen_version"-hypercall. It seems really basic but after struggling with
> this for quite a while I have some questions:
> 
> 1.
> -How do I test this? The usual way to make hypercalls seems to use the
> libxc-library, so do I have to change that as well?

Good question. You can do it in the libxc library. You write a function
for libxc, which then calls into the libxencall library to issue the
hypercall. There are plenty of examples there.

> -The "xen_version"-hypercall had a couple of COMPAT_versions, do I need
> them? This seems to be related with if I need to support both ARM and x86,
> although I'm really not sure here. Is it fine to just choose to support the
> one which my hypervisor is running on?

The compat layer is to support 32 bit guests on 64 bit Xen. You can
ignore that for this simple exercise, just run 64 bit guests on 64 bit
hypervisor.


> -Do I need to make changes in the XSM module? Again, this pops up when
> grepping for xen_version but it's disabled by default anyways and I'd
> otherwise just try to have a minimal working set.

Ignore that for now.

> 
> 2.
> -A stub for what? dom0?
> 

You will need to provide a function in order to use the trace-pc
mechanism. For now just provide an empty stub function is fine.

When it comes to the real project, the function will be filled in.

Again, feel free to ask more questions.

Wei.

> Felix

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

Re: [Xen-devel] [PATCH v2 14/27] ARM: vGICv3: introduce basic ITS emulation bits

[Shanker Donthineni]

Hi Andre,


On 03/16/2017 06:20 AM, Andre Przywara wrote:
> Create a new file to hold the emulation code for the ITS widget.
> For now we emulate the memory mapped ITS registers and provide a stub
> to introduce the ITS command handling framework (but without actually
> emulating any commands at this time).
>
> Signed-off-by: Andre Przywara 
> ---
>  xen/arch/arm/Makefile |   1 +
>  xen/arch/arm/vgic-v3-its.c| 487 
> ++
>  xen/arch/arm/vgic-v3.c|   9 -
>  xen/include/asm-arm/gic_v3_defs.h |  19 ++
>  4 files changed, 507 insertions(+), 9 deletions(-)
>  create mode 100644 xen/arch/arm/vgic-v3-its.c
>
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 02a8737..e7ce2c83 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -47,6 +47,7 @@ obj-y += traps.o
>  obj-y += vgic.o
>  obj-y += vgic-v2.o
>  obj-$(CONFIG_HAS_GICV3) += vgic-v3.o
> +obj-$(CONFIG_HAS_ITS) += vgic-v3-its.o
>  obj-y += vm_event.o
>  obj-y += vtimer.o
>  obj-y += vpsci.o
> diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
> new file mode 100644
> index 000..5337638
> --- /dev/null
> +++ b/xen/arch/arm/vgic-v3-its.c
> @@ -0,0 +1,487 @@
> +/*
> + * xen/arch/arm/vgic-v3-its.c
> + *
> + * ARM Interrupt Translation Service (ITS) emulation
> + *
> + * Andre Przywara 
> + * Copyright (c) 2016,2017 ARM Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; under version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Data structure to describe a virtual ITS */
> +struct virt_its {
> +struct domain *d;
> +spinlock_t vcmd_lock;   /* protects the virtual command buffer */
> +uint64_t cbaser;
> +uint64_t *cmdbuf;
> +int cwriter;
> +int creadr;
> +spinlock_t its_lock;/* protects the collection and device tables 
> */
> +uint64_t baser0, baser1;
> +uint16_t *coll_table;
> +int max_collections;
> +uint64_t *dev_table;
> +int max_devices;
> +bool enabled;
> +};
> +
> +/*
> + * An Interrupt Translation Table Entry: this is indexed by a
> + * DeviceID/EventID pair and is located in guest memory.
> + */
> +struct vits_itte
> +{
> +uint32_t vlpi;
> +uint16_t collection;
> +};
> +
> +/**
> + * Functions that handle ITS commands *
> + **/
> +
> +static uint64_t its_cmd_mask_field(uint64_t *its_cmd,
> +   int word, int shift, int size)
> +{
> +return (le64_to_cpu(its_cmd[word]) >> shift) & (BIT(size) - 1);
> +}
> +
> +#define its_cmd_get_command(cmd)its_cmd_mask_field(cmd, 0,  0,  8)
> +#define its_cmd_get_deviceid(cmd)   its_cmd_mask_field(cmd, 0, 32, 32)
> +#define its_cmd_get_size(cmd)   its_cmd_mask_field(cmd, 1,  0,  5)
> +#define its_cmd_get_id(cmd) its_cmd_mask_field(cmd, 1,  0, 32)
> +#define its_cmd_get_physical_id(cmd)its_cmd_mask_field(cmd, 1, 32, 32)
> +#define its_cmd_get_collection(cmd) its_cmd_mask_field(cmd, 2,  0, 16)
> +#define its_cmd_get_target_addr(cmd)its_cmd_mask_field(cmd, 2, 16, 32)
> +#define its_cmd_get_validbit(cmd)   its_cmd_mask_field(cmd, 2, 63,  1)
> +
> +#define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
> +
> +static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
> +uint32_t writer)
> +{
> +uint64_t *cmdptr;
> +
> +if ( !its->cmdbuf )
> +return -1;
> +
> +if ( writer >= ITS_CMD_BUFFER_SIZE(its->cbaser) )
> +return -1;
> +
> +spin_lock(>vcmd_lock);
> +
> +while ( its->creadr != writer )
> +{
> +cmdptr = its->cmdbuf + (its->creadr / sizeof(*its->cmdbuf));
> +switch (its_cmd_get_command(cmdptr))
> +{
> +case GITS_CMD_SYNC:
> +/* We handle ITS commands synchronously, so we ignore SYNC. */
> + break;
> +default:
> +gdprintk(XENLOG_G_WARNING, "ITS: unhandled ITS command %ld\n",
> +   its_cmd_get_command(cmdptr));
> +break;
> +}
> +
> +its->creadr += ITS_CMD_SIZE;
> +if ( 

Re: [Xen-devel] [GSoC] GSoC Introduction : Fuzzing Xen hypercall interface

[Felix Schmoll]

2017-03-13 12:14 GMT+01:00 Wei Liu :

> Hi Felix
>
> Thanks for your interest in this project.
>
> On Sun, Mar 12, 2017 at 09:48:11PM +0100, Felix Ekkehard Schmoll wrote:
> > Hi,
> >
> > I’m interested in the “Fuzzing Xen hypercall interface” project so I
> > just wanted to introduce myself:
> >
> > I’m a third-year undergraduate CS student at Jacobs University in
> > Bremen, Germany. It’s a rather small university and rather young but
> > quite successful in the national rankings (*brag*).
> >
> > Last semester I spent as part of an exchange program at CMU where I
> > took the sort of notorious 15-410 Operating Systems course where you
> > have to implement a kernel from scratch in 6 weeks. There the
> > professor (amazing guy) mentioned/promoted GSoC quite a couple of
> > times, and this seems like a really cool project to work on.
> >
> > From the course I have quite a substantial amount of experience in C
> > and ASM on x86, of the GCC toolchain and obviously of kernel
> > programming. I don’t really have any experience with fuzzing yet, but
> > I’m sure I’ll figure that out.
> >
> > I’d appreciate it if you could point me to some small patches I could
> > work on to get going (sorry if I missed the link to it).
> >
> > Also any other comments are of course welcome.
>
> This project is rather challenging given the time scale. As a starter,
> please install Xen from source and try it out -- you can find
> instructions on how to install on the wiki.
>
> Please also have a look at American Fuzzy Lop (the fuzzer we currently
> use) and play with it a bit.
>
> Then, as a small exercise, please provide patches against xen.git for
> two tasks:
>
> 1. implement a hypercall to get back the domain id of the caller domain;
> 2. check out gcc 6's -fsanitize-coverage=trace-pc option and build the
>hypervisor with that enabled -- building with a stub is fine;
>
> Please then provide some ideas on how you would approach this project.
>
> I know the tasks I described are quite high level so please don't
> hesitate to ask questions.
>
> Note that we don't have to finish all goals listed on the wiki page.
> Realistically I think if we manage to extract the execution paths from
> xen within three months and commit that in xen.git that would be rather
> great progress.
>
> Wei.
>
> >
> > Felix
>


Hi,

I installed Xen from source and I figured out that for the hypercall I have
to make a two-line change in xen/xen/common/kernel.c and a couple of
headers. I mostly went with what I got by grepping for the
"xen_version"-hypercall. It seems really basic but after struggling with
this for quite a while I have some questions:

1.
-How do I test this? The usual way to make hypercalls seems to use the
libxc-library, so do I have to change that as well?
-The "xen_version"-hypercall had a couple of COMPAT_versions, do I need
them? This seems to be related with if I need to support both ARM and x86,
although I'm really not sure here. Is it fine to just choose to support the
one which my hypervisor is running on?
-Do I need to make changes in the XSM module? Again, this pops up when
grepping for xen_version but it's disabled by default anyways and I'd
otherwise just try to have a minimal working set.

2.
-A stub for what? dom0?

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

Re: [Xen-devel] "Hello Xen Project" Book.

[Jason Long]

Thank you so much.
Finally, we see that someone thinking about beginners.
In my idea Linux Foundation must support this project.

On Wed, 3/15/17, Lars Kurth  wrote:

 Subject: Re: [Xen-devel] "Hello Xen Project" Book.
 To: "Mohsen" 
 Cc: "xen-de...@lists.xenproject.org" , 
"xen-us...@lists.xenproject.org" 
 Date: Wednesday, March 15, 2017, 5:34 AM
 
 Hi Mohsen,
 
 > On 15 Mar 2017, at 09:50, Mohsen 
 wrote:
 > 
 > Dear Xen Project community members,
 > 
 > I have written a Xen book recently (pdf attached) which
 is aimed at teaching Xen newbies. I would like to make the
 book available to the Xen Project under a CC-BY-SA-3.0
 license. Ideally, I would like to publish the content on the
 Xen Project wiki in an editable form, such that others can
 contribute and build on it and it stays up-to-date. I also
 noticed that the Xen Wiki has the 
https://www.mediawiki.org/wiki/Extension:Collection
 extension, which should make it possible to create a
 PDF, ODF or DocBook from the pages for those who want a
 manual rather than wiki pages.
 
 Thank you for doing this. As far as I can tell the fact that
 you published the book under CC-BY-SA-3.0 would make it
 possible to move the content to the wiki. 
 
 > I had a conversation with Lars to check whether this is
 possible and he believes it is. He suggests that first we
 upload the book as pdf to the wiki and as a second step,
 agree an information architecture and then convert the book
 to mark-down. There are a number of conversion tools which
 should get us there some of the way, with a bit of cleanup
 and beautification needed after the initial import. I can
 make the source available in a format that makes conversion
 to markdown easier.
 
 We do need to find a way to convert the content into
 markdown format though, which may be quite a bit of work.
 
 I have done this before for html pages, converting them into
 docman markdown. I have not checked whether there are online
 or command line tools which do that for mediawiki markdown.
 In any case, the conversion is fundamentally doable,
 although it will be somewhat tedious to do this. If anyone
 has more experience, please share and advise what the best
 way forward is.
 
 The main problem that I faced when doing something similar
 were tables, figures and other more advanced formatting.
 Much of this may get lost or "corrupted" in some way and
 will have to be re-introduced post conversion.  
 
 @Mohsen: as far as I recall, you used Word or LibreOffice to
 create the book? Is that correct? If so, it should be
 possible to save it in html, which would ensure that figures
 and so on are saved in some sensible way. We would probably
 need to find a temporary location where to store this. And
 we can start experimenting a little and maybe provide a
 quick guide on how to do this.
 
 As for the information architecture, I was thinking about a
 structure such as ...
 
 https://wiki.xenproject.org/wiki/ 
 https://wiki.xenproject.org/wiki//title_and_credits
 
 https://wiki.xenproject.org/wiki//
 
 https://wiki.xenproject.org/wiki///
 
 ... a separate article for each article in the book, such as
 "Virtualization and Security". As a first step, we would
 probably keep the original chapter structure. 
 
 This would then look something like ...
 https://wiki.xenproject.org/wiki/HelloXenProject
 https://wiki.xenproject.org/wiki/HelloXenProject/0/Title
 https://wiki.xenproject.org/wiki/HelloXenProject/0/Credits
 https://wiki.xenproject.org/wiki/HelloXenProject/0/Licence
 https://wiki.xenproject.org/wiki/HelloXenProject/1-Intro
 https://wiki.xenproject.org/wiki/HelloXenProject/1-Intro/History
 https://wiki.xenproject.org/wiki/HelloXenProject/1-Intro/TypesOfVirtualization
 
 We may need some other extensible numbering scheme, which
 would make it easy to create PDF's with 
https://www.mediawiki.org/wiki/Extension:Collection -
 again, this is something I don't have experience with.
 
 > What do people think? Is this a good idea? Would anyone
 be willing to help? I am not very familiar with Markdown and
 would need someone else to help with the wikification of the
 book. Lars already volunteered to help.
 
 I will definitely help, but this would be an activity, which
 could easily be distributed. So help from others would be
 very highly appreciated.
 
 Best Regards
 Lars
 
 
 ___
 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] x86/time: Don't use virtual TSC if host and guest frequencies are equal

[Jan Beulich]

>>> On 16.03.17 at 15:22,  wrote:
> On 03/16/2017 09:31 AM, Jan Beulich wrote:
> On 16.03.17 at 13:44,  wrote:
>>> On 03/16/2017 06:40 AM, Jan Beulich wrote:
>>> On 15.03.17 at 20:48,  wrote:
> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -2051,17 +2051,11 @@ void tsc_set_info(struct domain *d,
>  d->arch.vtsc_offset = get_s_time() - elapsed_nsec;
>  d->arch.tsc_khz = gtsc_khz ?: cpu_khz;
>  set_time_scale(>arch.vtsc_to_ns, d->arch.tsc_khz * 1000);
> -/*
> - * In default mode use native TSC if the host has safe TSC and:
> - *  HVM/PVH: host and guest frequencies are the same (either
> - *   "naturally" or via TSC scaling)
> - *  PV: guest has not migrated yet (and thus arch.tsc_khz == 
> cpu_khz)
> - */
> +
>  if ( tsc_mode == TSC_MODE_DEFAULT && host_tsc_is_safe() &&
> - (has_hvm_container_domain(d) ?
> -  (d->arch.tsc_khz == cpu_khz ||
> -   hvm_get_tsc_scaling_ratio(d->arch.tsc_khz)) :
> -  incarnation == 0) )
> + (d->arch.tsc_khz == cpu_khz || incarnation == 0 ||
 Is the incarnation comparison really needed here, i.e. doesn't it
 being zero imply the two frequencies to match in default mode?
>>> It is not necessary but I wanted to keep it for clarity so that it is
>>> explicit that when a domain is born we don't use vtsc.
>> Well, considering the history here, I think its presence is rather
>> going to raise questions than to answer any, so if anything I'd
>> suggest to have an ASSERT() to that effect, at once serving as
>> sort of documentation. But I may be the only one thinking this
>> way ...
> 
> 
> Haven't thought about an ASSERT. I can do that. Something like
> 
> ASSERT(gtsc_khz == 0 ? incarnation == 0 : true);

ASSERT(incarnation || d->arch.tsc_khz == cpu_khz);

Jan


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