Re: [Xen-devel] [PATCH v7 3/3] tools & docs: add tools and docs support for Intel CDP

[Chao Peng]

> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 365798b..8db0132 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -8434,6 +8434,8 @@ static int psr_cat_hwinfo(void)
>  }
>  printf("%-16s: %u\n", "Socket ID", info[i].id);
>  printf("%-16s: %uKB\n", "L3 Cache", l3_cache_size);
> +printf("%-16s: %s\n", "CDP Status",
> +   info->cdp_enabled ? "Enabled" : "Disabled");

Sorry I didn't notice this before but I guess 'info->cdp_enabled' here
really would be 'info[i].cdp_enabled' as CDP status is per-socket.
Current code will always print the data for the first socket in each
iteration, which is undesirable.

With this and the indention issue proposed by Ian being fixed:

Reviewed-by: Chao Peng 

>  printf("%-16s: %u\n", "Maximum COS", info[i].cos_max);
>  printf("%-16s: %u\n", "CBM length", info[i].cbm_len);
>  printf("%-16s: %#llx\n", "Default CBM",
> @@ -8445,29 +8447,46 @@ out:
>  return rc;
>  }

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

Re: [Xen-devel] [PATCH v7 1/3] x86: Support enable CDP by boot parameter and add get CDP status

[Chao Peng]

On Tue, Oct 13, 2015 at 04:53:44PM +0800, He Chen wrote:
> Add boot parameter `psr=cdp` to enable CDP at boot time.
> Intel Code/Data Prioritization (CDP) feature is based on CAT. Note that
> cos_max would be half when CDP is on. struct psr_cat_cbm is extended to
> support CDP operation. Extend psr_get_cat_l3_info sysctl to get CDP
> status.
> 
> Signed-off-by: He Chen 
> Reviewed-by: Andrew Cooper 
> ---
> Changes in v7:
> * write CDP data mask (mask1) before turning CDP on
> * check CDP status before clear enabled bit in function cat_cpu_fini

Reviewed-by: Chao Peng 

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

Re: [Xen-devel] [PATCH V7 3/7] libxl: add pvusb API

[Chun Yan Liu]

On 10/13/2015 09:15 PM, George Dunlap wrote:

On 13/10/15 02:46, Chun Yan Liu wrote:


On 10/12/2015 09:46 PM, George Dunlap wrote:

On 12/10/15 08:19, Chun Yan Liu wrote:

+
+usbinfo->devnum = usb->u.hostdev.hostaddr;
+usbinfo->busnum = usb->u.hostdev.hostbus;
+
+busid = usb_busaddr_to_busid(gc, usb->u.hostdev.hostbus,
+ usb->u.hostdev.hostaddr);
+if (!busid) {
+rc = ERROR_FAIL;
+goto out;
+}
+
+filename = GCSPRINTF(SYSFS_USB_DEV"/%s/idVendor", busid);
+if (!libxl_read_sysfs_file_contents(ctx, filename, , NULL))
+sscanf(buf, "%" SCNx16, >idVendor);
+
+filename = GCSPRINTF(SYSFS_USB_DEV"/%s/idProduct", busid);
+if (!libxl_read_sysfs_file_contents(ctx, filename, , NULL))
+sscanf(buf, "%" SCNx16, >idProduct);
+
+filename = GCSPRINTF(SYSFS_USB_DEV"/%s/manufacturer", busid);
+if (!libxl_read_sysfs_file_contents(ctx, filename, ,
) &&
+buflen > 0) {
+/* replace \n to \0 */
+if (((char *)buf)[buflen - 1] == '\n')
+((char *)buf)[buflen - 1] = '\0';
+usbinfo->manuf = libxl__strdup(NOGC, buf);
+   }
+
+filename = GCSPRINTF(SYSFS_USB_DEV"/%s/product", busid);
+if (!libxl_read_sysfs_file_contents(ctx, filename, ,
) &&
+buflen > 0) {
+/* replace \n to \0 */
+if (((char *)buf)[buflen - 1] == '\n')
+((char *)buf)[buflen - 1] = '\0';
+usbinfo->prod = libxl__strdup(NOGC, buf);
+}

   Basically, starting here, we have information which won't be
available
if we're using a pvusb driver domain.
   This information is nice-to-have, but I don't think this
information is
directly relevant to libxl or xl; the funcitonality to get this
information is available from other libraries like libusb.  I'm
inclined
to say that if we want to have pvusb driver domains (and I think we
do),
we should just get rid of this information.

For command 'xl usb-list', those information should be reported to user.
Do you mean we could call libusb to get thoes information directly in
xl toolstack and get rid of this function?

I think we can keep the function, since every other device type has the
function XXX_getinfo. But here we could check backend_domid, for
backend=dom0, doing above work; for backend!=dom0 (e.g. pvusb
driver domain, no matter how, it should also be able to let users
getting
those information. Can add code  in future.)

Does xl need that information?  Can't the user get that information from
lsusb?

In any case, I can see why it would be *useful* to have in xl.  But
about having it in libxl, I think this question sort of goes along with
the question about the next patch -- whether libxl should be in the
business of providing general information about the USB devices it's
handling, or whether it should limit itself to doing what is absolutely
necessary to talk to usbback.

There's a part of me that sees the point of it: it's not actually that
much extra code (at least for Linux), and it makes it easy to add some
very useful features to xl.

On the other hand, it's not portable to other OSes.  At the moment of
course pvusb isn't portable either, but once we have qemu USB (providing
either emulated or PV usb) then I *think* most of the other
functionality will Just Work on any platform that can compile qemu
(incl. FreeBSD, NetBSD, ), won't it?  The code you're introducing here
would have to be re-implented for those platforms, and for every new
platform that wanted to include this functionality, wouldn't it?

So, about the portability problem, I think it's back to: do need to
update code to call libusb instead of reading sysfs now? Except
for this function, still have places reading sysfs to get hostbus,
hostaddr, vendorId, deviceId. Those are not portable for other
platform.

I realize I didn't give you very clear guidance; I guess I was hoping to
get an opinion from the tools maintainers.  Or perhaps, I was hoping to
let them be the "bad guys" and say, "You can't have this feature in
libxl", so I wouldn't have to. :-)

In the absence of guidance to the contrary, I suggest that patch series
should focus on getting the core pvusb functionality in, without the
extra usb-querying bits.  Then we can discuss a further series which
either adds the usb querying functionality to libxl, or implement it in
xl using libusb.

OK. Got it. Thanks.

-Chunyan



  -George




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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-win7-amd64  9 windows-installfail REGR. vs. 62711
 test-amd64-amd64-xl-qemuu-win7-amd64  9 windows-install   fail REGR. vs. 62711
 test-amd64-amd64-xl-qemut-win7-amd64  9 windows-install   fail REGR. vs. 62711
 test-amd64-i386-xl-qemuu-win7-amd64  9 windows-installfail REGR. vs. 62711

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm  4 host-ping-check-nativefail REGR. vs. 62711
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 
62711
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail blocked in 62711
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
like 62711

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-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
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass

version targeted for testing:
 xen  4930444bdf33157763ade5dd959b9a2a7477e0a3
baseline version:
 xen  a23ce429779011de127e8ff6c9bf3486d87154d5

Last test of basis62711  2015-10-07 10:34:21 Z6 days
Failing since 62733  2015-10-08 22:34:06 Z5 days5 attempts
Testing same since62946  2015-10-13 11:49:41 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Brijesh Singh 
  Daniel Kiper 
  Dario Faggioli 
  Fabio Fantoni 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Mike Latimer 
  Roger Pau Monne 
  Roger Pau Monné 
  Sander Eikelenboom 
  Tamas K Lengyel 
  Tim Deegan 
  Wei Liu 
  Wei Wang 
  Yang Zhang 

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

Re: [Xen-devel] [Patch RFC 00/13] VT-d Asynchronous Device-TLB Flush for ATS Device

[Zhang, Yang Z]

Jan Beulich wrote on 2015-10-13:
 On 13.10.15 at 07:27,  wrote:
>> Jan Beulich wrote on 2015-10-12:
>> On 12.10.15 at 03:42,  wrote:
 So, my suggestion is that we can rely on user to not assign the
 ATS device if hypervisor says it cannot support such device. For
 example, if hypervisor find the invalidation isn't completed in 1
 second, then hypervisor can crash itself and tell the user this
 ATS device needs more than 1 second invalidation time which is not
 support by
>> Xen.
>>> 
>>> Crashing the hypervisor in such a case is a security issue, i.e. is
>>> not
>> 
>> Indeed. Crashing the guest is more reasonable.
>> 
>>> an acceptable thing (and the fact that we panic() on timeout expiry
>>> right now isn't really acceptable either). If crashing the
>>> offending guest was sufficient to contain the issue, that might be an 
>>> option.
>>> Else
>> 
>> I think it should be sufficient (any concern from you?).
> 
> Having looked at the code, it wasn't immediately clear whether that
> would work. After all there one would think there would be a reason
> for the code panic()ing right now instead.

What the panic()ing refer to here?

> 
>> Hypervisor can
>> crash the guest with hint that the device may need long time to
>> complete the invalidation or device maybe bad. And user should add
>> the device to a blacklist to disallow assignment again.
>> 
>>> ripping out ATS support (and limiting spin time below what there is
>>> currently) may be the only alternative to fixing it.
>> 
>> Yes, it is another solution considering ATS device is rare currently.
>> For spin time, 10ms should be enough in both two solutions.
> 
> But 10ms is awfully much already. Which is why I've been advocating
> async flushing independent of ATS.

Agree. Technically speaking, async flush is the best solution. But considering 
the complexity and the benefit it brings, a compromise solution maybe better.

> 
>> But if solution 1 is acceptable, I prefer it since most of ATS
>> devices are still able to play with Xen.
> 
> With a multi-millisecond spin, solution 1 would imo be acceptable only
> as a transitional measure.

What does the transitional measure mean? Do you mean we still need the async 
flush for ATS issue or we can adapt solution 1 before ATS spec changed?

> 
> Jan


Best regards,
Yang



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

Re: [Xen-devel] [PATCH v7 2/3] x86: add domctl cmd to set/get CDP code/data CBM

[Chao Peng]

On Tue, Oct 13, 2015 at 09:38:58AM -0600, Jan Beulich wrote:
> >>> On 13.10.15 at 10:53,  wrote:
> > @@ -331,19 +357,34 @@ static bool_t psr_check_cbm(unsigned int cbm_len, 
> > uint64_t cbm)
> >  struct cos_cbm_info
> >  {
> >  unsigned int cos;
> > -uint64_t cbm;
> > +uint64_t cbm_code;
> > +uint64_t cbm_data;
> > +bool_t cdp;
> >  };
> 
> The bool_t field really fits well in the gap between the first and second
> one; I'll take the liberty to adjust this when committing (unless Chao
> comes forward with further comments; otherwise I'm kind of hoping
> for a Reviewed-by-him).

Correct, it can be a optimization and I don't see any problem. So please feel
free to adjust it. Thereby:

Reviewed-by: Chao Peng 

> 
> Jan

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

Re: [Xen-devel] [PATCH v8 02/17] Add cmpxchg16b support for x86-64

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, October 13, 2015 11:29 PM
> To: Wu, Feng 
> Cc: Andrew Cooper ; xen-devel@lists.xen.org;
> Keir Fraser 
> Subject: Re: [PATCH v8 02/17] Add cmpxchg16b support for x86-64
> 
> >>> On 12.10.15 at 10:54,  wrote:
> > --- a/xen/include/asm-x86/x86_64/system.h
> > +++ b/xen/include/asm-x86/x86_64/system.h
> > @@ -6,6 +6,39 @@
> > (unsigned long)(n),sizeof(*(ptr
> >
> >  /*
> > + * Atomic 16 bytes compare and exchange.  Compare OLD with MEM, if
> > + * identical, store NEW in MEM.  Return the initial value in MEM.
> > + * Success is indicated by comparing RETURN with OLD.
> > + *
> > + * This function can only be called when cpu_has_cx16 is true.
> > + */
> > +
> > +static always_inline __uint128_t __cmpxchg16b(
> > +volatile void *ptr, const __uint128_t *old, const __uint128_t *new)
> > +{
> > +__uint128_t prev;
> > +uint64_t new_high = *new >> 64;
> > +uint64_t new_low = *new;
> > +
> > +ASSERT(cpu_has_cx16);
> > +
> > +asm volatile ( "lock; cmpxchg16b %3"
> > +   : "=A" (prev)
> > +   : "c" (new_high), "b" (new_low),
> > + "m" (*__xg(ptr)), "0" (*old) );
> 
> I was about to apply this when I spotted that this is still wrong:
> The (requested) removal of the memory clobber requires that
> the memory location (all 16 bytes of it) appear as output. 

This is the description about memory clobber from gcc online docs:
https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Clobbers

"The "memory" clobber tells the compiler that the assembly code
performs memory reads or writes to items other than those listed
in the input and output operands"

My understanding to it is if the variable is listed as input of output,
we don't need to add memory clobber. We need to add it only
when it is not listed in the intput/output and the memory may be
changed behind us.

What is your understanding about it? Thanks a lot!

Thanks,
Feng

> With __xg() covering 100 bytes, it should be possible to simply make
> the operand an in- and output ("+m") instead of just an input.
> 
> Jan


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

Re: [Xen-devel] [PATCH 01/13] x86/time.c: Use system time to calculate elapsed_nsec in tsc_get_info()

[Haozhong Zhang]

On Fri, Oct 09, 2015 at 12:51:32AM -0600, Jan Beulich wrote:
> >>> On 28.09.15 at 09:13,  wrote:
> > When the TSC mode of a domain is TSC_MODE_DEFAULT and no TSC emulation
> > is used, the existing tsc_get_info() calculates elapsed_nsec by scaling
> > the host TSC with a ratio between guest TSC rate and
> > nanoseconds. However, the result will be incorrect if the guest TSC rate
> > differs from the host TSC rate. This patch fixes this problem by using
> > the system time as elapsed_nsec.
> 
> For both this and patch 2, while at a first glance (and taking into
> account just the visible patch context) what you say seems to
> make sense, the explanation is far from sufficient namely when
> looking at the function as a whole. For one, effects on existing
> cases need to be explicitly described, in particular why SVM's TSC
> ratio code works without that change (or whether it has been
> broken all along, in which case these would become backporting
> candidates; input from SVM maintainers would be appreciated
> too). That may in particular mean being more specific about
> what is actually wrong with scaling the host TSC here (i.e. in
> which way both results differ), when supposedly that matches
> what the hardware does when TSC ratio is supported.
>

I just found that patch 1 is in fact not necessary for supporting VMX
TSC scaling/SVM TSC ratio, because

 1. VMX TSC scaling and SVM TSC ratio are only used for HVM domains.
 
 2. The value of elapsed_nsec, which is modified by patch 1, is used
to compute d->arch.vtsc_offset by tsc_set_info() for domains using
TSC_MODE_[DEFAULT|ALWAYS_EMULATE].

 3. d->arch.vtsc_offset is then used in three places:
   - gtime_to_gtsc() and gtsc_to_gtime()
In these two functions, d->arch.vtsc_offset does not take effect
for HVM domains.
   - cpuid_time_leaf()
It's only used for domains using TSC_MODE_PVRDTSCP.

Therefore, I think patch 1 can be removed.


However, patch 2 is still necessary. The existing tsc_get_info() uses
the host TSC frequency as the guest TSC frequency for a domain in
TSC_MODE_DEFAULT, which could cause errors in the following example:
 - A domain d using TSC_MODE_DEFAULT is created on host A, then
   migrated to host B, and finally migrated to host C.
 - The host TSC frequencies of three hosts are f_a, f_b and f_c
   respectively and f_a != f_b and f_b != f_c.
 - Both host B and host C support TSC scaling (either VMX TSC scaling
   or SVM TSC ratio).

In above example w/o patch 2,
 1. Initially, d->arch.tsc_khz == f_a.
 
 2. In the first migration, tsc_get_info() on host A passes f_a as the
guest TSC frequency to tsc_set_info() on host B, so that after the
migration it's still that d->arch.tsc_khz == f_a. As TSC scaling
takes effect, guest programs can still observe TSC in frequency f_a.
So far so good.

 3. However, in the second migration, f_b (!= f_a) is passed as the
guest TSC frequency to tsc_set_info() on host C so that after the
migration d->arch.tsc_khz is not f_a any more. As TSC scaling
takes effect on host C as well, the TSC frequency observed by
guest programs changes and may break some TSC sensitive programs

At least in my test for VMX TSC scaling, guest Linux kernel would
complain tsc clocksource is unstable. SVM TSC ratio should have
the same problem.

W/ patch 2, tsc_get_info() in the above case always gets the guest TSC
frequency from d->arch.tsc_khz. Then in the first migration above, it
behaves the same as before, while in the second migration it can
maintain the guest TSC frequency correctly.

> Then a reason needs to be given why the similar logic in the
> PVRDTSCP case does not also get adjusted.
>

It's just because I didn't consider about PVRDTSCP case. I will add it
in the next version.

- Haozhong

> Plus, looking at the respective code in tsc_set_info(), I'm
> getting the impression that what you're trying to do is not in line
> with what is intended so far: Especially the comment there
> suggests that the intention is for the guest TSC to be made
> match the host one. Considering migration this indeed looks
> suspicious, but then that would need changing too.
> 
> Jan
> 

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

Re: [Xen-devel] help for snapshot

[Ian Campbell]

On Tue, 2015-10-13 at 09:18 +0800, 高强 wrote:
> Hi,alls
> 
> I'm modifying the source code of xen-4.4.1. Specifically, I'm modifying
> the memory copy part of snapshot. I first put all memory pages to write
> protection, and then rewrite the write protection exception part of the
> code. After capture the exception  then save the memory page , and all
> memory page copy is complete, call the function xenaccess_teardown(xch,
> xenaccess), but there is a mistake:
> 
> libxl: error: libxl_utils.c:396:libxl_read_exactly: file/stream truncated
> reading ipc msg header from domain 3 save/restore helper stdout pipe
> libxl: error: libxl_exec.c:129:libxl_report_child_exitstatus: domain 3
> save/restore helper [-1] died due to fatal signal Segmentation fault
> (core dumped)
> Failed to save domain, resuming domain
> 
> Has anyone ever meet this kind of problem, and who can tell me the cause
> of the error.

Without knowing exactly what you have changed, probably not.

Ian.


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

[Xen-devel] [PATCH v7 0/3] detect and initialize CDP (Code/Data Prioritization) feature

[He Chen]

Changes in v7:
- x86:
  * amend function find_cos and pick_avail_cos to ignore reference count
for COS0
  * write CDP data mask (mask1) before turning CDP on
  * check CDP status before clear enabled bit in function cat_cpu_fini
  * code style
- tools & docs:
  * LIBXL_PSR_CBM_TYPE_L3_CODE (DATA) =>
LIBXL_PSR_CBM_TYPE_L3_CBM_CODE (DATA)
  * refactor psr_cat_print_one_domain and add a helper to print different
type CBM
  * fix docs wrap

Changes in v6:
- x86:
  * remove unnecessary parameter in cdp_is_enabled function
  * remove variable need_write and restruct code in psr_set_l3_cbm
- tools & docs:
  * separate CBM headings in the output of xl psr-cat-show
  * revert the numbers of SDM chapter in xl-psr.markdown
  * XC_PSR_CAT_L3_CODE (DATA) => XC_PSR_CAT_L3_CBM_CODE (DATA)
  * correct error message of passing -c and -d at the same time

Changes in v5:
- x86: address Andrew's and Jan's coments.
- tools: refine options parsing in psr-cat-cbm-set and invalidate passing -c
  and -d at the same time
- merge tools and docs patches.
- code style

Changes in v4:
- x86:
  * remove union member name in struct `psr_cat_cbm` (suggested by Jan)
  * fix log info of CAT & CDP (suggested by Chao & Jan)
  * add a helper `cdp_is_enabled` to tell the status of CDP and CDP initialize
failed is considered (Jan's comment)
  * XEN_SYSCTL_INTERFACE_VERSION 0x000C -> 0x000D (suggested by Jan)
  * refine CBM type check logic in get/set CBM function (suggested by Jan)
  * loop optimization in function `find_cos` (suggested by Jan)
- tools: address Chao's comments.
- docs: address Chao's comments.
- code style

Changes in v3:
- x86: remove redundant CDP field in cat_socket_enable (suggested by Chao)
- tools: simplify CBM setting function in tools (suggested by Jan)
- docs: add boot parameter description (suggested by Chao & Ian)
- code style

Changes in v2:
- x86: enable CDP by boot parameter instead of enabling/disabling CDP at
   runtime (suggested by Andrew)
- tools: remove psr-cat-cdp-enable/disable xl commands
- code style

Code/Data Prioritization(CDP) is offered in Intel Broadwell and later server
platforms, which is an extension of CAT. CDP enables isolation and separate
prioritization of code and data fetches to the L3 cache in a software
configurable manner, which can enable workload prioritization and tuning of
cache capacity to the characteristics of the workload. CDP extends Cache
Allocation Technology (CAT) by providing separate code and data capacity bit
masks(CBM) per Class of Service (COS). CDP is used on VM basis in the Xen
implementation.

More information about CDP, please refer to Intel SDM, Volumn 3, section 17.16
http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf

This patch series enables CDP feature in Xen based on CAT code, and extends
CBM operation functions to support CDP. For all the changes, please see in
each patch.

This v7 patchset has been tested on Intel Broadwell server platform.

To make this patchset better, any comment or suggestion is welcomed, I would
really appreciate it.

Thanks.

He Chen (3):
  x86: Support enable CDP by boot parameter and add get CDP status
  x86: add domctl cmd to set/get CDP code/data CBM
  tools & docs: add tools and docs support for Intel CDP

 docs/man/xl.pod.1   |  15 +++
 docs/misc/xen-command-line.markdown |  11 +-
 docs/misc/xl-psr.markdown   |  53 
 tools/libxc/include/xenctrl.h   |   7 +-
 tools/libxc/xc_psr.c|  17 ++-
 tools/libxl/libxl.h |   7 ++
 tools/libxl/libxl_psr.c |   5 +-
 tools/libxl/libxl_types.idl |   3 +
 tools/libxl/xl_cmdimpl.c|  66 --
 tools/libxl/xl_cmdtable.c   |   2 +
 xen/arch/x86/domctl.c   |  32 -
 xen/arch/x86/psr.c  | 232 +---
 xen/arch/x86/sysctl.c   |   5 +-
 xen/include/asm-x86/msr-index.h |   3 +
 xen/include/asm-x86/psr.h   |  20 +++-
 xen/include/public/domctl.h |   4 +
 xen/include/public/sysctl.h |   4 +-
 17 files changed, 414 insertions(+), 72 deletions(-)

-- 
1.9.1


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

[Xen-devel] [PATCH v7 2/3] x86: add domctl cmd to set/get CDP code/data CBM

[He Chen]

CDP extends CAT and provides the capacity to control L3 code & data
cache. With CDP, one COS corresponds to two CMBs(code & data). cbm_type
is added to distinguish different CBM operations. Besides, new domctl
cmds are introdunced to support set/get CDP CBM. Some CAT functions to
operation CBMs are extended to support CDP.

Signed-off-by: He Chen 
Reviewed-by: Andrew Cooper 
Reviewed-by: Chao Peng 
---
Changes in v7:
* amend function find_cos and pick_avail_cos to ignore reference count
  for COS0
* code style

Changes in v6:
* remove variable need_write and restruct code in psr_set_l3_cbm
* remove redundant type == PSR_CBM_TYPE_L3 in psr_get_l3_cbm

Changes in v5:
* replace -EINVAL with -ENXIO when setting code/data CBM on CDP
  disabled.
---
 xen/arch/x86/domctl.c   |  32 +++-
 xen/arch/x86/psr.c  | 181 ++--
 xen/include/asm-x86/psr.h   |  12 ++-
 xen/include/public/domctl.h |   4 +
 4 files changed, 183 insertions(+), 46 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index f8a559c..0f6fdb9 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1168,12 +1168,40 @@ long arch_do_domctl(
 {
 case XEN_DOMCTL_PSR_CAT_OP_SET_L3_CBM:
 ret = psr_set_l3_cbm(d, domctl->u.psr_cat_op.target,
- domctl->u.psr_cat_op.data);
+ domctl->u.psr_cat_op.data,
+ PSR_CBM_TYPE_L3);
+break;
+
+case XEN_DOMCTL_PSR_CAT_OP_SET_L3_CODE:
+ret = psr_set_l3_cbm(d, domctl->u.psr_cat_op.target,
+ domctl->u.psr_cat_op.data,
+ PSR_CBM_TYPE_L3_CODE);
+break;
+
+case XEN_DOMCTL_PSR_CAT_OP_SET_L3_DATA:
+ret = psr_set_l3_cbm(d, domctl->u.psr_cat_op.target,
+ domctl->u.psr_cat_op.data,
+ PSR_CBM_TYPE_L3_DATA);
 break;
 
 case XEN_DOMCTL_PSR_CAT_OP_GET_L3_CBM:
 ret = psr_get_l3_cbm(d, domctl->u.psr_cat_op.target,
- >u.psr_cat_op.data);
+ >u.psr_cat_op.data,
+ PSR_CBM_TYPE_L3);
+copyback = 1;
+break;
+
+case XEN_DOMCTL_PSR_CAT_OP_GET_L3_CODE:
+ret = psr_get_l3_cbm(d, domctl->u.psr_cat_op.target,
+ >u.psr_cat_op.data,
+ PSR_CBM_TYPE_L3_CODE);
+copyback = 1;
+break;
+
+case XEN_DOMCTL_PSR_CAT_OP_GET_L3_DATA:
+ret = psr_get_l3_cbm(d, domctl->u.psr_cat_op.target,
+ >u.psr_cat_op.data,
+ PSR_CBM_TYPE_L3_DATA);
 copyback = 1;
 break;
 
diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index 5ddeb2b..0083115 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -293,14 +293,40 @@ int psr_get_cat_l3_info(unsigned int socket, uint32_t 
*cbm_len,
 return 0;
 }
 
-int psr_get_l3_cbm(struct domain *d, unsigned int socket, uint64_t *cbm)
+int psr_get_l3_cbm(struct domain *d, unsigned int socket,
+   uint64_t *cbm, enum cbm_type type)
 {
 struct psr_cat_socket_info *info = get_cat_socket_info(socket);
+bool_t cdp_enabled = cdp_is_enabled(socket);
 
 if ( IS_ERR(info) )
 return PTR_ERR(info);
 
-*cbm = info->cos_to_cbm[d->arch.psr_cos_ids[socket]].cbm;
+switch ( type )
+{
+case PSR_CBM_TYPE_L3:
+if ( cdp_enabled )
+return -EXDEV;
+*cbm = info->cos_to_cbm[d->arch.psr_cos_ids[socket]].cbm;
+break;
+
+case PSR_CBM_TYPE_L3_CODE:
+if ( !cdp_enabled )
+*cbm = info->cos_to_cbm[d->arch.psr_cos_ids[socket]].cbm;
+else
+*cbm = info->cos_to_cbm[d->arch.psr_cos_ids[socket]].code;
+break;
+
+case PSR_CBM_TYPE_L3_DATA:
+if ( !cdp_enabled )
+*cbm = info->cos_to_cbm[d->arch.psr_cos_ids[socket]].cbm;
+else
+*cbm = info->cos_to_cbm[d->arch.psr_cos_ids[socket]].data;
+break;
+
+default:
+ASSERT_UNREACHABLE();
+}
 
 return 0;
 }
@@ -331,19 +357,34 @@ static bool_t psr_check_cbm(unsigned int cbm_len, 
uint64_t cbm)
 struct cos_cbm_info
 {
 unsigned int cos;
-uint64_t cbm;
+uint64_t cbm_code;
+uint64_t cbm_data;
+bool_t cdp;
 };
 
 static void do_write_l3_cbm(void *data)
 {
 struct cos_cbm_info *info = data;
 
-wrmsrl(MSR_IA32_PSR_L3_MASK(info->cos), info->cbm);
+if ( info->cdp )
+{
+wrmsrl(MSR_IA32_PSR_L3_MASK_CODE(info->cos), info->cbm_code);
+wrmsrl(MSR_IA32_PSR_L3_MASK_DATA(info->cos), info->cbm_data);
+}
+else
+

[Xen-devel] [PATCH v7 1/3] x86: Support enable CDP by boot parameter and add get CDP status

[He Chen]

Add boot parameter `psr=cdp` to enable CDP at boot time.
Intel Code/Data Prioritization (CDP) feature is based on CAT. Note that
cos_max would be half when CDP is on. struct psr_cat_cbm is extended to
support CDP operation. Extend psr_get_cat_l3_info sysctl to get CDP
status.

Signed-off-by: He Chen 
Reviewed-by: Andrew Cooper 
---
Changes in v7:
* write CDP data mask (mask1) before turning CDP on
* check CDP status before clear enabled bit in function cat_cpu_fini

Changes in v6:
* remove unnecessary parameter in cdp_is_enabled

Changes in v5:
* remove unnecessary u in psr_cat_cbm structure
* revert write_l3_cbm and put the modification to next patch
* remove duplicate PSR_CAT_FLAG_L3_CDP
---
 docs/misc/xen-command-line.markdown | 11 ++--
 xen/arch/x86/psr.c  | 51 ++---
 xen/arch/x86/sysctl.c   |  5 ++--
 xen/include/asm-x86/msr-index.h |  3 +++
 xen/include/asm-x86/psr.h   |  8 +-
 xen/include/public/sysctl.h |  4 ++-
 6 files changed, 72 insertions(+), 10 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index a565c1b..416e559 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1174,9 +1174,9 @@ This option can be specified more than once (up to 8 
times at present).
 > `= `
 
 ### psr (Intel)
-> `= List of ( cmt: | rmid_max: | cat: | 
cos_max: )`
+> `= List of ( cmt: | rmid_max: | cat: | 
cos_max: | cdp: )`
 
-> Default: `psr=cmt:0,rmid_max:255,cat:0,cos_max:255`
+> Default: `psr=cmt:0,rmid_max:255,cat:0,cos_max:255,cdp:0`
 
 Platform Shared Resource(PSR) Services.  Intel Haswell and later server
 platforms offer information about the sharing of resources.
@@ -1206,6 +1206,13 @@ The following resources are available:
   the cache allocation.
   * `cat` instructs Xen to enable/disable Cache Allocation Technology.
   * `cos_max` indicates the max value for COS ID.
+* Code and Data Prioritization Technology (Broadwell and later). Information
+  regarding the code cache and the data cache allocation. CDP is based on CAT.
+  * `cdp` instructs Xen to enable/disable Code and Data Prioritization. Note
+that `cos_max` of CDP is a little different from `cos_max` of CAT. With
+CDP, one COS will corespond two CBMs other than one with CAT, due to the
+sum of CBMs is fixed, that means actual `cos_max` in use will automatically
+reduce to half when CDP is enabled.
 
 ### reboot
 > `= t[riple] | k[bd] | a[cpi] | p[ci] | P[ower] | e[fi] | n[o] [, [w]arm | 
 > [c]old]`
diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index c0daa2e..5ddeb2b 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -21,9 +21,16 @@
 
 #define PSR_CMT(1<<0)
 #define PSR_CAT(1<<1)
+#define PSR_CDP(1<<2)
 
 struct psr_cat_cbm {
-uint64_t cbm;
+union {
+uint64_t cbm;
+struct {
+uint64_t code;
+uint64_t data;
+};
+};
 unsigned int ref;
 };
 
@@ -43,6 +50,7 @@ struct psr_cmt *__read_mostly psr_cmt;
 
 static unsigned long *__read_mostly cat_socket_enable;
 static struct psr_cat_socket_info *__read_mostly cat_socket_info;
+static unsigned long *__read_mostly cdp_socket_enable;
 
 static unsigned int __initdata opt_psr;
 static unsigned int __initdata opt_rmid_max = 255;
@@ -94,6 +102,7 @@ static void __init parse_psr_param(char *s)
 
 parse_psr_bool(s, val_str, "cmt", PSR_CMT);
 parse_psr_bool(s, val_str, "cat", PSR_CAT);
+parse_psr_bool(s, val_str, "cdp", PSR_CDP);
 
 if ( val_str && !strcmp(s, "rmid_max") )
 opt_rmid_max = simple_strtoul(val_str, NULL, 0);
@@ -261,8 +270,13 @@ static struct psr_cat_socket_info 
*get_cat_socket_info(unsigned int socket)
 return cat_socket_info + socket;
 }
 
+static inline bool_t cdp_is_enabled(unsigned int socket)
+{
+return cdp_socket_enable && test_bit(socket, cdp_socket_enable);
+}
+
 int psr_get_cat_l3_info(unsigned int socket, uint32_t *cbm_len,
-uint32_t *cos_max)
+uint32_t *cos_max, uint32_t *flags)
 {
 struct psr_cat_socket_info *info = get_cat_socket_info(socket);
 
@@ -272,6 +286,10 @@ int psr_get_cat_l3_info(unsigned int socket, uint32_t 
*cbm_len,
 *cbm_len = info->cbm_len;
 *cos_max = info->cos_max;
 
+*flags = 0;
+if ( cdp_is_enabled(socket) )
+*flags |= XEN_SYSCTL_PSR_CAT_L3_CDP;
+
 return 0;
 }
 
@@ -470,6 +488,7 @@ static void cat_cpu_init(void)
 struct psr_cat_socket_info *info;
 unsigned int socket;
 unsigned int cpu = smp_processor_id();
+uint64_t val;
 const struct cpuinfo_x86 *c = cpu_data + cpu;
 
 if ( !cpu_has(c, X86_FEATURE_CAT) || c->cpuid_level < PSR_CPUID_LEVEL_CAT )
@@ -495,8 +514,27 @@ static void cat_cpu_init(void)
 spin_lock_init(>cbm_lock);
 
 set_bit(socket, 

[Xen-devel] [PATCH v7 3/3] tools & docs: add tools and docs support for Intel CDP

[He Chen]

This is the xl/xc changes to support Intel Code/Data Prioritization.
CAT xl commands to set/get CBMs are extended to support CDP.
Add new CDP options with CAT commands in xl interface man page.
Add description of CDP in xl-psr.markdown.

Signed-off-by: He Chen 
---
Changes in v7:
* LIBXL_PSR_CBM_TYPE_L3_CODE (DATA) =>
  LIBXL_PSR_CBM_TYPE_L3_CBM_CODE (DATA)
* refactor psr_cat_print_one_domain and add a helper to print different
  type CBM
* fix docs wrap

Changes in v6:
* separate CBM headings in the output of xl psr-cat-show
* revert the numbers of SDM chapter in xl-psr.markdown
* XC_PSR_CAT_L3_CODE (DATA) => XC_PSR_CAT_L3_CBM_CODE (DATA)
* correct error message of passing -c and -d at the same time

Changes in v5:
* merge tools and docs patches
* replace EINVAL with ENXIO in libxl__psr_cat_log_err_msg
* revise options parsing in psr-cat-cbm-set and invalidate passing -c
  and -d at the same time
* refine CDP status output codes in psr_cat_hwinfo
* adjust CBM output format in command xl psr-cat-show
* docs revision

Example of new output format for command xl psr-cat-show:

*** CAT-only ***

Socket ID   : 0
L3 Cache: 56320KB
Default CBM : 0xf
   ID NAME CBM
0 Domain-0 0xf
1   centos.hvm 0xf

*** CDP enabled ***

Socket ID   : 0
L3 Cache: 56320KB
Default CBM : 0xf
   ID NAME  CBM (code) CBM (data)
0 Domain-0 0xf0xf
1   centos.hvm 0xf0xf
---
 docs/man/xl.pod.1 | 15 ++
 docs/misc/xl-psr.markdown | 53 ++
 tools/libxc/include/xenctrl.h |  7 +++--
 tools/libxc/xc_psr.c  | 17 ++-
 tools/libxl/libxl.h   |  7 +
 tools/libxl/libxl_psr.c   |  5 +++-
 tools/libxl/libxl_types.idl   |  3 ++
 tools/libxl/xl_cmdimpl.c  | 66 +++
 tools/libxl/xl_cmdtable.c |  2 ++
 9 files changed, 159 insertions(+), 16 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index d0cd612..4279c7c 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -1518,6 +1518,13 @@ applications. In the Xen implementation, CAT is used to 
control cache allocation
 on VM basis. To enforce cache on a specific domain, just set capacity bitmasks
 (CBM) for the domain.
 
+Intel Broadwell and later server platforms also offer Code/Data Prioritization
+(CDP) for cache allocations, which support specifying code or data cache for
+applications. CDP is used on a per VM basis in the Xen implementation. To
+specify code or data CBM for the domain, CDP feature must be enabled and CBM
+type options need to be specified when setting CBM, and the type options (code
+and data) are mutually exclusive.
+
 =over 4
 
 =item B [I] I I
@@ -1533,6 +1540,14 @@ B
 
 Specify the socket to process, otherwise all sockets are processed.
 
+=item B<-c>, B<--code>
+
+Set code CBM when CDP is enabled.
+
+=item B<-d>, B<--data>
+
+Set data CBM when CDP is enabled.
+
 =back
 
 =item B [I]
diff --git a/docs/misc/xl-psr.markdown b/docs/misc/xl-psr.markdown
index c32e25c..9b08ee3 100644
--- a/docs/misc/xl-psr.markdown
+++ b/docs/misc/xl-psr.markdown
@@ -127,6 +127,59 @@ Per domain CBM settings can be shown by:
 
 `xl psr-cat-show`
 
+## Code and Data Prioritization (CDP)
+
+Code and Data Prioritization (CDP) Technology is an extension of CAT, which
+is available on Intel Broadwell and later server platforms. CDP enables
+isolation and separate prioritization of code and data fetches to the L3
+cache in a software configurable manner, which can enable workload
+prioritization and tuning of cache capacity to the characteristics of the
+workload. CDP extends Cache Allocation Technology (CAT) by providing
+separate code and data masks per Class of Service (COS).
+
+CDP can be enabled by adding `psr=cdp` to Xen command line.
+
+When CDP is enabled,
+
+ * the CAT masks are re-mapped into interleaved pairs of masks for data or
+   code fetches.
+
+ * the range of COS for CAT is re-indexed, with the lower-half of the COS
+   range available for CDP.
+
+CDP allows the OS or Hypervisor to partition cache allocation in a more
+fine-grained. Code cache and data cache can be specified independently.
+With CDP enabled, one COS corresponds to two CBMs (code CBM & data CBM),
+since the sum of CBMs is fixed, that means the number of available COSes
+will reduce by half when CDP is on.
+
+For more detailed information please refer to Intel SDM chapter
+"Platform Shared Resource Control: Cache Allocation Technology".
+
+The xl interfaces are the same with that of CAT. The difference is that
+CBM type can be passed as option to set code CBM or data CBM.
+
+When CDP is enabled, `-c` or `--code` option is available to set code CBM
+for the domain.
+
+When CDP is enabled, `-d` or `--data` option is 

Re: [Xen-devel] help for snapshot

[高强]

I'm modifying the source code of snapshot,in the function xc_domain_save()
of xc_domain_save.c,through calling wrexact() to copy the memory pages to
the local dist.

I'm not sure if it is the answer you wang.

2015-10-13 13:49 GMT+08:00 Gohar Irfan :

> I'm also working on a similar thing - can you please tell me how you copy
> the memory pages from one part of the memory to another?
>
> On Tue, Oct 13, 2015 at 10:04 AM 高强  wrote:
>
>> Hi,alls
>>
>> I'm modifying the source code of xen-4.4.1. Specifically, I'm modifying
>> the memory copy part of snapshot. I first put all memory pages to write
>> protection, and then rewrite the write protection exception part of the
>> code. After capture the exception  then save the memory page , and all
>> memory page copy is complete, call the function xenaccess_teardown(xch,
>> xenaccess), but there is a mistake:
>>
>> libxl: error: libxl_utils.c:396:libxl_read_exactly: file/stream truncated
>> reading ipc msg header from domain 3 save/restore helper stdout pipe
>> libxl: error: libxl_exec.c:129:libxl_report_child_exitstatus: domain 3
>> save/restore helper [-1] died due to fatal signal Segmentation fault (core
>> dumped)
>> Failed to save domain, resuming domain
>>
>> Has anyone ever meet this kind of problem, and who can tell me the cause
>> of the error.
>>
>> Thanks
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] help for snapshot

[高强]

Hi,alls.

in xen-4.4.1/tools/libxc/xc_domain_save.c,the function
xc_domain_save(),there are two function xc_report_progress_start()
and xc_report_progress_step().And so as xc_domain_restore().

I don't know the function of these two functions,has anyone can tell me?

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail REGR. vs. 62318

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl3 host-install(3)  broken in 62719 pass in 62935
 test-amd64-amd64-libvirt  3 host-install(3)  broken in 62719 pass in 62935
 test-amd64-i386-qemut-rhel6hvm-intel 3 host-install(3) broken in 62719 pass in 
62935
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken in 
62719 pass in 62935
 test-amd64-i386-xl-raw3 host-install(3)  broken in 62719 pass in 62935
 test-amd64-amd64-xl-rtds  3 host-install(3)  broken in 62719 pass in 62935
 test-amd64-i386-libvirt   3 host-install(3)  broken in 62719 pass in 62935
 test-amd64-amd64-xl-qemuu-ovmf-amd64 3 host-install(3) broken in 62719 pass in 
62935
 test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-install(3) broken in 62719 pass in 
62935
 test-amd64-amd64-libvirt-vhd  3 host-install(3)  broken in 62719 pass in 62935
 test-armhf-armhf-xl-rtds 15 guest-start.2   fail pass in 62719

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail in 62719 
like 62256
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail like 62318
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail like 62318
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 62318
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 62318

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-qcow2 9 debian-di-install fail in 62719 never pass
 test-armhf-armhf-libvirt-vhd  9 debian-di-install fail in 62719 never pass
 test-armhf-armhf-xl-raw   9 debian-di-install fail in 62719 never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-check fail in 62719 never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-check fail in 62719 never pass
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 62719 never pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-check fail in 62719 never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-check fail in 62719 never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-check fail in 62719 never 
pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  12 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-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 

Re: [Xen-devel] [V6 2/4] x86/xsaves: enable xsaves/xrstors/xsavec in xen

[Shuai Ruan]

On Mon, Oct 12, 2015 at 11:05:33AM +0100, Andrew Cooper wrote:
> On 12/10/15 07:07, Shuai Ruan wrote:
> > This patch uses xsaves/xrstors/xsavec instead of xsaveopt/xrstor
> > to perform the xsave_area switching so that xen itself
> > can benefit from them when available.
> >
> > For xsaves/xrstors/xsavec only use compact format. Add format conversion
> > support when perform guest os migration.
> >
> > Also, pv guest will not support xsaves/xrstors.
> >
> > Signed-off-by: Shuai Ruan 
> > ---
> 
> With these 4 things fixed, Reviewed-by: Andrew Cooper
> 
> 
Ok.
Thanks.
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

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

Re: [Xen-devel] [Patch RFC 00/13] VT-d Asynchronous Device-TLB Flush for ATS Device

[Jan Beulich]

>>> On 13.10.15 at 07:27,  wrote:
> Jan Beulich wrote on 2015-10-12:
> On 12.10.15 at 03:42,  wrote:
>>> So, my suggestion is that we can rely on user to not assign the ATS
>>> device if hypervisor says it cannot support such device. For
>>> example, if hypervisor find the invalidation isn't completed in 1
>>> second, then hypervisor can crash itself and tell the user this ATS
>>> device needs more than 1 second invalidation time which is not support by 
> Xen.
>> 
>> Crashing the hypervisor in such a case is a security issue, i.e. is not
> 
> Indeed. Crashing the guest is more reasonable. 
> 
>> an acceptable thing (and the fact that we panic() on timeout expiry
>> right now isn't really acceptable either). If crashing the offending
>> guest was sufficient to contain the issue, that might be an option. Else
> 
> I think it should be sufficient (any concern from you?).

Having looked at the code, it wasn't immediately clear whether
that would work. After all there one would think there would be a
reason for the code panic()ing right now instead.

> Hypervisor can 
> crash the guest with hint that the device may need long time to complete the 
> invalidation or device maybe bad. And user should add the device to a 
> blacklist to disallow assignment again. 
> 
>> ripping out ATS support (and limiting spin time below what there is
>> currently) may be the only alternative to fixing it.
> 
> Yes, it is another solution considering ATS device is rare currently. For 
> spin time, 10ms should be enough in both two solutions. 

But 10ms is awfully much already. Which is why I've been advocating
async flushing independent of ATS.

> But if solution 1 is acceptable, I prefer it since most of ATS devices are 
> still able to play with Xen.

With a multi-millisecond spin, solution 1 would imo be acceptable only
as a transitional measure.

Jan


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

Re: [Xen-devel] [OSSTest Nested v12 03/21] Allow runvars to specify guest disk and ram size (turning previous values into defaults) [and 2 more messages]

[Ian Jackson]

Hu, Robert writes ("RE: [OSSTest Nested v12 03/21] Allow runvars to specify 
guest disk and ram size (turning  previous values into defaults)"):
> And sorry I haven't got a chance to read your replies/patches until now.
> So many test tasks almost crushed me.

That's fine, of course.  We all have other things we are doing.

> I'm going to read your mails in the coming week.

Thanks.  I see Ian Campbell has replied to several already.


Hu, Robert writes ("RE: [OSSTest Nested v12 16/21] Add PDU power method for 
nested L1 and L2 guest"):
> Ian Jackson [mailto:ian.jack...@eu.citrix.com]:
> > Robert Ho writes ("[OSSTest Nested v12 16/21] Add PDU power method for
> > nested L1 and L2 guest"):
> > > For nested host/guest, its power on/off method shall be
> > > its host invoke $(toolstack)->create/destroy method.
> > 
> > Thanks for this patch, which I have substantially edited for my v14.
> > 
> > However, I notice that it was missing a signed-off-by.  Can you please
> > confirm that I should add your s-o-b ?
> 
> Sorry I forgot to add my s-o-b. Yes, please add mine.

Of course only one of us ought to be rebasing this series at once,
because otherwise it will be difficult for us to merge our work.

In my mail
  Subject: [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing
  Date: Fri, 25 Sep 2015 20:15:05 +0100
I handed the series back to you.

So I think it is you who need to add your own s-o-b to that patch.

(I don't imply any criticism of you with this detailed explanation.  I
just don't want any misunderstandings; nor do I want this minor work
item to be dropped.)


Likewise:

> > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > Sent: Saturday, September 26, 2015 3:15 AM
> > To: xen-de...@lists.xenproject.org
> > Cc: Hu, Robert ; Ian Campbell
> > ; Ian Jackson ; Ian
> > Jackson 
> > Subject: [OSSTEST PATCH 15/26] DhcpWatch::leases: Fix a reporting message
> > 
> > This talks about `guest_check_ip', but this code is now factored out
> > into a method.  Use the correct method name in reporting.
...
> Ack.

If you meant
  Acked-by: Robert Ho 
then it would be better if you wrote that explicitly.

And of course as current custodian of the branch, it is up to you to
record your own ack in it.  This may seem a little odd, but it is the
standard approach when dealing with a series containing contributions
from multiple people.


I've read your other emails and Ian's replies and I think you should
be unblocked now ?  So I'm expecting more questions, bug reports,
etc., and hopefully eventually a v15.  Do not hesitate to ask again
for help.


Regards,
Ian.

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

Re: [Xen-devel] [PATCH] raisin: enable ovmf build for arm64

[Ian Campbell]

On Mon, 2015-10-12 at 18:18 +0100, Stefano Stabellini wrote:
> @@ -30,9 +38,18 @@ function ovmf_build() {
>  git-checkout $OVMF_URL $OVMF_REVISION ovmf-dir
>  cd ovmf-dir
>  
> -make -C BaseTools/Source/C
> -OvmfPkg/build.sh -a X64 -b RELEASE -n 4
> -cp Build/OvmfX64/RELEASE_GCC*/FV/OVMF.fd ovmf.bin
> +make -C BaseTools
> +
> +if [[ $RAISIN_ARCH = "arm64" ]]

Based on what I understand of the OVMF buildsystem I think you are going to
eventually want a case $RAISIN_ARCH here, since it seems to vary a fair
bit.

> +then
> +export GCC48_AARCH64_PREFIX=

Won't this (unexpectedly) leak into other subsequent component builds? Or
is each component built in a  fresh sub-shell?

What about host platforms which have a gcc other than 4.8? (e.g. Debian
Jessie uses 4.9 by default)

Should you add a comment explaining why this apparent workaround is needed?

> +bash -c "source edksetup.sh && build -a AARCH64 -t GCC48 -p 
> ArmVirtPkg/ArmVirtXen.dsc -b RELEASE"
> +mkdir -p "$INST_DIR"/$PREFIX/lib/xen/boot
> +cp Build/ArmVirtXen-AARCH64/RELEASE_GCC*/FV/XEN_EFI.fd 
> "$INST_DIR"/$PREFIX/lib/xen/boot/XEN_EFI.fd
> +else
> +OvmfPkg/build.sh -a X64 -b RELEASE -n 4
> +cp Build/OvmfX64/RELEASE_GCC*/FV/OVMF.fd ovmf.bin
> +fi
>  
>  cd "$BASEDIR"
>  }
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

Re: [Xen-devel] [Patch RFC 00/13] VT-d Asynchronous Device-TLB Flush for ATS Device

[Tim Deegan]

Hi,

At 11:09 + on 11 Oct (1444561760), Xu, Quan wrote:
> One question: do two lists refer to page_list and arch.relmem_list?

No, I was wondering if a page ever needed to be queued waiting for two
different flushes -- e.g. if there are multiple IOMMUs.

> I know you prefer __scheme_A__(I think Jan prefers __scheme_A__ too.  Jan, 
> correct me, if I am wrong :) )
> which fits better with the usual way refcounts are used. But __scheme_A__ 
> would be difficult for buy-in by my team (Obviously, why spend so many effort 
> for such a small issue? why does __scheme_B__ not accept?) I think, 
> __scheme_A__ is also a tricky solution.
> 

What in particular is worrying you about scheme A?  AFAICS you need to
build the same refcount-taking mechanism for either scheme.

Is it the interactions with other p2m-based features in VMs that don't
have devices passed through?  In that case perhaps you could just
mandate that ATS support means no shared HAP/IOMMU tables, and do the
refcounting only in the IOMMU ones?

>  I think __scheme_A__ is complex to keep a log of all relevant pending 
> derefs, and to be processed when the flush completes;
> 
> optimized __scheme_A__:
> It could keep a log of the reference only when the IOMMU entry is _ 
> removed/overwritten_.(if the IOMMU entry is not _ removed/overwritten_, it is 
> safe.).

Yes, though I'd add any change from read-write to read-only.
Basically, you only need the log/deref whenever you need to flush the
IOMMU. :)

Cheers,

Tim.

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

Re: [Xen-devel] ARM64 EFI runtime

[Stefano Stabellini]

Hi Brijesh,

EFI runtime services are not currently exported to Dom0. They are still
a work in progress.

Regards,

Stefano

On Mon, 12 Oct 2015, Brijesh Singh wrote:
> Hi All,
> 
> I noticed that DOM0 kernel fails to get time via RTC device on AMD ARM64 
> (Seattle) platform. On this platform Linux uses rtc-efi driver to get the 
> time through EFI runtime services, and I know for sure that driver works well 
> outside the Xen environment. It seems that devicetree passed to DOM0 through 
> Xen does not contain UEFI system table information hence DOM0 fails to probe 
> rtc-efi platform driver. I see the below message in DOM0 dmesg log
> 
> [0.00] bootconsole [uart0] enabled
> [0.00] efi: Getting EFI parameters from FDT:
> [0.00] efi: UEFI not found.
> [0.00] cma: Reserved 16 MiB at 0x0083df00
> 
> 
> Looking at Xen's common/efi/runtime.c indicates that EFI runtime services are 
> not yet supported on ARM platform, is anyone working on it? 
> 
> Thanks
> Brijesh
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

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

Re: [Xen-devel] [PATCH 2/2] VT-d: section placement and type adjustments

[Jan Beulich]

>>> On 13.10.15 at 07:28,  wrote:
> Acked-by: Yang Zhang 

Thanks. What about patch 1?

Jan


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

Re: [Xen-devel] [PATCH 2/2] VT-d: section placement and type adjustments

[Zhang, Yang Z]

Jan Beulich wrote on 2015-10-13:
 On 13.10.15 at 07:28,  wrote:
>> Acked-by: Yang Zhang 
> 
> Thanks. What about patch 1?

Done!
I think I have acked it. But seems I forget to do it. 

Best regards,
Yang



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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 38162 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38162/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf   3 host-install(3) broken REGR. vs. 38154
 build-armhf-xsm   3 host-install(3) broken REGR. vs. 38154
 test-amd64-amd64-xl-xsm  21 guest-start/debian.repeat fail REGR. vs. 38154
 test-amd64-amd64-xl  21 guest-start/debian.repeat fail REGR. vs. 38154
 test-amd64-amd64-amd64-pvgrub 10 guest-start  fail REGR. vs. 38154
 build-i3865 xen-build fail REGR. vs. 38154

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt-pair  9 xen-boot/src_hostfail REGR. vs. 38154
 test-amd64-amd64-xl-qemuu-winxpsp3  9 windows-install  fail like 38154

Tests which did not succeed, but are not blocking:
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-midway1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass

version targeted for testing:
 qemuuc9003eb4662f44c61be9c8d7d5c9d4a02d58b560
baseline version:
 qemuub37686f7e84b22cfaf7fd01ac5133f2617cc3027

Last test of basis38154  2015-10-11 18:52:01 Z1 days
Testing same since38162  2015-10-13 04:48:59 Z0 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Peter Maydell 

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

Re: [Xen-devel] [PATCH] raisin: enable ovmf build for arm64

[Ian Campbell]

On Tue, 2015-10-13 at 11:58 +0100, Stefano Stabellini wrote:
> On Tue, 13 Oct 2015, Ian Campbell wrote:
> > On Mon, 2015-10-12 at 18:18 +0100, Stefano Stabellini wrote:
> > > @@ -30,9 +38,18 @@ function ovmf_build() {
> > >  git-checkout $OVMF_URL $OVMF_REVISION ovmf-dir
> > >  cd ovmf-dir
> > >  
> > > -make -C BaseTools/Source/C
> > > -OvmfPkg/build.sh -a X64 -b RELEASE -n 4
> > > -cp Build/OvmfX64/RELEASE_GCC*/FV/OVMF.fd ovmf.bin
> > > +make -C BaseTools
> > > +
> > > +if [[ $RAISIN_ARCH = "arm64" ]]
> > 
> > Based on what I understand of the OVMF buildsystem I think you are
> > going to
> > eventually want a case $RAISIN_ARCH here, since it seems to vary a fair
> > bit.
> > 
> > > +then
> > > +export GCC48_AARCH64_PREFIX=
> > 
> > Won't this (unexpectedly) leak into other subsequent component builds?
> > Or
> > is each component built in a  fresh sub-shell?
> > 
> > What about host platforms which have a gcc other than 4.8? (e.g. Debian
> > Jessie uses 4.9 by default)
> > 
> > Should you add a comment explaining why this apparent workaround is
> > needed?
> 
> That is a good question. It all comes from
> https://wiki.linaro.org/LEG/UEFIforXEN, but I don't know why is
> required. Without GCC48_AARCH64_PREFIX= and -t GCC48, it won't build.

Is it just that GCC48_AARCH64_PREFIX defaults to some cross-compiler prefix
(e.g. aarch64-linux-gnu-) but a native build environment doesn't (always)
use that?

On Debian at least the prefixed name exists even for the native compiler,
but I'd not be surprised if that wasn't universal across all distros.

> Ard, do you know why? x86 doesn't need anything like that, as you can
> see below.
> 
> 
> > > +bash -c "source edksetup.sh && build -a AARCH64 -t GCC48 -p
> > > ArmVirtPkg/ArmVirtXen.dsc -b RELEASE"
> > > +mkdir -p "$INST_DIR"/$PREFIX/lib/xen/boot
> > > +cp Build/ArmVirtXen-AARCH64/RELEASE_GCC*/FV/XEN_EFI.fd
> > > "$INST_DIR"/$PREFIX/lib/xen/boot/XEN_EFI.fd
> > > +else
> > > +OvmfPkg/build.sh -a X64 -b RELEASE -n 4
> > > +cp Build/OvmfX64/RELEASE_GCC*/FV/OVMF.fd ovmf.bin
> > > +fi
> > >  
> > >  cd "$BASEDIR"
> > >  }
> > > 
> > > ___
> > > Xen-devel mailing list
> > > Xen-devel@lists.xen.org
> > > http://lists.xen.org/xen-devel
> > 

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

Re: [Xen-devel] [PATCH OSSTEST v3 3/3] Create a flight to test OpenStack with xen-unstable and libvirt

[Ian Jackson]

Anthony PERARD writes ("Re: [PATCH OSSTEST v3 3/3] Create a flight to test 
OpenStack with xen-unstable and libvirt"):
> On Thu, Oct 08, 2015 at 05:42:56PM +0100, Ian Jackson wrote:
> > If we do want to just ignore this issue of the other trees, I do
> > indeed see no particular reason to explicitly set all the runvars to
> > master.
> > 
> > > I think we want a push gate just for the regression tracking, but not
> > > really for its own sake.
> 
> Yes, that is what I had in mind, testing OpenStack with tips of xen and
> libvirt.
> > 
> > In that case we I think yes don't really need to push multiple branches.
>
> I'll remove all those revision_* runvars.

Do you mean to remove the settings of them all to `master', or the
code to honour them ?

The machinery in the ts-* script to honour revision_xyz and to set
built_revision_xyz is useful because the bisector can use it to finger
individual tress.

Unless, of course, you don't want to run the bisector on these tests.

Ian.

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

Re: [Xen-devel] netbsd in Xen testing environment

[Roger Pau Monné]

Hello,

Sorry for the delay. Ccing Ian Jackson and Ian Campbell, which are the
maintainers of OSSTest (our in-house Xen CI loop tool).

El 05/08/15 a les 18.09, Christoph Badura ha escrit:
> Hi Roger,
> 
> we talk during FOSDEM about setting up NetBSD in your testing environment.
> We agreed to get in touch again after you guys finshed the move to the
> public enviroment and after my projects have become less hectic.
> 
> Are you guys still interested?

AFAIK the move to the new colo is finished, so I guess it's a right time
to start looking into this. The first step would probably be to add a
NetBSD 32 and 64bit PV DomUs, and then we can look into also adding a
NetBSD Dom0 (host).

Some time ago I've added support for a FreeBSD 32/64bit HVM DomU, not
sure if that's very helpful since it's HVM and not PV, but it might be a
good starting point. In any case, OSSTest code can be fetched from:

http://xenbits.xen.org/gitweb/?p=osstest.git;a=summary

Take a look at the ts-freebsd-install script in order to see how DomUs
are set up.

Roger.


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

Re: [Xen-devel] [PATCH 1/2] VT-d: use proper error codes in iommu_enable_x2apic_IR()

[Zhang, Yang Z]

Jan Beulich wrote on 2015-09-29:
> ... allowing to suppress a confusing messeage combination: When 
> ACPI_DMAR_X2APIC_OPT_OUT is set, so far we first logged a message that 
> IR could not be enabled (hence not using x2APIC), followed by one 
> indicating successful initialization of IR (if no other problems prevented 
> that).
> 
> Also adjust the return type of iommu_supports_eim() and fix some 
> broken indentation in the function.
> 
> Signed-off-by: Jan Beulich 

Acked-by: Yang Zhang 

Best regards,
Yang



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

Re: [Xen-devel] [PATCH] raisin: enable ovmf build for arm64

[Stefano Stabellini]

On Tue, 13 Oct 2015, Ian Campbell wrote:
> On Mon, 2015-10-12 at 18:18 +0100, Stefano Stabellini wrote:
> > @@ -30,9 +38,18 @@ function ovmf_build() {
> >  git-checkout $OVMF_URL $OVMF_REVISION ovmf-dir
> >  cd ovmf-dir
> >  
> > -make -C BaseTools/Source/C
> > -OvmfPkg/build.sh -a X64 -b RELEASE -n 4
> > -cp Build/OvmfX64/RELEASE_GCC*/FV/OVMF.fd ovmf.bin
> > +make -C BaseTools
> > +
> > +if [[ $RAISIN_ARCH = "arm64" ]]
> 
> Based on what I understand of the OVMF buildsystem I think you are going to
> eventually want a case $RAISIN_ARCH here, since it seems to vary a fair
> bit.
> 
> > +then
> > +export GCC48_AARCH64_PREFIX=
> 
> Won't this (unexpectedly) leak into other subsequent component builds? Or
> is each component built in a  fresh sub-shell?
> 
> What about host platforms which have a gcc other than 4.8? (e.g. Debian
> Jessie uses 4.9 by default)
> 
> Should you add a comment explaining why this apparent workaround is needed?

That is a good question. It all comes from
https://wiki.linaro.org/LEG/UEFIforXEN, but I don't know why is
required. Without GCC48_AARCH64_PREFIX= and -t GCC48, it won't build.

Ard, do you know why? x86 doesn't need anything like that, as you can
see below.


> > +bash -c "source edksetup.sh && build -a AARCH64 -t GCC48 -p 
> > ArmVirtPkg/ArmVirtXen.dsc -b RELEASE"
> > +mkdir -p "$INST_DIR"/$PREFIX/lib/xen/boot
> > +cp Build/ArmVirtXen-AARCH64/RELEASE_GCC*/FV/XEN_EFI.fd 
> > "$INST_DIR"/$PREFIX/lib/xen/boot/XEN_EFI.fd
> > +else
> > +OvmfPkg/build.sh -a X64 -b RELEASE -n 4
> > +cp Build/OvmfX64/RELEASE_GCC*/FV/OVMF.fd ovmf.bin
> > +fi
> >  
> >  cd "$BASEDIR"
> >  }
> > 
> > ___
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 

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

Re: [Xen-devel] [OSSTEST PATCH 19/26] Toolstack::xl: Provide block_attach method

[Hu, Robert]

> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Saturday, September 26, 2015 3:15 AM
> To: xen-de...@lists.xenproject.org
> Cc: Hu, Robert ; Ian Campbell
> ; Ian Jackson ; Ian
> Jackson 
> Subject: [OSSTEST PATCH 19/26] Toolstack::xl: Provide block_attach method
> 
> It is possible that this may work some of the time with xm, so I have
> taken no measures to prevent it running then.
> 
> Signed-off-by: Ian Jackson 
> 
> v14: New patch
> ---
>  Osstest/Toolstack/xl.pm |8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
> index 0f8abed..cc26d61 100644
> --- a/Osstest/Toolstack/xl.pm
> +++ b/Osstest/Toolstack/xl.pm
> @@ -109,4 +109,12 @@ sub restore () {
>   ." $f", $timeout);
>  }
> 
> +sub block_attach () {
> +my ($self,$gho,$xldiskspec) = @_;
> +die "quotes in $xldiskspec ?" if $xldiskspec =~ m/'/;
> +my $gn = $gho->{Name};
> +my $cmd = $self->{_VerboseCommand}." block-attach $gn
> '$xldiskspec'";

I guess here lacks of a
my $ho = $self->{Host};

> +target_cmd_root($ho, $cmd, 100);
> +}
> +
>  1;
> --
> 1.7.10.4


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

Re: [Xen-devel] [PATCH] raisin: enable ovmf build for arm64

[Stefano Stabellini]

On Tue, 13 Oct 2015, Ian Campbell wrote:
> On Tue, 2015-10-13 at 13:49 +0100, Stefano Stabellini wrote:
> > I didn't git clean enough. You are right, only -t GCC48 is required.
> 
> What if only e.g. gcc-4.9 is available though?

It is just the no -t build that doesn't work. As far as I can tell
looking at BaseTools/Conf/tools_def.template there is no difference
between -t GCC49, -t GCC48 and -t GCC47 in terms of gcc flags.

Of course I could figure out the right GCCXX string to pass based on the
host gcc version, but it seems unnecessary.

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

Re: [Xen-devel] [PATCH] libxc: create an initial FPU state for HVM guests

[Andrew Cooper]

On 13/10/15 14:32, Roger Pau Monne wrote:
> Xen always set the FPU as initialized when loading a HVM context, so libxc
> has to provide a valid FPU context when setting the CPU registers.
>
> Signed-off-by: Roger Pau Monné 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Ian Jackson 
> Cc: Stefano Stabellini 
> Cc: Ian Campbell 
> Cc: Wei Liu 

It should be noted that this is the root cause for the current issue
OSSTest has identified while booting windows.

Reviewed-by: Andrew Cooper 

This will do until we fix the hvm save/load code properly.

> ---
>  tools/libxc/xc_dom_x86.c | 34 ++
>  1 file changed, 34 insertions(+)
>
> diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
> index dd331bf..f8d580c 100644
> --- a/tools/libxc/xc_dom_x86.c
> +++ b/tools/libxc/xc_dom_x86.c
> @@ -841,6 +841,23 @@ static int vcpu_hvm(struct xc_dom_image *dom)
>  struct hvm_save_descriptor end_d;
>  HVM_SAVE_TYPE(END) end;
>  } bsp_ctx;
> +struct {
> +uint16_t fcw;
> +uint16_t fsw;
> +uint8_t ftw;
> +uint8_t rsvd1;
> +uint16_t fop;
> +union {
> +uint64_t addr;
> +struct {
> +uint32_t offs;
> +uint16_t sel;
> +uint16_t rsvd;
> +};
> +} fip, fdp;
> +uint32_t mxcsr;
> +uint32_t mxcsr_mask;
> +} *fpu_ctxt;
>  uint8_t *full_ctx = NULL;
>  int rc;
>  
> @@ -908,6 +925,23 @@ static int vcpu_hvm(struct xc_dom_image *dom)
>  /* Set the control registers. */
>  bsp_ctx.cpu.cr0 = X86_CR0_PE | X86_CR0_ET;
>  
> +/*
> + * XXX: Set initial FPU state.
> + *
> + * This should be removed once Xen is able to know if the
> + * FPU state saved is valid or not, now Xen always sets
> + * fpu_initialised to true regardless of the FPU state.
> + *
> + * The code below mimics the FPU sate after executing
> + * fninit
> + * ldmxcsr 0x1f80
> + */
> +fpu_ctxt = (typeof(fpu_ctxt))bsp_ctx.cpu.fpu_regs;
> +
> +fpu_ctxt->fcw = 0x37f;
> +fpu_ctxt->ftw = 0xff;
> +fpu_ctxt->mxcsr = 0x1f80;
> +
>  /* Set the IP. */
>  bsp_ctx.cpu.rip = dom->parms.phys_entry;
>  


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

Re: [Xen-devel] [PATCH] raisin: enable ovmf build for arm64

[Julien Grall]

On 13/10/15 14:18, Stefano Stabellini wrote:
> On Tue, 13 Oct 2015, Ian Campbell wrote:
>> On Tue, 2015-10-13 at 13:49 +0100, Stefano Stabellini wrote:
>>> I didn't git clean enough. You are right, only -t GCC48 is required.
>>
>> What if only e.g. gcc-4.9 is available though?
> 
> It is just the no -t build that doesn't work. As far as I can tell
> looking at BaseTools/Conf/tools_def.template there is no difference
> between -t GCC49, -t GCC48 and -t GCC47 in terms of gcc flags.

The differences may be more subtle. I would be surprised if they
duplicate code just for having the variable name GCCXX matching the
version of the compiler.

For instance compiling using GCC 5.0 folds under GCC49. They didn't
bother to add a new GCCXX.

FWIW, the scripts to build x86 (OvmfPkg/build.sh) is detecting which
compiler is used and will setup the TARGET_TOOLS correctly:

gcc_version=$(gcc -v 2>&1 | tail -1 | awk '{print $3}')
case $gcc_version in
  4.5.*)
TARGET_TOOLS=GCC45
;;
  4.6.*)
TARGET_TOOLS=GCC46
;;
  4.7.*)
TARGET_TOOLS=GCC47
;;
  4.8.*)
TARGET_TOOLS=GCC48
;;
  4.9.*|4.1[0-9].*|5.*.*)
TARGET_TOOLS=GCC49
;;
  *)
TARGET_TOOLS=GCC44
;;
esac

A couple of weeks ago I've looked at porting this script for ARM but it
wasn't trivial to do it (i.e requiring more than a couple of hours to
fix it).

Regards,

-- 
Julien Grall

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

[Xen-devel] [PATCH] libxc: create an initial FPU state for HVM guests

[Roger Pau Monne]

Xen always set the FPU as initialized when loading a HVM context, so libxc
has to provide a valid FPU context when setting the CPU registers.

Signed-off-by: Roger Pau Monné 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
---
 tools/libxc/xc_dom_x86.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index dd331bf..f8d580c 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -841,6 +841,23 @@ static int vcpu_hvm(struct xc_dom_image *dom)
 struct hvm_save_descriptor end_d;
 HVM_SAVE_TYPE(END) end;
 } bsp_ctx;
+struct {
+uint16_t fcw;
+uint16_t fsw;
+uint8_t ftw;
+uint8_t rsvd1;
+uint16_t fop;
+union {
+uint64_t addr;
+struct {
+uint32_t offs;
+uint16_t sel;
+uint16_t rsvd;
+};
+} fip, fdp;
+uint32_t mxcsr;
+uint32_t mxcsr_mask;
+} *fpu_ctxt;
 uint8_t *full_ctx = NULL;
 int rc;
 
@@ -908,6 +925,23 @@ static int vcpu_hvm(struct xc_dom_image *dom)
 /* Set the control registers. */
 bsp_ctx.cpu.cr0 = X86_CR0_PE | X86_CR0_ET;
 
+/*
+ * XXX: Set initial FPU state.
+ *
+ * This should be removed once Xen is able to know if the
+ * FPU state saved is valid or not, now Xen always sets
+ * fpu_initialised to true regardless of the FPU state.
+ *
+ * The code below mimics the FPU sate after executing
+ * fninit
+ * ldmxcsr 0x1f80
+ */
+fpu_ctxt = (typeof(fpu_ctxt))bsp_ctx.cpu.fpu_regs;
+
+fpu_ctxt->fcw = 0x37f;
+fpu_ctxt->ftw = 0xff;
+fpu_ctxt->mxcsr = 0x1f80;
+
 /* Set the IP. */
 bsp_ctx.cpu.rip = dom->parms.phys_entry;
 
-- 
1.9.5 (Apple Git-50.3)


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

[Xen-devel] [PATCH] cxenstored: avoid using hardcoded paths

[Wei Liu]

Use library functions which return socket paths instead.

Signed-off-by: Wei Liu 
---
 tools/xenstore/xenstored_core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index eae4d31..bddec70 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -1769,8 +1769,8 @@ static int xs_get_sd_fd(const char *connect_to)
 
 static int xs_validate_active_socket(const char *connect_to)
 {
-   if ((strcmp("/var/run/xenstored/socket_ro", connect_to) != 0) &&
-   (strcmp("/var/run/xenstored/socket", connect_to) != 0)) {
+   if ((strcmp(xs_daemon_socket_ro(), connect_to) != 0) &&
+   (strcmp(xs_daemon_socket(), connect_to) != 0)) {
sd_notifyf(0, "STATUS=unexpected socket: %s\n"
   "ERRNO=%i",
   connect_to,
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] raisin: enable ovmf build for arm64

[Stefano Stabellini]

On Tue, 13 Oct 2015, Julien Grall wrote:
> On 13/10/15 14:18, Stefano Stabellini wrote:
> > On Tue, 13 Oct 2015, Ian Campbell wrote:
> >> On Tue, 2015-10-13 at 13:49 +0100, Stefano Stabellini wrote:
> >>> I didn't git clean enough. You are right, only -t GCC48 is required.
> >>
> >> What if only e.g. gcc-4.9 is available though?
> > 
> > It is just the no -t build that doesn't work. As far as I can tell
> > looking at BaseTools/Conf/tools_def.template there is no difference
> > between -t GCC49, -t GCC48 and -t GCC47 in terms of gcc flags.
> 
> The differences may be more subtle. I would be surprised if they
> duplicate code just for having the variable name GCCXX matching the
> version of the compiler.
> 
> For instance compiling using GCC 5.0 folds under GCC49. They didn't
> bother to add a new GCCXX.
> 
> FWIW, the scripts to build x86 (OvmfPkg/build.sh) is detecting which
> compiler is used and will setup the TARGET_TOOLS correctly:
> 
> gcc_version=$(gcc -v 2>&1 | tail -1 | awk '{print $3}')
> case $gcc_version in
>   4.5.*)
> TARGET_TOOLS=GCC45
> ;;
>   4.6.*)
> TARGET_TOOLS=GCC46
> ;;
>   4.7.*)
> TARGET_TOOLS=GCC47
> ;;
>   4.8.*)
> TARGET_TOOLS=GCC48
> ;;
>   4.9.*|4.1[0-9].*|5.*.*)
> TARGET_TOOLS=GCC49
> ;;
>   *)
> TARGET_TOOLS=GCC44
> ;;
> esac
> 
> A couple of weeks ago I've looked at porting this script for ARM but it
> wasn't trivial to do it (i.e requiring more than a couple of hours to
> fix it).

And it wouldn't solve the problem for the current and past ovfm
versions. I think it might be best to just import the case .. esac
above into the raisin build script for ovmf arm64.

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

Re: [Xen-devel] [PATCH] libxc: create an initial FPU state for HVM guests

[Ian Campbell]

On Tue, 2015-10-13 at 15:32 +0200, Roger Pau Monne wrote:
> Xen always set the FPU as initialized when loading a HVM context, so
> libxc
> has to provide a valid FPU context when setting the CPU registers.
> 
> Signed-off-by: Roger Pau Monné 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Ian Jackson 
> Cc: Stefano Stabellini 
> Cc: Ian Campbell 
> Cc: Wei Liu 
> ---
>  tools/libxc/xc_dom_x86.c | 34 ++
>  1 file changed, 34 insertions(+)
> 
> diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
> index dd331bf..f8d580c 100644
> --- a/tools/libxc/xc_dom_x86.c
> +++ b/tools/libxc/xc_dom_x86.c
> @@ -841,6 +841,23 @@ static int vcpu_hvm(struct xc_dom_image *dom)
>  struct hvm_save_descriptor end_d;
>  HVM_SAVE_TYPE(END) end;
>  } bsp_ctx;
> +struct {
> +uint16_t fcw;
> +uint16_t fsw;
> +uint8_t ftw;
> +uint8_t rsvd1;
> +uint16_t fop;
> +union {
> +uint64_t addr;
> +struct {
> +uint32_t offs;
> +uint16_t sel;
> +uint16_t rsvd;
> +};
> +} fip, fdp;
> +uint32_t mxcsr;
> +uint32_t mxcsr_mask;
> +} *fpu_ctxt;
>  uint8_t *full_ctx = NULL;
>  int rc;
>  
> @@ -908,6 +925,23 @@ static int vcpu_hvm(struct xc_dom_image *dom)
>  /* Set the control registers. */
>  bsp_ctx.cpu.cr0 = X86_CR0_PE | X86_CR0_ET;
>  
> +/*
> + * XXX: Set initial FPU state.
> + *
> + * This should be removed once Xen is able to know if the
> + * FPU state saved is valid or not, now Xen always sets
> + * fpu_initialised to true regardless of the FPU state.

I suppose we aren't just doing that now because there is some complexity in
doing so? Can that be mentioned in the commit log please.

Other than that if the hypervisor folks are happy with a) the approach and
b) the specifics of fpu_ctxt described below then it's fine by me too.


> + *
> + * The code below mimics the FPU sate after executing
> + * fninit
> + * ldmxcsr 0x1f80
> + */
> +fpu_ctxt = (typeof(fpu_ctxt))bsp_ctx.cpu.fpu_regs;
> +
> +fpu_ctxt->fcw = 0x37f;
> +fpu_ctxt->ftw = 0xff;
> +fpu_ctxt->mxcsr = 0x1f80;
> +
>  /* Set the IP. */
>  bsp_ctx.cpu.rip = dom->parms.phys_entry;
>  

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

Re: [Xen-devel] [PATCH] raisin: enable ovmf build for arm64

[Stefano Stabellini]

On Tue, 13 Oct 2015, Ard Biesheuvel wrote:
> > On 13 okt. 2015, at 15:31, Julien Grall  wrote:
> > 
> >> On 13/10/15 14:18, Stefano Stabellini wrote:
> >>> On Tue, 13 Oct 2015, Ian Campbell wrote:
>  On Tue, 2015-10-13 at 13:49 +0100, Stefano Stabellini wrote:
>  I didn't git clean enough. You are right, only -t GCC48 is required.
> >>> 
> >>> What if only e.g. gcc-4.9 is available though?
> >> 
> >> It is just the no -t build that doesn't work. As far as I can tell
> >> looking at BaseTools/Conf/tools_def.template there is no difference
> >> between -t GCC49, -t GCC48 and -t GCC47 in terms of gcc flags.
> > 
> > The differences may be more subtle. I would be surprised if they
> > duplicate code just for having the variable name GCCXX matching the
> > version of the compiler.
> > 
> 
> That was actually the case starting out, (i.e., lots of toolchain definitions 
> resolving to the same set of options) simply because a few guys thought it 
> makes sense, and those guys happen to be in charge :-)
> 
> But in the mean time, as Stefano found out, the tiny code model we prefer for 
> AArch64 (which uses relative symbol references but without the 4k alignment 
> requirement imposed by the small model) is only available under gcc 4.9 and 
> up so everything below that uses the large model (absolute symbol references 
> only)

Do you mean is only available for gcc <= 4.9 and gcc >= 4.7 ?

Do you think it is best to just force -t GCC48 independently from the
actual gcc version? Or should we use some kind of logic like the one
below:


> >gcc_version=$(gcc -v 2>&1 | tail -1 | awk '{print $3}')
> >case $gcc_version in
> >  4.5.*)
> >TARGET_TOOLS=GCC45
> >;;
> >  4.6.*)
> >TARGET_TOOLS=GCC46
> >;;
> >  4.7.*)
> >TARGET_TOOLS=GCC47
> >;;
> >  4.8.*)
> >TARGET_TOOLS=GCC48
> >;;
> >  4.9.*|4.1[0-9].*|5.*.*)
> >TARGET_TOOLS=GCC49
> >;;
> >  *)
> >TARGET_TOOLS=GCC44
> >;;
> >esac
 

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

Re: [Xen-devel] [PATCH] raisin: enable ovmf build for arm64

[Ard Biesheuvel]

> On 13 okt. 2015, at 15:31, Julien Grall  wrote:
> 
>> On 13/10/15 14:18, Stefano Stabellini wrote:
>>> On Tue, 13 Oct 2015, Ian Campbell wrote:
 On Tue, 2015-10-13 at 13:49 +0100, Stefano Stabellini wrote:
 I didn't git clean enough. You are right, only -t GCC48 is required.
>>> 
>>> What if only e.g. gcc-4.9 is available though?
>> 
>> It is just the no -t build that doesn't work. As far as I can tell
>> looking at BaseTools/Conf/tools_def.template there is no difference
>> between -t GCC49, -t GCC48 and -t GCC47 in terms of gcc flags.
> 
> The differences may be more subtle. I would be surprised if they
> duplicate code just for having the variable name GCCXX matching the
> version of the compiler.
> 

That was actually the case starting out, (i.e., lots of toolchain definitions 
resolving to the same set of options) simply because a few guys thought it 
makes sense, and those guys happen to be in charge :-)

But in the mean time, as Stefano found out, the tiny code model we prefer for 
AArch64 (which uses relative symbol references but without the 4k alignment 
requirement imposed by the small model) is only available under gcc 4.9 and up 
so everything below that uses the large model (absolute symbol references only)

> For instance compiling using GCC 5.0 folds under GCC49. They didn't
> bother to add a new GCCXX.
> 
> FWIW, the scripts to build x86 (OvmfPkg/build.sh) is detecting which
> compiler is used and will setup the TARGET_TOOLS correctly:
> 
>gcc_version=$(gcc -v 2>&1 | tail -1 | awk '{print $3}')
>case $gcc_version in
>  4.5.*)
>TARGET_TOOLS=GCC45
>;;
>  4.6.*)
>TARGET_TOOLS=GCC46
>;;
>  4.7.*)
>TARGET_TOOLS=GCC47
>;;
>  4.8.*)
>TARGET_TOOLS=GCC48
>;;
>  4.9.*|4.1[0-9].*|5.*.*)
>TARGET_TOOLS=GCC49
>;;
>  *)
>TARGET_TOOLS=GCC44
>;;
>esac
> 
> A couple of weeks ago I've looked at porting this script for ARM but it
> wasn't trivial to do it (i.e requiring more than a couple of hours to
> fix it).
> 
> Regards,
> 
> -- 
> Julien Grall

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

Re: [Xen-devel] [PATCH V7 3/7] libxl: add pvusb API

[George Dunlap]

On 13/10/15 02:46, Chun Yan Liu wrote:
> 
> 
> On 10/12/2015 09:46 PM, George Dunlap wrote:
>> On 12/10/15 08:19, Chun Yan Liu wrote:
> +
> +usbinfo->devnum = usb->u.hostdev.hostaddr;
> +usbinfo->busnum = usb->u.hostdev.hostbus;
> +
> +busid = usb_busaddr_to_busid(gc, usb->u.hostdev.hostbus,
> + usb->u.hostdev.hostaddr);
> +if (!busid) {
> +rc = ERROR_FAIL;
> +goto out;
> +}
> +
> +filename = GCSPRINTF(SYSFS_USB_DEV"/%s/idVendor", busid);
> +if (!libxl_read_sysfs_file_contents(ctx, filename, , NULL))
> +sscanf(buf, "%" SCNx16, >idVendor);
> +
> +filename = GCSPRINTF(SYSFS_USB_DEV"/%s/idProduct", busid);
> +if (!libxl_read_sysfs_file_contents(ctx, filename, , NULL))
> +sscanf(buf, "%" SCNx16, >idProduct);
> +
> +filename = GCSPRINTF(SYSFS_USB_DEV"/%s/manufacturer", busid);
> +if (!libxl_read_sysfs_file_contents(ctx, filename, ,
> ) &&
> +buflen > 0) {
> +/* replace \n to \0 */
> +if (((char *)buf)[buflen - 1] == '\n')
> +((char *)buf)[buflen - 1] = '\0';
> +usbinfo->manuf = libxl__strdup(NOGC, buf);
> +   }
> +
> +filename = GCSPRINTF(SYSFS_USB_DEV"/%s/product", busid);
> +if (!libxl_read_sysfs_file_contents(ctx, filename, ,
> ) &&
> +buflen > 0) {
> +/* replace \n to \0 */
> +if (((char *)buf)[buflen - 1] == '\n')
> +((char *)buf)[buflen - 1] = '\0';
> +usbinfo->prod = libxl__strdup(NOGC, buf);
> +}
   Basically, starting here, we have information which won't be
 available
 if we're using a pvusb driver domain.
   This information is nice-to-have, but I don't think this
 information is
 directly relevant to libxl or xl; the funcitonality to get this
 information is available from other libraries like libusb.  I'm
 inclined
 to say that if we want to have pvusb driver domains (and I think we
 do),
 we should just get rid of this information.
>>> For command 'xl usb-list', those information should be reported to user.
>>> Do you mean we could call libusb to get thoes information directly in
>>> xl toolstack and get rid of this function?
>>>
>>> I think we can keep the function, since every other device type has the
>>> function XXX_getinfo. But here we could check backend_domid, for
>>> backend=dom0, doing above work; for backend!=dom0 (e.g. pvusb
>>> driver domain, no matter how, it should also be able to let users
>>> getting
>>> those information. Can add code  in future.)
>> Does xl need that information?  Can't the user get that information from
>> lsusb?
>>
>> In any case, I can see why it would be *useful* to have in xl.  But
>> about having it in libxl, I think this question sort of goes along with
>> the question about the next patch -- whether libxl should be in the
>> business of providing general information about the USB devices it's
>> handling, or whether it should limit itself to doing what is absolutely
>> necessary to talk to usbback.
>>
>> There's a part of me that sees the point of it: it's not actually that
>> much extra code (at least for Linux), and it makes it easy to add some
>> very useful features to xl.
>>
>> On the other hand, it's not portable to other OSes.  At the moment of
>> course pvusb isn't portable either, but once we have qemu USB (providing
>> either emulated or PV usb) then I *think* most of the other
>> functionality will Just Work on any platform that can compile qemu
>> (incl. FreeBSD, NetBSD, ), won't it?  The code you're introducing here
>> would have to be re-implented for those platforms, and for every new
>> platform that wanted to include this functionality, wouldn't it?
> So, about the portability problem, I think it's back to: do need to
> update code to call libusb instead of reading sysfs now? Except
> for this function, still have places reading sysfs to get hostbus,
> hostaddr, vendorId, deviceId. Those are not portable for other
> platform.

I realize I didn't give you very clear guidance; I guess I was hoping to
get an opinion from the tools maintainers.  Or perhaps, I was hoping to
let them be the "bad guys" and say, "You can't have this feature in
libxl", so I wouldn't have to. :-)

In the absence of guidance to the contrary, I suggest that patch series
should focus on getting the core pvusb functionality in, without the
extra usb-querying bits.  Then we can discuss a further series which
either adds the usb querying functionality to libxl, or implement it in
xl using libusb.

 -George

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

Re: [Xen-devel] [PATCH] x86: hide MWAITX from PV domains

[Andrew Cooper]

On 13/10/15 13:25, Jan Beulich wrote:
> Since MWAIT is hidden too. (Linux starting with 4.3 is making use of
> that feature, and is checking for it without looking at the MWAIT one.)

This is surely a Linux bug which wants fixing as well?

>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

>
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -964,6 +964,7 @@ void pv_cpuid(struct cpu_user_regs *regs
>  __clear_bit(X86_FEATURE_LWP % 32, );
>  __clear_bit(X86_FEATURE_NODEID_MSR % 32, );
>  __clear_bit(X86_FEATURE_TOPOEXT % 32, );
> +__clear_bit(X86_FEATURE_MWAITX % 32, );
>  break;
>  
>  case 0x000a: /* Architectural Performance Monitor Features (Intel) */
> --- a/xen/include/asm-x86/cpufeature.h
> +++ b/xen/include/asm-x86/cpufeature.h
> @@ -140,6 +140,7 @@
>  #define X86_FEATURE_TBM (6*32+21) /* trailing bit manipulations */
>  #define X86_FEATURE_TOPOEXT (6*32+22) /* topology extensions CPUID leafs 
> */
>  #define X86_FEATURE_DBEXT   (6*32+26) /* data breakpoint extension */
> +#define X86_FEATURE_MWAITX  (6*32+29) /* MWAIT extension 
> (MONITORX/MWAITX) */
>  
>  /* Intel-defined CPU features, CPUID level 0x0007:0 (ebx), word 7 */
>  #define X86_FEATURE_FSGSBASE (7*32+ 0) /* {RD,WR}{FS,GS}BASE instructions */
>
>
>


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

Re: [Xen-devel] [PATCH] raisin: enable ovmf build for arm64

[Julien Grall]

On 13/10/15 14:00, Ian Campbell wrote:
> On Tue, 2015-10-13 at 13:49 +0100, Stefano Stabellini wrote:
>> I didn't git clean enough. You are right, only -t GCC48 is required.
> 
> What if only e.g. gcc-4.9 is available though?

Note that I'm able to build ovmf on Jessie with -t GCC48.

Although I don't know what is the different between -t GCC48 and -t
GCC49. Ard might be able to tell more?

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH] x86: hide MWAITX from PV domains

[Jan Beulich]

>>> On 13.10.15 at 15:15,  wrote:
> On 13/10/15 13:25, Jan Beulich wrote:
>> Since MWAIT is hidden too. (Linux starting with 4.3 is making use of
>> that feature, and is checking for it without looking at the MWAIT one.)
> 
> This is surely a Linux bug which wants fixing as well?

I don't think that's a bug - I cannot see it being invalid to have
MWAITX but not MWAIT. That's just pretty unlikely.

Jan


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

Re: [Xen-devel] [PATCH V7 3/7] libxl: add pvusb API

[George Dunlap]

On 13/10/15 14:15, George Dunlap wrote:
> On 13/10/15 02:46, Chun Yan Liu wrote:
>>
>>
>> On 10/12/2015 09:46 PM, George Dunlap wrote:
>>> On 12/10/15 08:19, Chun Yan Liu wrote:
>> +
>> +usbinfo->devnum = usb->u.hostdev.hostaddr;
>> +usbinfo->busnum = usb->u.hostdev.hostbus;
>> +
>> +busid = usb_busaddr_to_busid(gc, usb->u.hostdev.hostbus,
>> + usb->u.hostdev.hostaddr);
>> +if (!busid) {
>> +rc = ERROR_FAIL;
>> +goto out;
>> +}
>> +
>> +filename = GCSPRINTF(SYSFS_USB_DEV"/%s/idVendor", busid);
>> +if (!libxl_read_sysfs_file_contents(ctx, filename, , NULL))
>> +sscanf(buf, "%" SCNx16, >idVendor);
>> +
>> +filename = GCSPRINTF(SYSFS_USB_DEV"/%s/idProduct", busid);
>> +if (!libxl_read_sysfs_file_contents(ctx, filename, , NULL))
>> +sscanf(buf, "%" SCNx16, >idProduct);
>> +
>> +filename = GCSPRINTF(SYSFS_USB_DEV"/%s/manufacturer", busid);
>> +if (!libxl_read_sysfs_file_contents(ctx, filename, ,
>> ) &&
>> +buflen > 0) {
>> +/* replace \n to \0 */
>> +if (((char *)buf)[buflen - 1] == '\n')
>> +((char *)buf)[buflen - 1] = '\0';
>> +usbinfo->manuf = libxl__strdup(NOGC, buf);
>> +   }
>> +
>> +filename = GCSPRINTF(SYSFS_USB_DEV"/%s/product", busid);
>> +if (!libxl_read_sysfs_file_contents(ctx, filename, ,
>> ) &&
>> +buflen > 0) {
>> +/* replace \n to \0 */
>> +if (((char *)buf)[buflen - 1] == '\n')
>> +((char *)buf)[buflen - 1] = '\0';
>> +usbinfo->prod = libxl__strdup(NOGC, buf);
>> +}
>   Basically, starting here, we have information which won't be
> available
> if we're using a pvusb driver domain.
>   This information is nice-to-have, but I don't think this
> information is
> directly relevant to libxl or xl; the funcitonality to get this
> information is available from other libraries like libusb.  I'm
> inclined
> to say that if we want to have pvusb driver domains (and I think we
> do),
> we should just get rid of this information.
 For command 'xl usb-list', those information should be reported to user.
 Do you mean we could call libusb to get thoes information directly in
 xl toolstack and get rid of this function?

 I think we can keep the function, since every other device type has the
 function XXX_getinfo. But here we could check backend_domid, for
 backend=dom0, doing above work; for backend!=dom0 (e.g. pvusb
 driver domain, no matter how, it should also be able to let users
 getting
 those information. Can add code  in future.)
>>> Does xl need that information?  Can't the user get that information from
>>> lsusb?
>>>
>>> In any case, I can see why it would be *useful* to have in xl.  But
>>> about having it in libxl, I think this question sort of goes along with
>>> the question about the next patch -- whether libxl should be in the
>>> business of providing general information about the USB devices it's
>>> handling, or whether it should limit itself to doing what is absolutely
>>> necessary to talk to usbback.
>>>
>>> There's a part of me that sees the point of it: it's not actually that
>>> much extra code (at least for Linux), and it makes it easy to add some
>>> very useful features to xl.
>>>
>>> On the other hand, it's not portable to other OSes.  At the moment of
>>> course pvusb isn't portable either, but once we have qemu USB (providing
>>> either emulated or PV usb) then I *think* most of the other
>>> functionality will Just Work on any platform that can compile qemu
>>> (incl. FreeBSD, NetBSD, ), won't it?  The code you're introducing here
>>> would have to be re-implented for those platforms, and for every new
>>> platform that wanted to include this functionality, wouldn't it?
>> So, about the portability problem, I think it's back to: do need to
>> update code to call libusb instead of reading sysfs now? Except
>> for this function, still have places reading sysfs to get hostbus,
>> hostaddr, vendorId, deviceId. Those are not portable for other
>> platform.
> 
> I realize I didn't give you very clear guidance; I guess I was hoping to
> get an opinion from the tools maintainers.  Or perhaps, I was hoping to
> let them be the "bad guys" and say, "You can't have this feature in
> libxl", so I wouldn't have to. :-)
> 
> In the absence of guidance to the contrary, I suggest that patch series
> should focus on getting the core pvusb functionality in, without the
> extra usb-querying bits.  Then we can discuss a further series which
> either adds the usb querying functionality to libxl, or implement it in
> xl using libusb.

Just to be clear: Reading sysfs to actually implement the core pvusb
protocol is fine, because at the moment there *is* only a 

Re: [Xen-devel] [PATCH] x86/time: slightly streamline __update_vcpu_system_time()

[Andrew Cooper]

On 13/10/15 13:27, Jan Beulich wrote:
> Fold two if()-s using the same condition, converting the memset() so
> far separating them to a simple initializer. Move common assignments
> out of the conditional. Drop an unnecessary initializer.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH] x86/NUMA: fix SRAT table processor entry parsing and consumption

[Andrew Cooper]

On 13/10/15 13:28, Jan Beulich wrote:
> - don't overrun apicid_to_node[] (possible in the x2APIC case)
> - don't limit number of processor related SRAT entries we can consume
> - make acpi_numa_{processor,x2apic}_affinity_init() as similar to one
>   another as possible
> - print APIC IDs in hex (to ease matching with other log messages), at
>   once making legacy and x2APIC ones distinguishable (by width)
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH V7 3/7] libxl: add pvusb API

[Ian Campbell]

On Tue, 2015-10-13 at 14:15 +0100, George Dunlap wrote:
> In the absence of guidance to the contrary, I suggest that patch series
> should focus on getting the core pvusb functionality in, without the
> extra usb-querying bits.  Then we can discuss a further series which
> either adds the usb querying functionality to libxl, or implement it in
> xl using libusb.

That would seem sensible to me. Lets get the (hopefully) uncontroversial
core functionality done and then worry about any extras etc, since they
seem to be preventing us from making forward progress at the moment.

Ian.

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

Re: [Xen-devel] [PATCH] x86/time: slightly streamline __update_vcpu_system_time()

[Andrew Cooper]

On 13/10/15 13:27, Jan Beulich wrote:
> Fold two if()-s using the same condition, converting the memset() so
> far separating them to a simple initializer. Move common assignments
> out of the conditional. Drop an unnecessary initializer.
>
> Signed-off-by: Jan Beulich 
> ---
> Additionally the is_hvm_domain() visible in the last hunk's tail
> context looks, along with a few other releated ones, suspicious -
> shouldn't these be has_hvm_container_domain() instead?

I believe you are correct.

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

Re: [Xen-devel] [PATCH] x86/NUMA: cleanup

[Andrew Cooper]

On 13/10/15 13:29, Jan Beulich wrote:
> - constification
> - prefer container_of() over casts
> - check original pointer against NULL instead of the container_of()
>   result
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [V6 1/4] x86/xsaves: add basic definitions/helpers to support xsaves

[Jan Beulich]

>>> On 12.10.15 at 08:07,  wrote:
> --- a/xen/arch/x86/xstate.c
> +++ b/xen/arch/x86/xstate.c
> @@ -23,6 +23,11 @@ static u32 __read_mostly xsave_cntxt_size;
>  
>  /* A 64-bit bitmask of the XSAVE/XRSTOR features supported by processor. */
>  u64 __read_mostly xfeature_mask;
> +unsigned int * __read_mostly xstate_offsets;
> +unsigned int * __read_mostly xstate_sizes;

You appear to need the latter outside of this file in patch 3, but the
former could (and hence should) be static afaict.

> --- a/xen/include/asm-x86/xstate.h
> +++ b/xen/include/asm-x86/xstate.h
> @@ -19,7 +19,11 @@
>  
>  #define XCR_XFEATURE_ENABLED_MASK 0x  /* index of XCR0 */
>  
> +#define XSAVE_HDR_SIZE64
> +#define XSAVE_SSE_OFFSET  160
>  #define XSTATE_YMM_SIZE   256
> +#define FXSAVE_SIZE   512
> +#define XSAVE_HDR_OFFSET  FXSAVE_SIZE
>  #define XSTATE_AREA_MIN_SIZE  (512 + 64)  /* FP/SSE + XSAVE.HEADER */

This 512 should now get replaced too.

> @@ -38,8 +42,24 @@
>  #define XSTATE_ALL (~(1ULL << 63))
>  #define XSTATE_NONLAZY (XSTATE_LWP | XSTATE_BNDREGS | XSTATE_BNDCSR)
>  #define XSTATE_LAZY(XSTATE_ALL & ~XSTATE_NONLAZY)
> +#define XSTATE_COMPACTION_ENABLED  (1ULL << 63)
> +
> +#define XSTATE_FIXUP ".section .fixup,\"ax\"  \n"\
> + "2: mov %5,%%ecx \n"\
> + "   xor %1,%1\n"\
> + "   rep stosb\n"\
> + "   lea %2,%0\n"\
> + "   mov %3,%1\n"\
> + "   jmp 1b   \n"\
> + ".previous   \n"\
> + _ASM_EXTABLE(1b, 2b)\
> + : "+" (ptr), "+" (lmask)\
> + : "m" (*ptr), "g" (lmask), "d" (hmask), \
> +   "m" (xsave_cntxt_size)\
> + : "ecx"

First of all I don't think this belongs here - neither in this patch, nor
in this header. It's not being used by this patch, and the connection
between variable names used here and in patch 2 is completely lost.
If you put this into xrstor() as a local #define, then this may be
okay. In any other case the user of the macro has to have a way
to control the variable names used.

Jan


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

Re: [Xen-devel] [PATCH] raisin: enable ovmf build for arm64

[Ard Biesheuvel]

> On 13 okt. 2015, at 15:48, Stefano Stabellini 
>  wrote:
> 
> On Tue, 13 Oct 2015, Ard Biesheuvel wrote:
>>> On 13 okt. 2015, at 15:31, Julien Grall  wrote:
>>> 
> On 13/10/15 14:18, Stefano Stabellini wrote:
>> On Tue, 13 Oct 2015, Ian Campbell wrote:
>> On Tue, 2015-10-13 at 13:49 +0100, Stefano Stabellini wrote:
>> I didn't git clean enough. You are right, only -t GCC48 is required.
> 
> What if only e.g. gcc-4.9 is available though?
 
 It is just the no -t build that doesn't work. As far as I can tell
 looking at BaseTools/Conf/tools_def.template there is no difference
 between -t GCC49, -t GCC48 and -t GCC47 in terms of gcc flags.
>>> 
>>> The differences may be more subtle. I would be surprised if they
>>> duplicate code just for having the variable name GCCXX matching the
>>> version of the compiler.
>>> 
>> 
>> That was actually the case starting out, (i.e., lots of toolchain 
>> definitions resolving to the same set of options) simply because a few guys 
>> thought it makes sense, and those guys happen to be in charge :-)
>> 
>> But in the mean time, as Stefano found out, the tiny code model we prefer 
>> for AArch64 (which uses relative symbol references but without the 4k 
>> alignment requirement imposed by the small model) is only available under 
>> gcc 4.9 and up so everything below that uses the large model (absolute 
>> symbol references only)
> 
> Do you mean is only available for gcc <= 4.9 and gcc >= 4.7 ?
> 

The first gcc version to support the AArch64 tiny model is 4.9, but Linaro 
backported it so some variants of 4.8 support it as well.

> Do you think it is best to just force -t GCC48 independently from the
> actual gcc version? Or should we use some kind of logic like the one
> below:
> 

For now, just using GCC48 should work fine, but as I said, the tiny model is 
the recommended model so if you have 4.9, it is preferred imo. But other than 
that, the builds should be mostly identical.

> 
>>>   gcc_version=$(gcc -v 2>&1 | tail -1 | awk '{print $3}')
>>>   case $gcc_version in
>>> 4.5.*)
>>>   TARGET_TOOLS=GCC45
>>>   ;;
>>> 4.6.*)
>>>   TARGET_TOOLS=GCC46
>>>   ;;
>>> 4.7.*)
>>>   TARGET_TOOLS=GCC47
>>>   ;;
>>> 4.8.*)
>>>   TARGET_TOOLS=GCC48
>>>   ;;
>>> 4.9.*|4.1[0-9].*|5.*.*)
>>>   TARGET_TOOLS=GCC49
>>>   ;;
>>> *)
>>>   TARGET_TOOLS=GCC44
>>>   ;;
>>>   esac
> 

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

Re: [Xen-devel] [PATCH] raisin: enable ovmf build for arm64

[Julien Grall]

On 13/10/15 11:58, Stefano Stabellini wrote:
> On Tue, 13 Oct 2015, Ian Campbell wrote:
>> On Mon, 2015-10-12 at 18:18 +0100, Stefano Stabellini wrote:
>>> @@ -30,9 +38,18 @@ function ovmf_build() {
>>>  git-checkout $OVMF_URL $OVMF_REVISION ovmf-dir
>>>  cd ovmf-dir
>>>  
>>> -make -C BaseTools/Source/C
>>> -OvmfPkg/build.sh -a X64 -b RELEASE -n 4
>>> -cp Build/OvmfX64/RELEASE_GCC*/FV/OVMF.fd ovmf.bin
>>> +make -C BaseTools
>>> +
>>> +if [[ $RAISIN_ARCH = "arm64" ]]
>>
>> Based on what I understand of the OVMF buildsystem I think you are going to
>> eventually want a case $RAISIN_ARCH here, since it seems to vary a fair
>> bit.
>>
>>> +then
>>> +export GCC48_AARCH64_PREFIX=
>>
>> Won't this (unexpectedly) leak into other subsequent component builds? Or
>> is each component built in a  fresh sub-shell?
>>
>> What about host platforms which have a gcc other than 4.8? (e.g. Debian
>> Jessie uses 4.9 by default)
>>
>> Should you add a comment explaining why this apparent workaround is needed?
> 
> That is a good question. It all comes from
> https://wiki.linaro.org/LEG/UEFIforXEN, but I don't know why is
> required. Without GCC48_AARCH64_PREFIX= and -t GCC48, it won't build.

Are you sure? I'm able to build without GCC48_AARCH64_PREFIX=.

Although -t GCC48 is still required:

42sh> build -a AARCH64 -p ArmVirtPkg/ArmVirtXen.dsc -b RELEASE

WORKSPACE= /root/works/edk2
ECP_SOURCE   = /root/works/edk2/EdkCompatibilityPkg
EDK_SOURCE   = /root/works/edk2/EdkCompatibilityPkg
EFI_SOURCE   = /root/works/edk2/EdkCompatibilityPkg
EDK_TOOLS_PATH   = /root/works/edk2/BaseTools


Architecture(s)  = AARCH64
Build target = RELEASE
Toolchain= MYTOOLS

Active Platform  = /root/works/edk2/ArmVirtPkg/ArmVirtXen.dsc
Flash Image Definition   = /root/works/edk2/ArmVirtPkg/ArmVirtXen.fdf

Processing meta-data .

build.py...
 : error F000: Nothing to build

[/root/works/edk2/ArmPlatformPkg/Library/ArmPlatformStackLib/ArmPlatformStackLib.inf]
 

-- 
Julien Grall

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

[Xen-devel] [PATCH v3 4/9] libxc: introduce domain builder architecture specific data

[Juergen Gross]

Reorganize struct xc_dom_image to contain a pointer to domain builder
architecture specific private data. This will abstract the architecture
or domain type specific data from the general used data.

The new area is allocated as soon as the domain type is known.

Signed-off-by: Juergen Gross 
---
 stubdom/grub/kexec.c |  6 +-
 tools/libxc/include/xc_dom.h |  6 +-
 tools/libxc/xc_dom_core.c| 27 +++
 3 files changed, 29 insertions(+), 10 deletions(-)

diff --git a/stubdom/grub/kexec.c b/stubdom/grub/kexec.c
index 2300318..8fd9ff9 100644
--- a/stubdom/grub/kexec.c
+++ b/stubdom/grub/kexec.c
@@ -272,7 +272,11 @@ void kexec(void *kernel, long kernel_size, void *module, 
long module_size, char
 #endif
 
 /* equivalent of xc_dom_mem_init */
-dom->arch_hooks = xc_dom_find_arch_hooks(xc_handle, dom->guest_type);
+if (xc_dom_set_arch_hooks(dom)) {
+grub_printf("xc_dom_set_arch_hooks failed\n");
+errnum = ERR_EXEC_FORMAT;
+goto out;
+}
 dom->total_pages = start_info.nr_pages;
 
 /* equivalent of arch_setup_meminit */
diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 03d5407..912d5cb 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -176,6 +176,9 @@ struct xc_dom_image {
 unsigned int *vnode_to_pnode;
 unsigned int nr_vnodes;
 
+/* domain type/architecture specific data */
+void *arch_private;
+
 /* kernel loader */
 struct xc_dom_arch *arch_hooks;
 /* allocate up to virt_alloc_end */
@@ -238,6 +241,7 @@ struct xc_dom_arch {
 char *native_protocol;
 int page_shift;
 int sizeof_pfn;
+int arch_private_size;
 
 struct xc_dom_arch *next;
 };
@@ -291,7 +295,7 @@ int xc_dom_devicetree_mem(struct xc_dom_image *dom, const 
void *mem,
   size_t memsize);
 
 int xc_dom_parse_image(struct xc_dom_image *dom);
-struct xc_dom_arch *xc_dom_find_arch_hooks(xc_interface *xch, char 
*guest_type);
+int xc_dom_set_arch_hooks(struct xc_dom_image *dom);
 int xc_dom_build_image(struct xc_dom_image *dom);
 int xc_dom_update_guest_p2m(struct xc_dom_image *dom);
 
diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index 4b6eb9b..8e1e17f 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -710,19 +710,30 @@ void xc_dom_register_arch_hooks(struct xc_dom_arch *hooks)
 first_hook = hooks;
 }
 
-struct xc_dom_arch *xc_dom_find_arch_hooks(xc_interface *xch, char *guest_type)
+int xc_dom_set_arch_hooks(struct xc_dom_image *dom)
 {
 struct xc_dom_arch *hooks = first_hook;
 
 while (  hooks != NULL )
 {
-if ( !strcmp(hooks->guest_type, guest_type))
-return hooks;
+if ( !strcmp(hooks->guest_type, dom->guest_type) )
+{
+if ( hooks->arch_private_size )
+{
+dom->arch_private = malloc(hooks->arch_private_size);
+if ( dom->arch_private == NULL )
+return -1;
+memset(dom->arch_private, 0, hooks->arch_private_size);
+dom->alloc_malloc += hooks->arch_private_size;
+}
+dom->arch_hooks = hooks;
+return 0;
+}
 hooks = hooks->next;
 }
-xc_dom_panic(xch, XC_INVALID_KERNEL,
- "%s: not found (type %s)", __FUNCTION__, guest_type);
-return NULL;
+xc_dom_panic(dom->xch, XC_INVALID_KERNEL,
+ "%s: not found (type %s)", __FUNCTION__, dom->guest_type);
+return -1;
 }
 
 /*  */
@@ -734,6 +745,7 @@ void xc_dom_release(struct xc_dom_image *dom)
 if ( dom->phys_pages )
 xc_dom_unmap_all(dom);
 xc_dom_free_all(dom);
+free(dom->arch_private);
 free(dom);
 }
 
@@ -924,8 +936,7 @@ int xc_dom_mem_init(struct xc_dom_image *dom, unsigned int 
mem_mb)
 unsigned int page_shift;
 xen_pfn_t nr_pages;
 
-dom->arch_hooks = xc_dom_find_arch_hooks(dom->xch, dom->guest_type);
-if ( dom->arch_hooks == NULL )
+if ( xc_dom_set_arch_hooks(dom) )
 {
 xc_dom_panic(dom->xch, XC_INTERNAL_ERROR, "%s: arch hooks not set",
  __FUNCTION__);
-- 
2.1.4


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

[Xen-devel] [PATCH v3 3/9] libxc: rename domain builder count_pgtables to alloc_pgtables

[Juergen Gross]

Rename the count_pgtables hook of the domain builder to alloc_pgtables
and do the allocation of the guest memory for page tables inside this
hook. This will remove the need for accessing the x86 specific pgtables
member of struct xc_dom_image in the generic domain builder code.

Signed-off-by: Juergen Gross 
---
 tools/libxc/include/xc_dom.h |  2 +-
 tools/libxc/xc_dom_arm.c |  6 +++---
 tools/libxc/xc_dom_core.c| 11 ++-
 tools/libxc/xc_dom_x86.c | 26 +-
 4 files changed, 23 insertions(+), 22 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 878dc52..03d5407 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -221,7 +221,7 @@ void xc_dom_register_loader(struct xc_dom_loader *loader);
 struct xc_dom_arch {
 /* pagetable setup */
 int (*alloc_magic_pages) (struct xc_dom_image * dom);
-int (*count_pgtables) (struct xc_dom_image * dom);
+int (*alloc_pgtables) (struct xc_dom_image * dom);
 int (*setup_pgtables) (struct xc_dom_image * dom);
 
 /* arch-specific data structs setup */
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index 397eef0..d9a6371 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -49,7 +49,7 @@ const char *xc_domain_get_native_protocol(xc_interface *xch,
  * arm guests are hybrid and start off with paging disabled, therefore no
  * pagetables and nothing to do here.
  */
-static int count_pgtables_arm(struct xc_dom_image *dom)
+static int alloc_pgtables_arm(struct xc_dom_image *dom)
 {
 DOMPRINTF_CALLED(dom->xch);
 return 0;
@@ -534,7 +534,7 @@ static struct xc_dom_arch xc_dom_32 = {
 .page_shift = PAGE_SHIFT_ARM,
 .sizeof_pfn = 8,
 .alloc_magic_pages = alloc_magic_pages,
-.count_pgtables = count_pgtables_arm,
+.alloc_pgtables = alloc_pgtables_arm,
 .setup_pgtables = setup_pgtables_arm,
 .start_info = start_info_arm,
 .shared_info = shared_info_arm,
@@ -550,7 +550,7 @@ static struct xc_dom_arch xc_dom_64 = {
 .page_shift = PAGE_SHIFT_ARM,
 .sizeof_pfn = 8,
 .alloc_magic_pages = alloc_magic_pages,
-.count_pgtables = count_pgtables_arm,
+.alloc_pgtables = alloc_pgtables_arm,
 .setup_pgtables = setup_pgtables_arm,
 .start_info = start_info_arm,
 .shared_info = shared_info_arm,
diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index b1d7890..4b6eb9b 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -1082,15 +1082,8 @@ int xc_dom_build_image(struct xc_dom_image *dom)
 /* allocate other pages */
 if ( dom->arch_hooks->alloc_magic_pages(dom) != 0 )
 goto err;
-if ( dom->arch_hooks->count_pgtables )
-{
-if ( dom->arch_hooks->count_pgtables(dom) != 0 )
-goto err;
-if ( (dom->pgtables > 0) &&
- (xc_dom_alloc_segment(dom, >pgtables_seg, "page tables", 0,
-   dom->pgtables * page_size) != 0) )
-goto err;
-}
+if ( dom->arch_hooks->alloc_pgtables(dom) != 0 )
+goto err;
 if ( dom->alloc_bootstack )
 dom->bootstack_pfn = xc_dom_alloc_page(dom, "boot stack");
 DOMPRINTF("%-20s: virt_alloc_end : 0x%" PRIx64 "",
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index dd331bf..7eda047 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -126,7 +126,7 @@ nr_page_tables(struct xc_dom_image *dom,
 return tables;
 }
 
-static int count_pgtables(struct xc_dom_image *dom, int pae,
+static int alloc_pgtables(struct xc_dom_image *dom, int pae,
   int l4_bits, int l3_bits, int l2_bits, int l1_bits)
 {
 int pages, extra_pages;
@@ -172,7 +172,9 @@ static int count_pgtables(struct xc_dom_image *dom, int pae,
 break;
 }
 dom->virt_pgtab_end = try_virt_end + 1;
-return 0;
+
+return xc_dom_alloc_segment(dom, >pgtables_seg, "page tables", 0,
+dom->pgtables * PAGE_SIZE_X86);
 }
 
 /*  */
@@ -182,9 +184,9 @@ static int count_pgtables(struct xc_dom_image *dom, int pae,
 #define L2_PROT (_PAGE_PRESENT|_PAGE_RW|_PAGE_ACCESSED|_PAGE_DIRTY|_PAGE_USER)
 #define L3_PROT (_PAGE_PRESENT)
 
-static int count_pgtables_x86_32_pae(struct xc_dom_image *dom)
+static int alloc_pgtables_x86_32_pae(struct xc_dom_image *dom)
 {
-return count_pgtables(dom, 1, 0, 32,
+return alloc_pgtables(dom, 1, 0, 32,
   L3_PAGETABLE_SHIFT_PAE, L2_PAGETABLE_SHIFT_PAE);
 }
 
@@ -355,9 +357,9 @@ pfn_error:
 /*  */
 /* x86_64 pagetables*/
 
-static int count_pgtables_x86_64(struct xc_dom_image *dom)
+static int alloc_pgtables_x86_64(struct xc_dom_image *dom)
 {
-

[Xen-devel] [PATCH v3 2/9] xen: add generic flag to elf_dom_parms indicating support of unmapped initrd

[Juergen Gross]

Support of an unmapped initrd is indicated by the kernel of the domain
via elf notes. In order not to have to use raw elf data in the tools
for support of an unmapped initrd add a flag to the parsed data area
to indicate the kernel supporting this feature.

Switch using this flag in the hypervisor domain builder.

Suggested-by: Ian Campbell 
Signed-off-by: Juergen Gross 
---
 xen/arch/x86/domain_build.c| 4 ++--
 xen/common/libelf/libelf-dominfo.c | 3 +++
 xen/include/xen/libelf.h   | 1 +
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
index c2ef87a..d02dc4b 100644
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -353,7 +353,7 @@ static unsigned long __init compute_dom0_nr_pages(
 
 vstart = parms->virt_base;
 vend = round_pgup(parms->virt_kend);
-if ( !parms->elf_notes[XEN_ELFNOTE_MOD_START_PFN].data.num )
+if ( !parms->unmapped_initrd )
 vend += round_pgup(initrd_len);
 end = vend + nr_pages * sizeof_long;
 
@@ -1037,7 +1037,7 @@ int __init construct_dom0(
 v_start  = parms.virt_base;
 vkern_start  = parms.virt_kstart;
 vkern_end= parms.virt_kend;
-if ( parms.elf_notes[XEN_ELFNOTE_MOD_START_PFN].data.num )
+if ( parms.unmapped_initrd )
 {
 vinitrd_start  = vinitrd_end = 0;
 vphysmap_start = round_pgup(vkern_end);
diff --git a/xen/common/libelf/libelf-dominfo.c 
b/xen/common/libelf/libelf-dominfo.c
index 3de1c23..c9243e4 100644
--- a/xen/common/libelf/libelf-dominfo.c
+++ b/xen/common/libelf/libelf-dominfo.c
@@ -190,6 +190,9 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
 case XEN_ELFNOTE_INIT_P2M:
 parms->p2m_base = val;
 break;
+case XEN_ELFNOTE_MOD_START_PFN:
+parms->unmapped_initrd = !!val;
+break;
 case XEN_ELFNOTE_PADDR_OFFSET:
 parms->elf_paddr_offset = val;
 break;
diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h
index de788c7..6da4cc0 100644
--- a/xen/include/xen/libelf.h
+++ b/xen/include/xen/libelf.h
@@ -423,6 +423,7 @@ struct elf_dom_parms {
 char loader[16];
 enum xen_pae_type pae;
 bool bsd_symtab;
+bool unmapped_initrd;
 uint64_t virt_base;
 uint64_t virt_entry;
 uint64_t virt_hypercall;
-- 
2.1.4


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

[Xen-devel] [PATCH v3 8/9] libxc: rework of domain builder's page table handler

[Juergen Gross]

In order to prepare a p2m list outside of the initial kernel mapping
do a rework of the domain builder's page table handler. The goal is
to be able to use common helpers for page table allocation and setup
for initial kernel page tables and page tables mapping the p2m list.
This is achieved by supporting multiple mapping areas. The mapped
virtual addresses of the single areas must not overlap, while the
page tables of a new area added might already be partially present.
Especially the top level page table is existing only once, of course.

Signed-off-by: Juergen Gross 
---
 tools/libxc/xc_dom_x86.c | 404 ---
 1 file changed, 240 insertions(+), 164 deletions(-)

diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index c815e10..333ef6b 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -65,17 +65,27 @@
 #define NR_IOREQ_SERVER_PAGES 8
 #define ioreq_server_pfn(x) (special_pfn(0) - NR_IOREQ_SERVER_PAGES + (x))
 
-#define bits_to_mask(bits)   (((xen_vaddr_t)1 << (bits))-1)
+#define bits_to_mask(bits)   (((xen_vaddr_t)1 << (bits)) - 1)
 #define round_down(addr, mask)   ((addr) & ~(mask))
 #define round_up(addr, mask) ((addr) | (mask))
 
-struct xc_dom_image_x86 {
-/* initial page tables */
+struct xc_dom_x86_mapping_lvl {
+xen_vaddr_t from;
+xen_vaddr_t to;
+xen_pfn_t pfn;
 unsigned int pgtables;
-unsigned int pg_l4;
-unsigned int pg_l3;
-unsigned int pg_l2;
-unsigned int pg_l1;
+};
+
+struct xc_dom_x86_mapping {
+struct xc_dom_x86_mapping_lvl area;
+struct xc_dom_x86_mapping_lvl lvls[4];
+xen_pfn_t pfn_start;
+};
+
+struct xc_dom_image_x86 {
+unsigned n_mappings;
+#define MAPPING_MAX 1
+struct xc_dom_x86_mapping maps[MAPPING_MAX];
 };
 
 /* get guest IO ABI protocol */
@@ -105,43 +115,107 @@ const char *xc_domain_get_native_protocol(xc_interface 
*xch,
 return protocol;
 }
 
-static unsigned long
-nr_page_tables(struct xc_dom_image *dom,
-   xen_vaddr_t start, xen_vaddr_t end, unsigned long bits)
+static void
+nr_page_tables(struct xc_dom_image *dom, int lvl,
+   xen_vaddr_t from, xen_vaddr_t to, unsigned long bits)
 {
 xen_vaddr_t mask = bits_to_mask(bits);
-int tables;
+struct xc_dom_image_x86 *domx86 = dom->arch_private;
+struct xc_dom_x86_mapping *map = domx86->maps + domx86->n_mappings;
+struct xc_dom_x86_mapping *map_cmp;
+unsigned map_n;
 
 if ( bits == 0 )
-return 0;  /* unused */
+return;  /* unused */
+
+if ( lvl == 3 && domx86->n_mappings != 0 )
+return;  /* Top level page table already in first mapping. */
 
 if ( bits == (8 * sizeof(unsigned long)) )
 {
-/* must be pgd, need one */
-start = 0;
-end = -1;
-tables = 1;
+/* 32 bit top level page table special case */
+map->lvls[lvl].from = 0;
+map->lvls[lvl].to = -1;
+map->lvls[lvl].pgtables = 1;
+goto done;
 }
-else
+
+from = round_down(from, mask);
+to = round_up(to, mask);
+
+for ( map_n = 0, map_cmp = domx86->maps; map_n < domx86->n_mappings;
+  map_n++, map_cmp++ )
 {
-start = round_down(start, mask);
-end = round_up(end, mask);
-tables = ((end - start) >> bits) + 1;
+if ( map_cmp->lvls[lvl].from == map_cmp->lvls[lvl].to )
+continue;
+if ( from >= map_cmp->lvls[lvl].from && to <= map_cmp->lvls[lvl].to )
+return;  /* Area already completely covered on this level. */
+if ( from >= map_cmp->lvls[lvl].from && from <= map_cmp->lvls[lvl].to )
+from = map_cmp->lvls[lvl].to + 1;
+if ( to >= map_cmp->lvls[lvl].from && to <= map_cmp->lvls[lvl].to )
+to = map_cmp->lvls[lvl].from - 1;
 }
 
+map->lvls[lvl].from = from;
+map->lvls[lvl].to = to;
+map->lvls[lvl].pgtables = ((to - from) >> bits) + 1;
+
+ done:
 DOMPRINTF("%s: 0x%016" PRIx64 "/%ld: 0x%016" PRIx64
-  " -> 0x%016" PRIx64 ", %d table(s)",
-  __FUNCTION__, mask, bits, start, end, tables);
-return tables;
+  " -> 0x%016" PRIx64 ", %d table(s)", __FUNCTION__, mask, bits,
+  map->lvls[lvl].from, map->lvls[lvl].to, map->lvls[lvl].pgtables);
 }
 
-static int alloc_pgtables(struct xc_dom_image *dom, int pae,
-  int l4_bits, int l3_bits, int l2_bits, int l1_bits)
+static int count_pgtables(struct xc_dom_image *dom, int pae, int bits[4],
+  xen_vaddr_t from, xen_vaddr_t to, xen_pfn_t pfn)
+{
+struct xc_dom_image_x86 *domx86 = dom->arch_private;
+struct xc_dom_x86_mapping *map;
+xen_pfn_t pfn_end;
+int level;
+
+if ( domx86->n_mappings == MAPPING_MAX )
+{
+xc_dom_panic(dom->xch, XC_OUT_OF_MEMORY,
+ "%s: too many mappings\n", __FUNCTION__);
+return -ENOMEM;
+}
+map = 

[Xen-devel] [PATCH v3 5/9] libxc: use domain builder architecture private data for x86 pv domains

[Juergen Gross]

Move some data private to the x86 domain builder to the private data
section. Remove extra_pages as they are used nowhere.

Signed-off-by: Juergen Gross 
---
 tools/libxc/include/xc_dom.h |  8 
 tools/libxc/xc_dom_x86.c | 48 +---
 2 files changed, 32 insertions(+), 24 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 912d5cb..b0120a6 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -94,15 +94,7 @@ struct xc_dom_image {
 xen_pfn_t pfn_alloc_end;
 xen_vaddr_t virt_alloc_end;
 xen_vaddr_t bsd_symtab_start;
-
-/* initial page tables */
-unsigned int pgtables;
-unsigned int pg_l4;
-unsigned int pg_l3;
-unsigned int pg_l2;
-unsigned int pg_l1;
 unsigned int alloc_bootstack;
-unsigned int extra_pages;
 xen_vaddr_t virt_pgtab_end;
 
 /* other state info */
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 7eda047..60d54b3 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -69,6 +69,15 @@
 #define round_down(addr, mask)   ((addr) & ~(mask))
 #define round_up(addr, mask) ((addr) | (mask))
 
+struct xc_dom_image_x86 {
+/* initial page tables */
+unsigned int pgtables;
+unsigned int pg_l4;
+unsigned int pg_l3;
+unsigned int pg_l2;
+unsigned int pg_l1;
+};
+
 /* get guest IO ABI protocol */
 const char *xc_domain_get_native_protocol(xc_interface *xch,
   uint32_t domid)
@@ -132,9 +141,9 @@ static int alloc_pgtables(struct xc_dom_image *dom, int pae,
 int pages, extra_pages;
 xen_vaddr_t try_virt_end;
 xen_pfn_t try_pfn_end;
+struct xc_dom_image_x86 *domx86 = dom->arch_private;
 
 extra_pages = dom->alloc_bootstack ? 1 : 0;
-extra_pages += dom->extra_pages;
 extra_pages += 128; /* 512kB padding */
 pages = extra_pages;
 for ( ; ; )
@@ -152,29 +161,30 @@ static int alloc_pgtables(struct xc_dom_image *dom, int 
pae,
 return -ENOMEM;
 }
 
-dom->pg_l4 =
+domx86->pg_l4 =
 nr_page_tables(dom, dom->parms.virt_base, try_virt_end, l4_bits);
-dom->pg_l3 =
+domx86->pg_l3 =
 nr_page_tables(dom, dom->parms.virt_base, try_virt_end, l3_bits);
-dom->pg_l2 =
+domx86->pg_l2 =
 nr_page_tables(dom, dom->parms.virt_base, try_virt_end, l2_bits);
-dom->pg_l1 =
+domx86->pg_l1 =
 nr_page_tables(dom, dom->parms.virt_base, try_virt_end, l1_bits);
 if (pae && try_virt_end < 0xc000)
 {
 DOMPRINTF("%s: PAE: extra l2 page table for l3#3",
   __FUNCTION__);
-dom->pg_l2++;
+domx86->pg_l2++;
 }
-dom->pgtables = dom->pg_l4 + dom->pg_l3 + dom->pg_l2 + dom->pg_l1;
-pages = dom->pgtables + extra_pages;
+domx86->pgtables = domx86->pg_l4 + domx86->pg_l3 +
+   domx86->pg_l2 + domx86->pg_l1;
+pages = domx86->pgtables + extra_pages;
 if ( dom->virt_alloc_end + pages * PAGE_SIZE_X86 <= try_virt_end + 1 )
 break;
 }
 dom->virt_pgtab_end = try_virt_end + 1;
 
 return xc_dom_alloc_segment(dom, >pgtables_seg, "page tables", 0,
-dom->pgtables * PAGE_SIZE_X86);
+domx86->pgtables * PAGE_SIZE_X86);
 }
 
 /*  */
@@ -262,9 +272,10 @@ static xen_pfn_t move_l3_below_4G(struct xc_dom_image *dom,
 
 static int setup_pgtables_x86_32_pae(struct xc_dom_image *dom)
 {
+struct xc_dom_image_x86 *domx86 = dom->arch_private;
 xen_pfn_t l3pfn = dom->pgtables_seg.pfn;
-xen_pfn_t l2pfn = l3pfn + dom->pg_l3;
-xen_pfn_t l1pfn = l2pfn + dom->pg_l2;
+xen_pfn_t l2pfn = l3pfn + domx86->pg_l3;
+xen_pfn_t l1pfn = l2pfn + domx86->pg_l2;
 l3_pgentry_64_t *l3tab;
 l2_pgentry_64_t *l2tab = NULL;
 l1_pgentry_64_t *l1tab = NULL;
@@ -373,10 +384,11 @@ static int alloc_pgtables_x86_64(struct xc_dom_image *dom)
 
 static int setup_pgtables_x86_64(struct xc_dom_image *dom)
 {
+struct xc_dom_image_x86 *domx86 = dom->arch_private;
 xen_pfn_t l4pfn = dom->pgtables_seg.pfn;
-xen_pfn_t l3pfn = l4pfn + dom->pg_l4;
-xen_pfn_t l2pfn = l3pfn + dom->pg_l3;
-xen_pfn_t l1pfn = l2pfn + dom->pg_l2;
+xen_pfn_t l3pfn = l4pfn + domx86->pg_l4;
+xen_pfn_t l2pfn = l3pfn + domx86->pg_l3;
+xen_pfn_t l1pfn = l2pfn + domx86->pg_l2;
 l4_pgentry_64_t *l4tab = xc_dom_pfn_to_ptr(dom, l4pfn, 1);
 l3_pgentry_64_t *l3tab = NULL;
 l2_pgentry_64_t *l2tab = NULL;
@@ -619,6 +631,7 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
 
 static int start_info_x86_32(struct xc_dom_image *dom)
 {
+struct xc_dom_image_x86 *domx86 = dom->arch_private;
 start_info_x86_32_t *start_info 

[Xen-devel] [PATCH v3 7/9] libxc: split p2m allocation in domain builder from other magic pages

[Juergen Gross]

Carve out the p2m list allocation from the .alloc_magic_pages hook of
the domain builder in order to prepare allocating the p2m list outside
of the initial kernel mapping. This will be needed to support loading
domains with huge memory (>512 GB).

Signed-off-by: Juergen Gross 
Acked-by: Ian Campbell 
---
 tools/libxc/include/xc_dom.h |  1 +
 tools/libxc/xc_dom_core.c|  3 +++
 tools/libxc/xc_dom_x86.c | 11 ++-
 3 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index fa772a9..79d830f 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -222,6 +222,7 @@ struct xc_dom_arch {
 /* pagetable setup */
 int (*alloc_magic_pages) (struct xc_dom_image * dom);
 int (*alloc_pgtables) (struct xc_dom_image * dom);
+int (*alloc_p2m_list) (struct xc_dom_image * dom);
 int (*setup_pgtables) (struct xc_dom_image * dom);
 
 /* arch-specific data structs setup */
diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index 15e9fa3..18b98c9 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -1096,6 +1096,9 @@ int xc_dom_build_image(struct xc_dom_image *dom)
 }
 
 /* allocate other pages */
+if ( dom->arch_hooks->alloc_p2m_list &&
+ dom->arch_hooks->alloc_p2m_list(dom) != 0 )
+goto err;
 if ( dom->arch_hooks->alloc_magic_pages(dom) != 0 )
 goto err;
 if ( dom->arch_hooks->alloc_pgtables(dom) != 0 )
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 7e2f1c5..c815e10 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -475,7 +475,7 @@ pfn_error:
 
 /*  */
 
-static int alloc_magic_pages(struct xc_dom_image *dom)
+static int alloc_p2m_list(struct xc_dom_image *dom)
 {
 size_t p2m_alloc_size = dom->p2m_size * dom->arch_hooks->sizeof_pfn;
 
@@ -487,6 +487,13 @@ static int alloc_magic_pages(struct xc_dom_image *dom)
 if ( dom->p2m_guest == NULL )
 return -1;
 
+return 0;
+}
+
+/*  */
+
+static int alloc_magic_pages(struct xc_dom_image *dom)
+{
 /* allocate special pages */
 dom->start_info_pfn = xc_dom_alloc_page(dom, "start info");
 dom->xenstore_pfn = xc_dom_alloc_page(dom, "xenstore");
@@ -1670,6 +1677,7 @@ static struct xc_dom_arch xc_dom_32_pae = {
 .arch_private_size = sizeof(struct xc_dom_image_x86),
 .alloc_magic_pages = alloc_magic_pages,
 .alloc_pgtables = alloc_pgtables_x86_32_pae,
+.alloc_p2m_list = alloc_p2m_list,
 .setup_pgtables = setup_pgtables_x86_32_pae,
 .start_info = start_info_x86_32,
 .shared_info = shared_info_x86_32,
@@ -1687,6 +1695,7 @@ static struct xc_dom_arch xc_dom_64 = {
 .arch_private_size = sizeof(struct xc_dom_image_x86),
 .alloc_magic_pages = alloc_magic_pages,
 .alloc_pgtables = alloc_pgtables_x86_64,
+.alloc_p2m_list = alloc_p2m_list,
 .setup_pgtables = setup_pgtables_x86_64,
 .start_info = start_info_x86_64,
 .shared_info = shared_info_x86_64,
-- 
2.1.4


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

[Xen-devel] [PATCH v3 0/9] libxc: support building large pv-domains

[Juergen Gross]

The Xen hypervisor supports starting a dom0 with large memory (up to
the TB range) by not including the initrd and p2m list in the initial
kernel mapping. Especially the p2m list can grow larger than the
available virtual space in the initial mapping.

The started kernel is indicating the support of each feature via
elf notes.

This series enables the domain builder in libxc to do the same as the
hypervisor. This enables starting of huge pv-domUs via xl.

Unmapped initrd is supported for 64 and 32 bit domains, omitting the
p2m from initial kernel mapping is possible for 64 bit domains only.

Tested with:
- 32 bit domU (kernel not supporting unmapped initrd)
- 32 bit domU (kernel supporting unmapped initrd)
- 1 GB 64 bit domU (kernel supporting unmapped initrd, not p2m)
- 1 GB 64 bit domU (kernel supporting unmapped initrd and p2m)
- 900GB 64 bit domU (kernel supporting unmapped initrd and p2m)
- HVM domU

Changes in v3:
- Rebased the complete series to new staging (hvm builder patches by
  Roger Pau Monne)
- Removed old patch 1 as it broke stubdom build
- Introduced new Patch 1 to make allocation of guest memory more clear
  regarding virtual/physical memory allocation (requested by Ian Campbell)
- Change name of flag to indicate support of unmapped initrd in patch 2
  (requested by Ian Campbell)
- Introduce new patches 3, 4, 5 ("rename domain builder count_pgtables to
  alloc_pgtables", "introduce domain builder architecture specific data",
  "use domain builder architecture private data for x86 pv domains") to
  assist later page table work
- don't fiddle with initrd virtual address in patch 6 (was patch 3 in v2),
  add explicit initrd parameters for start_info in struct xc_dom_image
  instead (requested by Ian Campbell)
- Introduce new patch 8 ("rework of domain builder's page table handler")
  to be able to use common helpers for unmapped p2m list (requested by
  Ian Campbell)
- use now known segment size in pages for p2m list in patch 9 (was patch
  5 in v2) instead of fiddling with segment end address (requested by
  Ian Campbell)
- split alloc_p2m_list() in patch 9 (was patch 5 in v2) to 32/64 bit
  variants (requested by Ian Campbell)

Changes in v2:
- patch 2 has been removed as it has been applied already
- introduced new patch 2 as suggested by Ian Campbell: add a flag
  indicating support of an unmapped initrd to the parsed elf data of
  the elf_dom_parms structure
- updated patch description of patch 3 as requested by Ian Campbell


Juergen Gross (9):
  libxc: reorganize domain builder guest memory allocator
  xen: add generic flag to elf_dom_parms indicating support of unmapped
initrd
  libxc: rename domain builder count_pgtables to alloc_pgtables
  libxc: introduce domain builder architecture specific data
  libxc: use domain builder architecture private data for x86 pv domains
  libxc: create unmapped initrd in domain builder if supported
  libxc: split p2m allocation in domain builder from other magic pages
  libxc: rework of domain builder's page table handler
  libxc: create p2m list outside of kernel mapping if supported

 stubdom/grub/kexec.c   |  12 +-
 tools/libxc/include/xc_dom.h   |  32 +--
 tools/libxc/xc_dom_arm.c   |   6 +-
 tools/libxc/xc_dom_core.c  | 174 +
 tools/libxc/xc_dom_x86.c   | 496 -
 xen/arch/x86/domain_build.c|   4 +-
 xen/common/libelf/libelf-dominfo.c |   3 +
 xen/include/xen/libelf.h   |   1 +
 8 files changed, 480 insertions(+), 248 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH v3 1/9] libxc: reorganize domain builder guest memory allocator

[Juergen Gross]

Guest memory allocation in the domain builder of libxc is done via
virtual addresses only. In order to be able to support preallocated
areas not virtually mapped reorganize the memory allocator to keep
track of allocated pages globally and in allocated segments.

This requires an interface change of the allocate callback of the
domain builder which currently is using the last mapped virtual
address as a parameter. This is no problem as the only user of this
callback is stubdom/grub/kexec.c using this virtual address to
calculate the last used pfn.

Signed-off-by: Juergen Gross 
---
 stubdom/grub/kexec.c |   6 +--
 tools/libxc/include/xc_dom.h |  11 +++--
 tools/libxc/xc_dom_core.c| 101 +--
 3 files changed, 75 insertions(+), 43 deletions(-)

diff --git a/stubdom/grub/kexec.c b/stubdom/grub/kexec.c
index 0b2f4f3..2300318 100644
--- a/stubdom/grub/kexec.c
+++ b/stubdom/grub/kexec.c
@@ -100,9 +100,9 @@ static void do_exchange(struct xc_dom_image *dom, xen_pfn_t 
target_pfn, xen_pfn_
 dom->p2m_host[target_pfn] = source_mfn;
 }
 
-int kexec_allocate(struct xc_dom_image *dom, xen_vaddr_t up_to)
+int kexec_allocate(struct xc_dom_image *dom)
 {
-unsigned long new_allocated = (up_to - dom->parms.virt_base) / PAGE_SIZE;
+unsigned long new_allocated = dom->pfn_alloc_end - dom->rambase_pfn;
 unsigned long i;
 
 pages = realloc(pages, new_allocated * sizeof(*pages));
@@ -319,8 +319,6 @@ void kexec(void *kernel, long kernel_size, void *module, 
long module_size, char
 
 /* Make sure the bootstrap page table does not RW-map any of our current
  * page table frames */
-kexec_allocate(dom, dom->virt_pgtab_end);
-
 if ( (rc = xc_dom_update_guest_p2m(dom))) {
 grub_printf("xc_dom_update_guest_p2m returned %d\n", rc);
 errnum = ERR_BOOT_FAILURE;
diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index e52b023..878dc52 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -29,6 +29,7 @@ struct xc_dom_seg {
 xen_vaddr_t vstart;
 xen_vaddr_t vend;
 xen_pfn_t pfn;
+xen_pfn_t pages;
 };
 
 struct xc_dom_mem {
@@ -90,6 +91,7 @@ struct xc_dom_image {
 xen_pfn_t xenstore_pfn;
 xen_pfn_t shared_info_pfn;
 xen_pfn_t bootstack_pfn;
+xen_pfn_t pfn_alloc_end;
 xen_vaddr_t virt_alloc_end;
 xen_vaddr_t bsd_symtab_start;
 
@@ -177,7 +179,7 @@ struct xc_dom_image {
 /* kernel loader */
 struct xc_dom_arch *arch_hooks;
 /* allocate up to virt_alloc_end */
-int (*allocate) (struct xc_dom_image * dom, xen_vaddr_t up_to);
+int (*allocate) (struct xc_dom_image * dom);
 
 /* Container type (HVM or PV). */
 enum {
@@ -361,14 +363,11 @@ static inline void *xc_dom_seg_to_ptr_pages(struct 
xc_dom_image *dom,
   struct xc_dom_seg *seg,
   xen_pfn_t *pages_out)
 {
-xen_vaddr_t segsize = seg->vend - seg->vstart;
-unsigned int page_size = XC_DOM_PAGE_SIZE(dom);
-xen_pfn_t pages = (segsize + page_size - 1) / page_size;
 void *retval;
 
-retval = xc_dom_pfn_to_ptr(dom, seg->pfn, pages);
+retval = xc_dom_pfn_to_ptr(dom, seg->pfn, seg->pages);
 
-*pages_out = retval ? pages : 0;
+*pages_out = retval ? seg->pages : 0;
 return retval;
 }
 
diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index fbe4464..b1d7890 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -535,56 +535,75 @@ void *xc_dom_pfn_to_ptr_retcount(struct xc_dom_image 
*dom, xen_pfn_t pfn,
 return phys->ptr;
 }
 
-int xc_dom_alloc_segment(struct xc_dom_image *dom,
- struct xc_dom_seg *seg, char *name,
- xen_vaddr_t start, xen_vaddr_t size)
+static int xc_dom_chk_alloc_pages(struct xc_dom_image *dom, char *name,
+  xen_pfn_t pages)
 {
 unsigned int page_size = XC_DOM_PAGE_SIZE(dom);
-xen_pfn_t pages = (size + page_size - 1) / page_size;
-xen_pfn_t pfn;
-void *ptr;
 
-if ( start == 0 )
-start = dom->virt_alloc_end;
+if ( pages > dom->total_pages || /* multiple test avoids overflow probs */
+ dom->pfn_alloc_end - dom->rambase_pfn > dom->total_pages ||
+ pages > dom->total_pages - dom->pfn_alloc_end + dom->rambase_pfn )
+{
+xc_dom_panic(dom->xch, XC_OUT_OF_MEMORY,
+ "%s: segment %s too large (0x%"PRIpfn" > "
+ "0x%"PRIpfn" - 0x%"PRIpfn" pages)", __FUNCTION__, name,
+ pages, dom->total_pages,
+ dom->pfn_alloc_end - dom->rambase_pfn);
+return -1;
+}
+
+dom->pfn_alloc_end += pages;
+dom->virt_alloc_end += pages * page_size;
 
-if ( start & (page_size - 1) )
+return 0;
+}
+
+static int xc_dom_alloc_pad(struct xc_dom_image *dom, xen_vaddr_t end)
+{
+unsigned int page_size = 

[Xen-devel] [PATCH v3 6/9] libxc: create unmapped initrd in domain builder if supported

[Juergen Gross]

In case the kernel of a new pv-domU indicates it is supporting an
unmapped initrd, don't waste precious virtual space for the initrd,
but allocate only guest physical memory for it.

Signed-off-by: Juergen Gross 
---
 tools/libxc/include/xc_dom.h |  5 +
 tools/libxc/xc_dom_core.c| 19 +--
 tools/libxc/xc_dom_x86.c |  8 
 3 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index b0120a6..fa772a9 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -94,6 +94,11 @@ struct xc_dom_image {
 xen_pfn_t pfn_alloc_end;
 xen_vaddr_t virt_alloc_end;
 xen_vaddr_t bsd_symtab_start;
+
+/* initrd parameters as specified in start_info page */
+unsigned long initrd_start;
+unsigned long initrd_len;
+
 unsigned int alloc_bootstack;
 xen_vaddr_t virt_pgtab_end;
 
diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index 8e1e17f..15e9fa3 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -1041,6 +1041,7 @@ static int xc_dom_build_ramdisk(struct xc_dom_image *dom)
 int xc_dom_build_image(struct xc_dom_image *dom)
 {
 unsigned int page_size;
+bool unmapped_initrd;
 
 DOMPRINTF_CALLED(dom->xch);
 
@@ -1064,11 +1065,15 @@ int xc_dom_build_image(struct xc_dom_image *dom)
 if ( dom->kernel_loader->loader(dom) != 0 )
 goto err;
 
-/* load ramdisk */
-if ( dom->ramdisk_blob )
+/* Load ramdisk if initial mapping required. */
+unmapped_initrd = dom->parms.unmapped_initrd && !dom->ramdisk_seg.vstart;
+
+if ( dom->ramdisk_blob && !unmapped_initrd )
 {
 if ( xc_dom_build_ramdisk(dom) != 0 )
 goto err;
+dom->initrd_start = dom->ramdisk_seg.vstart;
+dom->initrd_len = dom->ramdisk_seg.vend - dom->ramdisk_seg.vstart;
 }
 
 /* load devicetree */
@@ -1106,6 +,16 @@ int xc_dom_build_image(struct xc_dom_image *dom)
 if ( dom->virt_pgtab_end && xc_dom_alloc_pad(dom, dom->virt_pgtab_end) )
 return -1;
 
+/* Load ramdisk if no initial mapping required. */
+if ( dom->ramdisk_blob && unmapped_initrd )
+{
+if ( xc_dom_build_ramdisk(dom) != 0 )
+goto err;
+dom->flags |= SIF_MOD_START_PFN;
+dom->initrd_start = dom->ramdisk_seg.pfn;
+dom->initrd_len = page_size * dom->ramdisk_seg.pages;
+}
+
 return 0;
 
  err:
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 60d54b3..7e2f1c5 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -663,8 +663,8 @@ static int start_info_x86_32(struct xc_dom_image *dom)
 
 if ( dom->ramdisk_blob )
 {
-start_info->mod_start = dom->ramdisk_seg.vstart;
-start_info->mod_len = dom->ramdisk_seg.vend - dom->ramdisk_seg.vstart;
+start_info->mod_start = dom->initrd_start;
+start_info->mod_len = dom->initrd_len;
 }
 
 if ( dom->cmdline )
@@ -710,8 +710,8 @@ static int start_info_x86_64(struct xc_dom_image *dom)
 
 if ( dom->ramdisk_blob )
 {
-start_info->mod_start = dom->ramdisk_seg.vstart;
-start_info->mod_len = dom->ramdisk_seg.vend - dom->ramdisk_seg.vstart;
+start_info->mod_start = dom->initrd_start;
+start_info->mod_len = dom->initrd_len;
 }
 
 if ( dom->cmdline )
-- 
2.1.4


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

[Xen-devel] [PATCH] x86/NUMA: fix SRAT table processor entry parsing and consumption

[Jan Beulich]

- don't overrun apicid_to_node[] (possible in the x2APIC case)
- don't limit number of processor related SRAT entries we can consume
- make acpi_numa_{processor,x2apic}_affinity_init() as similar to one
  another as possible
- print APIC IDs in hex (to ease matching with other log messages), at
  once making legacy and x2APIC ones distinguishable (by width)

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -349,7 +349,7 @@ void __init init_cpu_to_node(void)
 u32 apicid = x86_cpu_to_apicid[i];
 if ( apicid == BAD_APICID )
 continue;
-node = apicid_to_node[apicid];
+node = apicid < MAX_LOCAL_APIC ? apicid_to_node[apicid] : NUMA_NO_NODE;
 if ( node == NUMA_NO_NODE || !node_online(node) )
 node = 0;
 numa_set_node(i, node);
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -200,7 +200,7 @@ void __devinit srat_detect_node(int cpu)
 nodeid_t node;
 u32 apicid = x86_cpu_to_apicid[cpu];
 
-node = apicid_to_node[apicid];
+node = apicid < MAX_LOCAL_APIC ? apicid_to_node[apicid] : NUMA_NO_NODE;
 if ( node == NUMA_NO_NODE )
 node = 0;
 
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -993,7 +993,8 @@ int cpu_add(uint32_t apic_id, uint32_t a
 cpu = node;
 goto out;
 }
-apicid_to_node[apic_id] = node;
+if ( apic_id < MAX_LOCAL_APIC )
+ apicid_to_node[apic_id] = node;
 }
 
 /* Physically added CPUs do not have synchronised TSC. */
--- a/xen/arch/x86/srat.c
+++ b/xen/arch/x86/srat.c
@@ -209,7 +209,6 @@ acpi_numa_x2apic_affinity_init(struct
 {
unsigned pxm;
nodeid_t node;
-   u32 apic_id;
 
if (srat_disabled())
return;
@@ -217,8 +216,13 @@ acpi_numa_x2apic_affinity_init(struct ac
bad_srat();
return;
}
-   if ((pa->flags & ACPI_SRAT_CPU_ENABLED) == 0)
+   if (!(pa->flags & ACPI_SRAT_CPU_ENABLED))
+   return;
+   if (pa->apic_id >= MAX_LOCAL_APIC) {
+   printk(KERN_INFO "SRAT: APIC %08x ignored\n", pa->apic_id);
return;
+   }
+
pxm = pa->proximity_domain;
node = setup_node(pxm);
if (node == NUMA_NO_NODE) {
@@ -226,11 +230,11 @@ acpi_numa_x2apic_affinity_init(struct ac
return;
}
 
-   apic_id = pa->apic_id;
-   apicid_to_node[apic_id] = node;
+   apicid_to_node[pa->apic_id] = node;
+   node_set(node, processor_nodes_parsed);
acpi_numa = 1;
-   printk(KERN_INFO "SRAT: PXM %u -> APIC %u -> Node %u\n",
-  pxm, apic_id, node);
+   printk(KERN_INFO "SRAT: PXM %u -> APIC %08x -> Node %u\n",
+  pxm, pa->apic_id, node);
 }
 
 /* Callback for Proximity Domain -> LAPIC mapping */
@@ -262,7 +268,7 @@ acpi_numa_processor_affinity_init(struct
apicid_to_node[pa->apic_id] = node;
node_set(node, processor_nodes_parsed);
acpi_numa = 1;
-   printk(KERN_INFO "SRAT: PXM %u -> APIC %u -> Node %u\n",
+   printk(KERN_INFO "SRAT: PXM %u -> APIC %02x -> Node %u\n",
   pxm, pa->apic_id, node);
 }
 
--- a/xen/drivers/acpi/numa.c
+++ b/xen/drivers/acpi/numa.c
@@ -198,9 +199,9 @@ int __init acpi_numa_init(void)
/* SRAT: Static Resource Affinity Table */
if (!acpi_table_parse(ACPI_SIG_SRAT, acpi_parse_srat)) {
acpi_table_parse_srat(ACPI_SRAT_TYPE_X2APIC_CPU_AFFINITY,
- acpi_parse_x2apic_affinity, NR_CPUS);
+ acpi_parse_x2apic_affinity, 0);
acpi_table_parse_srat(ACPI_SRAT_TYPE_CPU_AFFINITY,
- acpi_parse_processor_affinity, NR_CPUS);
+ acpi_parse_processor_affinity, 0);
acpi_table_parse_srat(ACPI_SRAT_TYPE_MEMORY_AFFINITY,
  acpi_parse_memory_affinity,
  NR_NODE_MEMBLKS);



x86/NUMA: fix SRAT table processor entry parsing and consumption

- don't overrun apicid_to_node[] (possible in the x2APIC case)
- don't limit number of processor related SRAT entries we can consume
- make acpi_numa_{processor,x2apic}_affinity_init() as similar to one
  another as possible
- print APIC IDs in hex (to ease matching with other log messages), at
  once making legacy and x2APIC ones distinguishable (by width)

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -349,7 +349,7 @@ void __init init_cpu_to_node(void)
 u32 apicid = x86_cpu_to_apicid[i];
 if ( apicid == BAD_APICID )
 continue;
-node = apicid_to_node[apicid];
+node = apicid < MAX_LOCAL_APIC ? apicid_to_node[apicid] : NUMA_NO_NODE;
 if ( node == NUMA_NO_NODE || !node_online(node) )
 node = 0;
 

[Xen-devel] [PATCH] x86/NUMA: cleanup

[Jan Beulich]

- constification
- prefer container_of() over casts
- check original pointer against NULL instead of the container_of()
  result

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/srat.c
+++ b/xen/arch/x86/srat.c
@@ -205,7 +205,7 @@ void __init acpi_numa_slit_init(struct a
 
 /* Callback for Proximity Domain -> x2APIC mapping */
 void __init
-acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa)
+acpi_numa_x2apic_affinity_init(const struct acpi_srat_x2apic_cpu_affinity *pa)
 {
unsigned pxm;
nodeid_t node;
@@ -241,7 +241,7 @@ acpi_numa_x2apic_affinity_init(struct ac
 
 /* Callback for Proximity Domain -> LAPIC mapping */
 void __init
-acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa)
+acpi_numa_processor_affinity_init(const struct acpi_srat_cpu_affinity *pa)
 {
unsigned pxm;
nodeid_t node;
@@ -276,7 +276,7 @@ acpi_numa_processor_affinity_init(struct
 
 /* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
 void __init
-acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
+acpi_numa_memory_affinity_init(const struct acpi_srat_mem_affinity *ma)
 {
u64 start, end;
unsigned pxm;
--- a/xen/drivers/acpi/numa.c
+++ b/xen/drivers/acpi/numa.c
@@ -124,10 +124,11 @@ static int __init
 acpi_parse_x2apic_affinity(struct acpi_subtable_header *header,
   const unsigned long end)
 {
-   struct acpi_srat_x2apic_cpu_affinity *processor_affinity;
+   const struct acpi_srat_x2apic_cpu_affinity *processor_affinity
+   = container_of(header, struct acpi_srat_x2apic_cpu_affinity,
+  header);
 
-   processor_affinity = (struct acpi_srat_x2apic_cpu_affinity *)header;
-   if (!processor_affinity)
+   if (!header)
return -EINVAL;
 
acpi_table_print_srat_entry(header);
@@ -139,13 +140,13 @@ acpi_parse_x2apic_affinity(struct acpi_s
 }
 
 static int __init
-acpi_parse_processor_affinity(struct acpi_subtable_header * header,
+acpi_parse_processor_affinity(struct acpi_subtable_header *header,
  const unsigned long end)
 {
-   struct acpi_srat_cpu_affinity *processor_affinity
+   const struct acpi_srat_cpu_affinity *processor_affinity
= container_of(header, struct acpi_srat_cpu_affinity, header);
 
-   if (!processor_affinity)
+   if (!header)
return -EINVAL;
 
acpi_table_print_srat_entry(header);
@@ -157,13 +158,13 @@ acpi_parse_processor_affinity(struct acp
 }
 
 static int __init
-acpi_parse_memory_affinity(struct acpi_subtable_header * header,
+acpi_parse_memory_affinity(struct acpi_subtable_header *header,
   const unsigned long end)
 {
-   struct acpi_srat_mem_affinity *memory_affinity
+   const struct acpi_srat_mem_affinity *memory_affinity
= container_of(header, struct acpi_srat_mem_affinity, header);
 
-   if (!memory_affinity)
+   if (!header)
return -EINVAL;
 
acpi_table_print_srat_entry(header);
--- a/xen/include/xen/acpi.h
+++ b/xen/include/xen/acpi.h
@@ -76,9 +76,9 @@ void acpi_table_print_srat_entry (struct
 
 /* the following four functions are architecture-dependent */
 void acpi_numa_slit_init (struct acpi_table_slit *slit);
-void acpi_numa_processor_affinity_init (struct acpi_srat_cpu_affinity *pa);
-void acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa);
-void acpi_numa_memory_affinity_init (struct acpi_srat_mem_affinity *ma);
+void acpi_numa_processor_affinity_init(const struct acpi_srat_cpu_affinity *);
+void acpi_numa_x2apic_affinity_init(const struct acpi_srat_x2apic_cpu_affinity 
*);
+void acpi_numa_memory_affinity_init(const struct acpi_srat_mem_affinity *);
 void acpi_numa_arch_fixup(void);
 
 #ifdef CONFIG_ACPI_HOTPLUG_CPU



x86/NUMA: cleanup

- constification
- prefer container_of() over casts
- check original pointer against NULL instead of the container_of()
  result

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/srat.c
+++ b/xen/arch/x86/srat.c
@@ -205,7 +205,7 @@ void __init acpi_numa_slit_init(struct a
 
 /* Callback for Proximity Domain -> x2APIC mapping */
 void __init
-acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa)
+acpi_numa_x2apic_affinity_init(const struct acpi_srat_x2apic_cpu_affinity *pa)
 {
unsigned pxm;
nodeid_t node;
@@ -241,7 +241,7 @@ acpi_numa_x2apic_affinity_init(struct ac
 
 /* Callback for Proximity Domain -> LAPIC mapping */
 void __init
-acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa)
+acpi_numa_processor_affinity_init(const struct acpi_srat_cpu_affinity *pa)
 {
unsigned pxm;
nodeid_t node;
@@ -276,7 +276,7 @@ acpi_numa_processor_affinity_init(struct
 
 /* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
 void __init

Re: [Xen-devel] [PATCH] raisin: enable ovmf build for arm64

[Stefano Stabellini]

On Tue, 13 Oct 2015, Julien Grall wrote:
> On 13/10/15 11:58, Stefano Stabellini wrote:
> > On Tue, 13 Oct 2015, Ian Campbell wrote:
> >> On Mon, 2015-10-12 at 18:18 +0100, Stefano Stabellini wrote:
> >>> @@ -30,9 +38,18 @@ function ovmf_build() {
> >>>  git-checkout $OVMF_URL $OVMF_REVISION ovmf-dir
> >>>  cd ovmf-dir
> >>>  
> >>> -make -C BaseTools/Source/C
> >>> -OvmfPkg/build.sh -a X64 -b RELEASE -n 4
> >>> -cp Build/OvmfX64/RELEASE_GCC*/FV/OVMF.fd ovmf.bin
> >>> +make -C BaseTools
> >>> +
> >>> +if [[ $RAISIN_ARCH = "arm64" ]]
> >>
> >> Based on what I understand of the OVMF buildsystem I think you are going to
> >> eventually want a case $RAISIN_ARCH here, since it seems to vary a fair
> >> bit.
> >>
> >>> +then
> >>> +export GCC48_AARCH64_PREFIX=
> >>
> >> Won't this (unexpectedly) leak into other subsequent component builds? Or
> >> is each component built in a  fresh sub-shell?
> >>
> >> What about host platforms which have a gcc other than 4.8? (e.g. Debian
> >> Jessie uses 4.9 by default)
> >>
> >> Should you add a comment explaining why this apparent workaround is needed?
> > 
> > That is a good question. It all comes from
> > https://wiki.linaro.org/LEG/UEFIforXEN, but I don't know why is
> > required. Without GCC48_AARCH64_PREFIX= and -t GCC48, it won't build.
> 
> Are you sure? I'm able to build without GCC48_AARCH64_PREFIX=.

I didn't git clean enough. You are right, only -t GCC48 is required.

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

Re: [Xen-devel] [PATCH OSSTEST v3 3/3] Create a flight to test OpenStack with xen-unstable and libvirt

[Ian Campbell]

On Tue, 2015-10-13 at 12:02 +0100, Ian Jackson wrote:
> Anthony PERARD writes ("Re: [PATCH OSSTEST v3 3/3] Create a flight to
> test OpenStack with xen-unstable and libvirt"):
> > On Thu, Oct 08, 2015 at 05:42:56PM +0100, Ian Jackson wrote:
> > > If we do want to just ignore this issue of the other trees, I do
> > > indeed see no particular reason to explicitly set all the runvars to
> > > master.
> > > 
> > > > I think we want a push gate just for the regression tracking, but
> > > > not
> > > > really for its own sake.
> > 
> > Yes, that is what I had in mind, testing OpenStack with tips of xen and
> > libvirt.
> > > 
> > > In that case we I think yes don't really need to push multiple
> > > branches.
> > 
> > I'll remove all those revision_* runvars.
> 
> Do you mean to remove the settings of them all to `master', or the
> code to honour them ?
> 
> The machinery in the ts-* script to honour revision_xyz and to set
> built_revision_xyz is useful because the bisector can use it to finger
> individual tress.

That all comes for free via build_clone I think, IOW Anthony would need to
go a good deal out of his way to not honour them I think.

> Unless, of course, you don't want to run the bisector on these tests.

I don't think we should rule it out.

Ian.

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-win7-amd64  9 windows-installfail REGR. vs. 62711
 test-amd64-amd64-xl-qemuu-win7-amd64  9 windows-install   fail REGR. vs. 62711
 test-amd64-amd64-xl-qemut-win7-amd64  9 windows-install   fail REGR. vs. 62711
 test-amd64-i386-xl-qemuu-win7-amd64  9 windows-installfail REGR. vs. 62711

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
like 62711
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail like 62711

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   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-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass

version targeted for testing:
 xen  2c20224c72fbe40d22859b4e052d9c18eb89e42c
baseline version:
 xen  a23ce429779011de127e8ff6c9bf3486d87154d5

Last test of basis62711  2015-10-07 10:34:21 Z6 days
Testing same since62733  2015-10-08 22:34:06 Z4 days4 attempts


People who touched revisions under test:
  Andrew Cooper 
  Brijesh Singh 
  Daniel Kiper 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Mike Latimer 
  Roger Pau Monne 
  Roger Pau Monné 
  Sander Eikelenboom 
  Wei Liu 
  Wei Wang 

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

Re: [Xen-devel] [OSSTEST PATCH 19/26] Toolstack::xl: Provide block_attach method

[Ian Jackson]

Hu, Robert writes ("RE: [OSSTEST PATCH 19/26] Toolstack::xl: Provide 
block_attach method"):
> > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]

> > +sub block_attach () {
> > +my ($self,$gho,$xldiskspec) = @_;
> > +die "quotes in $xldiskspec ?" if $xldiskspec =~ m/'/;
> > +my $gn = $gho->{Name};
> > +my $cmd = $self->{_VerboseCommand}." block-attach $gn
> > '$xldiskspec'";
> 
> I guess here lacks of a
>   my $ho = $self->{Host};

Yes, it does seem so!  Thanks.

Ian.

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

Re: [Xen-devel] [PATCH] raisin: enable ovmf build for arm64

[Ian Campbell]

On Tue, 2015-10-13 at 13:49 +0100, Stefano Stabellini wrote:
> I didn't git clean enough. You are right, only -t GCC48 is required.

What if only e.g. gcc-4.9 is available though?

Ian.

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

[Xen-devel] [PATCH] x86: hide MWAITX from PV domains

[Jan Beulich]

Since MWAIT is hidden too. (Linux starting with 4.3 is making use of
that feature, and is checking for it without looking at the MWAIT one.)

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -964,6 +964,7 @@ void pv_cpuid(struct cpu_user_regs *regs
 __clear_bit(X86_FEATURE_LWP % 32, );
 __clear_bit(X86_FEATURE_NODEID_MSR % 32, );
 __clear_bit(X86_FEATURE_TOPOEXT % 32, );
+__clear_bit(X86_FEATURE_MWAITX % 32, );
 break;
 
 case 0x000a: /* Architectural Performance Monitor Features (Intel) */
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -140,6 +140,7 @@
 #define X86_FEATURE_TBM (6*32+21) /* trailing bit manipulations */
 #define X86_FEATURE_TOPOEXT (6*32+22) /* topology extensions CPUID leafs */
 #define X86_FEATURE_DBEXT   (6*32+26) /* data breakpoint extension */
+#define X86_FEATURE_MWAITX  (6*32+29) /* MWAIT extension (MONITORX/MWAITX) 
*/
 
 /* Intel-defined CPU features, CPUID level 0x0007:0 (ebx), word 7 */
 #define X86_FEATURE_FSGSBASE   (7*32+ 0) /* {RD,WR}{FS,GS}BASE instructions */




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

[Xen-devel] [PATCH] x86/time: slightly streamline __update_vcpu_system_time()

[Jan Beulich]

Fold two if()-s using the same condition, converting the memset() so
far separating them to a simple initializer. Move common assignments
out of the conditional. Drop an unnecessary initializer.

Signed-off-by: Jan Beulich 
---
Additionally the is_hvm_domain() visible in the last hunk's tail
context looks, along with a few other releated ones, suspicious -
shouldn't these be has_hvm_container_domain() instead?

--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -790,9 +790,9 @@ uint64_t tsc_ticks2ns(uint64_t ticks)
 static void __update_vcpu_system_time(struct vcpu *v, int force)
 {
 struct cpu_time   *t;
-struct vcpu_time_info *u, _u;
+struct vcpu_time_info *u, _u = {};
 struct domain *d = v->domain;
-s_time_t tsc_stamp = 0;
+s_time_t tsc_stamp;
 
 if ( v->vcpu_info == NULL )
 return;
@@ -816,28 +816,21 @@ static void __update_vcpu_system_time(st
 }
 else
 tsc_stamp = gtime_to_gtsc(d, stime);
-}
-else
-{
-tsc_stamp = t->local_tsc_stamp;
-}
-
-memset(&_u, 0, sizeof(_u));
 
-if ( d->arch.vtsc )
-{
-_u.tsc_timestamp = tsc_stamp;
-_u.system_time   = t->stime_local_stamp;
 _u.tsc_to_system_mul = d->arch.vtsc_to_ns.mul_frac;
 _u.tsc_shift = d->arch.vtsc_to_ns.shift;
 }
 else
 {
-_u.tsc_timestamp = t->local_tsc_stamp;
-_u.system_time   = t->stime_local_stamp;
+tsc_stamp = t->local_tsc_stamp;
+
 _u.tsc_to_system_mul = t->tsc_scale.mul_frac;
 _u.tsc_shift = (s8)t->tsc_scale.shift;
 }
+
+_u.tsc_timestamp = tsc_stamp;
+_u.system_time   = t->stime_local_stamp;
+
 if ( is_hvm_domain(d) )
 _u.tsc_timestamp += v->arch.hvm_vcpu.cache_tsc_offset;
 



x86/time: slightly streamline __update_vcpu_system_time()

Fold two if()-s using the same condition, converting the memset() so
far separating them to a simple initializer. Move common assignments
out of the conditional. Drop an unnecessary initializer.

Signed-off-by: Jan Beulich 
---
Additionally the is_hvm_domain() visible in the last hunk's tail
context looks, along with a few other releated ones, suspicious -
shouldn't these be has_hvm_container_domain() instead?

--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -790,9 +790,9 @@ uint64_t tsc_ticks2ns(uint64_t ticks)
 static void __update_vcpu_system_time(struct vcpu *v, int force)
 {
 struct cpu_time   *t;
-struct vcpu_time_info *u, _u;
+struct vcpu_time_info *u, _u = {};
 struct domain *d = v->domain;
-s_time_t tsc_stamp = 0;
+s_time_t tsc_stamp;
 
 if ( v->vcpu_info == NULL )
 return;
@@ -816,28 +816,21 @@ static void __update_vcpu_system_time(st
 }
 else
 tsc_stamp = gtime_to_gtsc(d, stime);
-}
-else
-{
-tsc_stamp = t->local_tsc_stamp;
-}
-
-memset(&_u, 0, sizeof(_u));
 
-if ( d->arch.vtsc )
-{
-_u.tsc_timestamp = tsc_stamp;
-_u.system_time   = t->stime_local_stamp;
 _u.tsc_to_system_mul = d->arch.vtsc_to_ns.mul_frac;
 _u.tsc_shift = d->arch.vtsc_to_ns.shift;
 }
 else
 {
-_u.tsc_timestamp = t->local_tsc_stamp;
-_u.system_time   = t->stime_local_stamp;
+tsc_stamp = t->local_tsc_stamp;
+
 _u.tsc_to_system_mul = t->tsc_scale.mul_frac;
 _u.tsc_shift = (s8)t->tsc_scale.shift;
 }
+
+_u.tsc_timestamp = tsc_stamp;
+_u.system_time   = t->stime_local_stamp;
+
 if ( is_hvm_domain(d) )
 _u.tsc_timestamp += v->arch.hvm_vcpu.cache_tsc_offset;
 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 9/9] libxc: create p2m list outside of kernel mapping if supported

[Juergen Gross]

In case the kernel of a new pv-domU indicates it is supporting a p2m
list outside the initial kernel mapping by specifying INIT_P2M, let
the domain builder allocate the memory for the p2m list from physical
guest memory only and map it to the address the kernel is expecting.

This will enable loading pv-domUs larger than 512 GB.

Signed-off-by: Juergen Gross 
---
 tools/libxc/include/xc_dom.h |  1 +
 tools/libxc/xc_dom_core.c| 15 ++-
 tools/libxc/xc_dom_x86.c | 59 ++--
 3 files changed, 67 insertions(+), 8 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 79d830f..9c000ca 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -239,6 +239,7 @@ struct xc_dom_arch {
 char *native_protocol;
 int page_shift;
 int sizeof_pfn;
+int p2m_base_supported;
 int arch_private_size;
 
 struct xc_dom_arch *next;
diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index 18b98c9..cfee598 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -777,6 +777,7 @@ struct xc_dom_image *xc_dom_allocate(xc_interface *xch,
 dom->parms.virt_hypercall = UNSET_ADDR;
 dom->parms.virt_hv_start_low = UNSET_ADDR;
 dom->parms.elf_paddr_offset = UNSET_ADDR;
+dom->parms.p2m_base = UNSET_ADDR;
 
 dom->alloc_malloc += sizeof(*dom);
 return dom;
@@ -1096,7 +1097,11 @@ int xc_dom_build_image(struct xc_dom_image *dom)
 }
 
 /* allocate other pages */
-if ( dom->arch_hooks->alloc_p2m_list &&
+if ( !dom->arch_hooks->p2m_base_supported ||
+ dom->parms.p2m_base >= dom->parms.virt_base ||
+ (dom->parms.p2m_base & (XC_DOM_PAGE_SIZE(dom) - 1)) )
+dom->parms.p2m_base = UNSET_ADDR;
+if ( dom->arch_hooks->alloc_p2m_list && dom->parms.p2m_base == UNSET_ADDR 
&&
  dom->arch_hooks->alloc_p2m_list(dom) != 0 )
 goto err;
 if ( dom->arch_hooks->alloc_magic_pages(dom) != 0 )
@@ -1124,6 +1129,14 @@ int xc_dom_build_image(struct xc_dom_image *dom)
 dom->initrd_len = page_size * dom->ramdisk_seg.pages;
 }
 
+/* Allocate p2m list if outside of initial kernel mapping. */
+if ( dom->arch_hooks->alloc_p2m_list && dom->parms.p2m_base != UNSET_ADDR )
+{
+if ( dom->arch_hooks->alloc_p2m_list(dom) != 0 )
+goto err;
+dom->p2m_seg.vstart = dom->parms.p2m_base;
+}
+
 return 0;
 
  err:
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 333ef6b..0847761 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -68,6 +68,8 @@
 #define bits_to_mask(bits)   (((xen_vaddr_t)1 << (bits)) - 1)
 #define round_down(addr, mask)   ((addr) & ~(mask))
 #define round_up(addr, mask) ((addr) | (mask))
+#define round_pg(addr)(((addr) + PAGE_SIZE_X86 - 1) & ~(PAGE_SIZE_X86 - 1))
+#define round_pfn(addr)   (((addr) + PAGE_SIZE_X86 - 1) / PAGE_SIZE_X86)
 
 struct xc_dom_x86_mapping_lvl {
 xen_vaddr_t from;
@@ -84,7 +86,7 @@ struct xc_dom_x86_mapping {
 
 struct xc_dom_image_x86 {
 unsigned n_mappings;
-#define MAPPING_MAX 1
+#define MAPPING_MAX 2
 struct xc_dom_x86_mapping maps[MAPPING_MAX];
 };
 
@@ -536,6 +538,7 @@ static int setup_pgtables_x86_64(struct xc_dom_image *dom)
 }
 }
 }
+
 return 0;
 
 pfn_error:
@@ -551,11 +554,8 @@ pfn_error:
 
 /*  */
 
-static int alloc_p2m_list(struct xc_dom_image *dom)
+static int alloc_p2m_list(struct xc_dom_image *dom, size_t p2m_alloc_size)
 {
-size_t p2m_alloc_size = dom->p2m_size * dom->arch_hooks->sizeof_pfn;
-
-/* allocate phys2mach table */
 if ( xc_dom_alloc_segment(dom, >p2m_seg, "phys2mach",
   0, p2m_alloc_size) )
 return -1;
@@ -566,6 +566,41 @@ static int alloc_p2m_list(struct xc_dom_image *dom)
 return 0;
 }
 
+static int alloc_p2m_list_x86_32(struct xc_dom_image *dom)
+{
+size_t p2m_alloc_size = dom->p2m_size * dom->arch_hooks->sizeof_pfn;
+
+p2m_alloc_size = round_pg(p2m_alloc_size);
+return alloc_p2m_list(dom, p2m_alloc_size);
+}
+
+static int alloc_p2m_list_x86_64(struct xc_dom_image *dom)
+{
+struct xc_dom_image_x86 *domx86 = dom->arch_private;
+struct xc_dom_x86_mapping *map = domx86->maps + domx86->n_mappings;
+size_t p2m_alloc_size = dom->p2m_size * dom->arch_hooks->sizeof_pfn;
+xen_vaddr_t from, to;
+unsigned lvl;
+
+p2m_alloc_size = round_pg(p2m_alloc_size);
+if ( dom->parms.p2m_base != UNSET_ADDR )
+{
+from = dom->parms.p2m_base;
+to = from + p2m_alloc_size - 1;
+if ( count_pgtables(dom, 0, pgtblshift_x86_64, from, to,
+dom->pfn_alloc_end) )
+return -1;
+
+map->area.pfn = dom->pfn_alloc_end;
+for ( lvl = 0; lvl < 4; lvl++ )
+map->lvls[lvl].pfn += 

Re: [Xen-devel] ARM64 EFI runtime

[Brijesh Singh]

Thanks for update Stefano,

If you have some sample code on private git then please point me at it. I 
should be able to help on both development and testing on Seattle  platform. 

-Brijesh

On 10/13/2015 04:57 AM, Stefano Stabellini wrote:
> Hi Brijesh,
> 
> EFI runtime services are not currently exported to Dom0. They are still
> a work in progress.
> 
> Regards,
> 
> Stefano
> 
> On Mon, 12 Oct 2015, Brijesh Singh wrote:
>> Hi All,
>>
>> I noticed that DOM0 kernel fails to get time via RTC device on AMD ARM64 
>> (Seattle) platform. On this platform Linux uses rtc-efi driver to get the 
>> time through EFI runtime services, and I know for sure that driver works 
>> well outside the Xen environment. It seems that devicetree passed to DOM0 
>> through Xen does not contain UEFI system table information hence DOM0 fails 
>> to probe rtc-efi platform driver. I see the below message in DOM0 dmesg log
>>
>> [0.00] bootconsole [uart0] enabled
>> [0.00] efi: Getting EFI parameters from FDT:
>> [0.00] efi: UEFI not found.
>> [0.00] cma: Reserved 16 MiB at 0x0083df00
>>
>>
>> Looking at Xen's common/efi/runtime.c indicates that EFI runtime services 
>> are not yet supported on ARM platform, is anyone working on it? 
>>
>> Thanks
>> Brijesh
>>
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>>

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

[Xen-devel] [linux-linus test] 62940: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16 
guest-localmigrate/x10 fail in 62908 REGR. vs. 59254

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail in 62908 pass in 62940
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail pass in 62908
 test-armhf-armhf-xl-rtds 15 guest-start.2   fail pass in 62908
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail pass in 62908

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-qcow2 7 host-ping-check-xen fail in 62908 baseline 
untested
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 62908 like 59254
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 59254

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   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-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 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-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-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-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass

version targeted for testing:
 linux25cb62b76430a91cc6195f902e61c2cb84ade622
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z   96 days
Failing since 59348  2015-07-10 04:24:05 Z   95 days   55 attempts
Testing same since62908  2015-10-11 19:28:19 Z1 days2 attempts


2435 people touched revisions under test,
not listing them all

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

[Xen-devel] [distros-debian-snapshot test] 38164: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf   3 host-install(3) broken REGR. vs. 38129
 build-armhf-pvops 3 host-install(3) broken REGR. vs. 38129
 test-amd64-i386-amd64-daily-netboot-pygrub 10 guest-start fail REGR. vs. 38129
 test-amd64-amd64-amd64-daily-netboot-pvgrub 10 guest-start fail REGR. vs. 38129
 test-amd64-i386-i386-daily-netboot-pvgrub 10 guest-start  fail REGR. vs. 38129
 test-amd64-amd64-i386-daily-netboot-pygrub 10 guest-start fail REGR. vs. 38129

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-amd64-current-netinst-pygrub 9 debian-di-install fail like 
38129
 test-amd64-amd64-i386-weekly-netinst-pygrub 9 debian-di-install fail like 38129
 test-amd64-i386-amd64-weekly-netinst-pygrub 13 guest-saverestore fail like 
38129
 test-amd64-amd64-amd64-weekly-netinst-pygrub 13 guest-saverestore fail like 
38129

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-armhf-daily-netboot-pygrub  1 build-check(1)  blocked n/a

baseline version:
 flight   38129

jobs:
 build-amd64  pass
 build-armhf  broken  
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopsbroken  
 build-i386-pvops pass
 test-amd64-amd64-amd64-daily-netboot-pvgrub  fail
 test-amd64-i386-i386-daily-netboot-pvgrubfail
 test-amd64-i386-amd64-daily-netboot-pygrub   fail
 test-armhf-armhf-armhf-daily-netboot-pygrub  blocked 
 test-amd64-amd64-i386-daily-netboot-pygrub   fail
 test-amd64-amd64-amd64-current-netinst-pygrubfail
 test-amd64-i386-amd64-current-netinst-pygrub pass
 test-amd64-amd64-i386-current-netinst-pygrub pass
 test-amd64-i386-i386-current-netinst-pygrub  pass
 test-amd64-amd64-amd64-weekly-netinst-pygrub fail
 test-amd64-i386-amd64-weekly-netinst-pygrub  fail
 test-amd64-amd64-i386-weekly-netinst-pygrub  fail
 test-amd64-i386-i386-weekly-netinst-pygrub   pass



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

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

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


Push not applicable.


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

Re: [Xen-devel] [PATCH v8 02/17] Add cmpxchg16b support for x86-64

[Jan Beulich]

>>> On 12.10.15 at 10:54,  wrote:
> --- a/xen/include/asm-x86/x86_64/system.h
> +++ b/xen/include/asm-x86/x86_64/system.h
> @@ -6,6 +6,39 @@
> (unsigned long)(n),sizeof(*(ptr
>  
>  /*
> + * Atomic 16 bytes compare and exchange.  Compare OLD with MEM, if
> + * identical, store NEW in MEM.  Return the initial value in MEM.
> + * Success is indicated by comparing RETURN with OLD.
> + *
> + * This function can only be called when cpu_has_cx16 is true.
> + */
> +
> +static always_inline __uint128_t __cmpxchg16b(
> +volatile void *ptr, const __uint128_t *old, const __uint128_t *new)
> +{
> +__uint128_t prev;
> +uint64_t new_high = *new >> 64;
> +uint64_t new_low = *new;
> +
> +ASSERT(cpu_has_cx16);
> +
> +asm volatile ( "lock; cmpxchg16b %3"
> +   : "=A" (prev)
> +   : "c" (new_high), "b" (new_low),
> + "m" (*__xg(ptr)), "0" (*old) );

I was about to apply this when I spotted that this is still wrong:
The (requested) removal of the memory clobber requires that
the memory location (all 16 bytes of it) appear as output. With
__xg() covering 100 bytes, it should be possible to simply make
the operand an in- and output ("+m") instead of just an input.

Jan


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

[Xen-devel] [libvirt test] 62942: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
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-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  179d92c8481b2229edbfb233614328e08ab79dfc
baseline version:
 libvirt  4f77c48cbaae66f4326a0a2314b9c6b63db82770

Last test of basis62807  2015-10-11 01:45:41 Z2 days
Testing same since62942  2015-10-13 04:23:31 Z0 days1 attempts


People who touched revisions under test:
  Daniel P. Berrange 
  John Ferlan 
  Michal Privoznik 
  Nikolay Shirokovskiy 

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



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

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

Explanation of these reports, and of osstest in general, is 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=libvirt
+ revision=179d92c8481b2229edbfb233614328e08ab79dfc
+ . ./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 libvirt 
179d92c8481b2229edbfb233614328e08ab79dfc
+ branch=libvirt
+ 

Re: [Xen-devel] [PATCH] libxc: create an initial FPU state for HVM guests

[Jan Beulich]

>>> On 13.10.15 at 15:32,  wrote:
> --- a/tools/libxc/xc_dom_x86.c
> +++ b/tools/libxc/xc_dom_x86.c
> @@ -841,6 +841,23 @@ static int vcpu_hvm(struct xc_dom_image *dom)
>  struct hvm_save_descriptor end_d;
>  HVM_SAVE_TYPE(END) end;
>  } bsp_ctx;
> +struct {
> +uint16_t fcw;
> +uint16_t fsw;
> +uint8_t ftw;
> +uint8_t rsvd1;
> +uint16_t fop;
> +union {
> +uint64_t addr;
> +struct {
> +uint32_t offs;
> +uint16_t sel;
> +uint16_t rsvd;
> +};
> +} fip, fdp;
> +uint32_t mxcsr;
> +uint32_t mxcsr_mask;
> +} *fpu_ctxt;

I think a comment should be added here that this layout is the 64-bit
one, no matter what bitness the tool stack. Or perhaps leave out all
pieces that you don't need; the ones you care about live at the same
offsets in both 32- and 64-bit variants.

Jan


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

Re: [Xen-devel] [Patch RFC 00/13] VT-d Asynchronous Device-TLB Flush for ATS Device

[Jan Beulich]

>>> On 13.10.15 at 16:29,  wrote:
>> > >>>On 29.09.2015 at 15:22  wrote:
>> >>> On 29.09.15 at 04:53,  wrote:
>>  Monday, September 28, 2015 2:47 PM, wrote:
>> >> >>> On 28.09.15 at 05:08,  wrote:
>> >>  Thursday, September 24, 2015 12:27 AM, Tim Deegan wrote:
>>The extra ref taken will prevent the page from getting freed. 
> 
> Jan, could you share more about it?
> 
> I want to check some cases of Xen memory. i.e.
> 
> 1. if (page->count_info & PGC_count_mask == 0) and (page->count_info != 0)
> In this case, can the page be freed to xen domain heap?

Whether a page can get freed depends on changes to count_info, not
just its current state. For instance, PGC_allocated set implies
page->count_info & PGC_count_mask != 0, i.e. your question above
cannot be answered properly. Just look at put_page() - it frees the
page when the count _drops_ to zero.

> 2. if  (page->count_info & PGC_count_mask == 0) and  (page->u.inuse.type_info 
> != 0) :
> In this case, can the page be freed to xen domain heap?

Generally type_info should be zero when the ref count is zero; there
are, I think, exceptional cases (like during domain death) where this
might get violated with no harm. But again - look at put_page() and
you'll see that type_info doesn't matter for whether a page gets
freed; all it matter is whether a page's type can change: Only when
type count is zero.

Jan


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

Re: [Xen-devel] [Patch RFC 00/13] VT-d Asynchronous Device-TLB Flush for ATS Device

[Xu, Quan]

>> >>>On 29.09.2015 at 15:22  wrote:
> >>> On 29.09.15 at 04:53,  wrote:
>  Monday, September 28, 2015 2:47 PM, wrote:
> >> >>> On 28.09.15 at 05:08,  wrote:
> >>  Thursday, September 24, 2015 12:27 AM, Tim Deegan wrote:


>The extra ref taken will prevent the page from getting freed. 

Jan, could you share more about it?

I want to check some cases of Xen memory. i.e.

1. if (page->count_info & PGC_count_mask == 0) and (page->count_info != 0)
In this case, can the page be freed to xen domain heap?

2. if  (page->count_info & PGC_count_mask == 0) and  (page->u.inuse.type_info 
!= 0) :
In this case, can the page be freed to xen domain heap?

Thanks!

Quan

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

Re: [Xen-devel] ARM64 EFI runtime

[Stefano Stabellini]

Hi Brijesh,

passing EFI tables to dom0 is still under work by Shannon, see:
http://marc.info/?l=xen-devel=144321258920213. For now you could
simply reuse the existing linux uefi device tree nodes, see
Documentation/arm/uefi.txt and the existing acpi patch series for Xen,
which also introduces passing efi tables to dom0:
http://marc.info/?l=xen-devel=143189314630953.

Once dom0 knows about efi, then it is just a matter of enabling the
existing PV runtime services on arm64, see drivers/xen/efi.c.


On Tue, 13 Oct 2015, Brijesh Singh wrote:
> Thanks for update Stefano,
> 
> If you have some sample code on private git then please point me at it. I 
> should be able to help on both development and testing on Seattle  platform. 
> 
> -Brijesh
> 
> On 10/13/2015 04:57 AM, Stefano Stabellini wrote:
> > Hi Brijesh,
> > 
> > EFI runtime services are not currently exported to Dom0. They are still
> > a work in progress.
> > 
> > Regards,
> > 
> > Stefano
> > 
> > On Mon, 12 Oct 2015, Brijesh Singh wrote:
> >> Hi All,
> >>
> >> I noticed that DOM0 kernel fails to get time via RTC device on AMD ARM64 
> >> (Seattle) platform. On this platform Linux uses rtc-efi driver to get the 
> >> time through EFI runtime services, and I know for sure that driver works 
> >> well outside the Xen environment. It seems that devicetree passed to DOM0 
> >> through Xen does not contain UEFI system table information hence DOM0 
> >> fails to probe rtc-efi platform driver. I see the below message in DOM0 
> >> dmesg log
> >>
> >> [0.00] bootconsole [uart0] enabled
> >> [0.00] efi: Getting EFI parameters from FDT:
> >> [0.00] efi: UEFI not found.
> >> [0.00] cma: Reserved 16 MiB at 0x0083df00
> >>
> >>
> >> Looking at Xen's common/efi/runtime.c indicates that EFI runtime services 
> >> are not yet supported on ARM platform, is anyone working on it? 
> >>
> >> Thanks
> >> Brijesh
> >>
> >> ___
> >> Xen-devel mailing list
> >> Xen-devel@lists.xen.org
> >> http://lists.xen.org/xen-devel
> >>
> 

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

[Xen-devel] [PATCH] xen/x86: Drop unused declarations from processor.h

[Andrew Cooper]

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/domain.c   |1 -
 xen/include/asm-x86/processor.h |5 -
 2 files changed, 6 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 7ca9b93..91c04f8 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1475,7 +1475,6 @@ static void paravirt_ctxt_switch_to(struct vcpu *v)
 {
 unsigned long cr4;
 
-set_int80_direct_trap(v);
 switch_kernel_stack(v);
 
 cr4 = pv_guest_cr4_to_real_cr4(v);
diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-x86/processor.h
index f507f5e..fcfa7dd 100644
--- a/xen/include/asm-x86/processor.h
+++ b/xen/include/asm-x86/processor.h
@@ -219,7 +219,6 @@ struct cpuinfo_x86 {
 extern void setup_clear_cpu_cap(unsigned int);
 extern void print_cpu_info(unsigned int cpu);
 extern unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c);
-extern void dodgy_tsc(void);
 
 extern void detect_extended_topology(struct cpuinfo_x86 *c);
 
@@ -471,10 +470,6 @@ static always_inline void set_ist(idt_entry_t *idt, 
unsigned long ist)
 
 extern void init_int80_direct_trap(struct vcpu *v);
 
-#define set_int80_direct_trap(_ed)  ((void)0)
-
-extern int gpf_emulate_4gb(struct cpu_user_regs *regs);
-
 extern void write_ptbase(struct vcpu *v);
 
 void destroy_gdt(struct vcpu *d);
-- 
1.7.10.4


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

Re: [Xen-devel] [PATCH v7 2/3] x86: add domctl cmd to set/get CDP code/data CBM

[Jan Beulich]

>>> On 13.10.15 at 10:53,  wrote:
> @@ -331,19 +357,34 @@ static bool_t psr_check_cbm(unsigned int cbm_len, 
> uint64_t cbm)
>  struct cos_cbm_info
>  {
>  unsigned int cos;
> -uint64_t cbm;
> +uint64_t cbm_code;
> +uint64_t cbm_data;
> +bool_t cdp;
>  };

The bool_t field really fits well in the gap between the first and second
one; I'll take the liberty to adjust this when committing (unless Chao
comes forward with further comments; otherwise I'm kind of hoping
for a Reviewed-by-him).

Jan


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

[Xen-devel] Question about xen disk unplug support for ahci missed in qemu

[Fabio Fantoni]

I added ahci disk support in libxl and using it for week seems that was 
ok, after a reply of Stefano Stabellini seems that xen disk unplug 
support only ide disks:

http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39c905374ee8663d5d8
Today Paul Durrant told me that even if pv disk is ok also with ahci and 
the emulated one is offline can be a risk:

http://lists.xenproject.org/archives/html/win-pv-devel/2015-10/msg00021.html

I tried to take a fast look in qemu code but I not understand the needed 
thing for add the xen disk unplug support also for ahci, can someone do 
it or tell me useful information for do it please?


Thanks for any reply and sorry for my bad english.

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

Re: [Xen-devel] ARM64 EFI runtime

[Julien Grall]

On 13/10/15 15:55, Stefano Stabellini wrote:
> Hi Brijesh,
> 
> passing EFI tables to dom0 is still under work by Shannon, see:
> http://marc.info/?l=xen-devel=144321258920213. For now you could
> simply reuse the existing linux uefi device tree nodes, see
> Documentation/arm/uefi.txt and the existing acpi patch series for Xen,
> which also introduces passing efi tables to dom0:
> http://marc.info/?l=xen-devel=143189314630953.
> 
> Once dom0 knows about efi, then it is just a matter of enabling the
> existing PV runtime services on arm64, see drivers/xen/efi.c.

That's not true. There is work to do in Xen in order to support efi
runtime. The hypercall to call runtime services (XENPF_efi_runtime_call)
is not plumbed and most of the code in common/efi/runtime.c is not built.

Regards,

-- 
Julien Grall

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

[Xen-devel] [PATCH v2] libxc: create an initial FPU state for HVM guests

[Roger Pau Monne]

Xen always set the FPU as initialized when loading a HVM context, so libxc
has to provide a valid FPU context when setting the CPU registers.

This is a stop-gap measure in order to unblock OSSTest Windows 7 failures
while a proper fix for the HVM CPU save/restore is being worked on.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Andrew Cooper 
Suggested-by: Jan Beulich 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
---
Changes since v1:
 - Add a comment to clarify that the layout of the FPU context structure is
   the same for both 32 and 64bits.
 - Add Jan Beulich Suggested-by.
 - Add Andrew Cooper Reviewed-by.
---
 tools/libxc/xc_dom_x86.c | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index dd331bf..034abe0 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -841,6 +841,27 @@ static int vcpu_hvm(struct xc_dom_image *dom)
 struct hvm_save_descriptor end_d;
 HVM_SAVE_TYPE(END) end;
 } bsp_ctx;
+/*
+ * The layout of the fpu context structure is the same for
+ * both 32 and 64 bits.
+ */
+struct {
+uint16_t fcw;
+uint16_t fsw;
+uint8_t ftw;
+uint8_t rsvd1;
+uint16_t fop;
+union {
+uint64_t addr;
+struct {
+uint32_t offs;
+uint16_t sel;
+uint16_t rsvd;
+};
+} fip, fdp;
+uint32_t mxcsr;
+uint32_t mxcsr_mask;
+} *fpu_ctxt;
 uint8_t *full_ctx = NULL;
 int rc;
 
@@ -908,6 +929,23 @@ static int vcpu_hvm(struct xc_dom_image *dom)
 /* Set the control registers. */
 bsp_ctx.cpu.cr0 = X86_CR0_PE | X86_CR0_ET;
 
+/*
+ * XXX: Set initial FPU state.
+ *
+ * This should be removed once Xen is able to know if the
+ * FPU state saved is valid or not, now Xen always sets
+ * fpu_initialised to true regardless of the FPU state.
+ *
+ * The code below mimics the FPU sate after executing
+ * fninit
+ * ldmxcsr 0x1f80
+ */
+fpu_ctxt = (typeof(fpu_ctxt))bsp_ctx.cpu.fpu_regs;
+
+fpu_ctxt->fcw = 0x37f;
+fpu_ctxt->ftw = 0xff;
+fpu_ctxt->mxcsr = 0x1f80;
+
 /* Set the IP. */
 bsp_ctx.cpu.rip = dom->parms.phys_entry;
 
-- 
1.9.5 (Apple Git-50.3)


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

Re: [Xen-devel] [PATCH] libxc: create an initial FPU state for HVM guests

[Roger Pau Monné]

El 13/10/15 a les 15.42, Ian Campbell ha escrit:
> On Tue, 2015-10-13 at 15:32 +0200, Roger Pau Monne wrote:
>> Xen always set the FPU as initialized when loading a HVM context, so
>> libxc
>> has to provide a valid FPU context when setting the CPU registers.
>>
>> Signed-off-by: Roger Pau Monné 
>> Cc: Jan Beulich 
>> Cc: Andrew Cooper 
>> Cc: Ian Jackson 
>> Cc: Stefano Stabellini 
>> Cc: Ian Campbell 
>> Cc: Wei Liu 
>> ---
>>  tools/libxc/xc_dom_x86.c | 34 ++
>>  1 file changed, 34 insertions(+)
>>
>> diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
>> index dd331bf..f8d580c 100644
>> --- a/tools/libxc/xc_dom_x86.c
>> +++ b/tools/libxc/xc_dom_x86.c
>> @@ -841,6 +841,23 @@ static int vcpu_hvm(struct xc_dom_image *dom)
>>  struct hvm_save_descriptor end_d;
>>  HVM_SAVE_TYPE(END) end;
>>  } bsp_ctx;
>> +struct {
>> +uint16_t fcw;
>> +uint16_t fsw;
>> +uint8_t ftw;
>> +uint8_t rsvd1;
>> +uint16_t fop;
>> +union {
>> +uint64_t addr;
>> +struct {
>> +uint32_t offs;
>> +uint16_t sel;
>> +uint16_t rsvd;
>> +};
>> +} fip, fdp;
>> +uint32_t mxcsr;
>> +uint32_t mxcsr_mask;
>> +} *fpu_ctxt;
>>  uint8_t *full_ctx = NULL;
>>  int rc;
>>  
>> @@ -908,6 +925,23 @@ static int vcpu_hvm(struct xc_dom_image *dom)
>>  /* Set the control registers. */
>>  bsp_ctx.cpu.cr0 = X86_CR0_PE | X86_CR0_ET;
>>  
>> +/*
>> + * XXX: Set initial FPU state.
>> + *
>> + * This should be removed once Xen is able to know if the
>> + * FPU state saved is valid or not, now Xen always sets
>> + * fpu_initialised to true regardless of the FPU state.
> 
> I suppose we aren't just doing that now because there is some complexity in
> doing so? Can that be mentioned in the commit log please.

Yes, this is the easiest way for me to unblock the push gate.

I'm going to work on fixing the CPU save/restore stuff ASAP, but it's
probably going to be a more complex patch(es) involving compatibility
layers and stuff.

I've added the following to the commit message:

This is a stop-gap measure in order to unblock OSSTest Windows 7
failures while a proper fix for the HVM CPU save/restore is being worked on.

Roger.

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

[Xen-devel] [PATCH 0/3] xen/xenbus: Support multiple grants ring with 64KB page

[Julien Grall]

Hi all,

The support of multiple grants ring was left aside for 64KB page. This series
aims to fix it.

It's based on xentip/for-linus-4.4.

Sincelerely yours,

Cc: Boris Ostrovsky 
Cc: David Vrabel 
Cc: Konrad Rzeszutek Wilk 
Cc: "Roger Pau Monné" 
Cc: Stefano Stabellini 

Julien Grall (3):
  xen/xenbus: Rename *RING_PAGE* to *RING_GRANT*
  xen/grant-table: Add an helper to iterate over a specific number of
grants
  xenbus: Support multiple grants ring with 64KB

 drivers/block/xen-blkback/blkback.c |   8 +--
 drivers/block/xen-blkback/xenbus.c  |   2 +-
 drivers/block/xen-blkfront.c|  10 +--
 drivers/xen/grant-table.c   |  22 +++
 drivers/xen/xenbus/xenbus_client.c  | 121 +---
 include/xen/grant_table.h   |   6 ++
 include/xen/xenbus.h|   4 +-
 7 files changed, 124 insertions(+), 49 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH 1/3] xen/xenbus: Rename *RING_PAGE* to *RING_GRANT*

[Julien Grall]

Linux may use a different page size than the size of grant. So make
clear that the order is actually in number of grant.

Signed-off-by: Julien Grall 

---
Cc: Konrad Rzeszutek Wilk 
Cc: "Roger Pau Monné" 
Cc: Boris Ostrovsky 
Cc: David Vrabel 
Cc: Stefano Stabellini 
---
 drivers/block/xen-blkback/blkback.c |  8 
 drivers/block/xen-blkback/xenbus.c  |  2 +-
 drivers/block/xen-blkfront.c| 10 +-
 drivers/xen/xenbus/xenbus_client.c  | 34 +-
 include/xen/xenbus.h|  4 ++--
 5 files changed, 29 insertions(+), 29 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c 
b/drivers/block/xen-blkback/blkback.c
index 809634c..f909994 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -87,7 +87,7 @@ MODULE_PARM_DESC(max_persistent_grants,
  * Maximum order of pages to be used for the shared ring between front and
  * backend, 4KB page granularity is used.
  */
-unsigned int xen_blkif_max_ring_order = XENBUS_MAX_RING_PAGE_ORDER;
+unsigned int xen_blkif_max_ring_order = XENBUS_MAX_RING_GRANT_ORDER;
 module_param_named(max_ring_page_order, xen_blkif_max_ring_order, int, 
S_IRUGO);
 MODULE_PARM_DESC(max_ring_page_order, "Maximum order of pages to be used for 
the shared ring");
 /*
@@ -1446,10 +1446,10 @@ static int __init xen_blkif_init(void)
if (!xen_domain())
return -ENODEV;
 
-   if (xen_blkif_max_ring_order > XENBUS_MAX_RING_PAGE_ORDER) {
+   if (xen_blkif_max_ring_order > XENBUS_MAX_RING_GRANT_ORDER) {
pr_info("Invalid max_ring_order (%d), will use default max: 
%d.\n",
-   xen_blkif_max_ring_order, XENBUS_MAX_RING_PAGE_ORDER);
-   xen_blkif_max_ring_order = XENBUS_MAX_RING_PAGE_ORDER;
+   xen_blkif_max_ring_order, XENBUS_MAX_RING_GRANT_ORDER);
+   xen_blkif_max_ring_order = XENBUS_MAX_RING_GRANT_ORDER;
}
 
rc = xen_blkif_interface_init();
diff --git a/drivers/block/xen-blkback/xenbus.c 
b/drivers/block/xen-blkback/xenbus.c
index edd27e4..cde8ccd 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -827,7 +827,7 @@ again:
 static int connect_ring(struct backend_info *be)
 {
struct xenbus_device *dev = be->dev;
-   unsigned int ring_ref[XENBUS_MAX_RING_PAGES];
+   unsigned int ring_ref[XENBUS_MAX_RING_GRANTS];
unsigned int evtchn, nr_grefs, ring_page_order;
unsigned int pers_grants;
char protocol[64] = "";
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 43cda94..3ea948c 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -111,7 +111,7 @@ MODULE_PARM_DESC(max_ring_page_order, "Maximum order of 
pages to be used for the
__CONST_RING_SIZE(blkif, XEN_PAGE_SIZE * (info)->nr_ring_pages)
 
 #define BLK_MAX_RING_SIZE  \
-   __CONST_RING_SIZE(blkif, XEN_PAGE_SIZE * XENBUS_MAX_RING_PAGES)
+   __CONST_RING_SIZE(blkif, XEN_PAGE_SIZE * XENBUS_MAX_RING_GRANTS)
 
 /*
  * ring-ref%i i=(-1UL) would take 11 characters + 'ring-ref' is 8, so 19
@@ -133,7 +133,7 @@ struct blkfront_info
int vdevice;
blkif_vdev_t handle;
enum blkif_state connected;
-   int ring_ref[XENBUS_MAX_RING_PAGES];
+   int ring_ref[XENBUS_MAX_RING_GRANTS];
unsigned int nr_ring_pages;
struct blkif_front_ring ring;
unsigned int evtchn, irq;
@@ -1412,7 +1412,7 @@ static int setup_blkring(struct xenbus_device *dev,
struct blkif_sring *sring;
int err, i;
unsigned long ring_size = info->nr_ring_pages * XEN_PAGE_SIZE;
-   grant_ref_t gref[XENBUS_MAX_RING_PAGES];
+   grant_ref_t gref[XENBUS_MAX_RING_GRANTS];
 
for (i = 0; i < info->nr_ring_pages; i++)
info->ring_ref[i] = GRANT_INVALID_REF;
@@ -2283,9 +2283,9 @@ static int __init xlblk_init(void)
if (!xen_domain())
return -ENODEV;
 
-   if (xen_blkif_max_ring_order > XENBUS_MAX_RING_PAGE_ORDER) {
+   if (xen_blkif_max_ring_order > XENBUS_MAX_RING_GRANT_ORDER) {
pr_info("Invalid max_ring_order (%d), will use default max: 
%d.\n",
-   xen_blkif_max_ring_order, XENBUS_MAX_RING_PAGE_ORDER);
+   xen_blkif_max_ring_order, XENBUS_MAX_RING_GRANT_ORDER);
xen_blkif_max_ring_order = 0;
}
 
diff --git a/drivers/xen/xenbus/xenbus_client.c 
b/drivers/xen/xenbus/xenbus_client.c
index 42abee3..b776433 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -56,11 +56,11 @@ struct xenbus_map_node {
struct vm_struct *area;
} pv;
struct {
-   struct page 

[Xen-devel] [PATCH 2/3] xen/grant-table: Add an helper to iterate over a specific number of grants

[Julien Grall]

With the 64KB page granularity support on ARM64, a Linux page may be
split accross multiple grant.

Currently we have the helper gnttab_foreach_grant_in_grant to break a
Linux page based on an offset and a len, but it doesn't fit when we only
have a number of grants in hand.

Introduce a new helper which take an array of Linux page and a number of
grant and will figure out the address of each grant.

Signed-off-by: Julien Grall 

---
Cc: Konrad Rzeszutek Wilk 
Cc: Boris Ostrovsky 
Cc: David Vrabel 
Cc: Stefano Stabellini 
---
 drivers/xen/grant-table.c | 22 ++
 include/xen/grant_table.h |  6 ++
 2 files changed, 28 insertions(+)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 72d6339..c49f79ed 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -802,6 +802,28 @@ void gnttab_foreach_grant_in_range(struct page *page,
 }
 EXPORT_SYMBOL_GPL(gnttab_foreach_grant_in_range);
 
+void gnttab_foreach_grant(struct page **pages,
+ unsigned int nr_grefs,
+ xen_grant_fn_t fn,
+ void *data)
+{
+   unsigned int goffset = 0;
+   unsigned long xen_pfn = 0;
+   unsigned int i;
+
+   for (i = 0; i < nr_grefs; i++) {
+   if ((i % XEN_PFN_PER_PAGE) == 0) {
+   xen_pfn = page_to_xen_pfn(pages[i / XEN_PFN_PER_PAGE]);
+   goffset = 0;
+   }
+
+   fn(pfn_to_gfn(xen_pfn), goffset, XEN_PAGE_SIZE, data);
+
+   goffset += XEN_PAGE_SIZE;
+   xen_pfn++;
+   }
+}
+
 int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
struct gnttab_map_grant_ref *kmap_ops,
struct page **pages, unsigned int count)
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index e17a4b3..34b1379 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -264,6 +264,12 @@ static inline void gnttab_for_one_grant(struct page *page, 
unsigned int offset,
gnttab_foreach_grant_in_range(page, offset, len, fn, data);
 }
 
+/* Get @nr_grefs grants from an array of page and call fn for each grant */
+void gnttab_foreach_grant(struct page **pages,
+ unsigned int nr_grefs,
+ xen_grant_fn_t fn,
+ void *data);
+
 /* Get the number of grant in a specified region
  *
  * start: Offset from the beginning of the first page
-- 
2.1.4


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

[Xen-devel] [PATCH 3/3] xenbus: Support multiple grants ring with 64KB

[Julien Grall]

The PV ring may use multiple grants and expect them to be mapped
contiguously in the virtual memory.

Although, the current code is relying on a Linux page will be mapped to
a single grant. On build where Linux is using a different page size than
the grant (i.e other than 4KB), the grant will always be mapped on the
first 4KB of each Linux page which make the final ring not contiguous in
the memory.

This can be fixed by mapping multiple grant in a same Linux page.

Signed-off-by: Julien Grall 

---
Cc: Konrad Rzeszutek Wilk 
Cc: Boris Ostrovsky 
Cc: David Vrabel 
Cc: Stefano Stabellini 
---
 drivers/xen/xenbus/xenbus_client.c | 97 --
 1 file changed, 72 insertions(+), 25 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_client.c 
b/drivers/xen/xenbus/xenbus_client.c
index b776433..056da6e 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -49,6 +49,10 @@
 
 #include "xenbus_probe.h"
 
+#define XENBUS_PAGES(_grants)  (DIV_ROUND_UP(_grants, XEN_PFN_PER_PAGE))
+
+#define XENBUS_MAX_RING_PAGES  (XENBUS_PAGES(XENBUS_MAX_RING_GRANTS))
+
 struct xenbus_map_node {
struct list_head next;
union {
@@ -56,7 +60,8 @@ struct xenbus_map_node {
struct vm_struct *area;
} pv;
struct {
-   struct page *pages[XENBUS_MAX_RING_GRANTS];
+   struct page *pages[XENBUS_MAX_RING_PAGES];
+   unsigned long addrs[XENBUS_MAX_RING_GRANTS];
void *addr;
} hvm;
};
@@ -591,19 +596,42 @@ failed:
return err;
 }
 
+struct map_ring_valloc_hvm
+{
+   unsigned int idx;
+
+   /* Why do we need two arrays? See comment of __xenbus_map_ring */
+   phys_addr_t phys_addrs[XENBUS_MAX_RING_GRANTS];
+   unsigned long addrs[XENBUS_MAX_RING_GRANTS];
+};
+
+static void xenbus_map_ring_setup_grant_hvm(unsigned long gfn,
+   unsigned int goffset,
+   unsigned int len,
+   void *data)
+{
+   struct map_ring_valloc_hvm *info = data;
+   unsigned long vaddr = (unsigned long)gfn_to_virt(gfn);
+
+   info->phys_addrs[info->idx] = vaddr;
+   info->addrs[info->idx] = vaddr;
+
+   info->idx++;
+}
+
 static int xenbus_map_ring_valloc_hvm(struct xenbus_device *dev,
  grant_ref_t *gnt_ref,
  unsigned int nr_grefs,
  void **vaddr)
 {
struct xenbus_map_node *node;
-   int i;
int err;
void *addr;
bool leaked = false;
-   /* Why do we need two arrays? See comment of __xenbus_map_ring */
-   phys_addr_t phys_addrs[XENBUS_MAX_RING_GRANTS];
-   unsigned long addrs[XENBUS_MAX_RING_GRANTS];
+   struct map_ring_valloc_hvm info = {
+   .idx = 0,
+   };
+   unsigned int nr_pages = XENBUS_PAGES(nr_grefs);
 
if (nr_grefs > XENBUS_MAX_RING_GRANTS)
return -EINVAL;
@@ -614,24 +642,22 @@ static int xenbus_map_ring_valloc_hvm(struct 
xenbus_device *dev,
if (!node)
return -ENOMEM;
 
-   err = alloc_xenballooned_pages(nr_grefs, node->hvm.pages);
+   err = alloc_xenballooned_pages(nr_pages, node->hvm.pages);
if (err)
goto out_err;
 
-   for (i = 0; i < nr_grefs; i++) {
-   unsigned long pfn = page_to_pfn(node->hvm.pages[i]);
-   phys_addrs[i] = (unsigned long)pfn_to_kaddr(pfn);
-   addrs[i] = (unsigned long)pfn_to_kaddr(pfn);
-   }
+   gnttab_foreach_grant(node->hvm.pages, nr_grefs,
+xenbus_map_ring_setup_grant_hvm,
+);
 
err = __xenbus_map_ring(dev, gnt_ref, nr_grefs, node->handles,
-   phys_addrs, GNTMAP_host_map, );
+   info.phys_addrs, GNTMAP_host_map, );
node->nr_handles = nr_grefs;
 
if (err)
goto out_free_ballooned_pages;
 
-   addr = vmap(node->hvm.pages, nr_grefs, VM_MAP | VM_IOREMAP,
+   addr = vmap(node->hvm.pages, nr_pages, VM_MAP | VM_IOREMAP,
PAGE_KERNEL);
if (!addr) {
err = -ENOMEM;
@@ -649,14 +675,13 @@ static int xenbus_map_ring_valloc_hvm(struct 
xenbus_device *dev,
 
  out_xenbus_unmap_ring:
if (!leaked)
-   xenbus_unmap_ring(dev, node->handles, node->nr_handles,
- addrs);
+   xenbus_unmap_ring(dev, node->handles, nr_grefs, info.addrs);
else
pr_alert("leaking %p size %u page(s)",
-addr, nr_grefs);
+   

Re: [Xen-devel] [PATCH v7 3/3] tools & docs: add tools and docs support for Intel CDP

[Ian Campbell]

On Tue, 2015-10-13 at 16:53 +0800, He Chen wrote:
> @@ -8445,29 +8447,46 @@ out:
>  return rc;
>  }
>  
> -static void psr_cat_print_one_domain_cbm(uint32_t domid, uint32_t
> socketid)
> +static void psr_cat_print_one_domain_cbm_type(uint32_t domid, uint32_t
> socketid,
> +  libxl_psr_cbm_type type)
>  {
> -char *domain_name;
>  uint64_t cbm;
> +if (!libxl_psr_cat_get_cbm(ctx, domid, type, socketid, ))
> +printf("%#16"PRIx64, cbm);
> +else
> +printf("%16s", "error");

Coding style is 4 space indentation, here you appear to have 8 for the
first level and 4 for the second level of indentation.

With that fixed:

Acked-by: Ian Campbell 


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

Re: [Xen-devel] [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[John Snow]

On 10/13/2015 11:55 AM, Fabio Fantoni wrote:
> I added ahci disk support in libxl and using it for week seems that was
> ok, after a reply of Stefano Stabellini seems that xen disk unplug
> support only ide disks:
> http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39c905374ee8663d5d8
> 
> Today Paul Durrant told me that even if pv disk is ok also with ahci and
> the emulated one is offline can be a risk:
> http://lists.xenproject.org/archives/html/win-pv-devel/2015-10/msg00021.html
> 
> 
> I tried to take a fast look in qemu code but I not understand the needed
> thing for add the xen disk unplug support also for ahci, can someone do
> it or tell me useful information for do it please?
> 
> Thanks for any reply and sorry for my bad english.
> 

I'm not entirely sure what features you need AHCI to support in order
for Xen to be happy.

I'd guess hotplugging, but where I get confused is that IDE disks don't
support hotplugging either, so I guess I'm not sure sure what you need.

Stefano, can you help bridge my Xen knowledge gap?

--js

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

[Xen-devel] [linux-mingo-tip-master test] 62941: regressions - FAIL

[osstest service owner]

flight 62941 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62941/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvh-intel  6 xen-boot fail REGR. vs. 60684
 test-amd64-amd64-xl-pvh-amd   6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-xl-xsm6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-xsm   6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-multivcpu  6 xen-boot fail REGR. vs. 60684
 test-amd64-amd64-xl-credit2   6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-amd64-pvgrub  6 xen-boot fail REGR. vs. 60684
 test-amd64-amd64-i386-pvgrub  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 60684
 test-amd64-amd64-xl-qemut-debianhvm-amd64  6 xen-boot fail REGR. vs. 60684
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. 
vs. 60684
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  6 xen-boot fail REGR. vs. 60684
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
60684
 test-amd64-i386-xl-raw6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 60684
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-rumpuserxen-i386  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-freebsd10-amd64  6 xen-boot   fail REGR. vs. 60684
 test-amd64-amd64-xl-qcow2 6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-rumpuserxen-amd64  6 xen-bootfail REGR. vs. 60684
 test-amd64-amd64-xl   6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-pygrub   6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot   fail REGR. vs. 60684
 test-amd64-amd64-xl-qemut-win7-amd64  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-xl-qemuu-win7-amd64  6 xen-boot   fail REGR. vs. 60684
 test-amd64-i386-freebsd10-i386  6 xen-bootfail REGR. vs. 60684
 test-amd64-amd64-pair10 xen-boot/dst_host fail REGR. vs. 60684
 test-amd64-amd64-pair 9 xen-boot/src_host fail REGR. vs. 60684
 test-amd64-amd64-xl-qemuu-win7-amd64  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-pair 10 xen-boot/dst_host fail REGR. vs. 60684
 test-amd64-i386-pair  9 xen-boot/src_host fail REGR. vs. 60684
 test-amd64-amd64-xl-qemut-winxpsp3  6 xen-bootfail REGR. vs. 60684
 test-amd64-i386-xl-qemut-winxpsp3  6 xen-boot fail REGR. vs. 60684
 test-amd64-amd64-xl-qemuu-winxpsp3  6 xen-bootfail REGR. vs. 60684
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  6 xen-boot  fail REGR. vs. 60684

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-xsm   6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-libvirt  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
60684
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
60684
 test-amd64-amd64-libvirt-xsm  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-libvirt-vhd  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-rtds  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_hostfail REGR. vs. 60684
 test-amd64-amd64-libvirt-pair  9 xen-boot/src_hostfail REGR. vs. 60684
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host fail REGR. vs. 60684
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host fail REGR. vs. 60684

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass

version targeted for testing:
 linuxe6f195fd5c80214c5a4f139ee28798e66e20aa8f
baseline version:
 linux69f75ebe3b1d1e636c4ce0a0ee248edacc69cbe0

Last test of basis60684  2015-08-13 04:21:46 Z   61 days
Failing since

[Xen-devel] [PATCH] x86/boot: Use mnemonics rather than magic numbers

[Andrew Cooper]

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/boot/trampoline.S |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/trampoline.S
index ccb40fb..3452979 100644
--- a/xen/arch/x86/boot/trampoline.S
+++ b/xen/arch/x86/boot/trampoline.S
@@ -98,7 +98,8 @@ trampoline_protmode_entry:
 1:  wrmsr
 .Lskip_efer:
 
-mov $0x80050033,%eax /* hi-to-lo: PG,AM,WP,NE,ET,MP,PE */
+mov $(X86_CR0_PG | X86_CR0_AM | X86_CR0_WP | X86_CR0_NE |\
+  X86_CR0_ET | X86_CR0_MP | X86_CR0_PE), %eax
 mov %eax,%cr0
 jmp 1f
 1:
-- 
1.7.10.4


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 
62934
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 62934

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

version targeted for testing:
 qemuu5451316ed07b758a187dedf21047bed8f843f7f1
baseline version:
 qemuuc9003eb4662f44c61be9c8d7d5c9d4a02d58b560

Last test of basis62934  2015-10-12 10:12:29 Z1 days
Testing same since62943  2015-10-13 04:49:09 Z0 days1 attempts


People who touched revisions under test:
  Alistair Francis 
  Dana Rubin 
  Greg Kurz 
  Jason Wang 
  Kevin O'Connor 
  Markus Armbruster 
  Paolo Bonzini 
  Peter Maydell 
  Pierre Morel 
  Pradeep Surisetty 
  Shmulik Ladkani 
  Stefan Hajnoczi 
  Yang Hongyang 
  Yang Hongyang 

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

Re: [Xen-devel] [PATCH] libxc: create an initial FPU state for HVM guests

[Roger Pau Monné]

El 13/10/15 a les 16.43, Jan Beulich ha escrit:
 On 13.10.15 at 15:32,  wrote:
>> --- a/tools/libxc/xc_dom_x86.c
>> +++ b/tools/libxc/xc_dom_x86.c
>> @@ -841,6 +841,23 @@ static int vcpu_hvm(struct xc_dom_image *dom)
>>  struct hvm_save_descriptor end_d;
>>  HVM_SAVE_TYPE(END) end;
>>  } bsp_ctx;
>> +struct {
>> +uint16_t fcw;
>> +uint16_t fsw;
>> +uint8_t ftw;
>> +uint8_t rsvd1;
>> +uint16_t fop;
>> +union {
>> +uint64_t addr;
>> +struct {
>> +uint32_t offs;
>> +uint16_t sel;
>> +uint16_t rsvd;
>> +};
>> +} fip, fdp;
>> +uint32_t mxcsr;
>> +uint32_t mxcsr_mask;
>> +} *fpu_ctxt;
> 
> I think a comment should be added here that this layout is the 64-bit
> one, no matter what bitness the tool stack. Or perhaps leave out all
> pieces that you don't need; the ones you care about live at the same
> offsets in both 32- and 64-bit variants.

The layout of this structure is exactly the same for 32 and 64bits, I'm
going to add a comment stating this.

Roger.


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

[Xen-devel] [PATCH] x86/traps: Don't use 16bit reads of segment registers

[Andrew Cooper]

When executing `mov %sreg, %r32`, older Intel processors would leave the
upper 16 bits of %r32 undefined.  P4 processors and newer, as well as
all AMD processors will zero extend the segment selector.

As Xen only supports 64bit these days, there is no need to use the
operand-size override prefix and suffer the resulting pipeline overhead.

Rename read_segment_register() to read_sreg() and drop the existing
read_sreg() wrapper which took a regs parameter and did nothing with it.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/domain.c|8 
 xen/arch/x86/traps.c |   26 --
 xen/arch/x86/x86_64/traps.c  |   16 
 xen/include/asm-x86/system.h |6 +++---
 4 files changed, 27 insertions(+), 29 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 91c04f8..fe3be30 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1412,10 +1412,10 @@ static void save_segments(struct vcpu *v)
 struct cpu_user_regs *regs = >arch.user_regs;
 unsigned int dirty_segment_mask = 0;
 
-regs->ds = read_segment_register(ds);
-regs->es = read_segment_register(es);
-regs->fs = read_segment_register(fs);
-regs->gs = read_segment_register(gs);
+regs->ds = read_sreg(ds);
+regs->es = read_sreg(es);
+regs->fs = read_sreg(fs);
+regs->gs = read_sreg(gs);
 
 if ( cpu_has_fsgsbase && !is_pv_32bit_vcpu(v) )
 {
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index f1fc7b7..8093535 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1981,8 +1981,6 @@ static inline uint64_t guest_misc_enable(uint64_t val)
 }   \
 (eip) += sizeof(_x); _x; })
 
-#define read_sreg(regs, sr) read_segment_register(sr)
-
 static int is_cpufreq_controller(struct domain *d)
 {
 return ((cpufreq_controller == FREQCTL_dom0_kernel) &&
@@ -2029,7 +2027,7 @@ static int emulate_privileged_op(struct cpu_user_regs 
*regs)
 goto fail;
 
 /* emulating only opcodes not allowing SS to be default */
-data_sel = read_sreg(regs, ds);
+data_sel = read_sreg(ds);
 
 /* Legacy prefixes. */
 for ( i = 0; i < 8; i++, rex == opcode || (rex = 0) )
@@ -2047,17 +2045,17 @@ static int emulate_privileged_op(struct cpu_user_regs 
*regs)
 data_sel = regs->cs;
 continue;
 case 0x3e: /* DS override */
-data_sel = read_sreg(regs, ds);
+data_sel = read_sreg(ds);
 continue;
 case 0x26: /* ES override */
-data_sel = read_sreg(regs, es);
+data_sel = read_sreg(es);
 continue;
 case 0x64: /* FS override */
-data_sel = read_sreg(regs, fs);
+data_sel = read_sreg(fs);
 lm_ovr = lm_seg_fs;
 continue;
 case 0x65: /* GS override */
-data_sel = read_sreg(regs, gs);
+data_sel = read_sreg(gs);
 lm_ovr = lm_seg_gs;
 continue;
 case 0x36: /* SS override */
@@ -2104,7 +2102,7 @@ static int emulate_privileged_op(struct cpu_user_regs 
*regs)
 
 if ( !(opcode & 2) )
 {
-data_sel = read_sreg(regs, es);
+data_sel = read_sreg(es);
 lm_ovr = lm_seg_none;
 }
 
@@ -2912,22 +2910,22 @@ static void emulate_gate_op(struct cpu_user_regs *regs)
 ASSERT(opnd_sel);
 continue;
 case 0x3e: /* DS override */
-opnd_sel = read_sreg(regs, ds);
+opnd_sel = read_sreg(ds);
 if ( !opnd_sel )
 opnd_sel = dpl;
 continue;
 case 0x26: /* ES override */
-opnd_sel = read_sreg(regs, es);
+opnd_sel = read_sreg(es);
 if ( !opnd_sel )
 opnd_sel = dpl;
 continue;
 case 0x64: /* FS override */
-opnd_sel = read_sreg(regs, fs);
+opnd_sel = read_sreg(fs);
 if ( !opnd_sel )
 opnd_sel = dpl;
 continue;
 case 0x65: /* GS override */
-opnd_sel = read_sreg(regs, gs);
+opnd_sel = read_sreg(gs);
 if ( !opnd_sel )
 opnd_sel = dpl;
 continue;
@@ -2980,7 +2978,7 @@ static void emulate_gate_op(struct cpu_user_regs *regs)
 switch ( modrm & 7 )
 {
 default:
-opnd_sel = read_sreg(regs, ds);
+opnd_sel = read_sreg(ds);
 break;
 case 4: case 5:
 opnd_sel = regs->ss;
@@ -3008,7 +3006,7 @@ static void emulate_gate_op(struct cpu_user_regs *regs)
 break;
 }

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  ed740187a5d8a7fcec2116c410d850f1b54a0603
baseline version:
 xen  4930444bdf33157763ade5dd959b9a2a7477e0a3

Last test of basis62939  2015-10-12 16:52:33 Z1 days
Testing same since62949  2015-10-13 16:52:30 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Yang Zhang 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=ed740187a5d8a7fcec2116c410d850f1b54a0603
+ . ./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 
ed740187a5d8a7fcec2116c410d850f1b54a0603
+ branch=xen-unstable-smoke
+ revision=ed740187a5d8a7fcec2116c410d850f1b54a0603
+ . ./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-unstable
+ : tested/2.6.39.x
+ . ./ap-common
++ xenbranch_forqemu=xen-unstable
++ : 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/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/

[Xen-devel] [OSSTEST PATCH v2] standalone-generate-dump-flight-runvars: Handle ^C properly

[Ian Jackson]

This is all mad.

Signed-off-by: Ian Jackson 
Acked-by: Ian Campbell 
---
v2: Updated comment with more accurate discussion, references to
bash "trap - INT" bug, and proposed new shopt.
No code change.
---
 standalone-generate-dump-flight-runvars |   27 +++
 1 file changed, 27 insertions(+)

diff --git a/standalone-generate-dump-flight-runvars 
b/standalone-generate-dump-flight-runvars
index a1907b0..e91026a 100755
--- a/standalone-generate-dump-flight-runvars
+++ b/standalone-generate-dump-flight-runvars
@@ -58,8 +58,35 @@ perbranch () {
 flight=check_${branch//[-._]/_}
 }
 
+# Good grief, handling background proceesses from shell is a pain.
+#
+# For stupid historical reasons, background processes start with
+# SIGINT (and QUIT) ignored (SuSv3 2.11).  bash does not currently
+# offer a way to ask it not to do this; nor is there a reliable way to
+# put the SIGINT handling back to normal.
+#
+# "trap - INT" can be used to put the handling back in recent versions
+# of bash (eg Debian jessie), but earlier versions are buggy, so
+# we use perl.
+#
+# However, there is still a race: if the signal arrives just after the
+# fork, after the shell has (in the child) set it to to IGN, but
+# before Perl has put it back, the child might still escape.
+# There is no reasonable way to deal with this race.  So the result
+# may still be slightly racy in the case that s-g-d-f-r is ^C'd right
+# after starting.
+#
+# Hopefully in the future we can fix this with something like
+# "shopt -s no_async_sig_ignore".  See
+# https://lists.gnu.org/archive/html/bug-bash/2015-10/msg00077.html
+
 for branch in $@; do
 perbranch
+perl -e '
+$SIG{$_}=DFL foreach qw(INT QUIT HUP);
+   kill 1, $$ unless getppid=='$$';
+   exec @ARGV or die $!;
+' \
 ./standalone make-flight -f $flight $branch >$log 2>&1 &
 procs+=" $branch=$!"
 done
-- 
1.7.10.4


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