[Xen-devel] [xen-4.5-testing test] 83003: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-debianhvm-amd64 15 guest-localmigrate/x10 fail REGR. 
vs. 78736

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail REGR. vs. 78640
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 78736
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10   fail like 78640
 test-amd64-amd64-xl-rtds  6 xen-boot fail   like 78736
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 78736
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 78736
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 78736

Tests which did not succeed, but are not blocking:
 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-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  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-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   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-armhf-armhf-xl-vhd  10 guest-start  fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 10 guest-start  fail never pass
 test-armhf-armhf-libvirt-raw 10 guest-start  fail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  fe71162ab965d4a3344bb867f88e967806c80af5
baseline version:
 xen  7afddd3b945b11a7f5162d1355283b6b9ae7aba3

Last test of basis78736  2016-01-21 20:56:44 Z   28 days
Testing same since83003  2016-02-18 14:45:02 Z0 days1 attempts


People who touched revisions under test:
  Alan.Robinson 
  Andrew Cooper 
  Anthony PERARD 
  Dirk Behme 
  George Dunlap 
  Ian Campbell 
  Jan Beulich 
  Juergen Gross 
  Kevin Tian 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64fail
 

Re: [Xen-devel] [PATCH] arm/monitor vm-events: Implement guest-request support

[Corneliu ZUZU]

On 2/18/2016 11:25 PM, Tamas K Lengyel wrote:



On Thu, Feb 18, 2016 at 1:08 PM, Razvan Cojocaru 
> wrote:


On 02/18/2016 09:35 PM, Corneliu ZUZU wrote:
> This patch adds ARM support for guest-request monitor vm-events.
>
> Summary of changes:
> == Moved to common-side:
>   * XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST handling (moved from X86
>   arch_monitor_domctl_event to common monitor_domctl)
>   * hvm_event_guest_request, hvm_event_traps (also added target
vcpu as param)
>   * guest-request bits from X86 'struct arch_domain' (to common
'struct domain')
> == ARM implementations:
>   * do_hvm_op now handling of HVMOP_guest_request_vm_event => calls
>   hvm_event_guest_request (as on X86)
>   * arch_monitor_get_capabilities: updated to reflect support for
>   XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST
>   * vm_event_init_domain (does nothing), vm_event_cleanup_domain
> == Misc:
>   * hvm_event_fill_regs renamed to arch_hvm_event_fill_regs, no
longer
>   X86-specific. ARM-side implementation of this function
currently does
>   nothing, that will be added in a separate patch.

We should probably take into account what happens with Tamas'
"vm_event:
consolidate hvm_event_fill_regs and p2m_vm_event_fill_regs" patch
here.
That patch already affects hvm_event_fill_regs().


Well it seems one of us will have to rebase depending which patch gets 
accepted & merged first. The conflict is minimal so it's not a major 
issue. If my patch gets merged first then just have to introduce the 
empty function in the ARM header with the new name.


Tamas



Okay then, for me it's fine either way.

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

Re: [Xen-devel] [PATCH v3 01/10] xen: make xen loader callable multiple times

[Juergen Gross]

On 18/02/16 17:58, Daniel Kiper wrote:
> On Thu, Feb 18, 2016 at 11:32:16AM +0100, Juergen Gross wrote:
>> On 18/02/16 11:12, Daniel Kiper wrote:
>>> On Wed, Feb 17, 2016 at 06:19:28PM +0100, Juergen Gross wrote:
 The loader for xen paravirtualized environment isn't callable multiple
 times as it won't free any memory in case of failure.

 Call grub_relocator_unload() as other modules do it before allocating
>>>
>>> Do you mean grub_xen_reset?
>>
>> No. I do want to call grub_relocator_unload() and I'm doing it in
>> grub_xen_reset(). Other modules don't call grub_xen_reset(). :-)
>>
>>>
 a new relocator or when unloading the module.

 Signed-off-by: Juergen Gross 
 ---
  grub-core/loader/i386/xen.c| 28 +++-
  grub-core/loader/i386/xen_fileXX.c | 17 +++--
  2 files changed, 30 insertions(+), 15 deletions(-)

 diff --git a/grub-core/loader/i386/xen.c b/grub-core/loader/i386/xen.c
 index c4d9689..ff7c553 100644
 --- a/grub-core/loader/i386/xen.c
 +++ b/grub-core/loader/i386/xen.c
 @@ -316,11 +316,23 @@ grub_xen_boot (void)
  xen_inf.virt_base);
  }

 +static void
 +grub_xen_reset (void)
 +{
 +  grub_memset (_start, 0, sizeof (next_start));
 +  xen_module_info_page = NULL;
 +  n_modules = 0;
 +
 +  grub_relocator_unload (relocator);
 +  relocator = NULL;
 +  loaded = 0;
 +}
 +
  static grub_err_t
  grub_xen_unload (void)
  {
 +  grub_xen_reset ();
grub_dl_unref (my_mod);
 -  loaded = 0;
return GRUB_ERR_NONE;
  }

 @@ -403,10 +415,7 @@ grub_cmd_xen (grub_command_t cmd __attribute__ 
 ((unused)),

grub_loader_unset ();

 -  grub_memset (_start, 0, sizeof (next_start));
 -
 -  xen_module_info_page = NULL;
 -  n_modules = 0;
 +  grub_xen_reset ();

grub_create_loader_cmdline (argc - 1, argv + 1,
  (char *) next_start.cmd_line,
 @@ -503,16 +512,17 @@ grub_cmd_xen (grub_command_t cmd __attribute__ 
 ((unused)),
goto fail;

  fail:
 +  err = grub_errno;
>>>
>>> I do not think this is needed.
>>
>> grub_elf_close() and others might clobber grub_errno.
> 
> OK, so, please say it in comment. It is not obvious.

Okay.

if (elf)
  grub_elf_close (elf);
else if (file)
  grub_file_close (file);

 -  if (grub_errno != GRUB_ERR_NONE)
 -loaded = 0;
 +  if (err != GRUB_ERR_NONE)
 +grub_xen_reset ();

 -  return grub_errno;
 +  return err;
  }

  static grub_err_t
 @@ -552,7 +562,7 @@ grub_cmd_initrd (grub_command_t cmd __attribute__ 
 ((unused)),
  {
err = grub_relocator_alloc_chunk_addr (relocator, , max_addr, 
 size);
if (err)
 -  return err;
 +  goto fail;
>>>
>>> It looks that this change should not be part of this patch.
>>
>> Why not? It's correcting a memory leak in case of failure. Like the
>> other cases below, too. That's the purpose of this patch, after all.
> 
> OK but you are referring to grub_relocator_unload() in commit message
> and below you are trying to fix different memory leak in the same patch.
> So, I think everything below should be separate patch.

Okay.


Juergen


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

Re: [Xen-devel] [PATCH v3 09/10] xen: modify page table construction

[Juergen Gross]

On 18/02/16 17:40, Daniel Kiper wrote:
> On Wed, Feb 17, 2016 at 06:19:36PM +0100, Juergen Gross wrote:
>> Modify the page table construction to allow multiple virtual regions
>> to be mapped. This is done as preparation for removing the p2m list
>> from the initial kernel mapping in order to support huge pv domains.
>>
>> This allows a cleaner approach for mapping the relocator page by
>> using this capability.
>>
>> The interface to the assembler level of the relocator has to be changed
>> in order to be able to process multiple page table areas.
>>
>> Signed-off-by: Juergen Gross 
>> ---
>> V3: use constants instead of numbers as requested by Daniel Kiper
>> add lots of comments to assembly code as requested by Daniel Kiper

...

>>  1:
>> +movq0(%r8), %r12/* Get start pfn of the current area */
>> +movqGRUB_TARGET_SIZEOF_LONG(%r8), %rcx  /* Get # of pg tables */
> 
> Use %r9 here and...
> 
>> +testq   %rcx, %rcx  /* 0 -> last area reached */
>> +jz  3f
>> +2:
>>  movq%r12, %rdi
>> -movq%rsi, %rbx
>> -movq0(%rsi), %rsi
>> -shlq$12,  %rsi
>> -orq $5, %rsi
>> -movq$2, %rdx
>> -movq%rcx, %r9
>> +shlq$PAGE_SHIFT, %rdi   /* virtual address (1:1 mapping) */
>> +movq(%rbx, %r12, 8), %rsi   /* mfn */
>> +shlq$PAGE_SHIFT,  %rsi
>> +orq $(GRUB_PAGE_PRESENT | GRUB_PAGE_USER), %rsi /* Build pte */
>> +movq$UVMF_INVLPG, %rdx
>> +movq%rcx, %r9   /* %rcx clobbered by hypercall */
> 
> ... you can avoid this...
> 
>>  movq$__HYPERVISOR_update_va_mapping, %rax
>>  syscall
>>
>>  movq%r9, %rcx
> 
> and this...
> 
>> -addq$8, %rbx
>> -addq$4096, %r12
>> -movq%rbx, %rsi
>> +incq%r12/* next pfn */
>>
>> -loop 1b
>> +loop 2b
>>

This would require to open code the loop statement here with %r9 as
count register.

...

>> diff --git a/grub-core/lib/xen/relocator.c b/grub-core/lib/xen/relocator.c
>> index 8f427d3..250fbd4 100644
>> --- a/grub-core/lib/xen/relocator.c
>> +++ b/grub-core/lib/xen/relocator.c
>> @@ -36,15 +36,18 @@ extern grub_uint8_t grub_relocator_xen_remap_end;
>>  extern grub_xen_reg_t grub_relocator_xen_stack;
>>  extern grub_xen_reg_t grub_relocator_xen_start_info;
>>  extern grub_xen_reg_t grub_relocator_xen_entry_point;
>> -extern grub_xen_reg_t grub_relocator_xen_paging_start;
>> -extern grub_xen_reg_t grub_relocator_xen_paging_size;
>>  extern grub_xen_reg_t grub_relocator_xen_remapper_virt;
>>  extern grub_xen_reg_t grub_relocator_xen_remapper_virt2;
>>  extern grub_xen_reg_t grub_relocator_xen_remapper_map;
>>  extern grub_xen_reg_t grub_relocator_xen_mfn_list;
>> +extern struct {
>> +  grub_xen_reg_t start;
>> +  grub_xen_reg_t size;
>> +} grub_relocator_xen_paging_areas[XEN_MAX_MAPPINGS];
> 
> Should not you add GRUB_PACKED here? Could you define type
> earlier and use it here?

Why packed? Aah, I think I should align the variable in the assembly
source instead.

Regarding type: sure I could.


Juergen

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

Re: [Xen-devel] [PATCH v3 02/10] xen: reduce number of global variables in xen loader

[Juergen Gross]

On 18/02/16 18:00, Lennart Sorensen wrote:
> On Thu, Feb 18, 2016 at 11:34:49AM +0100, Juergen Gross wrote:
>> On 18/02/16 11:22, Daniel Kiper wrote:
>>> On Wed, Feb 17, 2016 at 06:19:29PM +0100, Juergen Gross wrote:
 The loader for xen paravirtualized environment is using lots of global
 variables. Reduce the number by making them either local or by putting
 them into a single state structure.

 Signed-off-by: Juergen Gross 
>>>
>>> Just two nitpicks but in general...
>>>
>>> Reviewed-by: Daniel Kiper 
>>>
 ---
  grub-core/loader/i386/xen.c | 259 
 +++-
  1 file changed, 138 insertions(+), 121 deletions(-)

 diff --git a/grub-core/loader/i386/xen.c b/grub-core/loader/i386/xen.c
 index ff7c553..d5fe168 100644
 --- a/grub-core/loader/i386/xen.c
 +++ b/grub-core/loader/i386/xen.c
 @@ -42,16 +42,20 @@

  GRUB_MOD_LICENSE ("GPLv3+");

 -static struct grub_relocator *relocator = NULL;
 -static grub_uint64_t max_addr;
 +struct xen_loader_state {
 +  struct grub_relocator *relocator;
 +  struct start_info next_start;
 +  struct grub_xen_file_info xen_inf;
 +  grub_uint64_t max_addr;
 +  struct xen_multiboot_mod_list *module_info_page;
 +  grub_uint64_t modules_target_start;
 +  grub_size_t n_modules;
 +  int loaded;
 +};
 +
 +static struct xen_loader_state xen_state;
 +
  static grub_dl_t my_mod;
 -static int loaded = 0;
 -static struct start_info next_start;
 -static void *kern_chunk_src;
 -static struct grub_xen_file_info xen_inf;
 -static struct xen_multiboot_mod_list *xen_module_info_page;
 -static grub_uint64_t modules_target_start;
 -static grub_size_t n_modules;

  #define PAGE_SIZE 4096
  #define MAX_MODULES (PAGE_SIZE / sizeof (struct xen_multiboot_mod_list))
 @@ -225,50 +229,55 @@ grub_xen_boot (void)
if (grub_xen_n_allocated_shared_pages)
  return grub_error (GRUB_ERR_BUG, "active grants");

 -  state.mfn_list = max_addr;
 -  next_start.mfn_list = max_addr + xen_inf.virt_base;
 -  next_start.first_p2m_pfn = max_addr >> PAGE_SHIFT;  /* Is this 
 right? */
 +  state.mfn_list = xen_state.max_addr;
 +  xen_state.next_start.mfn_list =
 +xen_state.max_addr + xen_state.xen_inf.virt_base;
 +  xen_state.next_start.first_p2m_pfn = xen_state.max_addr >> PAGE_SHIFT;
pgtsize = sizeof (grub_xen_mfn_t) * grub_xen_start_page_addr->nr_pages;
 -  err = grub_relocator_alloc_chunk_addr (relocator, , max_addr, 
 pgtsize);
 -  next_start.nr_p2m_frames = (pgtsize + PAGE_SIZE - 1) >> PAGE_SHIFT;
 +  err = grub_relocator_alloc_chunk_addr (xen_state.relocator, ,
 +   xen_state.max_addr, pgtsize);
 +  xen_state.next_start.nr_p2m_frames = (pgtsize + PAGE_SIZE - 1) >> 
 PAGE_SHIFT;
if (err)
  return err;
new_mfn_list = get_virtual_current_address (ch);
grub_memcpy (new_mfn_list,
   (void *) grub_xen_start_page_addr->mfn_list, pgtsize);
 -  max_addr = ALIGN_UP (max_addr + pgtsize, PAGE_SIZE);
 +  xen_state.max_addr = ALIGN_UP (xen_state.max_addr + pgtsize, PAGE_SIZE);

 -  err = grub_relocator_alloc_chunk_addr (relocator, ,
 -   max_addr, sizeof (next_start));
 +  err = grub_relocator_alloc_chunk_addr (xen_state.relocator, ,
 +   xen_state.max_addr,
 +   sizeof (xen_state.next_start));
if (err)
  return err;
 -  state.start_info = max_addr + xen_inf.virt_base;
 +  state.start_info = xen_state.max_addr + xen_state.xen_inf.virt_base;
nst = get_virtual_current_address (ch);
 -  max_addr = ALIGN_UP (max_addr + sizeof (next_start), PAGE_SIZE);
 +  xen_state.max_addr =
 +ALIGN_UP (xen_state.max_addr + sizeof (xen_state.next_start), 
 PAGE_SIZE);

 -  next_start.nr_pages = grub_xen_start_page_addr->nr_pages;
 -  grub_memcpy (next_start.magic, grub_xen_start_page_addr->magic,
 - sizeof (next_start.magic));
 -  next_start.store_mfn = grub_xen_start_page_addr->store_mfn;
 -  next_start.store_evtchn = grub_xen_start_page_addr->store_evtchn;
 -  next_start.console.domU = grub_xen_start_page_addr->console.domU;
 -  next_start.shared_info = grub_xen_start_page_addr->shared_info;
 +  xen_state.next_start.nr_pages = grub_xen_start_page_addr->nr_pages;
 +  grub_memcpy (xen_state.next_start.magic, 
 grub_xen_start_page_addr->magic,
 + sizeof (xen_state.next_start.magic));
 +  xen_state.next_start.store_mfn = grub_xen_start_page_addr->store_mfn;
 +  xen_state.next_start.store_evtchn = 
 grub_xen_start_page_addr->store_evtchn;
 +  xen_state.next_start.console.domU = 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm5 xen-build fail REGR. vs. 81632
 test-armhf-armhf-libvirt-raw  9 debian-di-install fail REGR. vs. 81632
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat fail REGR. vs. 81632

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail REGR. vs. 81632
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail REGR. vs. 81632
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 81632
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 81632
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 81632

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 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-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 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-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  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-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-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  046e5d0218a0600f9a21fd3b5a5ccfbaaf4357b6
baseline version:
 xen  d77bac5c064ffb9dbb5b89b55b89853f1b784ebf

Last test of basis81632  2016-02-09 15:11:54 Z9 days
Testing same since83001  2016-02-18 14:40:57 Z0 days1 attempts


People who touched revisions under test:
  Alan.Robinson 
  Andrew Cooper 
  Anthony PERARD 
  Boris Ostrovsky 
  Dirk Behme 
  George Dunlap 
  Ian Campbell 
  Jan Beulich 
  Juergen Gross 
  Kevin Tian 

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

[Xen-devel] [PATCH v5 1/2] xenoprof: fix up ability to disable it

[Doug Goldstein]

Allow Xenoprof to be fully disabled when toggling the option off.

Signed-off-by: Doug Goldstein 
---
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 

change since v4:
- as much as possible disabled by CONFIG_XENOPROF as suggested by Andrew Cooper
change since v3:
- drop (void)var; from static inlines
- fix typo that broke build (must have forgotten to do XEN_CONFIG_EXPERT=y make
change since v2:
- move all functions in xenoprof.h inside CONFIG_XENOPROF as suggested by
  Andrew Cooper
change since v1:
- switch to #define empty 'functions' as suggested by Andrew Cooper
---
 xen/arch/x86/Makefile  |  2 +-
 xen/arch/x86/Rules.mk  |  2 ++
 xen/arch/x86/x86_64/compat/entry.S |  4 
 xen/arch/x86/x86_64/entry.S|  4 
 xen/include/asm-x86/config.h   |  1 -
 xen/include/asm-x86/xenoprof.h | 21 +
 xen/include/xen/xenoprof.h | 27 +--
 7 files changed, 53 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 8e6e901..434d985 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -3,7 +3,7 @@ subdir-y += cpu
 subdir-y += genapic
 subdir-y += hvm
 subdir-y += mm
-subdir-y += oprofile
+subdir-$(xenoprof) += oprofile
 subdir-y += x86_64
 
 obj-bin-y += alternative.init.o
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index a1cdae0..94e4efd 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -10,6 +10,8 @@ CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-generic
 CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-default
 CFLAGS += '-D__OBJECT_LABEL__=$(subst /,$$,$(subst -,_,$(subst 
$(BASEDIR)/,,$(CURDIR))/$@))'
 
+CFLAGS-$(xenoprof) += -DCONFIG_XENOPROF
+
 # Prevent floating-point variables from creeping into Xen.
 CFLAGS += -msoft-float
 
diff --git a/xen/arch/x86/x86_64/compat/entry.S 
b/xen/arch/x86/x86_64/compat/entry.S
index 8cb8bca..927439d 100644
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -345,6 +345,10 @@ compat_crash_page_fault:
 #define compat_kexec_op do_ni_hypercall
 #endif
 
+#ifndef CONFIG_XENOPROF
+#define compat_xenoprof_op do_ni_hypercall
+#endif
+
 ENTRY(compat_hypercall_table)
 .quad compat_set_trap_table /*  0 */
 .quad do_mmu_update
diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
index fc81a93..e0f5c83 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -682,6 +682,10 @@ ENTRY(exception_table)
 #define do_kexec_op do_ni_hypercall
 #endif
 
+#ifndef CONFIG_XENOPROF
+#define do_xenoprof_op do_ni_hypercall
+#endif
+
 ENTRY(hypercall_table)
 .quad do_set_trap_table /*  0 */
 .quad do_mmu_update
diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
index d97877d..a45d3ee 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -47,7 +47,6 @@
 #define CONFIG_VGA 1
 #define CONFIG_VIDEO 1
 
-#define CONFIG_XENOPROF 1
 #define CONFIG_WATCHDOG 1
 
 #define CONFIG_MULTIBOOT 1
diff --git a/xen/include/asm-x86/xenoprof.h b/xen/include/asm-x86/xenoprof.h
index b006ddc..dca4223 100644
--- a/xen/include/asm-x86/xenoprof.h
+++ b/xen/include/asm-x86/xenoprof.h
@@ -22,6 +22,8 @@
 #ifndef __ASM_X86_XENOPROF_H__
 #define __ASM_X86_XENOPROF_H__
 
+#ifdef CONFIG_XENOPROF
+
 int nmi_reserve_counters(void);
 int nmi_setup_events(void);
 int nmi_enable_virq(void);
@@ -67,10 +69,29 @@ void xenoprof_backtrace(struct vcpu *, const struct 
cpu_user_regs *,
  "xenoprof/x86 with autotranslated mode enabled"\
  "isn't supported yet\n");  \
 } while (0)
+
 int passive_domain_do_rdmsr(unsigned int msr, uint64_t *msr_content);
 int passive_domain_do_wrmsr(unsigned int msr, uint64_t msr_content);
 void passive_domain_destroy(struct vcpu *v);
 
+#else
+
+static inline int passive_domain_do_rdmsr(unsigned int msr,
+  uint64_t *msr_content)
+{
+return 0;
+}
+
+static inline int passive_domain_do_wrmsr(unsigned int msr,
+  uint64_t msr_content)
+{
+return 0;
+}
+
+static inline void passive_domain_destroy(struct vcpu *v) {}
+
+#endif /* CONFIG_XENOPROF */
+
 #endif /* __ASM_X86_XENOPROF_H__ */
 
 /*
diff --git a/xen/include/xen/xenoprof.h b/xen/include/xen/xenoprof.h
index 9b9ef56..8f045ab 100644
--- a/xen/include/xen/xenoprof.h
+++ b/xen/include/xen/xenoprof.h
@@ -14,6 +14,12 @@
 #include 
 #include 
 
+#define PMU_OWNER_NONE  0
+#define PMU_OWNER_XENOPROF  1
+#define PMU_OWNER_HVM   2
+
+#ifdef CONFIG_XENOPROF
+
 #define XENOPROF_DOMAIN_IGNORED0
 #define XENOPROF_DOMAIN_ACTIVE 1
 #define XENOPROF_DOMAIN_PASSIVE2
@@ -64,19 +70,28 @@ struct xenoprof {
 #endif
 
 struct domain;
+
+int acquire_pmu_ownership(int pmu_ownership);
+void 

[Xen-devel] [PATCH v5 2/2] build: convert xenoprof to Kconfig

[Doug Goldstein]

Convert the xenoprof x86 build time option to Kconfig.

Signed-off-by: Doug Goldstein 
Reviewed-by: Andrew Cooper 
Acked-by: Jan Beulich 
---
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 

change since v4:
- none
change since v3:
- move xenoprof entry to the main sources list as suggested by Jan Beulich
- combine 'default' and 'bool' into 'def_bool' as suggested by Jan Beulich
change since v2:
- require EXPERT for XENOPROF as suggested by Jan Beulich
change since v1:
- fix name of Kconfig entry as suggested by Andrew Cooper
---
 xen/arch/x86/Makefile |  2 +-
 xen/arch/x86/Rules.mk |  3 ---
 xen/common/Kconfig| 13 +
 xen/common/Makefile   |  2 +-
 4 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 434d985..1bcb08b 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -3,7 +3,7 @@ subdir-y += cpu
 subdir-y += genapic
 subdir-y += hvm
 subdir-y += mm
-subdir-$(xenoprof) += oprofile
+subdir-$(CONFIG_XENOPROF) += oprofile
 subdir-y += x86_64
 
 obj-bin-y += alternative.init.o
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 94e4efd..14519e3 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -3,15 +3,12 @@
 
 HAS_NUMA := y
 HAS_CORE_PARKING := y
-xenoprof := y
 
 CFLAGS += -I$(BASEDIR)/include 
 CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-generic
 CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-default
 CFLAGS += '-D__OBJECT_LABEL__=$(subst /,$$,$(subst -,_,$(subst 
$(BASEDIR)/,,$(CURDIR))/$@))'
 
-CFLAGS-$(xenoprof) += -DCONFIG_XENOPROF
-
 # Prevent floating-point variables from creeping into Xen.
 CFLAGS += -msoft-float
 
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 6f404b4..49de790 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -84,6 +84,19 @@ config LATE_HWDOM
 
  If unsure, say N.
 
+# Adds support for Xenoprof
+config XENOPROF
+   def_bool y
+   prompt "Xen Oprofile Support" if EXPERT = "y"
+   depends on X86
+   ---help---
+ Xen OProfile (Xenoprof) is a system-wide profiler for Xen virtual
+ machine environments, capable of profiling the Xen virtual machine
+ monitor, multiple Linux guest operating systems, and applications
+ running on them.
+
+ If unsure, say Y.
+
 # Enable/Disable XSM support
 config XSM
bool "Xen Security Modules support"
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 0d76efe..57f4ed7 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -57,13 +57,13 @@ obj-y += vm_event.o
 obj-y += vmap.o
 obj-y += vsprintf.o
 obj-y += wait.o
+obj-$(CONFIG_XENOPROF) += xenoprof.o
 obj-y += xmalloc_tlsf.o
 
 obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma unlzo 
unlz4 earlycpio,$(n).init.o)
 
 obj-$(perfc)   += perfc.o
 obj-$(crash_debug) += gdbstub.o
-obj-$(xenoprof)+= xenoprof.o
 
 obj-$(CONFIG_COMPAT) += $(addprefix compat/,domain.o kernel.o memory.o 
multicall.o tmem_xen.o xlat.o)
 
-- 
2.4.10


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

[Xen-devel] [PATCH v2 1/4] tools/configure: only require bcc/ld86/as86 when needed

[Doug Goldstein]

bcc/ld86/as86 are only necessary when we build rombios and not always so
failing the build when they aren't available should not happen if the
user isn't building rombios.

Signed-off-by: Doug Goldstein 
---
CC: Ian Jackson 
CC: Stefano Stabellini 
CC: Ian Campbell 
CC: Wei Liu 

change since v1:
- don't screw up the white space
---
 README |  3 ++-
 tools/configure.ac | 11 +++
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/README b/README
index dd36ec8..7cde45f 100644
--- a/README
+++ b/README
@@ -58,7 +58,6 @@ provided by your OS distributor:
 * iproute package (/sbin/ip)
 * GNU bison and GNU flex
 * GNU gettext
-* 16-bit x86 assembler, loader and compiler (dev86 rpm or bin86 & bcc debs)
 * ACPI ASL compiler (iasl)
 * Libc multiarch package (e.g. libc6-dev-i386 / glibc-devel.i686).
   Required when building on a 64-bit platform to build
@@ -78,6 +77,8 @@ disabled at compile time:
   libnl-3-dev, etc).  Required if network buffering is desired
   when using Remus with libxl.  See docs/README.remus for detailed
   information.
+* 16-bit x86 assembler, loader and compiler for qemu-traditional / rombios
+  (dev86 rpm or bin86 & bcc debs)
 
 Second, you need to acquire a suitable kernel for use in domain 0. If
 possible you should use a kernel provided by your OS distributor. If
diff --git a/tools/configure.ac b/tools/configure.ac
index 6c70040..5b5dda4 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -164,7 +164,13 @@ AC_ARG_ENABLE([rombios],
 ])
 ])
 AS_IF([test "x$enable_rombios" = "xyes"], [
-AC_DEFINE([HAVE_ROMBIOS], [1], [ROMBIOS enabled])
+dnl as86, ld86, and bcc are only required when building rombios. They
+dnl are only needed when the host system is x86 but that check is done
+dnl for us above when checking if we should build with qemu-traditional.
+AX_PATH_PROG_OR_FAIL([AS86], [as86])
+AX_PATH_PROG_OR_FAIL([LD86], [ld86])
+AX_PATH_PROG_OR_FAIL([BCC], [bcc])
+AC_DEFINE([HAVE_ROMBIOS], [1], [ROMBIOS enabled])
 rombios=y],[
 rombios=n
 ])
@@ -320,9 +326,6 @@ dnl going to run, not the platform on which we are building 
(known as
 dnl "build" in gnu speak).
 case "$host_cpu" in
 i[[3456]]86|x86_64)
-AX_PATH_PROG_OR_FAIL([AS86], [as86])
-AX_PATH_PROG_OR_FAIL([LD86], [ld86])
-AX_PATH_PROG_OR_FAIL([BCC], [bcc])
 AX_PATH_PROG_OR_FAIL([IASL], [iasl])
 ;;
 esac
-- 
2.4.10


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

Re: [Xen-devel] [PATCH] hvmloader: Use xen/errno.h rather than the host systems errno.h

[Konrad Rzeszutek Wilk]

On Thu, Feb 18, 2016 at 10:10:09PM +, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper 

Reviewed-by: Konrad Rzeszutek Wilk 
> ---
> CC: Jan Beulich 
> CC: Ian Campbell 
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Doug Goldstein 
> ---
>  tools/firmware/hvmloader/xenbus.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/firmware/hvmloader/xenbus.c 
> b/tools/firmware/hvmloader/xenbus.c
> index d0ed993..947d865 100644
> --- a/tools/firmware/hvmloader/xenbus.c
> +++ b/tools/firmware/hvmloader/xenbus.c
> @@ -27,7 +27,7 @@
>  
>  #include "util.h"
>  #include "hypercall.h"
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> -- 
> 2.1.4
> 
> 
> ___
> 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 v2 2/4] m4/python: fix typo in LDFLAGS variable name

[Doug Goldstein]

Reported-by: Jonathan Creekmore 
Signed-off-by: Doug Goldstein 
---
CC: Ian Jackson 
CC: Stefano Stabellini 
CC: Ian Campbell 
CC: Wei Liu 

change since v1:
- don't screw up the white space
---
 m4/python_devel.m4 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/m4/python_devel.m4 b/m4/python_devel.m4
index 659e7d4..deff19e 100644
--- a/m4/python_devel.m4
+++ b/m4/python_devel.m4
@@ -32,5 +32,5 @@ AC_CHECK_HEADER([Python.h], [],
 AC_CHECK_LIB(python$ac_python_version, PyArg_ParseTuple, [],
 [AC_MSG_ERROR([Unable to find a suitable python development library])])
 CPPFLAGS=$ac_previous_cppflags
-LDLFAGS=$ac_previous_ldflags
+LDFLAGS=$ac_previous_ldflags
 ])
-- 
2.4.10


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

[Xen-devel] [PATCH v2 4/4] configure: rerun autoconf

[Doug Goldstein]

Signed-off-by: Doug Goldstein 
---
CC: Ian Jackson 
CC: Stefano Stabellini 
CC: Ian Campbell 
CC: Wei Liu 

Before these changes I was seeing the following errors:

https://travis-ci.org/cardoe/xen/jobs/110174912

https://travis-ci.org/cardoe/xen/jobs/110196932#L1435 (you have to
expand the 'cat tools/config.log' and go down to line 1435).

The goal here is to enabling building the toolstack in Travis. This
series gets us to this:
https://travis-ci.org/cardoe/xen/jobs/110210149#L3536

But Andrew Cooper has provided a patch to solve that issue in
'hvmloader: Use xen/errno.h rather than the host systems errno.h'

change since v1:
- don't screw up the white space
---
 tools/configure | 295 
 1 file changed, 148 insertions(+), 147 deletions(-)

diff --git a/tools/configure b/tools/configure
index cd41b26..0244591 100755
--- a/tools/configure
+++ b/tools/configure
@@ -682,9 +682,6 @@ INSTALL_PROGRAM
 SET_MAKE
 AWK
 IASL
-BCC
-LD86
-AS86
 XGETTEXT
 BASH
 XML
@@ -704,6 +701,9 @@ qemu_xen_systemd
 qemu_xen_path
 qemu_xen
 rombios
+BCC
+LD86
+AS86
 qemu_traditional
 blktap2
 LINUX_BACKEND_MODULES
@@ -3348,7 +3348,7 @@ else
 We can't simply define LARGE_OFF_T to be 9223372036854775807,
 since some C++ compilers masquerading as C compilers
 incorrectly reject 9223372036854775807.  */
-#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31))
+#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
   int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
   && LARGE_OFF_T % 2147483647 == 1)
  ? 1 : -1];
@@ -3394,7 +3394,7 @@ else
 We can't simply define LARGE_OFF_T to be 9223372036854775807,
 since some C++ compilers masquerading as C compilers
 incorrectly reject 9223372036854775807.  */
-#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31))
+#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
   int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
   && LARGE_OFF_T % 2147483647 == 1)
  ? 1 : -1];
@@ -3418,7 +3418,7 @@ rm -f core conftest.err conftest.$ac_objext 
conftest.$ac_ext
 We can't simply define LARGE_OFF_T to be 9223372036854775807,
 since some C++ compilers masquerading as C compilers
 incorrectly reject 9223372036854775807.  */
-#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31))
+#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
   int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
   && LARGE_OFF_T % 2147483647 == 1)
  ? 1 : -1];
@@ -3463,7 +3463,7 @@ else
 We can't simply define LARGE_OFF_T to be 9223372036854775807,
 since some C++ compilers masquerading as C compilers
 incorrectly reject 9223372036854775807.  */
-#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31))
+#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
   int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
   && LARGE_OFF_T % 2147483647 == 1)
  ? 1 : -1];
@@ -3487,7 +3487,7 @@ rm -f core conftest.err conftest.$ac_objext 
conftest.$ac_ext
 We can't simply define LARGE_OFF_T to be 9223372036854775807,
 since some C++ compilers masquerading as C compilers
 incorrectly reject 9223372036854775807.  */
-#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31))
+#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
   int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
   && LARGE_OFF_T % 2147483647 == 1)
  ? 1 : -1];
@@ -4242,6 +4242,141 @@ fi
 
 if test "x$enable_rombios" = "xyes"; then :
 
+# Extract the first word of "as86", so it can be a program 
name with args.
+set dummy as86; ac_word=$2
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
+$as_echo_n "checking for $ac_word... " >&6; }
+if ${ac_cv_path_AS86+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  case $AS86 in
+  [\\/]* | ?:[\\/]*)
+  ac_cv_path_AS86="$AS86" # Let the user override the test with a path.
+  ;;
+  *)
+  as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+for ac_exec_ext in '' $ac_executable_extensions; do
+  if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+ac_cv_path_AS86="$as_dir/$ac_word$ac_exec_ext"
+$as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" 
>&5
+break 2
+  fi
+done
+  done
+IFS=$as_save_IFS
+
+  test -z "$ac_cv_path_AS86" && ac_cv_path_AS86="no"
+  ;;
+esac
+fi
+AS86=$ac_cv_path_AS86
+if test -n "$AS86"; then
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $AS86" >&5
+$as_echo 

[Xen-devel] [PATCH v2 3/4] m4/python: fix checks for Python library support

[Doug Goldstein]

AC_CHECK_LIB() was running gcc -Llib -lm -lutils conftest.c which on
platforms that do as needed operations by default will result in
underlinking. Instead AC_CHECK_LIB() suggests supplying the extra
libraries necessary in a 5th argument.

Signed-off-by: Doug Goldstein 
---
CC: Ian Jackson 
CC: Stefano Stabellini 
CC: Ian Campbell 
CC: Wei Liu 

change since v1:
- don't screw up the white space
---
 m4/python_devel.m4 | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/m4/python_devel.m4 b/m4/python_devel.m4
index deff19e..05ea4ef 100644
--- a/m4/python_devel.m4
+++ b/m4/python_devel.m4
@@ -10,9 +10,9 @@ AS_IF([test x"$pyconfig" = x"no"], [
 print "-I" + distutils.sysconfig.get_config_var("INCLUDEPY")'`"
 CPPFLAGS="$CPPFLAGS `$PYTHON -c 'import distutils.sysconfig; \
 print distutils.sysconfig.get_config_var("CFLAGS")'`"
-LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
+PYTHON_LIBS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
 print distutils.sysconfig.get_config_var("LIBS")'`"
-LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
+PYTHON_LIBS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
 print distutils.sysconfig.get_config_var("SYSLIBS")'`"
 LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
 print "-L" + distutils.sysconfig.get_python_lib(plat_specific=1,\
@@ -25,12 +25,14 @@ AS_IF([test x"$pyconfig" = x"no"], [
 dnl If python-config is found use it
 CPPFLAGS="$CFLAGS `$PYTHON-config --cflags`"
 LDFLAGS="$LDFLAGS `$PYTHON-config --ldflags`"
+PYTHON_LIBS="$LIBS `$PYTHON-config --libs`"
 ])
 
 AC_CHECK_HEADER([Python.h], [],
 [AC_MSG_ERROR([Unable to find Python development headers])],)
 AC_CHECK_LIB(python$ac_python_version, PyArg_ParseTuple, [],
-[AC_MSG_ERROR([Unable to find a suitable python development library])])
+[AC_MSG_ERROR([Unable to find a suitable python development library])],
+[$PYTHON_LIBS])
 CPPFLAGS=$ac_previous_cppflags
 LDFLAGS=$ac_previous_ldflags
 ])
-- 
2.4.10


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

Re: [Xen-devel] [PATCH] hvmloader: Use xen/errno.h rather than the host systems errno.h

[Doug Goldstein]

On 2/18/16 4:10 PM, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Ian Campbell 
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Doug Goldstein 
> ---

Reviewed-by: Doug Goldstein 

https://travis-ci.org/cardoe/xen/jobs/110249618 shows the patch in
action getting past the previous problem.

-- 
Doug Goldstein



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

[Xen-devel] [PATCH v12 2/2] Add a command line parameter for VT-d posted-interrupts

[Feng Wu]

Enable VT-d Posted-Interrupts and add a command line
parameter for it.

CC: Jan Beulich 
Signed-off-by: Feng Wu 
Reviewed-by: Kevin Tian 
Acked-by: Jan Beulich 
---
 docs/misc/xen-command-line.markdown | 9 -
 xen/drivers/passthrough/iommu.c | 3 +++
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 467dc8f..ea1d60d 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -868,7 +868,7 @@ debug hypervisor only).
 > Default: `new` unless directed-EOI is supported
 
 ### iommu
-> `= List of [  | force | required | intremap | qinval | snoop | 
sharept | dom0-passthrough | dom0-strict | amd-iommu-perdev-intremap | 
workaround_bios_bug | igfx | verbose | debug ]`
+> `= List of [  | force | required | intremap | intpost | qinval | 
snoop | sharept | dom0-passthrough | dom0-strict | amd-iommu-perdev-intremap | 
workaround_bios_bug | igfx | verbose | debug ]`
 
 > Sub-options:
 
@@ -895,6 +895,13 @@ debug hypervisor only).
 >> Control the use of interrupt remapping (DMA remapping will always be enabled
 >> if IOMMU functionality is enabled).
 
+> `intpost`
+
+> Default: `false`
+
+>> Control the use of interrupt posting, which depends on the availability of
+>> interrupt remapping.
+
 > `qinval` (VT-d)
 
 > Default: `true`
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 0b2abf4..50d74a5 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -32,6 +32,7 @@ static void iommu_dump_p2m_table(unsigned char key);
  *   off|no|false|disable   Disable IOMMU (default)
  *   force|required Don't boot unless IOMMU is enabled
  *   no-intremapDisable interrupt remapping
+ *   no-intpost Disable VT-d Interrupt posting
  *   verboseBe more verbose
  *   debug  Enable debugging messages and checks
  *   workaround_bios_bugWorkaround some bios issue to still enable
@@ -105,6 +106,8 @@ static void __init parse_iommu_param(char *s)
 iommu_qinval = val;
 else if ( !strcmp(s, "intremap") )
 iommu_intremap = val;
+else if ( !strcmp(s, "intpost") )
+iommu_intpost = val;
 else if ( !strcmp(s, "debug") )
 {
 iommu_debug = val;
-- 
2.1.0


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

[Xen-devel] [PATCH v12 0/2] Add VT-d Posted-Interrupts support

[Feng Wu]

VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
With VT-d Posted-Interrupts enabled, external interrupts from
direct-assigned devices can be delivered to guests without VMM
intervention when guest is running in non-root mode.

You can find the VT-d Posted-Interrtups Spec. in the following URL:
http://www.intel.com/content/www/us/en/intelligent-systems/intel-technology/vt-directed-io-spec.html

Feng Wu (2):
  vmx: VT-d posted-interrupt core logic handling
  Add a command line parameter for VT-d posted-interrupts

 docs/misc/xen-command-line.markdown |   9 +-
 xen/arch/x86/hvm/vmx/vmcs.c |   2 +
 xen/arch/x86/hvm/vmx/vmx.c  | 185 
 xen/common/schedule.c   |   4 +
 xen/drivers/passthrough/iommu.c |   3 +
 xen/drivers/passthrough/vtd/iommu.c |   7 ++
 xen/include/asm-arm/domain.h|   2 +
 xen/include/asm-x86/hvm/hvm.h   |   5 +
 xen/include/asm-x86/hvm/vmx/vmcs.h  |  67 +
 xen/include/asm-x86/hvm/vmx/vmx.h   |   5 +
 10 files changed, 288 insertions(+), 1 deletion(-)

-- 
2.1.0


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

Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support for Xen

[Konrad Rzeszutek Wilk]

> > > QEMU would always use MFN above guest normal ram and I/O holes for
> > > vNVDIMM. It would attempt to search in that space for a contiguous range
> > > that is large enough for that that vNVDIMM devices. Is guest able to
> > > punch holes in such GFN space?
> > 
> > See XENMAPSPACE_* and their uses.
> > 
> 
> I think we can add following restrictions to avoid uses of XENMAPSPACE_*
> punching holes in GFNs of vNVDIMM:
> 
> (1) For XENMAPSPACE_shared_info and _grant_table, never map idx in them
> to GFNs occupied by vNVDIMM.

OK, that sounds correct.
> 
> (2) For XENMAPSPACE_gmfn, _gmfn_range and _gmfn_foreign,
>(a) never map idx in them to GFNs occupied by vNVDIMM, and
>(b) never map idx corresponding to GFNs occupied by vNVDIMM

Would that mean that guest xen-blkback or xen-netback wouldn't
be able to fetch data from the GFNs? As in, what if the HVM guest
that has the NVDIMM also serves as a device domain - that is it
has xen-blkback running to service other guests?

> 
> 
> Haozhong

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

[Xen-devel] [PATCH v12 1/2] vmx: VT-d posted-interrupt core logic handling

[Feng Wu]

This is the core logic handling for VT-d posted-interrupts. Basically it
deals with how and when to update posted-interrupts during the following
scenarios:
- vCPU is preempted
- vCPU is slept
- vCPU is blocked

When vCPU is preempted/slept, we update the posted-interrupts during
scheduling by introducing two new architecutral scheduler hooks:
vmx_pi_switch_from() and vmx_pi_switch_to(). When vCPU is blocked, we
introduce a new architectural hook: arch_vcpu_block() to update
posted-interrupts descriptor.

Besides that, before VM-entry, we will make sure the 'NV' filed is set
to 'posted_intr_vector' and the vCPU is not in any blocking lists, which
is needed when vCPU is running in non-root mode. The reason we do this check
is because we change the posted-interrupts descriptor in vcpu_block(),
however, we don't change it back in vcpu_unblock() or when vcpu_block()
directly returns due to event delivery (in fact, we don't need to do it
in the two places, that is why we do it before VM-Entry).

When we handle the lazy context switch for the following two scenarios:
- Preempted by a tasklet, which uses in an idle context.
- the prev vcpu is in offline and no new available vcpus in run queue.
We don't change the 'SN' bit in posted-interrupt descriptor, this
may incur spurious PI notification events, but since PI notification
event is only sent when 'ON' is clear, and once the PI notificatoin
is sent, ON is set by hardware, hence no more notification events
before 'ON' is clear. Besides that, spurious PI notification events are
going to happen from time to time in Xen hypervisor, such as, when
guests trap to Xen and PI notification event happens, there is
nothing Xen actually needs to do about it, the interrupts will be
delivered to guest atht the next time we do a VMENTRY.

CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Kevin Tian 
CC: George Dunlap 
CC: Dario Faggioli 
Suggested-by: Yang Zhang 
Suggested-by: Dario Faggioli 
Suggested-by: George Dunlap 
Suggested-by: Jan Beulich 
Signed-off-by: Feng Wu 
---
v12:
- Move the ASSERT to the locked region in vmx_vcpu_block()
- Add barrier() before using the local variable in vmx_pi_do_resume()
- Split vmx_pi_hooks_reassign() to two functions:
  * vmx_pi_hooks_assign()
  * vmx_pi_hooks_deassign()
- Add more comments about how PI works during vCPU state transition
- coding style

v11:
- Add ASSERT() in vmx_vcpu_block()
- Add some comments in vmx_pi_switch_from()
- Remove some comments which should have been removed when the
  related code was removed during v9 -> v10
- Rename 'vmx_pi_state_to_normal' to 'vmx_pi_do_resume'
- Coding style
- Make arch_vcpu_block() a macro
- Make 'pi_wakeup_vector' static
- Move hook 'vcpu_block' to 'struct hvm_vcpu'
- Initial hook 'vcpu_block' when assigning the first pci device
  and zap it on removal of the last device
- Save pointer to the block list lock instead of the processor
  id in 'struct arch_vmx_struct'
- Implement the following functions as hooks, so we
  can elimilate lots of checkings and spinlocks in scheduling
  related code path, which is good for performance.
vmx_pi_switch_from
vmx_pi_switch_to
vmx_pi_do_resume

v10:
- Check iommu_intpost first
- Remove pointless checking of has_hvm_container_vcpu(v)
- Rename 'vmx_pi_state_change' to 'vmx_pi_state_to_normal'
- Since vcpu_unblock() doesn't acquire 'pi_blocked_vcpu_lock', we
  don't need use another list to save the vCPUs with 'ON' set, just
  directly call vcpu_unblock(v).

v9:
- Remove arch_vcpu_block_cancel() and arch_vcpu_wake_prepare()
- Add vmx_pi_state_change() and call it before VM Entry

v8:
- Remove the lazy context switch handling for PI state transition
- Change PI state in vcpu_block() and do_poll() when the vCPU
  is going to be blocked

v7:
- Merge [PATCH v6 16/18] vmx: Add some scheduler hooks for VT-d posted 
interrupts
  and "[PATCH v6 14/18] vmx: posted-interrupt handling when vCPU is blocked"
  into this patch, so it is self-contained and more convenient
  for code review.
- Make 'pi_blocked_vcpu' and 'pi_blocked_vcpu_lock' static
- Coding style
- Use per_cpu() instead of this_cpu() in pi_wakeup_interrupt()
- Move ack_APIC_irq() to the beginning of pi_wakeup_interrupt()
- Rename 'pi_ctxt_switch_from' to 'ctxt_switch_prepare'
- Rename 'pi_ctxt_switch_to' to 'ctxt_switch_cancel'
- Use 'has_hvm_container_vcpu' instead of 'is_hvm_vcpu'
- Use 'spin_lock' and 'spin_unlock' when the interrupt has been
  already disabled.
- Rename arch_vcpu_wake_prepare to vmx_vcpu_wake_prepare
- Define vmx_vcpu_wake_prepare in xen/arch/x86/hvm/hvm.c
- Call .pi_ctxt_switch_to() __context_switch() instead of directly
  calling vmx_post_ctx_switch_pi() in vmx_ctxt_switch_to()
- Make 

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

[osstest service owner]

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

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  e1ff823b65ae004e4aa3fe9a94078ef82816dee9
baseline version:
 xen  8dd6d1c099865ee5f5916616a0ca79cd943c46f9

Last test of basis83012  2016-02-18 15:03:15 Z0 days
Testing same since83064  2016-02-18 21:55:51 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Corneliu ZUZU 
  Doug Goldstein 
  Jan Beulich 
  Konrad Rzeszutek Wilk 
  Razvan Cojocaru 

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=e1ff823b65ae004e4aa3fe9a94078ef82816dee9
+ . ./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 
e1ff823b65ae004e4aa3fe9a94078ef82816dee9
+ branch=xen-unstable-smoke
+ revision=e1ff823b65ae004e4aa3fe9a94078ef82816dee9
+ . ./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-coverity
+ '[' xe1ff823b65ae004e4aa3fe9a94078ef82816dee9 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/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 '
  

Re: [Xen-devel] [PATCH] MAINTAINERS: add myself as seabios maintainer

[Dario Faggioli]

On Wed, 2016-02-17 at 16:47 +, Wei Liu wrote:
> On Wed, Feb 17, 2016 at 11:45:58AM -0500, Konrad Rzeszutek Wilk
> wrote:
> > On Wed, Feb 17, 2016 at 09:48:28AM +, Ian Campbell wrote:
> > > 
> > > Acked-by: Ian Campbell 
> > 
> > Acked-by: Konrad Rzeszutek Wilk 
> > 
> > Is there an roadmap of what you want to add in SeaBIOS?
> > 
> 
> No plan to add anything.
> 
Coolest roadmap EVER! :-D :-D :-D

Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



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

Re: [Xen-devel] [PATCH] docs: document handling of metacharacter escape in xl disk format

[Jim Fehlig]

Ian Campbell wrote:
> Signed-off-by: Ian Campbell 
> Cc: Jim Fehlig 
> ---
>  docs/misc/xl-disk-configuration.txt | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/docs/misc/xl-disk-configuration.txt 
> b/docs/misc/xl-disk-configuration.txt
> index 6a2118d..a03ad10 100644
> --- a/docs/misc/xl-disk-configuration.txt
> +++ b/docs/misc/xl-disk-configuration.txt
> @@ -48,6 +48,24 @@ positionally or explicitly).
>  
>  Whitespace may appear before each parameter and will be ignored.
>  
> +Metacharacters in a  may be escaped using a backslash:
> +
> +Escape  HEX Description
> +--  --- ---
> +\a  0x07Bell
> +\b  0x08Backspace
> +\t  0x09Horizontal Tab
> +\n  0x0ANew Line / Line Feed
> +\f  0x0CForm Feed
> +\r  0x0DCarriage Return
> +\v  0x0BVertical Tab
> +\"  0x22A literal double quote
> +\'  0x27A literal single quote
> +\\  0x5CA literal backslash
> +\xXXCharacter XX in hexadecimal
> +\OOOCharacter OOO in octal

Do you know how any of these would be useful in a diskspec? I guess I'm
struggling to understand when a 'Bell' would be needed :-).

Regards,
Jim

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

[Xen-devel] [PATCH 2/4] m4/python: fix typo in LDFLAGS variable name

[Doug Goldstein]

Reported-by: Jonathan Creekmore 
Signed-off-by: Doug Goldstein 
---
CC: Ian Jackson 
CC: Stefano Stabellini 
CC: Ian Campbell 
CC: Wei Liu 
---
 m4/python_devel.m4 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/m4/python_devel.m4 b/m4/python_devel.m4
index 659e7d4..deff19e 100644
--- a/m4/python_devel.m4
+++ b/m4/python_devel.m4
@@ -32,5 +32,5 @@ AC_CHECK_HEADER([Python.h], [],
 AC_CHECK_LIB(python$ac_python_version, PyArg_ParseTuple, [],
 [AC_MSG_ERROR([Unable to find a suitable python development library])])
 CPPFLAGS=$ac_previous_cppflags
-LDLFAGS=$ac_previous_ldflags
+LDFLAGS=$ac_previous_ldflags
 ])
-- 
2.4.10


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

[Xen-devel] [PATCH 1/4] tools/configure: only require bcc/ld86/as86 when needed

[Doug Goldstein]

bcc/ld86/as86 are only necessary when we build rombios and not always so
failing the build when they aren't available should not happen if the
user isn't building rombios.

Signed-off-by: Doug Goldstein 
---
CC: Ian Jackson 
CC: Stefano Stabellini 
CC: Ian Campbell 
CC: Wei Liu 
---
 README |  3 ++-
 tools/configure.ac | 11 +++
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/README b/README
index dd36ec8..e688fb5 100644
--- a/README
+++ b/README
@@ -58,7 +58,6 @@ provided by your OS distributor:
 * iproute package (/sbin/ip)
 * GNU bison and GNU flex
 * GNU gettext
-* 16-bit x86 assembler, loader and compiler (dev86 rpm or bin86 & bcc debs)
 * ACPI ASL compiler (iasl)
 * Libc multiarch package (e.g. libc6-dev-i386 / glibc-devel.i686).
   Required when building on a 64-bit platform to build
@@ -78,6 +77,8 @@ disabled at compile time:
   libnl-3-dev, etc).  Required if network buffering is desired
   when using Remus with libxl.  See docs/README.remus for detailed
   information.
+* 16-bit x86 assembler, loader and compiler for qemu-traditional / rombios
+ (dev86 rpm or bin86 & bcc debs)
 
 Second, you need to acquire a suitable kernel for use in domain 0. If
 possible you should use a kernel provided by your OS distributor. If
diff --git a/tools/configure.ac b/tools/configure.ac
index 6c70040..d384967 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -164,7 +164,13 @@ AC_ARG_ENABLE([rombios],
 ])
 ])
 AS_IF([test "x$enable_rombios" = "xyes"], [
-AC_DEFINE([HAVE_ROMBIOS], [1], [ROMBIOS enabled])
+   dnl as86, ld86, and bcc are only required when building rombios. They
+   dnl are only needed when the host system is x86 but that check is done
+   dnl for us above when checking if we should build with qemu-traditional.
+   AX_PATH_PROG_OR_FAIL([AS86], [as86])
+   AX_PATH_PROG_OR_FAIL([LD86], [ld86])
+   AX_PATH_PROG_OR_FAIL([BCC], [bcc])
+   AC_DEFINE([HAVE_ROMBIOS], [1], [ROMBIOS enabled])
 rombios=y],[
 rombios=n
 ])
@@ -320,9 +326,6 @@ dnl going to run, not the platform on which we are building 
(known as
 dnl "build" in gnu speak).
 case "$host_cpu" in
 i[[3456]]86|x86_64)
-AX_PATH_PROG_OR_FAIL([AS86], [as86])
-AX_PATH_PROG_OR_FAIL([LD86], [ld86])
-AX_PATH_PROG_OR_FAIL([BCC], [bcc])
 AX_PATH_PROG_OR_FAIL([IASL], [iasl])
 ;;
 esac
-- 
2.4.10


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

[Xen-devel] [PATCH] hvmloader: Use xen/errno.h rather than the host systems errno.h

[Andrew Cooper]

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Ian Campbell 
CC: Ian Jackson 
CC: Wei Liu 
CC: Doug Goldstein 
---
 tools/firmware/hvmloader/xenbus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/firmware/hvmloader/xenbus.c 
b/tools/firmware/hvmloader/xenbus.c
index d0ed993..947d865 100644
--- a/tools/firmware/hvmloader/xenbus.c
+++ b/tools/firmware/hvmloader/xenbus.c
@@ -27,7 +27,7 @@
 
 #include "util.h"
 #include "hypercall.h"
-#include 
+#include 
 #include 
 #include 
 #include 
-- 
2.1.4


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

Re: [Xen-devel] Is: PVH dom0 - MWAIT detection logic to get deeper C-states exposed in ACPI AML code. Was:Re: [PATCH v2 10/30] xen/x86: Annotate VM applicability in featureset

[Konrad Rzeszutek Wilk]

. snip..
> > Hmm, you're right, somehow I've managed to ignore the relevant
> > lines grep reported. Yet - how do things work then, without the
> > MWAIT feature flag currently getting cleared?
>  I have never observed it being used.  Do you have some local patches in
>  the SLES hypervisor?
> 
>  There is some gross layer violation in xen/enlighten.c to pretend that
>  MWAIT is present to trick the ACPI code into evaluating _CST() methods
>  to report back to Xen.  (This is yet another PV-ism which will cause a
>  headache for a DMLite dom0)
> >>> Yes indeed. CC-ing Roger, and Boris.
> >> Yes, all this is indeed not very nice, and we would ideally like to get
> >> rid of it on PVHv2.
> >>
> >> Could we use the acpica tools (acpidump/acpixtract/acpiexec/...) in
> >> order to fetch this information from user-space and send it to Xen using
> >> privcmd?
> >>
> >> AFAIK those tools work on most OSes (or at least the ones we care about
> >> as Dom0).
> > 
> > In general, we can't rely on userspace evaluation of AML.
> > 
> > For trivial AML which evaluates to a constant, it could be interpreted
> > by userspace, but anything accessing system resources will need
> > evaluating by the kernel.
> 
> Hm, I've took a look at the ACPI tables in one of my systems, and I'm 
... snip ..
> Do we have a formal list of what exactly does Xen want from ACPI that 
> it cannot fetch itself?
> 
> I'm quite sure Xen cares about all the "Processor Vendor-Specific ACPI" 
> [0], that should be _PCT, _CST and _PTC (located in \_PR_.CPUN._XXX).

Correct. But those values - especially _CST are modified by the firmware
depending on the ..[something, I can't actually find the code for it].

Here is an copy-n-paste of the code that sets the
generic ACPI code on the path to get the lower C-states:

commit 73c154c60be106b47f15dfc2d75cc7a436f2
Author: Konrad Rzeszutek Wilk 
Date:   Mon Feb 13 22:26:32 2012 -0500

xen/enlighten: Expose MWAIT and MWAIT_LEAF if hypervisor OKs it.

For the hypervisor to take advantage of the MWAIT support it needs
to extract from the ACPI _CST the register address. But the
hypervisor does not have the support to parse DSDT so it relies on
the initial domain (dom0) to parse the ACPI Power Management information
and push it up to the hypervisor. The pushing of the data is done
by the processor_harveset_xen module which parses the information that
the ACPI parser has graciously exposed in 'struct acpi_processor'.

For the ACPI parser to also expose the Cx states for MWAIT, we need
to expose the MWAIT capability (leaf 1). Furthermore we also need to
expose the MWAIT_LEAF capability (leaf 5) for cstate.c to properly
function.

The hypervisor could expose these flags when it traps the XEN_EMULATE_PREFIX
operations, but it can't do it since it needs to be backwards compatible.
Instead we choose to use the native CPUID to figure out if the MWAIT
capability exists and use the XEN_SET_PDC query hypercall to figure out
if the hypervisor wants us to expose the MWAIT_LEAF capability or not.

Note: The XEN_SET_PDC query was implemented in c/s 23783:
"ACPI: add _PDC input override mechanism".

With this in place, instead of
 C3 ACPI IOPORT 415
we get now
 C3:ACPI FFH INTEL MWAIT 0x20

Note: The cpu_idle which would be calling the mwait variants for
idling
never gets set b/c we set the default pm_idle to be the hypercall
variant.

> 
> Roger.
> 
> [0] 
> http://www.intel.es/content/dam/www/public/us/en/documents/product-specifications/processor-vendor-specific-acpi-specification.pdf

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

Re: [Xen-devel] [PATCH] arm/monitor vm-events: Implement guest-request support

[Tamas K Lengyel]

On Thu, Feb 18, 2016 at 1:08 PM, Razvan Cojocaru 
wrote:

> On 02/18/2016 09:35 PM, Corneliu ZUZU wrote:
> > This patch adds ARM support for guest-request monitor vm-events.
> >
> > Summary of changes:
> > == Moved to common-side:
> >   * XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST handling (moved from X86
> >   arch_monitor_domctl_event to common monitor_domctl)
> >   * hvm_event_guest_request, hvm_event_traps (also added target vcpu as
> param)
> >   * guest-request bits from X86 'struct arch_domain' (to common 'struct
> domain')
> > == ARM implementations:
> >   * do_hvm_op now handling of HVMOP_guest_request_vm_event => calls
> >   hvm_event_guest_request (as on X86)
> >   * arch_monitor_get_capabilities: updated to reflect support for
> >   XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST
> >   * vm_event_init_domain (does nothing), vm_event_cleanup_domain
> > == Misc:
> >   * hvm_event_fill_regs renamed to arch_hvm_event_fill_regs, no longer
> >   X86-specific. ARM-side implementation of this function currently
> does
> >   nothing, that will be added in a separate patch.
>
> We should probably take into account what happens with Tamas' "vm_event:
> consolidate hvm_event_fill_regs and p2m_vm_event_fill_regs" patch here.
> That patch already affects hvm_event_fill_regs().
>

Well it seems one of us will have to rebase depending which patch gets
accepted & merged first. The conflict is minimal so it's not a major issue.
If my patch gets merged first then just have to introduce the empty
function in the ARM header with the new name.

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

Re: [Xen-devel] [PATCH 4/4] tools/configure: rerun autoconf

[Andrew Cooper]

On 18/02/2016 21:31, Doug Goldstein wrote:
> On 2/18/16 3:22 PM, Doug Goldstein wrote:
>> Rerun autoconf to regenerate configure
>>
>> Signed-off-by: Doug Goldstein 
>> ---
>> CC: Ian Jackson 
>> CC: Stefano Stabellini 
>> CC: Ian Campbell 
>> CC: Wei Liu 
>> ---
>>  tools/configure | 295 
>> 
>>  1 file changed, 148 insertions(+), 147 deletions(-)
>>
>>
> Before these changes I was seeing the following errors:
>
> https://travis-ci.org/cardoe/xen/jobs/110174912
>
> https://travis-ci.org/cardoe/xen/jobs/110196932#L1435 (you have to
> expand the 'cat tools/config.log' and go down to line 1435).
>
> The goal here is to enabling building the toolstack in Travis.
> Unfortunately the last issue is a Ubuntu one. If anyone Ubuntu devs or
> users here have a good suggestion let me know. The error is:
>
> https://travis-ci.org/cardoe/xen/jobs/110210149#L3536
>
> On my personal machine I've just made a symlink from /usr/include/asm ->
> /usr/include/asm-generic to get past this.

This is a tools issue, not an ubuntu issue.

HVMLoader is an embedded 32bit target.  It should be using up errno.h
from the Xen public headers, and not using any system headers whatsoever.

(I could have sworn we fix this bug once already.  Luckily, Xen's errno
was copied from Linux, so the numbers match up.)

~Andrew


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

Re: [Xen-devel] [PATCH 4/4] tools/configure: rerun autoconf

[Doug Goldstein]

On 2/18/16 3:31 PM, Doug Goldstein wrote:
> On 2/18/16 3:22 PM, Doug Goldstein wrote:
>> Rerun autoconf to regenerate configure
>>
>> Signed-off-by: Doug Goldstein 
>> ---
>> CC: Ian Jackson 
>> CC: Stefano Stabellini 
>> CC: Ian Campbell 
>> CC: Wei Liu 
>> ---
>>  tools/configure | 295 
>> 
>>  1 file changed, 148 insertions(+), 147 deletions(-)
>>
>>
> 
> Before these changes I was seeing the following errors:
> 
> https://travis-ci.org/cardoe/xen/jobs/110174912
> 
> https://travis-ci.org/cardoe/xen/jobs/110196932#L1435 (you have to
> expand the 'cat tools/config.log' and go down to line 1435).
> 
> The goal here is to enabling building the toolstack in Travis.
> Unfortunately the last issue is a Ubuntu one. If anyone Ubuntu devs or
> users here have a good suggestion let me know. The error is:
> 
> https://travis-ci.org/cardoe/xen/jobs/110210149#L3536
> 
> On my personal machine I've just made a symlink from /usr/include/asm ->
> /usr/include/asm-generic to get past this.
> 

Oh forgot to link the Ubuntu bug.
https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/1300211

Obviously its possible I'm doing it wrong and maybe someone has a
suggestion.

-- 
Doug Goldstein



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

Re: [Xen-devel] [PATCH 4/4] tools/configure: rerun autoconf

[Doug Goldstein]

On 2/18/16 3:22 PM, Doug Goldstein wrote:
> Rerun autoconf to regenerate configure
> 
> Signed-off-by: Doug Goldstein 
> ---
> CC: Ian Jackson 
> CC: Stefano Stabellini 
> CC: Ian Campbell 
> CC: Wei Liu 
> ---
>  tools/configure | 295 
> 
>  1 file changed, 148 insertions(+), 147 deletions(-)
> 
> 

Before these changes I was seeing the following errors:

https://travis-ci.org/cardoe/xen/jobs/110174912

https://travis-ci.org/cardoe/xen/jobs/110196932#L1435 (you have to
expand the 'cat tools/config.log' and go down to line 1435).

The goal here is to enabling building the toolstack in Travis.
Unfortunately the last issue is a Ubuntu one. If anyone Ubuntu devs or
users here have a good suggestion let me know. The error is:

https://travis-ci.org/cardoe/xen/jobs/110210149#L3536

On my personal machine I've just made a symlink from /usr/include/asm ->
/usr/include/asm-generic to get past this.

-- 
Doug Goldstein



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

[Xen-devel] [PATCH 4/4] tools/configure: rerun autoconf

[Doug Goldstein]

Rerun autoconf to regenerate configure

Signed-off-by: Doug Goldstein 
---
CC: Ian Jackson 
CC: Stefano Stabellini 
CC: Ian Campbell 
CC: Wei Liu 
---
 tools/configure | 295 
 1 file changed, 148 insertions(+), 147 deletions(-)

diff --git a/tools/configure b/tools/configure
index cd41b26..3669594 100755
--- a/tools/configure
+++ b/tools/configure
@@ -682,9 +682,6 @@ INSTALL_PROGRAM
 SET_MAKE
 AWK
 IASL
-BCC
-LD86
-AS86
 XGETTEXT
 BASH
 XML
@@ -704,6 +701,9 @@ qemu_xen_systemd
 qemu_xen_path
 qemu_xen
 rombios
+BCC
+LD86
+AS86
 qemu_traditional
 blktap2
 LINUX_BACKEND_MODULES
@@ -3348,7 +3348,7 @@ else
 We can't simply define LARGE_OFF_T to be 9223372036854775807,
 since some C++ compilers masquerading as C compilers
 incorrectly reject 9223372036854775807.  */
-#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31))
+#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
   int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
   && LARGE_OFF_T % 2147483647 == 1)
  ? 1 : -1];
@@ -3394,7 +3394,7 @@ else
 We can't simply define LARGE_OFF_T to be 9223372036854775807,
 since some C++ compilers masquerading as C compilers
 incorrectly reject 9223372036854775807.  */
-#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31))
+#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
   int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
   && LARGE_OFF_T % 2147483647 == 1)
  ? 1 : -1];
@@ -3418,7 +3418,7 @@ rm -f core conftest.err conftest.$ac_objext 
conftest.$ac_ext
 We can't simply define LARGE_OFF_T to be 9223372036854775807,
 since some C++ compilers masquerading as C compilers
 incorrectly reject 9223372036854775807.  */
-#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31))
+#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
   int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
   && LARGE_OFF_T % 2147483647 == 1)
  ? 1 : -1];
@@ -3463,7 +3463,7 @@ else
 We can't simply define LARGE_OFF_T to be 9223372036854775807,
 since some C++ compilers masquerading as C compilers
 incorrectly reject 9223372036854775807.  */
-#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31))
+#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
   int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
   && LARGE_OFF_T % 2147483647 == 1)
  ? 1 : -1];
@@ -3487,7 +3487,7 @@ rm -f core conftest.err conftest.$ac_objext 
conftest.$ac_ext
 We can't simply define LARGE_OFF_T to be 9223372036854775807,
 since some C++ compilers masquerading as C compilers
 incorrectly reject 9223372036854775807.  */
-#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31))
+#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
   int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
   && LARGE_OFF_T % 2147483647 == 1)
  ? 1 : -1];
@@ -4242,6 +4242,141 @@ fi
 
 if test "x$enable_rombios" = "xyes"; then :
 
+   # Extract the first word of "as86", so it can 
be a program name with args.
+set dummy as86; ac_word=$2
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
+$as_echo_n "checking for $ac_word... " >&6; }
+if ${ac_cv_path_AS86+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  case $AS86 in
+  [\\/]* | ?:[\\/]*)
+  ac_cv_path_AS86="$AS86" # Let the user override the test with a path.
+  ;;
+  *)
+  as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+for ac_exec_ext in '' $ac_executable_extensions; do
+  if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+ac_cv_path_AS86="$as_dir/$ac_word$ac_exec_ext"
+$as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" 
>&5
+break 2
+  fi
+done
+  done
+IFS=$as_save_IFS
+
+  test -z "$ac_cv_path_AS86" && ac_cv_path_AS86="no"
+  ;;
+esac
+fi
+AS86=$ac_cv_path_AS86
+if test -n "$AS86"; then
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $AS86" >&5
+$as_echo "$AS86" >&6; }
+else
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
+$as_echo "no" >&6; }
+fi
+
+
+if test x"${AS86}" = x"no"
+then
+as_fn_error $? "Unable to find as86, please install as86" "$LINENO" 5
+fi
+   # Extract the first word of "ld86", so it can be a program name with 
args.
+set dummy ld86; ac_word=$2
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
+$as_echo_n "checking for $ac_word... " >&6; }
+if ${ac_cv_path_LD86+:} false; then :
+  $as_echo_n 

[Xen-devel] [PATCH 3/4] m4/python: fix checks for Python library support

[Doug Goldstein]

AC_CHECK_LIB() was running gcc -Llib -lm -lutils conftest.c which on
platforms that do as needed operations by default will result in
underlinking. Instead AC_CHECK_LIB() suggests supplying the extra
libraries necessary in a 5th argument.

Signed-off-by: Doug Goldstein 
---
CC: Ian Jackson 
CC: Stefano Stabellini 
CC: Ian Campbell 
CC: Wei Liu 
---
 m4/python_devel.m4 | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/m4/python_devel.m4 b/m4/python_devel.m4
index deff19e..6aaed4e 100644
--- a/m4/python_devel.m4
+++ b/m4/python_devel.m4
@@ -10,9 +10,9 @@ AS_IF([test x"$pyconfig" = x"no"], [
 print "-I" + distutils.sysconfig.get_config_var("INCLUDEPY")'`"
 CPPFLAGS="$CPPFLAGS `$PYTHON -c 'import distutils.sysconfig; \
 print distutils.sysconfig.get_config_var("CFLAGS")'`"
-LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
+PYTHON_LIBS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
 print distutils.sysconfig.get_config_var("LIBS")'`"
-LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
+PYTHON_LIBS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
 print distutils.sysconfig.get_config_var("SYSLIBS")'`"
 LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
 print "-L" + distutils.sysconfig.get_python_lib(plat_specific=1,\
@@ -25,12 +25,14 @@ AS_IF([test x"$pyconfig" = x"no"], [
 dnl If python-config is found use it
 CPPFLAGS="$CFLAGS `$PYTHON-config --cflags`"
 LDFLAGS="$LDFLAGS `$PYTHON-config --ldflags`"
+   PYTHON_LIBS="$LIBS `$PYTHON-config --libs`"
 ])
 
 AC_CHECK_HEADER([Python.h], [],
 [AC_MSG_ERROR([Unable to find Python development headers])],)
 AC_CHECK_LIB(python$ac_python_version, PyArg_ParseTuple, [],
-[AC_MSG_ERROR([Unable to find a suitable python development library])])
+[AC_MSG_ERROR([Unable to find a suitable python development library])],
+   [$PYTHON_LIBS])
 CPPFLAGS=$ac_previous_cppflags
 LDFLAGS=$ac_previous_ldflags
 ])
-- 
2.4.10


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

Re: [Xen-devel] [PATCH v3 5/5] mkelf32: Close those file descriptors in the error paths.

[Konrad Rzeszutek Wilk]

On Thu, Feb 18, 2016 at 09:45:30AM -0700, Jan Beulich wrote:
> >>> On 18.02.16 at 17:39,  wrote:
> > Jan Beulich writes ("Re: [PATCH v3 5/5] mkelf32: Close those file 
> > descriptors 
> > in the error paths."):
> >> On 12.02.16 at 04:08,  wrote:
> >> > While we are operating here we may as well fix some of the
> >> > file descriptor leaks.
> >> 
> >> I'm not convinced. The added goto-s make the code uglier to read,
> >> and this being a standalone utility there's not really any leak here.
> > 
> > I don't buy this `uglier to read'.  What `return 1' does is make me
> > think `is some resource being leaked' and `do I need to audit this
> > thing'.
> 
> Certainly a matter of taste to some degree - goto-s are always
> ugly to read to my eyes. Irrespective of this I don't buy the leak
> aspect for a non-library like, short running build utility. The close()
> calls are just more code, with absolutely no added benefit to the
> system the code runs on.



If I turned them in:

if (..blah..)
{
close(infd);
return -1;
}

would that satisfy you?

(Irrespective of the 'no added benefit to the system the code runs
on.').

> 
> Jan
> 

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

Re: [Xen-devel] [PATCH] arm/monitor vm-events: Implement guest-request support

[Razvan Cojocaru]

On 02/18/2016 09:35 PM, Corneliu ZUZU wrote:
> This patch adds ARM support for guest-request monitor vm-events.
> 
> Summary of changes:
> == Moved to common-side:
>   * XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST handling (moved from X86
>   arch_monitor_domctl_event to common monitor_domctl)
>   * hvm_event_guest_request, hvm_event_traps (also added target vcpu as param)
>   * guest-request bits from X86 'struct arch_domain' (to common 'struct 
> domain')
> == ARM implementations:
>   * do_hvm_op now handling of HVMOP_guest_request_vm_event => calls
>   hvm_event_guest_request (as on X86)
>   * arch_monitor_get_capabilities: updated to reflect support for
>   XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST
>   * vm_event_init_domain (does nothing), vm_event_cleanup_domain
> == Misc:
>   * hvm_event_fill_regs renamed to arch_hvm_event_fill_regs, no longer
>   X86-specific. ARM-side implementation of this function currently does
>   nothing, that will be added in a separate patch.

We should probably take into account what happens with Tamas' "vm_event:
consolidate hvm_event_fill_regs and p2m_vm_event_fill_regs" patch here.
That patch already affects hvm_event_fill_regs().

Tamas'll probably chime in with more.


Thanks,
Razvan

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

[Xen-devel] [PATCH] arm/monitor vm-events: Implement guest-request support

[Corneliu ZUZU]

This patch adds ARM support for guest-request monitor vm-events.

Summary of changes:
== Moved to common-side:
  * XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST handling (moved from X86
  arch_monitor_domctl_event to common monitor_domctl)
  * hvm_event_guest_request, hvm_event_traps (also added target vcpu as param)
  * guest-request bits from X86 'struct arch_domain' (to common 'struct domain')
== ARM implementations:
  * do_hvm_op now handling of HVMOP_guest_request_vm_event => calls
  hvm_event_guest_request (as on X86)
  * arch_monitor_get_capabilities: updated to reflect support for
  XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST
  * vm_event_init_domain (does nothing), vm_event_cleanup_domain
== Misc:
  * hvm_event_fill_regs renamed to arch_hvm_event_fill_regs, no longer
  X86-specific. ARM-side implementation of this function currently does
  nothing, that will be added in a separate patch.

Signed-off-by: Corneliu ZUZU 
---
 MAINTAINERS |   1 +
 xen/arch/arm/hvm.c  |   8 +++
 xen/arch/x86/hvm/event.c| 116 ++--
 xen/arch/x86/hvm/hvm.c  |   1 +
 xen/arch/x86/monitor.c  |  14 -
 xen/arch/x86/vm_event.c |   1 +
 xen/common/Makefile |   2 +-
 xen/common/hvm/Makefile |   3 +-
 xen/common/hvm/event.c  |  96 +
 xen/common/monitor.c|  31 +--
 xen/include/asm-arm/hvm/event.h |  41 ++
 xen/include/asm-arm/monitor.h   |   7 ++-
 xen/include/asm-arm/vm_event.h  |   4 +-
 xen/include/asm-x86/domain.h|  18 +++
 xen/include/asm-x86/hvm/event.h |  43 ++-
 xen/include/xen/hvm/event.h |  41 ++
 xen/include/xen/sched.h |   6 +++
 17 files changed, 299 insertions(+), 134 deletions(-)
 create mode 100644 xen/common/hvm/event.c
 create mode 100644 xen/include/asm-arm/hvm/event.h
 create mode 100644 xen/include/xen/hvm/event.h

diff --git a/MAINTAINERS b/MAINTAINERS
index cd4da04..768ad32 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -356,6 +356,7 @@ M:  Tamas K Lengyel 
 S: Supported
 F: xen/common/vm_event.c
 F: xen/common/mem_access.c
+F: xen/common/hvm/event.c
 F: xen/common/monitor.c
 F: xen/arch/x86/hvm/event.c
 F: xen/arch/x86/monitor.c
diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
index 056db1a..767edd1 100644
--- a/xen/arch/arm/hvm.c
+++ b/xen/arch/arm/hvm.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -72,6 +73,13 @@ long do_hvm_op(unsigned long op, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 break;
 }
 
+case HVMOP_guest_request_vm_event:
+if ( guest_handle_is_null(arg) )
+hvm_event_guest_request();
+else
+rc = -EINVAL;
+break;
+
 default:
 {
 gdprintk(XENLOG_DEBUG, "HVMOP op=%lu: not implemented\n", op);
diff --git a/xen/arch/x86/hvm/event.c b/xen/arch/x86/hvm/event.c
index cb9c152..bbb0dc8 100644
--- a/xen/arch/x86/hvm/event.c
+++ b/xen/arch/x86/hvm/event.c
@@ -6,6 +6,7 @@
  * Copyright (c) 2004, Intel Corporation.
  * Copyright (c) 2005, International Business Machines Corporation.
  * Copyright (c) 2008, Citrix Systems, Inc.
+ * Copyright (c) 2016, Bitdefender S.R.L.
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms and conditions of the GNU General Public License,
@@ -20,103 +21,32 @@
  * this program; If not, see .
  */
 
-#include 
-#include 
+#include 
 #include 
 #include 
-#include 
 #include 
 
-static void hvm_event_fill_regs(vm_event_request_t *req)
-{
-const struct cpu_user_regs *regs = guest_cpu_user_regs();
-const struct vcpu *curr = current;
-
-req->data.regs.x86.rax = regs->eax;
-req->data.regs.x86.rcx = regs->ecx;
-req->data.regs.x86.rdx = regs->edx;
-req->data.regs.x86.rbx = regs->ebx;
-req->data.regs.x86.rsp = regs->esp;
-req->data.regs.x86.rbp = regs->ebp;
-req->data.regs.x86.rsi = regs->esi;
-req->data.regs.x86.rdi = regs->edi;
-
-req->data.regs.x86.r8  = regs->r8;
-req->data.regs.x86.r9  = regs->r9;
-req->data.regs.x86.r10 = regs->r10;
-req->data.regs.x86.r11 = regs->r11;
-req->data.regs.x86.r12 = regs->r12;
-req->data.regs.x86.r13 = regs->r13;
-req->data.regs.x86.r14 = regs->r14;
-req->data.regs.x86.r15 = regs->r15;
-
-req->data.regs.x86.rflags = regs->eflags;
-req->data.regs.x86.rip= regs->eip;
-
-req->data.regs.x86.msr_efer = curr->arch.hvm_vcpu.guest_efer;
-req->data.regs.x86.cr0 = curr->arch.hvm_vcpu.guest_cr[0];
-req->data.regs.x86.cr3 = curr->arch.hvm_vcpu.guest_cr[3];
-req->data.regs.x86.cr4 = curr->arch.hvm_vcpu.guest_cr[4];
-}
-
-static int hvm_event_traps(uint8_t sync, vm_event_request_t *req)
-{
-int rc;
-struct vcpu *curr = current;
-struct domain *currd = 

Re: [Xen-devel] [PATCH RFC] osstest: add a cd-{insert/eject} test for Debian HVM

[Ian Jackson]

Roger Pau Monne writes ("[PATCH RFC] osstest: add a cd-{insert/eject} test for 
Debian HVM"):
> It could/should be expanded to other guest types, but at least it's a start.
> It should also test that the guest can correctly access the disk contents.
> 
> The only supported toolstack for this test is xl.

Thanks.

> +# Both the insert/eject functions hardcode 'hdc' as the virtual cdrom unit,
> +# if more_prepareguest_hvm is changed to use a different unit this is doomed
> +# to fail.

I think this hardcoding should be done closer to the source.  Ie, in
ts-hvm-cd.  The vdev to be ejected and inserted should be passed as
parameter to the toolstack functions.

The same goes for the iso image, I think.

BUT:

Regarding the vdev, I think it would be much better to get the vdev
information from a runvar.  ts-debianhvm-install could store the cd
vdev and your ts- script could read it.

Regarding the iso image: I think it's not a good idea to use the
install iso image.  Because, we would like to be able to carry on with
the rest of the test job if this step fails.  And we may not know
whether the cd has been inserted.  If it has, and it's the install cd,
things might boot off it and redo the install.

Using the empty iso image would be better.  (See guest_editconfig_nocd
in TestSupport.pm.)


> +sub guest_eject_cd ($) {
> +my ($gho) = @_;
> +my $ho = $gho->{Host};
> +die "xl is the only supported toolstack" if $tsname neq 'xl';
> +toolstack($ho)->cd_eject($gho);

This is not appropriate.  You could do this by providing dummy
methods in the toolstack classes.  But TBH if you just leave out the
check, what happens is that the call will go to an unimplemented
method and bomb out anyway.

> diff --git a/sg-run-job b/sg-run-job
> index 3e0f966..43a141f 100755
> --- a/sg-run-job
> +++ b/sg-run-job
> @@ -320,6 +320,7 @@ proc run-job/test-rhelhvm {} {
>  proc need-hosts/test-debianhvm {} { return host }
>  proc run-job/test-debianhvm {} {
>  run-ts . = ts-debian-hvm-install
> +run-ts . = ts-hvm-cd

I think that it would be worth making some effort to avoid blocking
the whole test job if this fails.  (Since AIUI currently we expect
this to fail on some branches.)

>  test-guest debianhvm

And then ideally this new call would be in test-guest.

Also I am not happy with the script name.  ts-cd-eject ?  (The script
name turns into a test step name (by default) and the test step name
ought not to vary according to whether the job is HVM or not.)


> +guest_eject_cd($gho)
> +sleep(10)
> +guest_insert_cd($gho)
> +sleep(10)
> +guest_eject_cd($gho)

How hard would it be to provide a dummy image and then check, in the
guest, that the guest can read it ?


Ian.

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

Re: [Xen-devel] [PATCHv1 4/5] x86/viridian: set x87 FIP width to 4 for Windows guests

[Andrew Cooper]

On 18/02/16 18:52, David Vrabel wrote:
> diff --git a/xen/arch/x86/hvm/viridian.c b/xen/arch/x86/hvm/viridian.c
> index 6bd844b..fb9f044 100644
> --- a/xen/arch/x86/hvm/viridian.c
> +++ b/xen/arch/x86/hvm/viridian.c
> @@ -148,6 +148,30 @@ static void dump_guest_os_id(const struct domain *d)
> goi->fields.service_pack, goi->fields.build_number);
>  }
>  
> +static void set_guest_os_id(struct domain *d, uint64_t val)
> +{
> +const union viridian_guest_os_id *goi;
> +
> +d->arch.hvm_domain.viridian.guest_os_id.raw = val;
> +goi = >arch.hvm_domain.viridian.guest_os_id;
> +
> +/*
> + * Microsoft Windows only saves the lower 32-bits of FIP/FDP and
> + * can get upset if the selectors are not saved/restored by the
> + * hypervisor.
> + *
> + * Only do this if the FIP width is not in auto-mode, so this
> + * heuristic can be overriden by the toolstack.
> + */
> +if ( !d->arch.x87_fip_width )
> +{
> +if ( goi->fields.vendor == 1 && goi->fields.os == 4 )

Are there any named parameters we could use here?

In principle, Reviewed-by: Andrew Cooper 
(allowing for the potential change of x86_fip_width per the discussion
on patch 3).

> +d->arch.x87_fip_width = 4;
> +}
> +
> +dump_guest_os_id(d);
> +}
> +
>  static void dump_hypercall(const struct domain *d)
>  {
>  const union viridian_hypercall_gpa *hg;


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

Re: [Xen-devel] [PATCHv1 3/5] x86/fpu: Add a per-domain field to set the width of FIP/FDP

[Andrew Cooper]

On 18/02/16 18:52, David Vrabel wrote:
> The x86 architecture allows either: a) the 64-bit FIP/FDP registers to be
> restored (clearing FCS and FDS); or b) the 32-bit FIP/FDP and FCS/FDS
> registers to be restored (clearing the upper 32-bits).

^ of FIP/FDP

> diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
> index 4fad638..362fd8f 100644
> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -394,6 +394,21 @@ struct arch_domain
>  
>  /* Emulated devices enabled bitmap. */
>  uint32_t emulation_flags;
> +
> +/*
> + * The width of the FIP/FDP register in the FPU that needs to be
> + * saved/restored during a context switch.  This is needed because
> + * the FPU can either: a) restore the 64-bit FIP/FDP and clear FCS
> + * and FDS; or b) retstore the 32-bit FIP/FDP (clearing the upper
> + * 32-bits) and restore FCS/FDS.
> + *
> + * Which one is needed depends on the guest.
> + *
> + * This can be either: 8, 4 or 0.  0 means auto-detect the size
> + * based on the width of FIP/FDP values that are written by by the
> + * guest.
> + */
> +uint8_t x87_fip_width;

Can we get away with always using fpu_sse.x[FPU_WORD_SIZE_OFFSET],
instead if duplicating the information in arch_domain and risking them
getting out of sync?

VMs which have migrated in will already have some policy latched, and we
should preserve their old behaviour if possible.

~Andrew

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

Re: [Xen-devel] [PATCHv1 2/5] tools/libxc: add xc_domain_get_param() and xc_domain_set_param()

[Andrew Cooper]

On 18/02/16 18:52, David Vrabel wrote:
> These are a thin wrapper around the XEN_DOMCTL_param hypercall.
>
> Signed-off-by: David Vrabel 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCHv1 1/5] domctl: Add op to get/set generic numeric parameters

[Andrew Cooper]

On 18/02/16 18:52, David Vrabel wrote:
> Add XEN_DOMCTL_param to get/set generic numeric parameters for a domain.
> This should reduce the number of specialized domctls that need to be
> added.
>
> Signed-off-by: David Vrabel 

As far as the code here goes, Reviewed-by: Andrew Cooper


However, you will need to patch flask_domctl() as well, possibly
introducing a new flask bit.

~Andrew

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

[Xen-devel] [RFC PATCH 0/5] x86: workaround inability to fully restore FPU state

[David Vrabel]

This series extends the workaround for the inability for some x86 CPUs
to fully restore the FPU exception state (64-bit FIP/FDP and FCS/FDS).

32-bit save/restore is always done for Windows guests and the
toolstack may override the default behaviour.

The first 2 patches add a domctl to get/set numeric parameters.  I was
surprised there wasn't an existing mechanism for this.

This series is RFC since I haven't tested it very much.

David


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

[Xen-devel] [PATCHv1 4/5] x86/viridian: set x87 FIP width to 4 for Windows guests

[David Vrabel]

Microsoft Windows always uses a 32-bit FPU state save/restore and expects
the FCS/FDS to be saved/restored.  Ensure that for these guests, the
hypervisor does 32-bit save/restore to preserve FCS/FDS.

These guests are identified by the write to the Guest OS ID MSR.

This fixes an 0x3D BugCheck when running the Driver Verifier in 64-bit
Windows.  This BugCheck occurs because a context switch would clear
FCS/FDS and Driver Verifier would assert because the FPU state changed.

We only set FIP width if it is still in auto-mode, to allow the toolstack
to override if necessary.

Signed-off-by: David Vrabel 
---
 xen/arch/x86/hvm/viridian.c | 27 +--
 1 file changed, 25 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/viridian.c b/xen/arch/x86/hvm/viridian.c
index 6bd844b..fb9f044 100644
--- a/xen/arch/x86/hvm/viridian.c
+++ b/xen/arch/x86/hvm/viridian.c
@@ -148,6 +148,30 @@ static void dump_guest_os_id(const struct domain *d)
goi->fields.service_pack, goi->fields.build_number);
 }
 
+static void set_guest_os_id(struct domain *d, uint64_t val)
+{
+const union viridian_guest_os_id *goi;
+
+d->arch.hvm_domain.viridian.guest_os_id.raw = val;
+goi = >arch.hvm_domain.viridian.guest_os_id;
+
+/*
+ * Microsoft Windows only saves the lower 32-bits of FIP/FDP and
+ * can get upset if the selectors are not saved/restored by the
+ * hypervisor.
+ *
+ * Only do this if the FIP width is not in auto-mode, so this
+ * heuristic can be overriden by the toolstack.
+ */
+if ( !d->arch.x87_fip_width )
+{
+if ( goi->fields.vendor == 1 && goi->fields.os == 4 )
+d->arch.x87_fip_width = 4;
+}
+
+dump_guest_os_id(d);
+}
+
 static void dump_hypercall(const struct domain *d)
 {
 const union viridian_hypercall_gpa *hg;
@@ -334,8 +358,7 @@ int wrmsr_viridian_regs(uint32_t idx, uint64_t val)
 {
 case VIRIDIAN_MSR_GUEST_OS_ID:
 perfc_incr(mshv_wrmsr_osid);
-d->arch.hvm_domain.viridian.guest_os_id.raw = val;
-dump_guest_os_id(d);
+set_guest_os_id(d, val);
 break;
 
 case VIRIDIAN_MSR_HYPERCALL:
-- 
2.1.4


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

[Xen-devel] [PATCHv1 1/5] domctl: Add op to get/set generic numeric parameters

[David Vrabel]

Add XEN_DOMCTL_param to get/set generic numeric parameters for a domain.
This should reduce the number of specialized domctls that need to be
added.

Signed-off-by: David Vrabel 
---
 xen/arch/x86/domctl.c   | 14 ++
 xen/common/domctl.c | 11 +++
 xen/include/public/domctl.h | 21 +
 xen/include/xen/domain.h|  3 +++
 4 files changed, 49 insertions(+)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 55aecdc..3a3ebbf 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1408,6 +1408,20 @@ void arch_get_info_guest(struct vcpu *v, 
vcpu_guest_context_u c)
 #undef c
 }
 
+int arch_domctl_param(struct domain *d, uint32_t param, bool_t set,
+  uint64_t *value)
+{
+uint64_t new_value = *value;
+
+switch ( param )
+{
+default:
+return -EINVAL;
+}
+
+return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 22fa5d5..54c51ba 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -1186,6 +1186,17 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
u_domctl)
 copyback = 1;
 break;
 
+case XEN_DOMCTL_param:
+{
+uint32_t param = op->u.param.param & ~XEN_DOMCTL_PARAM_SET;
+bool_t set = !!(op->u.param.param & XEN_DOMCTL_PARAM_SET);
+
+ret = arch_domctl_param(d, param, set, >u.param.value);
+if ( ret == 0 )
+copyback = 1;
+break;
+}
+
 default:
 ret = arch_do_domctl(op, d, u_domctl);
 break;
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index a934318..330b3e7 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -1092,6 +1092,25 @@ struct xen_domctl_psr_cat_op {
 typedef struct xen_domctl_psr_cat_op xen_domctl_psr_cat_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_psr_cat_op_t);
 
+/*
+ * Get/set a per-domain numeric parameter.
+ *
+ * If bit 31 of @param is set, the original value is returned and the
+ * new value is written.  If bit 31 is clear, the value is returned.
+ *
+ * Not all parameters are valid for all architectures or domain types.
+ */
+#define XEN_DOMCTL_PARAM_SET (1u << 31)
+
+struct xen_domctl_param {
+/* IN */
+uint32_t param;
+/* IN/OUT */
+uint64_t value;
+};
+typedef struct xen_domctl_param xen_domctl_param;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_param);
+
 struct xen_domctl {
 uint32_t cmd;
 #define XEN_DOMCTL_createdomain   1
@@ -1169,6 +1188,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_monitor_op77
 #define XEN_DOMCTL_psr_cat_op78
 #define XEN_DOMCTL_soft_reset79
+#define XEN_DOMCTL_param 80
 #define XEN_DOMCTL_gdbsx_guestmemio1000
 #define XEN_DOMCTL_gdbsx_pausevcpu 1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu   1002
@@ -1231,6 +1251,7 @@ struct xen_domctl {
 struct xen_domctl_psr_cmt_oppsr_cmt_op;
 struct xen_domctl_monitor_opmonitor_op;
 struct xen_domctl_psr_cat_oppsr_cat_op;
+struct xen_domctl_param param;
 uint8_t pad[128];
 } u;
 };
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index a1a6f25..a8a6d7d 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -77,6 +77,9 @@ void arch_dump_domain_info(struct domain *d);
 
 int arch_vcpu_reset(struct vcpu *);
 
+int arch_domctl_param(struct domain *d, uint32_t param, bool_t set,
+  uint64_t *value);
+
 extern spinlock_t vcpu_alloc_lock;
 bool_t domctl_lock_acquire(void);
 void domctl_lock_release(void);
-- 
2.1.4


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

[Xen-devel] [PATCHv1 5/5] x86/domctl: Add XEN_DOMCTL_PARAM_ARCH_X86_FIP_WIDTH parameter

[David Vrabel]

Add a parameter to allow the toolstack to set the x87 FIP width in case
the hypervisor's heuristics do the wrong thing.

Signed-off-by: David Vrabel 
---
 xen/arch/x86/domctl.c   | 10 ++
 xen/include/public/domctl.h |  1 +
 2 files changed, 11 insertions(+)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 3a3ebbf..f75cd69 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1415,6 +1415,16 @@ int arch_domctl_param(struct domain *d, uint32_t param, 
bool_t set,
 
 switch ( param )
 {
+case XEN_DOMCTL_PARAM_ARCH_X86_FIP_WIDTH:
+*value = d->arch.x87_fip_width;
+if ( set )
+{
+if ( new_value != 0 && new_value != 4 && new_value != 8 )
+return -EINVAL;
+d->arch.x87_fip_width = new_value;
+}
+break;
+
 default:
 return -EINVAL;
 }
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 330b3e7..26d4096 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -1100,6 +1100,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_psr_cat_op_t);
  *
  * Not all parameters are valid for all architectures or domain types.
  */
+#define XEN_DOMCTL_PARAM_ARCH_X86_FIP_WIDTH 0
 #define XEN_DOMCTL_PARAM_SET (1u << 31)
 
 struct xen_domctl_param {
-- 
2.1.4


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

[Xen-devel] [PATCHv1 3/5] x86/fpu: Add a per-domain field to set the width of FIP/FDP

[David Vrabel]

The x86 architecture allows either: a) the 64-bit FIP/FDP registers to be
restored (clearing FCS and FDS); or b) the 32-bit FIP/FDP and FCS/FDS
registers to be restored (clearing the upper 32-bits).

Add a per-domain field to indicate which of these options a guest needs.
The options are: 8, 4 or 0.  Where 0 indicates that the hypervisor should
automatically guess the FIP width by checking the value of FIP/FDP when
saving the state (this is the existing behaviour).

The FIP width is initially automatic but is set explicitly in the following
cases:

- 32-bit PV guest: 4
- 64-bit PV guest: 8
- Newer CPUs that do not save FCS/FDS: 8

xsave() has been simplified to not require clearing the FCS/FDS fields --
either these are updated by the XSAVE* instruction or they are not
written.

Signed-off-by: David Vrabel 
---
 xen/arch/x86/domain.c| 10 ++
 xen/arch/x86/i387.c  | 15 ---
 xen/arch/x86/xstate.c| 43 +++
 xen/include/asm-x86/domain.h | 15 +++
 4 files changed, 44 insertions(+), 39 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 9d43f7b..a15cdf7 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -343,6 +343,8 @@ int switch_native(struct domain *d)
 hvm_set_mode(v, 8);
 }
 
+d->arch.x87_fip_width = 8;
+
 return 0;
 }
 
@@ -377,6 +379,8 @@ int switch_compat(struct domain *d)
 
 domain_set_alloc_bitsize(d);
 
+d->arch.x87_fip_width = 4;
+
 return 0;
 
  undo_and_fail:
@@ -653,6 +657,12 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 /* PV/PVH guests get an emulated PIT too for video BIOSes to use. */
 pit_init(d, cpu_khz);
 
+/*
+ * If the FPU not to save FCS/FDS then we can always save/restore
+ * the 64-bit FIP/FDP and ignore the selectors.
+ */
+d->arch.x87_fip_width = cpu_has_fpu_sel ? 0 : 8;
+
 return 0;
 
  fail:
diff --git a/xen/arch/x86/i387.c b/xen/arch/x86/i387.c
index 67016c9..ef08a52 100644
--- a/xen/arch/x86/i387.c
+++ b/xen/arch/x86/i387.c
@@ -144,9 +144,9 @@ static inline void fpu_xsave(struct vcpu *v)
 static inline void fpu_fxsave(struct vcpu *v)
 {
 typeof(v->arch.xsave_area->fpu_sse) *fpu_ctxt = v->arch.fpu_ctxt;
-int word_size = cpu_has_fpu_sel ? 8 : 0;
+unsigned int fip_width = v->domain->arch.x87_fip_width;
 
-if ( !is_pv_32bit_vcpu(v) )
+if ( fip_width != 4 )
 {
 /*
  * The only way to force fxsaveq on a wide range of gas versions.
@@ -164,7 +164,7 @@ static inline void fpu_fxsave(struct vcpu *v)
  boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
 return;
 
-if ( word_size > 0 &&
+if ( !fip_width &&
  !((fpu_ctxt->fip.addr | fpu_ctxt->fdp.addr) >> 32) )
 {
 struct ix87_env fpu_env;
@@ -172,17 +172,18 @@ static inline void fpu_fxsave(struct vcpu *v)
 asm volatile ( "fnstenv %0" : "=m" (fpu_env) );
 fpu_ctxt->fip.sel = fpu_env.fcs;
 fpu_ctxt->fdp.sel = fpu_env.fds;
-word_size = 4;
+fip_width = 4;
 }
+else
+fip_width = 8;
 }
 else
 {
 asm volatile ( "fxsave %0" : "=m" (*fpu_ctxt) );
-word_size = 4;
+fip_width = 4;
 }
 
-if ( word_size >= 0 )
-fpu_ctxt->x[FPU_WORD_SIZE_OFFSET] = word_size;
+fpu_ctxt->x[FPU_WORD_SIZE_OFFSET] = fip_width;
 }
 
 /***/
diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
index 4f2fb8e..c4cc071 100644
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -249,7 +249,7 @@ void xsave(struct vcpu *v, uint64_t mask)
 struct xsave_struct *ptr = v->arch.xsave_area;
 uint32_t hmask = mask >> 32;
 uint32_t lmask = mask;
-int word_size = mask & XSTATE_FP ? (cpu_has_fpu_sel ? 8 : 0) : -1;
+unsigned int fip_width = v->domain->arch.x87_fip_width;
 #define XSAVE(pfx) \
 alternative_io_3(".byte " pfx "0x0f,0xae,0x27\n", /* xsave */ \
  ".byte " pfx "0x0f,0xae,0x37\n", /* xsaveopt */ \
@@ -261,28 +261,8 @@ void xsave(struct vcpu *v, uint64_t mask)
  "=m" (*ptr), \
  "a" (lmask), "d" (hmask), "D" (ptr))
 
-if ( word_size <= 0 || !is_pv_32bit_vcpu(v) )
+if ( fip_width != 4 )
 {
-typeof(ptr->fpu_sse.fip.sel) fcs = ptr->fpu_sse.fip.sel;
-typeof(ptr->fpu_sse.fdp.sel) fds = ptr->fpu_sse.fdp.sel;
-
-if ( cpu_has_xsaveopt || cpu_has_xsaves )
-{
-/*
- * XSAVEOPT/XSAVES may not write the FPU portion even when the
- * respective mask bit is set. For the check further down to work
- * we hence need to put the save image back into the state that
- * it was in right after the previous XSAVEOPT.
- */
-if ( word_size > 0 &&
-

[Xen-devel] [PATCHv1 2/5] tools/libxc: add xc_domain_get_param() and xc_domain_set_param()

[David Vrabel]

These are a thin wrapper around the XEN_DOMCTL_param hypercall.

Signed-off-by: David Vrabel 
---
 tools/libxc/include/xenctrl.h |  5 +
 tools/libxc/xc_domain.c   | 35 +++
 2 files changed, 40 insertions(+)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 42eafa4..862c748 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -812,6 +812,11 @@ int xc_domain_hvm_setcontext(xc_interface *xch,
 const char *xc_domain_get_native_protocol(xc_interface *xch,
   uint32_t domid);
 
+int xc_domain_get_param(xc_interface *xch, unsigned int domid,
+uint32_t param, uint64_t *value);
+int xc_domain_set_param(xc_interface *xch, unsigned int domid,
+uint32_t param, uint64_t value, uint64_t *old_value);
+
 /**
  * This function returns information about the execution context of a
  * particular vcpu of a domain.
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 4fa993a..4caa250 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -2574,6 +2574,41 @@ int xc_domain_soft_reset(xc_interface *xch,
 domctl.domain = (domid_t)domid;
 return do_domctl(xch, );
 }
+
+static int xc_domain_param(xc_interface *xch, unsigned int domid,
+   uint32_t param, int set, uint64_t *value)
+{
+int ret;
+DECLARE_DOMCTL;
+
+domctl.cmd = XEN_DOMCTL_param;
+domctl.domain = domid;
+domctl.u.param.param = param | (set ? XEN_DOMCTL_PARAM_SET : 0);
+domctl.u.param.value = *value;
+
+ret = do_domctl(xch, );
+if ( ret == 0 )
+*value = domctl.u.param.value;
+return ret;
+}
+
+int xc_domain_get_param(xc_interface *xch, unsigned int domid,
+uint32_t param, uint64_t *value)
+{
+return xc_domain_param(xch, domid, param, 0, value);
+}
+
+int xc_domain_set_param(xc_interface *xch, unsigned int domid,
+uint32_t param, uint64_t value, uint64_t *old_value)
+{
+int ret;
+
+ret = xc_domain_param(xch, domid, param, 1, );
+if ( ret == 0 && old_value )
+*old_value = value;
+return ret;
+}
+
 /*
  * Local variables:
  * mode: C
-- 
2.1.4


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

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

[osstest service owner]

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

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  8dd6d1c099865ee5f5916616a0ca79cd943c46f9
baseline version:
 xen  e33b2921d28c8a3aff2c25fd3d046c7432b3a606

Last test of basis82876  2016-02-16 18:02:41 Z2 days
Testing same since83012  2016-02-18 15:03:15 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Corneliu ZUZU 
  Dario Faggioli 
  Dirk Behme 
  Doug Goldstein 
  Feng Wu 
  George Dunlap 
  Harmandeep Kaur 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jim Fehlig 
  Juergen Gross 
  Kevin Tian 
  Razvan Cojocaru 
  Roger Pau Monné 
  Stefano Stabellini 
  Wei Liu 

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=8dd6d1c099865ee5f5916616a0ca79cd943c46f9
+ . ./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 
8dd6d1c099865ee5f5916616a0ca79cd943c46f9
+ branch=xen-unstable-smoke
+ revision=8dd6d1c099865ee5f5916616a0ca79cd943c46f9
+ . ./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-coverity
+ '[' x8dd6d1c099865ee5f5916616a0ca79cd943c46f9 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/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
++ : 

Re: [Xen-devel] Current LibXL Status

[Ian Jackson]

Ian Campbell writes ("Re: [Xen-devel] Current LibXL Status"):
> The only one I can find which isn't one of this is
> in libxl__event_disaster, and that is only if the applications (or language
> bindings) haven't provided a suitable disaster callback.

libxl__event_disaster can currently happen in the following cases.

Disasters which are specific to a specific requested event (type!=0):

  xc_domain_getinfolist failure (breaks reporting domain death, only
  xw_write failure for acknowledging disk eject (breaks reporting
  ejects, only)

General disasters (type==0) due to xenstore problems:

  POLLERR or POLLHUP on xenstore fd
  xs_check_watch fails (represents trouble on xenstore fd or with xenstore)
  xs_read for domain death check

General disasters (type==0) due to hypercall trouble:

  xenevtchn_pending fails other than with EAGAIN
  (unrequested) event other than POLLIN on evtchn fd

General disasters (type==0) due to syscall failure:

  poll syscall fails
  (unrequested) event other than POLLIN on self-pipe
  read() or write() fails on a self-pipe (other than EAGAIN/EWOULDBLOCK)
  waitpid() syscall fails

General disasters (type==0) induced by the application:

  waitpid reports ECHILD when we know we have a child (probably,
something else in the process reaped it; arguably this should abort)
  application's childproc_hooks->reaped_callback failure

Disasters are not reported unless it is impossible to proceed.  So in
general it is not possible for a process to recover from a disaster
reported by libxl.

But disasters are never expected.  They should occur only if
everything is totally doomed anyway.  Having a daemon crash is a
perfectly reasonable response.

Ian.

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

Re: [Xen-devel] [PATCH] xen/x86: Map Xen code/data/bss with superpages

[Andrew Cooper]

On 18/02/16 18:03, Andrew Cooper wrote:
> And make use of NX and RO attributes wherever possible.
>
> Andrew Cooper (4):
>   xen: Introduce IS_ALIGNED()
>   xen/memguard: Drop memguard_init() entirely
>   xen/x86: Use 2M superpages for text/data/bss mappings
>   xen/x86: Unilaterally remove .init mappings

Apologies - I messed up with git format-patch and omitted the patch
numbers.  (at least there are only 4)

The patches are available on
http://xenbits.xen.org/git-http/people/andrewcoop/xen.git xen-super-v1

~Andrew

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

[Xen-devel] libxl and malloc failure (Re: Current LibXL Status)

[Ian Jackson]

Andrew Cooper writes ("Re: [Xen-devel] Current LibXL Status"):
> There really is a show-stopper, which I have stated before.
> 
> Languages such as OCaml use -ENOMEM as a hint to run the garbage
> collector some more.  I expect Haskell is the same.

This cannot possibly be true (if what you mean is that they use
ENOMEM[1] from malloc as such an indication).  It would make it
impossible to write a correct binding to a normal C library.

Typically C library which calls malloc will do so in the middle of its
execution.  Even if the library returns the resulting error up as
a distinguishable error code, you can't just make the same library
call again - it may have done half its work but not the other half.

So I think you must be wrong.

Ian.

[1] NB that when malloc fails there is no -ENOMEM, only ENOMEM.

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

[Xen-devel] [PATCH RFC] osstest: add a cd-{insert/eject} test for Debian HVM

[Roger Pau Monne]

It could/should be expanded to other guest types, but at least it's a start.
It should also test that the guest can correctly access the disk contents.

The only supported toolstack for this test is xl.

Signed-off-by: Roger Pau Monné 
---
CC: Ian Jackson 
---
 Osstest/TestSupport.pm  | 17 +
 Osstest/Toolstack/xl.pm | 18 ++
 sg-run-job  |  1 +
 ts-hvm-cd   | 31 +++
 4 files changed, 67 insertions(+)
 create mode 100644 ts-hvm-cd

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 2141905..4445a04 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -2508,6 +2508,23 @@ sub guest_editconfig_nocd ($$) {
 });
 }
 
+# Both the insert/eject functions hardcode 'hdc' as the virtual cdrom unit,
+# if more_prepareguest_hvm is changed to use a different unit this is doomed
+# to fail.
+sub guest_eject_cd ($) {
+my ($gho) = @_;
+my $ho = $gho->{Host};
+die "xl is the only supported toolstack" if $tsname neq 'xl';
+toolstack($ho)->cd_eject($gho);
+}
+
+sub guest_insert_cd ($) {
+my ($gho) = @_;
+my $ho = $gho->{Host};
+die "xl is the only supported toolstack" if $tsname neq 'xl';
+toolstack($ho)->cd_insert($gho);
+}
+
 sub host_install_postboot_complete ($) {
 my ($ho) = @_;
 target_core_dump_setup($ho);
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
index d956bcd..b25b19c 100644
--- a/Osstest/Toolstack/xl.pm
+++ b/Osstest/Toolstack/xl.pm
@@ -118,4 +118,22 @@ sub block_attach () {
 target_cmd_root($ho, $cmd, 100);
 }
 
+sub cd_eject($$) {
+my ($self,$gho) = @_;
+my $ho = $self->{Host};
+my $gn = $gho->{Name};
+my $cmd = $self->{_VerboseCommand}." cd-eject $gn hdc";
+target_cmd_root($ho, $cmd, 100);
+}
+
+sub cd_insert($$) {
+my ($self,$gho) = @_;
+my $ho = $self->{Host};
+my $gn = $gho->{Name};
+my $iso = $gho->{Rimage};
+my $cmd = $self->{_VerboseCommand}." cd-insert $gn hdc $iso";
+target_cmd_root($ho, $cmd, 100);
+}
+
+
 1;
diff --git a/sg-run-job b/sg-run-job
index 3e0f966..43a141f 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -320,6 +320,7 @@ proc run-job/test-rhelhvm {} {
 proc need-hosts/test-debianhvm {} { return host }
 proc run-job/test-debianhvm {} {
 run-ts . = ts-debian-hvm-install
+run-ts . = ts-hvm-cd
 test-guest debianhvm
 }
 
diff --git a/ts-hvm-cd b/ts-hvm-cd
new file mode 100644
index 000..5776afd
--- /dev/null
+++ b/ts-hvm-cd
@@ -0,0 +1,31 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-2016 Citrix Inc.
+# 
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU Affero General Public License for more details.
+# 
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see .
+
+use strict qw(vars);
+use DBI;
+use Osstest;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+our $gho;
+
+guest_eject_cd($gho)
+sleep(10)
+guest_insert_cd($gho)
+sleep(10)
+guest_eject_cd($gho)
-- 
2.5.4 (Apple Git-61)


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

[Xen-devel] [PATCH] xen/x86: Unilaterally remove .init mappings

[Andrew Cooper]

Because of the new 2M alignment of .init and .bss, the existing memory
guarding infrastructure causes a shattered 2M superpage with non-present
entries for .init, and present entries for the alignment space.

Do away with the difference in behaviour between debug and non-debug builds;
always destroy the .init mappings, and reuse the space for xenheap.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/setup.c   | 24 +++-
 xen/arch/x86/xen.lds.S |  3 +++
 2 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index c360fbc..e6d1fe6 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -176,16 +176,6 @@ void __init discard_initial_images(void)
 initial_images = NULL;
 }
 
-static void free_xen_data(char *s, char *e)
-{
-#ifndef MEMORY_GUARD
-init_xenheap_pages(__pa(s), __pa(e));
-#endif
-memguard_guard_range(s, e-s);
-/* Also zap the mapping in the 1:1 area. */
-memguard_guard_range(__va(__pa(s)), e-s);
-}
-
 extern char __init_begin[], __init_end[], __bss_start[], __bss_end[];
 
 static void __init init_idle_domain(void)
@@ -509,13 +499,21 @@ static void __init kexec_reserve_area(struct e820map 
*e820)
 
 static void noinline init_done(void)
 {
+void *va;
+
 system_state = SYS_STATE_active;
 
 domain_unpause_by_systemcontroller(hardware_domain);
 
-/* Free (or page-protect) the init areas. */
-memset(__init_begin, 0xcc, __init_end - __init_begin); /* int3 poison */
-free_xen_data(__init_begin, __init_end);
+/* Zero the .init code and data. */
+for ( va = __init_begin; va < _p(__init_end); va += PAGE_SIZE )
+clear_page(va);
+
+/* Destroy Xen's mappings, and reuse the pages. */
+destroy_xen_mappings((unsigned long)&__2M_init_start,
+ (unsigned long)&__2M_init_end);
+init_xenheap_pages(__pa(__2M_init_start), __pa(__2M_init_end));
+
 printk("Freed %ldkB init memory.\n", (long)(__init_end-__init_begin)>>10);
 
 startup_cpu_idle_loop();
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 6c23c02..72578f0 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -263,3 +263,6 @@ ASSERT(IS_ALIGNED(__2M_bss_start,MB(2)), 
"__2M_bss_start misaligned")
 ASSERT(IS_ALIGNED(__2M_bss_end,  MB(2)), "__2M_bss_end misaligned")
 
 ASSERT(IS_ALIGNED(cpu0_stack, STACK_SIZE), "cpu0_stack misaligned")
+
+ASSERT(IS_ALIGNED(__init_begin, PAGE_SIZE), "__init_begin misaligned")
+ASSERT(IS_ALIGNED(__init_end,   PAGE_SIZE), "__init_end misaligned")
-- 
2.1.4


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

[Xen-devel] [PATCH] xen/memguard: Drop memguard_init() entirely

[Andrew Cooper]

It is not obvious what this code is doing.  Most of it dates from 2007/2008,
and there have been substantial changes in Xen's memory handling since then.

It was previously optional, and isn't needed for any of the memguard
infrastructure to function.  The use of MAP_SMALL_PAGES causes needless
shattering of superpages.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Tim Deegan 
CC: Ian Campbell 
---
 xen/arch/x86/mm.c| 16 
 xen/arch/x86/setup.c |  2 --
 xen/include/asm-arm/mm.h |  1 -
 xen/include/asm-x86/mm.h |  2 --
 4 files changed, 21 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index d6aaed8..ed8ab02 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -6346,22 +6346,6 @@ void free_perdomain_mappings(struct domain *d)
 
 #ifdef MEMORY_GUARD
 
-void memguard_init(void)
-{
-unsigned long start = max_t(unsigned long, xen_phys_start, 1UL << 20);
-map_pages_to_xen(
-(unsigned long)__va(start),
-start >> PAGE_SHIFT,
-(__pa(&_end) + PAGE_SIZE - 1 - start) >> PAGE_SHIFT,
-__PAGE_HYPERVISOR_RW|MAP_SMALL_PAGES);
-BUG_ON(start != xen_phys_start);
-map_pages_to_xen(
-XEN_VIRT_START,
-start >> PAGE_SHIFT,
-(__pa(&_end) + PAGE_SIZE - 1 - start) >> PAGE_SHIFT,
-__PAGE_HYPERVISOR|MAP_SMALL_PAGES);
-}
-
 static void __memguard_change_range(void *p, unsigned long l, int guard)
 {
 unsigned long _p = (unsigned long)p;
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index b8a28d7..cddf954 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1146,8 +1146,6 @@ void __init noreturn __start_xen(unsigned long mbi_p)
~((1UL << L2_PAGETABLE_SHIFT) - 1);
 destroy_xen_mappings(xen_virt_end, XEN_VIRT_START + BOOTSTRAP_MAP_BASE);
 
-memguard_init();
-
 nr_pages = 0;
 for ( i = 0; i < e820.nr_map; i++ )
 if ( e820.map[i].type == E820_RAM )
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index 2e9d0b2..68cf203 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -331,7 +331,6 @@ unsigned long domain_get_maximum_gpfn(struct domain *d);
 
 extern struct domain *dom_xen, *dom_io, *dom_cow;
 
-#define memguard_init(_s)  (_s)
 #define memguard_guard_stack(_p)   ((void)0)
 #define memguard_guard_range(_p,_l)((void)0)
 #define memguard_unguard_range(_p,_l)  ((void)0)
diff --git a/xen/include/asm-x86/mm.h b/xen/include/asm-x86/mm.h
index a097382..23a4092 100644
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -479,11 +479,9 @@ extern struct rangeset *mmio_ro_ranges;
 #define compat_cr3_to_pfn(cr3) (((unsigned)(cr3) >> 12) | ((unsigned)(cr3) << 
20))
 
 #ifdef MEMORY_GUARD
-void memguard_init(void);
 void memguard_guard_range(void *p, unsigned long l);
 void memguard_unguard_range(void *p, unsigned long l);
 #else
-#define memguard_init()((void)0)
 #define memguard_guard_range(_p,_l)((void)0)
 #define memguard_unguard_range(_p,_l)  ((void)0)
 #endif
-- 
2.1.4


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

[Xen-devel] [PATCH] xen/x86: Use 2M superpages for text/data/bss mappings

[Andrew Cooper]

This balloons the size of Xen in memory from 3.4MB to 12MB, because of the
required alignment adjustments.

However
 * All mappings are 2M superpages.
 * .text (and .init at boot) are the only sections marked executable.
 * .text and .rodata are marked read-only.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/setup.c | 44 +---
 xen/arch/x86/xen.lds.S   | 33 +
 xen/include/xen/kernel.h |  6 ++
 3 files changed, 80 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index cddf954..c360fbc 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -921,13 +921,51 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 /* The only data mappings to be relocated are in the Xen area. */
 pl2e = __va(__pa(l2_xenmap));
 *pl2e++ = l2e_from_pfn(xen_phys_start >> PAGE_SHIFT,
-   PAGE_HYPERVISOR_RWX | _PAGE_PSE);
+   PAGE_HYPERVISOR_RX | _PAGE_PSE);
 for ( i = 1; i < L2_PAGETABLE_ENTRIES; i++, pl2e++ )
 {
+unsigned int flags;
+
 if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) )
 continue;
-*pl2e = l2e_from_intpte(l2e_get_intpte(*pl2e) +
-xen_phys_start);
+
+if ( /*
+  * Should be:
+  *
+  * i >= l2_table_offset((unsigned long)&__2M_text_start) 
&&
+  *
+  * but the EFI build can't manage the relocation.  It
+  * evaluates to 0, so just use the upper bound.
+  */
+ i < l2_table_offset((unsigned long)&__2M_text_end) )
+{
+flags = PAGE_HYPERVISOR_RX | _PAGE_PSE;
+}
+else if ( i >= l2_table_offset((unsigned 
long)&__2M_rodata_start) &&
+  i <  l2_table_offset((unsigned 
long)&__2M_rodata_end) )
+{
+flags = PAGE_HYPERVISOR_RO | _PAGE_PSE;
+}
+else if ( (i >= l2_table_offset((unsigned 
long)&__2M_data_start) &&
+   i <  l2_table_offset((unsigned 
long)&__2M_data_end)) ||
+  (i >= l2_table_offset((unsigned 
long)&__2M_bss_start) &&
+   i <  l2_table_offset((unsigned long)&__2M_bss_end)) 
)
+{
+flags = PAGE_HYPERVISOR_RW | _PAGE_PSE;
+}
+else if ( i >= l2_table_offset((unsigned 
long)&__2M_init_start) &&
+  i <  l2_table_offset((unsigned long)&__2M_init_end) )
+{
+flags = PAGE_HYPERVISOR_RWX | _PAGE_PSE;
+}
+else
+{
+*pl2e = l2e_empty();
+continue;
+}
+
+*pl2e = l2e_from_paddr(
+l2e_get_paddr(*pl2e) + xen_phys_start, flags);
 }
 
 /* Re-sync the stack and then switch to relocated pagetables. */
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 9fde1db..6c23c02 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -38,6 +38,9 @@ SECTIONS
   . = __XEN_VIRT_START;
   __image_base__ = .;
 #endif
+
+  __2M_text_start = .; /* Start of 2M superpages, mapped RX. */
+
   . = __XEN_VIRT_START + MB(1);
   _start = .;
   .text : {
@@ -50,6 +53,10 @@ SECTIONS
_etext = .; /* End of text section */
   } :text = 0x9090
 
+  . = ALIGN(MB(2));
+  __2M_text_end = .;
+
+  __2M_rodata_start = .;   /* Start of 2M superpages, mapped RO. */
   .rodata : {
/* Bug frames table */
. = ALIGN(4);
@@ -67,6 +74,10 @@ SECTIONS
*(.rodata.*)
   } :text
 
+  . = ALIGN(MB(2));
+  __2M_rodata_end = .;
+
+  __2M_data_start = .; /* Start of 2M superpages, mapped RW. */
   . = ALIGN(SMP_CACHE_BYTES);
   .data.read_mostly : {
/* Exception table */
@@ -104,6 +115,10 @@ SECTIONS
   __lock_profile_end = .;
 #endif
 
+  . = ALIGN(MB(2));
+  __2M_data_end = .;
+
+  __2M_init_start = .; /* Start of 2M superpages, mapped RWX (boot 
only). */
   . = ALIGN(PAGE_SIZE); /* Init code and data */
   __init_begin = .;
   .init.text : {
@@ -166,6 +181,10 @@ SECTIONS
   . = ALIGN(STACK_SIZE);
   __init_end = .;
 
+  . = ALIGN(MB(2));
+  __2M_init_end = .;
+
+  __2M_bss_start = .;  /* Start of 2M superpages, mapped RW. */
   .bss : { /* BSS */
__bss_start = .;
*(.bss.stack_aligned)
@@ -183,6 +202,9 @@ SECTIONS
   } :text
   _end = . ;
 
+  . = ALIGN(MB(2));
+  __2M_bss_end = .;
+
 #ifdef EFI
   . = ALIGN(4);
   .reloc : 

[Xen-devel] [PATCH] xen/x86: Map Xen code/data/bss with superpages

[Andrew Cooper]

And make use of NX and RO attributes wherever possible.

Andrew Cooper (4):
  xen: Introduce IS_ALIGNED()
  xen/memguard: Drop memguard_init() entirely
  xen/x86: Use 2M superpages for text/data/bss mappings
  xen/x86: Unilaterally remove .init mappings

 xen/arch/x86/mm.c  | 24 +++-
 xen/arch/x86/setup.c   | 70 ++
 xen/arch/x86/xen.lds.S | 38 -
 xen/include/asm-arm/mm.h   |  1 -
 xen/include/asm-x86/mm.h   |  2 --
 xen/include/xen/config.h   |  2 ++
 xen/include/xen/kernel.h   |  6 
 xen/include/xen/tmem_xen.h |  3 +-
 8 files changed, 102 insertions(+), 44 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH] xen: Introduce IS_ALIGNED()

[Andrew Cooper]

And a few open-coded alignment checks which I encountered

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Tim Deegan 
CC: Ian Campbell 
---
 xen/arch/x86/mm.c  | 8 
 xen/arch/x86/xen.lds.S | 2 +-
 xen/include/xen/config.h   | 2 ++
 xen/include/xen/tmem_xen.h | 3 +--
 4 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index ea3f9f2..d6aaed8 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5957,8 +5957,8 @@ void destroy_xen_mappings(unsigned long s, unsigned long 
e)
 unsigned int  i;
 unsigned long v = s;
 
-ASSERT((s & ~PAGE_MASK) == 0);
-ASSERT((e & ~PAGE_MASK) == 0);
+ASSERT(IS_ALIGNED(s, PAGE_SIZE));
+ASSERT(IS_ALIGNED(e, PAGE_SIZE));
 
 while ( v < e )
 {
@@ -6369,8 +6369,8 @@ static void __memguard_change_range(void *p, unsigned 
long l, int guard)
 unsigned int flags = __PAGE_HYPERVISOR_RW | MAP_SMALL_PAGES;
 
 /* Ensure we are dealing with a page-aligned whole number of pages. */
-ASSERT((_p&~PAGE_MASK) == 0);
-ASSERT((_l&~PAGE_MASK) == 0);
+ASSERT(IS_ALIGNED(_p, PAGE_SIZE));
+ASSERT(IS_ALIGNED(_l, PAGE_SIZE));
 
 if ( guard )
 flags &= ~_PAGE_PRESENT;
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 3b199ca..9fde1db 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -229,4 +229,4 @@ ASSERT(__image_base__ > XEN_VIRT_START ||
 ASSERT(kexec_reloc_size - kexec_reloc <= PAGE_SIZE, "kexec_reloc is too large")
 #endif
 
-ASSERT((cpu0_stack & (STACK_SIZE - 1)) == 0, "cpu0_stack misaligned")
+ASSERT(IS_ALIGNED(cpu0_stack, STACK_SIZE), "cpu0_stack misaligned")
diff --git a/xen/include/xen/config.h b/xen/include/xen/config.h
index a992933..bd78176 100644
--- a/xen/include/xen/config.h
+++ b/xen/include/xen/config.h
@@ -74,6 +74,8 @@
 #define MB(_mb) (_AC(_mb, ULL) << 20)
 #define GB(_gb) (_AC(_gb, ULL) << 30)
 
+#define IS_ALIGNED(val, align) (((val) & ((align) - 1)) == 0)
+
 #define __STR(...) #__VA_ARGS__
 #define STR(...) __STR(__VA_ARGS__)
 
diff --git a/xen/include/xen/tmem_xen.h b/xen/include/xen/tmem_xen.h
index 0fdbf68..c770f3e 100644
--- a/xen/include/xen/tmem_xen.h
+++ b/xen/include/xen/tmem_xen.h
@@ -23,8 +23,7 @@
 #endif
 typedef uint32_t pagesize_t;  /* like size_t, must handle largest PAGE_SIZE */
 
-#define IS_PAGE_ALIGNED(addr) \
-  ((void *)unsigned long)addr + (PAGE_SIZE - 1)) & PAGE_MASK)) == addr)
+#define IS_PAGE_ALIGNED(addr) IS_ALIGNED((unsigned long)(addr), PAGE_SIZE)
 #define IS_VALID_PAGE(_pi)  ( mfn_valid(page_to_mfn(_pi)) )
 
 extern struct page_list_head tmem_page_list;
-- 
2.1.4


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

Re: [Xen-devel] Current LibXL Status

[Ian Campbell]

On Thu, 2016-02-18 at 17:39 +, Ian Campbell wrote:
> On Thu, 2016-02-18 at 17:26 +, George Dunlap wrote:
> 
> > According to them, the ocaml garbage collector never frees memory.  It
> > grows its own internal heap as necessary, but it never reduces the
> > size of its heap.
> 
> Assume that's true: Wow!

https://github.com/ocaml/ocaml/blob/trunk/byterun/compact.c#L374
is a call by do_compaction to caml_shrink_heap at
https://github.com/ocaml/ocaml/blob/trunk/byterun/memory.c#L408
which calls caml_free_for_heap at
https://github.com/ocaml/ocaml/blob/trunk/byterun/memory.c#L290
which certainly looks like it is returning memory to the malloc pool.

Maybe this never happens in practice for some reason, or perhaps the
"byterun" in those paths is relevant? I couldn't find another heap
implementation which would be associated with native binaries.

http://caml.inria.fr/mantis/view.php?id=5389 also seems to suggest that it
is expected for the heap to shrink (i.e. it was considered a bug that it
did not in this case).

Ian.

> 
> Although, I presume this is a factor of the current/particular
> implementation, rather than a fundamental property of an ocaml runtime,
> so
> in theory it could change (and we have here a good real world argument
> why
> it perhaps should do!)
> 
> > So no -ENOMEM call or OOM callback can make a failed malloc succeed.
> > 
> > One might then ask if libxl could simply allocate memory *from the
> > ocaml heap* itself.  It turns out that is also not tenable: Data in
> > the ocaml heap is stored in a heavily coded format.  (For example
> > integers are stored as (n*2+1), so that pointers can all be even and
> > non-pointers can all be odd.)
> > 
> > The only thing they said might be improved is:
> > 
> > 1.  To know that libxl would never call exit() for any other reason
> > (which it seems is true)
> > 
> > 2. To  have a callback in OOM conditions.  It's unlikely the process
> > as a whole could do anything but exit, but the ocaml runtime itself
> > might still have internal heap available, which would allow it to exit
> > more gracefully.
> > 
> > I think if Haskell or any library *is* capable of integrating with the
> > garbage collector, we'll have to wait until someone who understands
> > the language actually writes bindings and can ask for something they
> > know to be useful for that language.
> 
> Agreed.
> 
> Hopefully it is possible to make the callback without needing to malloc
> anything!
> 
> If I were adding an API for #2 to libxl (which must therefore be stable)
> I
> think I might be inclined to allow for the possibility of the callback
> returning "please retry" since it would be inconvenient in the usual API
> stability ways to retrofit it, I would guess, but really until a language
> even exposes that possibility we don't really know if it is worthwhile
> doing so.
> 
> Ian.

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

Re: [Xen-devel] Current LibXL Status

[George Dunlap]

On Thu, Feb 18, 2016 at 5:39 PM, Ian Campbell  wrote:
> On Thu, 2016-02-18 at 17:26 +, George Dunlap wrote:
>
>> According to them, the ocaml garbage collector never frees memory.  It
>> grows its own internal heap as necessary, but it never reduces the
>> size of its heap.
>
> Assume that's true: Wow!
>
> Although, I presume this is a factor of the current/particular
> implementation, rather than a fundamental property of an ocaml runtime, so
> in theory it could change (and we have here a good real world argument why
> it perhaps should do!)
>
>> So no -ENOMEM call or OOM callback can make a failed malloc succeed.
>>
>> One might then ask if libxl could simply allocate memory *from the
>> ocaml heap* itself.  It turns out that is also not tenable: Data in
>> the ocaml heap is stored in a heavily coded format.  (For example
>> integers are stored as (n*2+1), so that pointers can all be even and
>> non-pointers can all be odd.)
>>
>> The only thing they said might be improved is:
>>
>> 1.  To know that libxl would never call exit() for any other reason
>> (which it seems is true)
>>
>> 2. To  have a callback in OOM conditions.  It's unlikely the process
>> as a whole could do anything but exit, but the ocaml runtime itself
>> might still have internal heap available, which would allow it to exit
>> more gracefully.
>>
>> I think if Haskell or any library *is* capable of integrating with the
>> garbage collector, we'll have to wait until someone who understands
>> the language actually writes bindings and can ask for something they
>> know to be useful for that language.
>
> Agreed.
>
> Hopefully it is possible to make the callback without needing to malloc
> anything!
>
> If I were adding an API for #2 to libxl (which must therefore be stable) I
> think I might be inclined to allow for the possibility of the callback
> returning "please retry" since it would be inconvenient in the usual API
> stability ways to retrofit it, I would guess, but really until a language
> even exposes that possibility we don't really know if it is worthwhile
> doing so.

Well we could just make the semantics such that if the callback
returns at all, that libxl should retry.  That shouldn't be
particularly harder than just making a callback we don't expect to
ever return (which is what it sounds like the xapi folks would be
happy with).  Then when we come across a language runtime /
application that *can* do something useful, it might possibly Just
Work; but if it doesn't we can implement what they actually need.

 -George

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

Re: [Xen-devel] Current LibXL Status

[George Dunlap]

On Thu, Feb 18, 2016 at 5:26 PM, Ian Campbell  wrote:
> On Thu, 2016-02-18 at 17:19 +, Ian Jackson wrote:
>> George Dunlap writes ("Re: [Xen-devel] Current LibXL Status"):
>> > So what was the conclusion here?  It looks like we've confirmed that
>> > exit() is only called:
>> >
>> > 1. In the case of a malloc() failure
>> > 2. in libxl-save-helper (a separate process forked by the library)
>> > 3. In libxl__event_disaster(), if no callback is provided
>>   4. In other processes forked by the library
>>
>> But, yes,l basically.
>>
>> > Which just leaves #1 as something to be discussed?
>>
>> Is this crashing on malloc failure a problem ?
>
> It is for non-C language bindings which might be using garbage collection,
> since they might be OOM from a malloc perspective but actually have loads
> of spare memory waiting to be collected (which they might plausibly be
> doing quite lazily).
>
> I just reminded people of my proposal to provide a callback to allow the
> app/bindings to run their gc here in my reply to George before I saw your
> reply.
>
>> From the point of view of libxl's innards, making malloc failures
>> fatal means that nothing that allocates memory needs to care about
>> malloc failures.  That massively reduces the number of error paths to
>> be considered and eliminates an entire class of (largely theoretical)
>> bugs.
>>
>> And often there is no good recovery possible (and logging the error is
>> hard too).
>>
>> I'm not sure whether I'd want to change this policy even if someone
>> wanted to commit to auditing libxl and submitting the necessary
>> patches to cope with every malloc failure.  Having to cope with malloc
>> failure would be a continual burden on every proposed change or new
>> feature.
>
> I agree that we don't want to change this policy, but I think an OOM hook
> is sufficient to solve the actual problem.

And in the situation like ocaml seems to be at the moment, it also
gives the process an opportunity to attempt to shut down as gracefully
as it can even if it knows it can't free up any more memory to libxl.
(And who knows, some future version of ocaml may even allow you to ask
to shrink the heap.)

 -George

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

Re: [Xen-devel] Current LibXL Status

[Ian Campbell]

On Thu, 2016-02-18 at 17:26 +, George Dunlap wrote:

> According to them, the ocaml garbage collector never frees memory.  It
> grows its own internal heap as necessary, but it never reduces the
> size of its heap.

Assume that's true: Wow!

Although, I presume this is a factor of the current/particular
implementation, rather than a fundamental property of an ocaml runtime, so
in theory it could change (and we have here a good real world argument why
it perhaps should do!)

> So no -ENOMEM call or OOM callback can make a failed malloc succeed.
> 
> One might then ask if libxl could simply allocate memory *from the
> ocaml heap* itself.  It turns out that is also not tenable: Data in
> the ocaml heap is stored in a heavily coded format.  (For example
> integers are stored as (n*2+1), so that pointers can all be even and
> non-pointers can all be odd.)
> 
> The only thing they said might be improved is:
> 
> 1.  To know that libxl would never call exit() for any other reason
> (which it seems is true)
> 
> 2. To  have a callback in OOM conditions.  It's unlikely the process
> as a whole could do anything but exit, but the ocaml runtime itself
> might still have internal heap available, which would allow it to exit
> more gracefully.
> 
> I think if Haskell or any library *is* capable of integrating with the
> garbage collector, we'll have to wait until someone who understands
> the language actually writes bindings and can ask for something they
> know to be useful for that language.

Agreed.

Hopefully it is possible to make the callback without needing to malloc
anything!

If I were adding an API for #2 to libxl (which must therefore be stable) I
think I might be inclined to allow for the possibility of the callback
returning "please retry" since it would be inconvenient in the usual API
stability ways to retrofit it, I would guess, but really until a language
even exposes that possibility we don't really know if it is worthwhile
doing so.

Ian.

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

Re: [Xen-devel] Current LibXL Status

[Ian Campbell]

On Thu, 2016-02-18 at 17:19 +, Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] Current LibXL Status"):
> > So what was the conclusion here?  It looks like we've confirmed that
> > exit() is only called:
> > 
> > 1. In the case of a malloc() failure
> > 2. in libxl-save-helper (a separate process forked by the library)
> > 3. In libxl__event_disaster(), if no callback is provided
>   4. In other processes forked by the library
> 
> But, yes,l basically.
> 
> > Which just leaves #1 as something to be discussed?
> 
> Is this crashing on malloc failure a problem ?

It is for non-C language bindings which might be using garbage collection,
since they might be OOM from a malloc perspective but actually have loads
of spare memory waiting to be collected (which they might plausibly be
doing quite lazily).

I just reminded people of my proposal to provide a callback to allow the
app/bindings to run their gc here in my reply to George before I saw your
reply.

> From the point of view of libxl's innards, making malloc failures
> fatal means that nothing that allocates memory needs to care about
> malloc failures.  That massively reduces the number of error paths to
> be considered and eliminates an entire class of (largely theoretical)
> bugs.
> 
> And often there is no good recovery possible (and logging the error is
> hard too).
> 
> I'm not sure whether I'd want to change this policy even if someone
> wanted to commit to auditing libxl and submitting the necessary
> patches to cope with every malloc failure.  Having to cope with malloc
> failure would be a continual burden on every proposed change or new
> feature.

I agree that we don't want to change this policy, but I think an OOM hook
is sufficient to solve the actual problem.


> If in practice this is a problem it would probaby be better to run
> libxl in a process which can be restarted if it dies due to malloc
> failure.
> 
> Ian.

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

Re: [Xen-devel] Current LibXL Status

[George Dunlap]

On Thu, Nov 19, 2015 at 11:23 AM, Ian Campbell  wrote:
> create !
> title it libxl exit() on ENOMEM incompatible with gc'd languages
> thanks
>
> On Thu, 2015-11-19 at 10:55 +, Andrew Cooper wrote:
>> On 19/11/15 09:20, Ian Campbell wrote:
>> > On Wed, 2015-11-18 at 18:32 +, Martin Osterloh wrote:
>> >
>> > > I wanted to inquire about the current state of LibXL and in
>> > > particular
>> > > if there are any issues with using it in long-running processes.
>> > It is currently being used by libvirtd which I think has shaken out
>> > most of
>> > the issues with that environment.
>> >
>> > There are certain to be other bugs, but nothing show-stopping.
[snip]
>> Languages such as OCaml use -ENOMEM as a hint to run the garbage
>> collector some more.  I expect Haskell is the same.

So the implication you've made here, is that if libxl were to return
-ENOMEM to ocaml, that it would run the garbage collector and free up
some heap space, so that malloc() could succeed and the libxl
operation could proceed.

In preparation for writing up a descripion for an "outreach project"
(Outreachy/OPW/GSoC), I went and had a chat with some of the guys on
the xapi team (cc'd) about what such a thing might look like.

According to them, the ocaml garbage collector never frees memory.  It
grows its own internal heap as necessary, but it never reduces the
size of its heap.  So no -ENOMEM call or OOM callback can make a
failed malloc succeed.

One might then ask if libxl could simply allocate memory *from the
ocaml heap* itself.  It turns out that is also not tenable: Data in
the ocaml heap is stored in a heavily coded format.  (For example
integers are stored as (n*2+1), so that pointers can all be even and
non-pointers can all be odd.)

The only thing they said might be improved is:

1.  To know that libxl would never call exit() for any other reason
(which it seems is true)

2. To  have a callback in OOM conditions.  It's unlikely the process
as a whole could do anything but exit, but the ocaml runtime itself
might still have internal heap available, which would allow it to exit
more gracefully.

I think if Haskell or any library *is* capable of integrating with the
garbage collector, we'll have to wait until someone who understands
the language actually writes bindings and can ask for something they
know to be useful for that language.

 -George

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

Re: [Xen-devel] Current LibXL Status

[Ian Campbell]

On Thu, 2016-02-18 at 17:09 +, George Dunlap wrote:
> On Thu, Nov 19, 2015 at 12:16 PM, Ian Campbell 
> wrote:
> > On Thu, 2015-11-19 at 11:55 +, Ian Campbell wrote:
> > > On Thu, 2015-11-19 at 11:48 +, Ian Campbell wrote:
> > > > On Thu, 2015-11-19 at 11:33 +, Andrew Cooper wrote:
> > > > > 
> > > > > The majority of those are cases are not appropriate uses of
> > > > > exit().
> > > > > AFAIIR, the *only* valid use of exit() in a library is to clean
> > > > > up in
> > > > > a
> > > > > child process from a library-initiated fork().
> > > > 
> > > > ... or (in this case) in the libxl-save-helper (separate process).
> > > > 
> > > > The only one I can find which isn't one of this is
> > > > in libxl__event_disaster, and that is only if the applications (or
> > > > language
> > > > bindings) haven't provided a suitable disaster callback.
> > > 
> > > Was looking at 4.4, in staging I also see a very odd one in
> > > drbd_preresume_async, which isn't obviously in a child process
> > > AFAICT.
> > > 
> > > Hongyang, what prevents that exit from killing the whole toolstack
> > > process?
> > 
> > I had missed an _async suffix on that function versus the one which was
> > the
> > actual callback, it is invoked via drbd_async_call which involves a
> > fork().
> 
> So what was the conclusion here?  It looks like we've confirmed that
> exit() is only called:
> 
> 1. In the case of a malloc() failure
> 2. in libxl-save-helper (a separate process forked by the library)
> 3. In libxl__event_disaster(), if no callback is provided
> 
> Which just leaves #1 as something to be discussed?

Somewhere/when I proposed handling #1 by having the small number of places
which call libxl__alloc_failed() call an application (or language binding)
provided "please free some memory" hook (i.e. "please run your garbage
collector") and then retry some appropriate number of times. Perhaps with
an error code available for the hook to say "this is never going to help".

There's less than a dozen such call sites so this is quite doable, vastly
so compared with adding OOM error handling and reporting back up the
callchain to all libxl functions.

Ian.

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

Re: [Xen-devel] libxl_device handling for nic and vtmp

[Wei Liu]

On Thu, Feb 18, 2016 at 06:19:07PM +0100, Olaf Hering wrote:
> On Thu, Feb 18, Wei Liu wrote:
> 
> > Sorry I don't follow. What do you mean by 1:1 copy? Why does it make the
> > update unnecessary?
> 
> The current code does:
> 
>   libxl_device_nic_init(_saved);
>   libxl_device_nic_copy(CTX, _saved, nic);
>   nic->devid = libxl__device_nextid(gc, domid, "vif");
>   libxl__update_config_nic(gc, _saved, nic);
> 
> Which is equivalent to the more obvious version:
> 
>   libxl_device_nic_init(_saved);
>   nic->devid = libxl__device_nextid(gc, domid, "vif");
>   libxl_device_nic_copy(CTX, _saved, nic);
> 
> The input gets modified either way. Is it expected that future versions
> of libxl_device_nic/vtmp_copy will not duplicate the mac/uuid parts?
> 

You missed libxl__device_nic_setdefault -- it changes fields in the
structure.

Wei.

> 
> Olaf

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

Re: [Xen-devel] Current LibXL Status

[Ian Jackson]

George Dunlap writes ("Re: [Xen-devel] Current LibXL Status"):
> So what was the conclusion here?  It looks like we've confirmed that
> exit() is only called:
> 
> 1. In the case of a malloc() failure
> 2. in libxl-save-helper (a separate process forked by the library)
> 3. In libxl__event_disaster(), if no callback is provided
  4. In other processes forked by the library

But, yes,l basically.

> Which just leaves #1 as something to be discussed?

Is this crashing on malloc failure a problem ?

>From the point of view of libxl's innards, making malloc failures
fatal means that nothing that allocates memory needs to care about
malloc failures.  That massively reduces the number of error paths to
be considered and eliminates an entire class of (largely theoretical)
bugs.

And often there is no good recovery possible (and logging the error is
hard too).

I'm not sure whether I'd want to change this policy even if someone
wanted to commit to auditing libxl and submitting the necessary
patches to cope with every malloc failure.  Having to cope with malloc
failure would be a continual burden on every proposed change or new
feature.

If in practice this is a problem it would probaby be better to run
libxl in a process which can be restarted if it dies due to malloc
failure.

Ian.

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

Re: [Xen-devel] [PATCH v3 08/10] xen: add capability to load initrd outside of initial mapping

[Daniel Kiper]

On Thu, Feb 18, 2016 at 01:43:33PM +0100, Juergen Gross wrote:
> On 18/02/16 12:18, Daniel Kiper wrote:
> > On Wed, Feb 17, 2016 at 06:19:35PM +0100, Juergen Gross wrote:
> >> Modern pvops linux kernels support an initrd not covered by the initial
> >> mapping. This capability is flagged by an elf-note.
> >>
> >> In case the elf-note is set by the kernel don't place the initrd into
> >> the initial mapping. This will allow to load larger initrds and/or
> >> support domains with larger memory, as the initial mapping is limited
> >> to 2GB and it is containing the p2m list.
> >>
> >> Signed-off-by: Juergen Gross 
> >
> > One nitpick.
> >
> > Reviewed-by: Daniel Kiper 
> >
> >> ---
> >>  grub-core/loader/i386/xen.c| 61 
> >> ++
> >>  grub-core/loader/i386/xen_fileXX.c |  3 ++
> >>  include/grub/xen_file.h|  1 +
> >>  3 files changed, 52 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/grub-core/loader/i386/xen.c b/grub-core/loader/i386/xen.c
> >> index 3bcf4c8..7ac74f6 100644
> >> --- a/grub-core/loader/i386/xen.c
> >> +++ b/grub-core/loader/i386/xen.c
> >> @@ -58,6 +58,7 @@ struct xen_loader_state {
> >>grub_uint64_t modules_target_start;
> >>grub_size_t n_modules;
> >>int loaded;
> >> +  int alloc_end_called;
> >>  };
> >>
> >>  static struct xen_loader_state xen_state;
> >> @@ -320,6 +321,28 @@ grub_xen_pt_alloc (void)
> >>  }
> >>
> >>  static grub_err_t
> >> +grub_xen_alloc_end (void)
> >
> > Why is it called grub_xen_alloc_end()?
> > Could we use just grub_xen_alloc()?
>
> We could, of course. I just wanted to make clear that this function will
> do the allocations needed to be at the end of the allocation process.
> Naming it grub_xen_alloc() would make it occur to be a very basic
> allocation function, which just isn't true. What about
> grub_xen_alloc_rest()?

My order of preference is: grub_xen_alloc_final() or grub_xen_alloc_last() or
grub_xen_alloc_end() or grub_xen_alloc_rest().

Choose one which is best for you.

Daniel

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

Re: [Xen-devel] libxl_device handling for nic and vtmp

[Olaf Hering]

On Thu, Feb 18, Wei Liu wrote:

> Sorry I don't follow. What do you mean by 1:1 copy? Why does it make the
> update unnecessary?

The current code does:

  libxl_device_nic_init(_saved);
  libxl_device_nic_copy(CTX, _saved, nic);
  nic->devid = libxl__device_nextid(gc, domid, "vif");
  libxl__update_config_nic(gc, _saved, nic);

Which is equivalent to the more obvious version:

  libxl_device_nic_init(_saved);
  nic->devid = libxl__device_nextid(gc, domid, "vif");
  libxl_device_nic_copy(CTX, _saved, nic);

The input gets modified either way. Is it expected that future versions
of libxl_device_nic/vtmp_copy will not duplicate the mac/uuid parts?


Olaf

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

Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support for Xen

[Jan Beulich]

>>> On 01.02.16 at 06:44,  wrote:
>  This design treats host NVDIMM devices as ordinary MMIO devices:

Wrt the cachability note earlier on, I assume you're aware that with
the XSA-154 changes we disallow any cachable mappings of MMIO
by default.

>  (1) Dom0 Linux NVDIMM driver is responsible to detect (through NFIT)
>  and drive host NVDIMM devices (implementing block device
>  interface). Namespaces and file systems on host NVDIMM devices
>  are handled by Dom0 Linux as well.
> 
>  (2) QEMU mmap(2) the pmem NVDIMM devices (/dev/pmem0) into its
>  virtual address space (buf).
> 
>  (3) QEMU gets the host physical address of buf, i.e. the host system
>  physical address that is occupied by /dev/pmem0, and calls Xen
>  hypercall XEN_DOMCTL_memory_mapping to map it to a DomU.
> 
>  (ACPI part is described in Section 3.3 later)
> 
>  Above (1)(2) have already been done in current QEMU. Only (3) is
>  needed to implement in QEMU. No change is needed in Xen for address
>  mapping in this design.
> 
>  Open: It seems no system call/ioctl is provided by Linux kernel to
>get the physical address from a virtual address.
>/proc//pagemap provides information of mapping from
>VA to PA. Is it an acceptable solution to let QEMU parse this
>file to get the physical address?
> 
>  Open: For a large pmem, mmap(2) is very possible to not map all SPA
>occupied by pmem at the beginning, i.e. QEMU may not be able to
>get all SPA of pmem from buf (in virtual address space) when
>calling XEN_DOMCTL_memory_mapping.
>Can mmap flag MAP_LOCKED or mlock(2) be used to enforce the
>entire pmem being mmaped?

A fundamental question I have here is: Why does qemu need to
map this at all? It shouldn't itself need to access those ranges,
since the guest is given direct access. It would seem quite a bit
more natural if qemu simply inquired to underlying GFN range(s)
and handed those to Xen for translation to MFNs and mapping
into guest space.

>  I notice that current XEN_DOMCTL_memory_mapping does not make santiy
>  check for the physical address and size passed from caller
>  (QEMU). Can QEMU be always trusted? If not, we would need to make Xen
>  aware of the SPA range of pmem so that it can refuse map physical
>  address in neither the normal ram nor pmem.

I'm not sure what missing sanity checks this is about: The handling
involves two iomem_access_permitted() calls.

> 3.3 Guest ACPI Emulation
> 
> 3.3.1 My Design
> 
>  Guest ACPI emulation is composed of two parts: building guest NFIT
>  and SSDT that defines ACPI namespace devices for NVDIMM, and
>  emulating guest _DSM.
> 
>  (1) Building Guest ACPI Tables
> 
>   This design reuses and extends hvmloader's existing mechanism that
>   loads passthrough ACPI tables from binary files to load NFIT and
>   SSDT tables built by QEMU:
>   1) Because the current QEMU does not building any ACPI tables when
>  it runs as the Xen device model, this design needs to patch QEMU
>  to build NFIT and SSDT (so far only NFIT and SSDT) in this case.
> 
>   2) QEMU copies NFIT and SSDT to the end of guest memory below
>  4G. The guest address and size of those tables are written into
>  xenstore (/local/domain/domid/hvmloader/dm-acpi/{address,length}).
> 
>   3) hvmloader is patched to probe and load device model passthrough
>  ACPI tables from above xenstore keys. The detected ACPI tables
>  are then appended to the end of existing guest ACPI tables just
>  like what current construct_passthrough_tables() does.
> 
>   Reasons for this design are listed below:
>   - NFIT and SSDT in question are quite self-contained, i.e. they do
> not refer to other ACPI tables and not conflict with existing
> guest ACPI tables in Xen. Therefore, it is safe to copy them from
> QEMU and append to existing guest ACPI tables.

How is this not conflicting being guaranteed? In particular I don't
see how tables containing AML code and coming from different
sources won't possibly cause ACPI name space collisions.

> 3.3.3 Alternative Design 2: keeping in Xen
> 
>  Alternative to switching to QEMU, another design would be building
>  NFIT and SSDT in hvmloader or toolstack.
> 
>  The amount and parameters of sub-structures in guest NFIT vary
>  according to different vNVDIMM configurations that can not be decided
>  at compile-time. In contrast, current hvmloader and toolstack can
>  only build static ACPI tables, i.e. their contents are decided
>  statically at compile-time and independent from the guest
>  configuration. In order to build guest NFIT at runtime, this design
>  may take following steps:
>  (1) xl converts NVDIMM configurations in xl.cfg to corresponding QEMU
>  options,
> 
>  (2) QEMU accepts above options, figures out the start SPA range
>  address/size/NVDIMM device handles/..., and writes them in
>  xenstore. No ACPI table is built by 

Re: [Xen-devel] libxl_device handling for nic and vtmp

[Wei Liu]

On Thu, Feb 18, 2016 at 05:54:38PM +0100, Olaf Hering wrote:
> On Thu, Feb 18, Wei Liu wrote:
> 
> > For example, user might not have specified mac address so the library
> > generates one for (s)he. You don't want mac address to regenerate after
> > save / restore or migration.  But you don't want to preserve all
> > autogenerated state, so you use the original copy as template and fill
> > it up as you see fit.
> 
> How does that fit into DEFINE_DEVICE_ADD? The functions do 1:1 copies,
> calling libxl__update_config_* looks unnecessary.
> 

Sorry I don't follow. What do you mean by 1:1 copy? Why does it make the
update unnecessary?

As said, we want some of the states but not all.

Wei.

> Olaf

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

Re: [Xen-devel] [PATCH v3 03/10] xen: add elfnote.h to avoid using numbers instead of constants

[Daniel Kiper]

On Thu, Feb 18, 2016 at 11:35:52AM +0100, Juergen Gross wrote:
> On 18/02/16 11:30, Daniel Kiper wrote:
> > On Wed, Feb 17, 2016 at 06:19:30PM +0100, Juergen Gross wrote:
> >> Various features and parameters of a pv-kernel are specified via
> >> elf notes in the kernel image. Those notes are part of the interface
> >> between the Xen hypervisor and the kernel.
> >>
> >> Instead of using num,bers in the code when interpreting the elf notes
> >> make use of the header supplied by Xen for that purpose.
> >>
> >> Signed-off-by: Juergen Gross 
> >
> > Yummy! Just one nitpick.
> >
> > Reviewed-by: Daniel Kiper 
> >
> >> ---
> >>  grub-core/loader/i386/xen_fileXX.c |  19 +--
> >>  include/xen/elfnote.h  | 281 
> >> +
> >>  2 files changed, 291 insertions(+), 9 deletions(-)
> >>  create mode 100644 include/xen/elfnote.h

[...]

> >> +/*
> >> + * Local variables:
> >> + * mode: C
> >> + * c-file-style: "BSD"
> >> + * c-basic-offset: 4
> >> + * tab-width: 4
> >> + * indent-tabs-mode: nil
> >> + * End:
> >> + */
> >
> > I am not sure that Emacs footer should be copied to GRUB2 source.
>
> Other xen include files contain it, too.

If maintainer do not complain I will do not object.

Daniel

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

[Xen-devel] [PATCH OSSTEST] crontab: adjust to remove "." from mg-list-all-branches output

[Ian Campbell]

The regex in mg-list-all-branches assumes that the BRANCHES= will
either be a singleton entry separated from the following command by a hard tab
or a single quoted list of space separated entries, however the
xen-unstable-coverity line is singleton separated from the command by a single
space.

Rather than using a hard tab (which ends up aligning things in an
aesthetically displeasing way) simply quote the single list entry.

This will (I assume) have the effect of removing this line from
http://logs.test-lab.xenproject.org/osstest/results/all-branch-statuses.txt:

. Error!  0-   n/an/a

Signed-off-by: Ian Campbell 
---
 crontab | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/crontab b/crontab
index 2cfad74..c8d8cac 100755
--- a/crontab
+++ b/crontab
@@ -8,7 +8,7 @@ MAILTO=ian.jack...@citrix.com,ian.campb...@eu.citrix.com
 0  *   * * *   cd testing.git && 
BRANCHES=xen-unstable-smoke   ./cr-for-branches branches -q "./cr-daily-branch 
--real"
 4-59/30*   * * *   cd testing.git &&   
./cr-for-branches branches -q "./cr-daily-branch --real"
 18 9   * * 1,3,5   cd testing.git && BRANCHES=linux-next   
./cr-for-branches branches -w "./cr-daily-branch --real"
-18 9   * * 3,7 cd testing.git && 
BRANCHES=xen-unstable-coverity ./cr-for-branches branches -w "./cr-daily-branch 
--real"
+18 9   * * 3,7 cd testing.git && 
BRANCHES='xen-unstable-coverity' ./cr-for-branches branches -w 
"./cr-daily-branch --real"
 18 4   * * *   cd testing.git && BRANCHES='linux-linus 
linux-mingo-tip-master linux-3.0 libvirt rumpuserxen' ./cr-for-branches 
branches -w "./cr-daily-branch --real"
 6-59/15*   * * *   cd testing.git && 
EXTRA_BRANCHES='linux-linus linux-3.0 rumpuserxen libvirt' ./cr-for-branches 
bisects -w "./cr-try-bisect --real"
 #8-59/5*   * * *   cd bisects/adhoc.git && 
with-lock-ex -q data-tree-lock bash -c "./cr-try-bisect-adhoc; exit $?"
-- 
2.6.1


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

Re: [Xen-devel] [PATCH v3 02/10] xen: reduce number of global variables in xen loader

[Daniel Kiper]

On Thu, Feb 18, 2016 at 11:34:49AM +0100, Juergen Gross wrote:
> On 18/02/16 11:22, Daniel Kiper wrote:
> > On Wed, Feb 17, 2016 at 06:19:29PM +0100, Juergen Gross wrote:
> >> The loader for xen paravirtualized environment is using lots of global
> >> variables. Reduce the number by making them either local or by putting
> >> them into a single state structure.
> >>
> >> Signed-off-by: Juergen Gross 
> >
> > Just two nitpicks but in general...
> >
> > Reviewed-by: Daniel Kiper 
> >
> >> ---
> >>  grub-core/loader/i386/xen.c | 259 
> >> +++-
> >>  1 file changed, 138 insertions(+), 121 deletions(-)

[...]

> >> -  if (!xen_module_info_page)
> >> +  if (!xen_state.module_info_page)
> >>  {
> >> -  n_modules = 0;
> >> -  max_addr = ALIGN_UP (max_addr, PAGE_SIZE);
> >> -  modules_target_start = max_addr;
> >> -  next_start.mod_start = max_addr + xen_inf.virt_base;
> >> -  next_start.flags |= SIF_MULTIBOOT_MOD;
> >> +  xen_state.n_modules = 0;
> >> +  xen_state.max_addr = ALIGN_UP (xen_state.max_addr, PAGE_SIZE);
> >> +  xen_state.modules_target_start = xen_state.max_addr;
> >> +  xen_state.next_start.mod_start =
> >> +  xen_state.max_addr + xen_state.xen_inf.virt_base;
> >
> > Lost one space.
>
> Really? Common indentation style seams to be to use tabs where possible.
> And this is a tab.

Sorry, I have missed that.

Daniel

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

Re: [Xen-devel] Current LibXL Status

[George Dunlap]

On Thu, Nov 19, 2015 at 12:16 PM, Ian Campbell  wrote:
> On Thu, 2015-11-19 at 11:55 +, Ian Campbell wrote:
>> On Thu, 2015-11-19 at 11:48 +, Ian Campbell wrote:
>> > On Thu, 2015-11-19 at 11:33 +, Andrew Cooper wrote:
>> > >
>> > > The majority of those are cases are not appropriate uses of exit().
>> > > AFAIIR, the *only* valid use of exit() in a library is to clean up in
>> > > a
>> > > child process from a library-initiated fork().
>> >
>> > ... or (in this case) in the libxl-save-helper (separate process).
>> >
>> > The only one I can find which isn't one of this is
>> > in libxl__event_disaster, and that is only if the applications (or
>> > language
>> > bindings) haven't provided a suitable disaster callback.
>>
>> Was looking at 4.4, in staging I also see a very odd one in
>> drbd_preresume_async, which isn't obviously in a child process AFAICT.
>>
>> Hongyang, what prevents that exit from killing the whole toolstack
>> process?
>
> I had missed an _async suffix on that function versus the one which was the
> actual callback, it is invoked via drbd_async_call which involves a fork().

So what was the conclusion here?  It looks like we've confirmed that
exit() is only called:

1. In the case of a malloc() failure
2. in libxl-save-helper (a separate process forked by the library)
3. In libxl__event_disaster(), if no callback is provided

Which just leaves #1 as something to be discussed?

(Also, I had suggested making a new thread, but I can't find any
threads continuing this conversation.)

 -George

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

Re: [Xen-devel] [PATCH v2 15/16] xenalyze: handle RTDS scheduler events

[Dario Faggioli]

On Thu, 2016-02-18 at 17:06 +, George Dunlap wrote:
> On 18/02/16 17:02, Dario Faggioli wrote:
> > On Thu, 2016-02-18 at 15:28 +, George Dunlap wrote:
> > > 
> > > > +case TRC_SCHED_CLASS_EVT(RTDS, 2): /*
> > > > RUNQ_PICK*/
> > > > +if(opt.dump_all) {
> > > > +struct {
> > > > +unsigned int vcpuid:16, domid:16;
> > > > +unsigned int cur_dl_lo, cur_dl_hi;
> > > > +unsigned int cur_bg_lo, cur_bg_hi;
> > > > +} *r = (typeof(r))ri->d;
> > > > +uint64_t dl = (((uint64_t)r->cur_dl_hi) << 32)
> > > > +
> > > > r->cur_dl_lo;
> > > > +uint64_t bg = (((uint64_t)r->cur_bg_hi) << 32)
> > > > +
> > > > r->cur_bg_lo;
> > > 
> > > Why are you doing this, instead of just using uint64_t?
> > > 
> > It was to make the struct in sched_rt.c and here exactly match, for
> > ease of someone reading both the pieces of code at the same time,
> > to
> > understand what's being printed.
> > 
> > However, yes, using uint64_t is probably equally understandable,
> > and
> > more readable in case one only look at this code, so I can change
> > this
> > (and resend).
> 
> Hrm, well perhaps having the struct match exactly is better.
> 
> I think most of these patches can be checked in now.  What about
> checking in the other patches, then sending a follow-up series with
> the
> struct changed in the scheduler, and then this patch with the
> resulting
> changes?
> 
This would work for me.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



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

Re: [Xen-devel] [PATCH v2 15/16] xenalyze: handle RTDS scheduler events

[George Dunlap]

On 18/02/16 17:02, Dario Faggioli wrote:
> On Thu, 2016-02-18 at 15:28 +, George Dunlap wrote:
>> On 16/02/16 18:13, Dario Faggioli wrote:
>>> ---
>>>  tools/xentrace/xenalyze.c |   59
>>> +
>>>  1 file changed, 59 insertions(+)
>>>
>>> diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
>>> index 8f97f3a..dd21229 100644
>>> --- a/tools/xentrace/xenalyze.c
>>> +++ b/tools/xentrace/xenalyze.c
>>> @@ -7828,6 +7828,65 @@ void sched_process(struct pcpu_info *p)
>>> r->rq_avgload, r->b_avgload);
>>>  }
>>>  break;
>>> +/* RTDS (TRC_RTDS_xxx) */
>>> +case TRC_SCHED_CLASS_EVT(RTDS, 1): /* TICKLE   */
>>> +if(opt.dump_all) {
>>> +struct {
>>> +unsigned int cpu:16;
>>> +} *r = (typeof(r))ri->d;
>>> +
>>> +printf(" %s rtds:runq_tickle cpu %u\n",
>>> +   ri->dump_header, r->cpu);
>>> +}
>>> +break;
>>> +case TRC_SCHED_CLASS_EVT(RTDS, 2): /* RUNQ_PICK*/
>>> +if(opt.dump_all) {
>>> +struct {
>>> +unsigned int vcpuid:16, domid:16;
>>> +unsigned int cur_dl_lo, cur_dl_hi;
>>> +unsigned int cur_bg_lo, cur_bg_hi;
>>> +} *r = (typeof(r))ri->d;
>>> +uint64_t dl = (((uint64_t)r->cur_dl_hi) << 32) +
>>> r->cur_dl_lo;
>>> +uint64_t bg = (((uint64_t)r->cur_bg_hi) << 32) +
>>> r->cur_bg_lo;
>>
>> Why are you doing this, instead of just using uint64_t?
>>
> It was to make the struct in sched_rt.c and here exactly match, for
> ease of someone reading both the pieces of code at the same time, to
> understand what's being printed.
> 
> However, yes, using uint64_t is probably equally understandable, and
> more readable in case one only look at this code, so I can change this
> (and resend).

Hrm, well perhaps having the struct match exactly is better.

I think most of these patches can be checked in now.  What about
checking in the other patches, then sending a follow-up series with the
struct changed in the scheduler, and then this patch with the resulting
changes?

 -George



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

Re: [Xen-devel] Stabilising some tools only HVMOPs?

[Jan Beulich]

>>> On 18.02.16 at 17:28,  wrote:
> Wei Liu writes ("Re: Stabilising some tools only HVMOPs?"):
>> I think we come to the conclusion that these HVMOPs should be made
>> stable. And to do so I'm going to introduce a __XEN_TOOLS_STABLE__ macro
>> for them to distinguish from __XEN_TOOLS__.  And then libxendevicemodel
>> will have -D__XEN_TOOLS_STABLE__  only.
>> 
>> Does this sound sufficient?
> 
> It would be better to rename -D__XEN_TOOLS__ too, to
> -D__XEN_TOOLS_UNSTABLE.

Even if a minor one, this will create a compatibility problem for
out of tree code including the headers: Their builds will all of
the sudden break, until they figure they need to go and
#define this new manifest symbol. Otoh maybe we would
actually like to break their builds this way, to make them aware
of the fact. In which case maybe __XEN_TOOLS__ should be
retained for the stable portions?

Jan


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

Re: [Xen-devel] Is: PVH dom0 - MWAIT detection logic to get deeper C-states exposed in ACPI AML code. Was:Re: [PATCH v2 10/30] xen/x86: Annotate VM applicability in featureset

[Roger Pau Monné]

El 18/2/16 a les 16:12, Andrew Cooper ha escrit:
> On 18/02/16 15:02, Roger Pau Monné wrote:
>> El 17/2/16 a les 20:02, Konrad Rzeszutek Wilk ha escrit:
>>> On Mon, Feb 15, 2016 at 03:41:41PM +, Andrew Cooper wrote:
 On 15/02/16 15:02, Jan Beulich wrote:
 On 15.02.16 at 15:53,  wrote:
>> On 15/02/16 14:50, Jan Beulich wrote:
>> On 15.02.16 at 15:38,  wrote:
 On 15/02/16 09:20, Jan Beulich wrote:
 On 12.02.16 at 18:42,  wrote:
>> On 12/02/16 17:05, Jan Beulich wrote:
>> On 05.02.16 at 14:42,  wrote:
  #define X86_FEATURE_MWAITX( 3*32+29) /*   MWAIT extension 
>> (MONITORX/MWAITX) */
>>> Why not exposed to HVM (also for _MWAIT as I now notice)?
>> Because that is a good chunk of extra work to support.  We would 
>> need to
>> use 4K monitor widths, and extra p2m handling.
> I don't understand: The base (_MWAIT) feature being exposed to
> guests today, and kernels making use of the feature when available
> suggests to me that things work. Are you saying you know
> otherwise? (And if there really is a reason to mask the feature all of
> the sudden, this should again be justified in the commit message.)
 PV guests had it clobbered by Xen in traps.c

 HVM guests have:

 vmx.c:
 case EXIT_REASON_MWAIT_INSTRUCTION:
 case EXIT_REASON_MONITOR_INSTRUCTION:
 [...]
 hvm_inject_hw_exception(TRAP_invalid_op, 
 HVM_DELIVER_NO_ERROR_CODE);
 break;

 and svm.c:
 case VMEXIT_MONITOR:
 case VMEXIT_MWAIT:
 hvm_inject_hw_exception(TRAP_invalid_op, 
 HVM_DELIVER_NO_ERROR_CODE);
 break;

 I don't see how a guest could actually use this feature.
>>> Do you see the respective intercepts getting enabled anywhere?
>>> (I don't outside of nested code, which I didn't check in detail.)
>> Yes - the intercepts are always enabled to prevent the guest actually
>> putting the processor to sleep.
> Hmm, you're right, somehow I've managed to ignore the relevant
> lines grep reported. Yet - how do things work then, without the
> MWAIT feature flag currently getting cleared?
 I have never observed it being used.  Do you have some local patches in
 the SLES hypervisor?

 There is some gross layer violation in xen/enlighten.c to pretend that
 MWAIT is present to trick the ACPI code into evaluating _CST() methods
 to report back to Xen.  (This is yet another PV-ism which will cause a
 headache for a DMLite dom0)
>>> Yes indeed. CC-ing Roger, and Boris.
>> Yes, all this is indeed not very nice, and we would ideally like to get
>> rid of it on PVHv2.
>>
>> Could we use the acpica tools (acpidump/acpixtract/acpiexec/...) in
>> order to fetch this information from user-space and send it to Xen using
>> privcmd?
>>
>> AFAIK those tools work on most OSes (or at least the ones we care about
>> as Dom0).
> 
> In general, we can't rely on userspace evaluation of AML.
> 
> For trivial AML which evaluates to a constant, it could be interpreted
> by userspace, but anything accessing system resources will need
> evaluating by the kernel.

Hm, I've took a look at the ACPI tables in one of my systems, and I'm 
not sure, but I guess the CPU related methods indeed must be executed 
by the kernel. I don't have much idea of ASL, but I guess the 
"Register" instruction means that a specific register must be poked, 
and it probably can't be done from user-space:

[...]
Scope (\_PR.CPU0)
{
Name (_PPC, Zero)  // _PPC: Performance Present Capabilities
Method (_PCT, 0, NotSerialized)  // _PCT: Performance Control
{
\_PR.CPU0._PPC = \_PR.CPPC
If (((CFGD & One) && (PDC0 & One)))
{
Return (Package (0x02)
{
ResourceTemplate ()
{
Register (FFixedHW, 
0x00,   // Bit Width
0x00,   // Bit Offset
0x, // Address
,)
}, 

ResourceTemplate ()
{
Register (FFixedHW, 
0x00,   // Bit Width
0x00,   // Bit Offset
0x, // Address
,)
}
})
}
}

Name (_PSS, Package (0x10)  // _PSS: Performance Supported States
{
Package (0x06)
{
 

Re: [Xen-devel] [PATCH v2 13/16] xenalyze: handle Credit1 scheduler events

[Dario Faggioli]

On Thu, 2016-02-18 at 15:31 +, George Dunlap wrote:
> On 16/02/16 18:12, Dario Faggioli wrote:
> > 
> > diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
> > index 17021f1..4ab2dba 100644
> > --- a/tools/xentrace/xenalyze.c
> > +++ b/tools/xentrace/xenalyze.c
> > @@ -7673,6 +7673,63 @@ void sched_process(struct pcpu_info *p)
> >  default:
> >  process_generic(>ri);
> >  }
> > +} else if(ri->evt.sub == 2) {
> > +/* TRC_SCHED_CLASS */
> > +switch(ri->event)
> > +{
> > +/* CREDIT (TRC_CSCHED_xxx) */
> > +case TRC_SCHED_CLASS_EVT(CSCHED, 1): /* SCHED_TASKLET */
> 
> Sorry, just one more comment:
> 
> It would probably be good at some point to find a way to expose these
> in
> a public header, rather than having to manually keep this file in
> sync
> with the values in sched_*.c.  But that's a nice-to-have for another
> day. :-)
> 
Indeed. I can add this to my TODO list, although...

> (Maybe a cleanup for a GSoC / OPW student...?)
> 
... that's actually a good idea (and we should add this to the list of
similar projects, if we keep one).

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



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

Re: [Xen-devel] [PATCH v2 15/16] xenalyze: handle RTDS scheduler events

[Dario Faggioli]

On Thu, 2016-02-18 at 15:28 +, George Dunlap wrote:
> On 16/02/16 18:13, Dario Faggioli wrote:
> > ---
> >  tools/xentrace/xenalyze.c |   59
> > +
> >  1 file changed, 59 insertions(+)
> > 
> > diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
> > index 8f97f3a..dd21229 100644
> > --- a/tools/xentrace/xenalyze.c
> > +++ b/tools/xentrace/xenalyze.c
> > @@ -7828,6 +7828,65 @@ void sched_process(struct pcpu_info *p)
> > r->rq_avgload, r->b_avgload);
> >  }
> >  break;
> > +/* RTDS (TRC_RTDS_xxx) */
> > +case TRC_SCHED_CLASS_EVT(RTDS, 1): /* TICKLE   */
> > +if(opt.dump_all) {
> > +struct {
> > +unsigned int cpu:16;
> > +} *r = (typeof(r))ri->d;
> > +
> > +printf(" %s rtds:runq_tickle cpu %u\n",
> > +   ri->dump_header, r->cpu);
> > +}
> > +break;
> > +case TRC_SCHED_CLASS_EVT(RTDS, 2): /* RUNQ_PICK*/
> > +if(opt.dump_all) {
> > +struct {
> > +unsigned int vcpuid:16, domid:16;
> > +unsigned int cur_dl_lo, cur_dl_hi;
> > +unsigned int cur_bg_lo, cur_bg_hi;
> > +} *r = (typeof(r))ri->d;
> > +uint64_t dl = (((uint64_t)r->cur_dl_hi) << 32) +
> > r->cur_dl_lo;
> > +uint64_t bg = (((uint64_t)r->cur_bg_hi) << 32) +
> > r->cur_bg_lo;
> 
> Why are you doing this, instead of just using uint64_t?
> 
It was to make the struct in sched_rt.c and here exactly match, for
ease of someone reading both the pieces of code at the same time, to
understand what's being printed.

However, yes, using uint64_t is probably equally understandable, and
more readable in case one only look at this code, so I can change this
(and resend).

Regards,
Dario

-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



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

Re: [Xen-devel] [PATCH v3 02/10] xen: reduce number of global variables in xen loader

[Lennart Sorensen]

On Thu, Feb 18, 2016 at 11:34:49AM +0100, Juergen Gross wrote:
> On 18/02/16 11:22, Daniel Kiper wrote:
> > On Wed, Feb 17, 2016 at 06:19:29PM +0100, Juergen Gross wrote:
> >> The loader for xen paravirtualized environment is using lots of global
> >> variables. Reduce the number by making them either local or by putting
> >> them into a single state structure.
> >>
> >> Signed-off-by: Juergen Gross 
> > 
> > Just two nitpicks but in general...
> > 
> > Reviewed-by: Daniel Kiper 
> > 
> >> ---
> >>  grub-core/loader/i386/xen.c | 259 
> >> +++-
> >>  1 file changed, 138 insertions(+), 121 deletions(-)
> >>
> >> diff --git a/grub-core/loader/i386/xen.c b/grub-core/loader/i386/xen.c
> >> index ff7c553..d5fe168 100644
> >> --- a/grub-core/loader/i386/xen.c
> >> +++ b/grub-core/loader/i386/xen.c
> >> @@ -42,16 +42,20 @@
> >>
> >>  GRUB_MOD_LICENSE ("GPLv3+");
> >>
> >> -static struct grub_relocator *relocator = NULL;
> >> -static grub_uint64_t max_addr;
> >> +struct xen_loader_state {
> >> +  struct grub_relocator *relocator;
> >> +  struct start_info next_start;
> >> +  struct grub_xen_file_info xen_inf;
> >> +  grub_uint64_t max_addr;
> >> +  struct xen_multiboot_mod_list *module_info_page;
> >> +  grub_uint64_t modules_target_start;
> >> +  grub_size_t n_modules;
> >> +  int loaded;
> >> +};
> >> +
> >> +static struct xen_loader_state xen_state;
> >> +
> >>  static grub_dl_t my_mod;
> >> -static int loaded = 0;
> >> -static struct start_info next_start;
> >> -static void *kern_chunk_src;
> >> -static struct grub_xen_file_info xen_inf;
> >> -static struct xen_multiboot_mod_list *xen_module_info_page;
> >> -static grub_uint64_t modules_target_start;
> >> -static grub_size_t n_modules;
> >>
> >>  #define PAGE_SIZE 4096
> >>  #define MAX_MODULES (PAGE_SIZE / sizeof (struct xen_multiboot_mod_list))
> >> @@ -225,50 +229,55 @@ grub_xen_boot (void)
> >>if (grub_xen_n_allocated_shared_pages)
> >>  return grub_error (GRUB_ERR_BUG, "active grants");
> >>
> >> -  state.mfn_list = max_addr;
> >> -  next_start.mfn_list = max_addr + xen_inf.virt_base;
> >> -  next_start.first_p2m_pfn = max_addr >> PAGE_SHIFT;  /* Is this 
> >> right? */
> >> +  state.mfn_list = xen_state.max_addr;
> >> +  xen_state.next_start.mfn_list =
> >> +xen_state.max_addr + xen_state.xen_inf.virt_base;
> >> +  xen_state.next_start.first_p2m_pfn = xen_state.max_addr >> PAGE_SHIFT;
> >>pgtsize = sizeof (grub_xen_mfn_t) * grub_xen_start_page_addr->nr_pages;
> >> -  err = grub_relocator_alloc_chunk_addr (relocator, , max_addr, 
> >> pgtsize);
> >> -  next_start.nr_p2m_frames = (pgtsize + PAGE_SIZE - 1) >> PAGE_SHIFT;
> >> +  err = grub_relocator_alloc_chunk_addr (xen_state.relocator, ,
> >> +   xen_state.max_addr, pgtsize);
> >> +  xen_state.next_start.nr_p2m_frames = (pgtsize + PAGE_SIZE - 1) >> 
> >> PAGE_SHIFT;
> >>if (err)
> >>  return err;
> >>new_mfn_list = get_virtual_current_address (ch);
> >>grub_memcpy (new_mfn_list,
> >>   (void *) grub_xen_start_page_addr->mfn_list, pgtsize);
> >> -  max_addr = ALIGN_UP (max_addr + pgtsize, PAGE_SIZE);
> >> +  xen_state.max_addr = ALIGN_UP (xen_state.max_addr + pgtsize, PAGE_SIZE);
> >>
> >> -  err = grub_relocator_alloc_chunk_addr (relocator, ,
> >> -   max_addr, sizeof (next_start));
> >> +  err = grub_relocator_alloc_chunk_addr (xen_state.relocator, ,
> >> +   xen_state.max_addr,
> >> +   sizeof (xen_state.next_start));
> >>if (err)
> >>  return err;
> >> -  state.start_info = max_addr + xen_inf.virt_base;
> >> +  state.start_info = xen_state.max_addr + xen_state.xen_inf.virt_base;
> >>nst = get_virtual_current_address (ch);
> >> -  max_addr = ALIGN_UP (max_addr + sizeof (next_start), PAGE_SIZE);
> >> +  xen_state.max_addr =
> >> +ALIGN_UP (xen_state.max_addr + sizeof (xen_state.next_start), 
> >> PAGE_SIZE);
> >>
> >> -  next_start.nr_pages = grub_xen_start_page_addr->nr_pages;
> >> -  grub_memcpy (next_start.magic, grub_xen_start_page_addr->magic,
> >> - sizeof (next_start.magic));
> >> -  next_start.store_mfn = grub_xen_start_page_addr->store_mfn;
> >> -  next_start.store_evtchn = grub_xen_start_page_addr->store_evtchn;
> >> -  next_start.console.domU = grub_xen_start_page_addr->console.domU;
> >> -  next_start.shared_info = grub_xen_start_page_addr->shared_info;
> >> +  xen_state.next_start.nr_pages = grub_xen_start_page_addr->nr_pages;
> >> +  grub_memcpy (xen_state.next_start.magic, 
> >> grub_xen_start_page_addr->magic,
> >> + sizeof (xen_state.next_start.magic));
> >> +  xen_state.next_start.store_mfn = grub_xen_start_page_addr->store_mfn;
> >> +  xen_state.next_start.store_evtchn = 
> >> grub_xen_start_page_addr->store_evtchn;
> >> +  xen_state.next_start.console.domU = 
> >> grub_xen_start_page_addr->console.domU;

Re: [Xen-devel] [PATCH v3 01/10] xen: make xen loader callable multiple times

[Daniel Kiper]

On Thu, Feb 18, 2016 at 11:32:16AM +0100, Juergen Gross wrote:
> On 18/02/16 11:12, Daniel Kiper wrote:
> > On Wed, Feb 17, 2016 at 06:19:28PM +0100, Juergen Gross wrote:
> >> The loader for xen paravirtualized environment isn't callable multiple
> >> times as it won't free any memory in case of failure.
> >>
> >> Call grub_relocator_unload() as other modules do it before allocating
> >
> > Do you mean grub_xen_reset?
>
> No. I do want to call grub_relocator_unload() and I'm doing it in
> grub_xen_reset(). Other modules don't call grub_xen_reset(). :-)
>
> >
> >> a new relocator or when unloading the module.
> >>
> >> Signed-off-by: Juergen Gross 
> >> ---
> >>  grub-core/loader/i386/xen.c| 28 +++-
> >>  grub-core/loader/i386/xen_fileXX.c | 17 +++--
> >>  2 files changed, 30 insertions(+), 15 deletions(-)
> >>
> >> diff --git a/grub-core/loader/i386/xen.c b/grub-core/loader/i386/xen.c
> >> index c4d9689..ff7c553 100644
> >> --- a/grub-core/loader/i386/xen.c
> >> +++ b/grub-core/loader/i386/xen.c
> >> @@ -316,11 +316,23 @@ grub_xen_boot (void)
> >>  xen_inf.virt_base);
> >>  }
> >>
> >> +static void
> >> +grub_xen_reset (void)
> >> +{
> >> +  grub_memset (_start, 0, sizeof (next_start));
> >> +  xen_module_info_page = NULL;
> >> +  n_modules = 0;
> >> +
> >> +  grub_relocator_unload (relocator);
> >> +  relocator = NULL;
> >> +  loaded = 0;
> >> +}
> >> +
> >>  static grub_err_t
> >>  grub_xen_unload (void)
> >>  {
> >> +  grub_xen_reset ();
> >>grub_dl_unref (my_mod);
> >> -  loaded = 0;
> >>return GRUB_ERR_NONE;
> >>  }
> >>
> >> @@ -403,10 +415,7 @@ grub_cmd_xen (grub_command_t cmd __attribute__ 
> >> ((unused)),
> >>
> >>grub_loader_unset ();
> >>
> >> -  grub_memset (_start, 0, sizeof (next_start));
> >> -
> >> -  xen_module_info_page = NULL;
> >> -  n_modules = 0;
> >> +  grub_xen_reset ();
> >>
> >>grub_create_loader_cmdline (argc - 1, argv + 1,
> >>  (char *) next_start.cmd_line,
> >> @@ -503,16 +512,17 @@ grub_cmd_xen (grub_command_t cmd __attribute__ 
> >> ((unused)),
> >>goto fail;
> >>
> >>  fail:
> >> +  err = grub_errno;
> >
> > I do not think this is needed.
>
> grub_elf_close() and others might clobber grub_errno.

OK, so, please say it in comment. It is not obvious.

> >>if (elf)
> >>  grub_elf_close (elf);
> >>else if (file)
> >>  grub_file_close (file);
> >>
> >> -  if (grub_errno != GRUB_ERR_NONE)
> >> -loaded = 0;
> >> +  if (err != GRUB_ERR_NONE)
> >> +grub_xen_reset ();
> >>
> >> -  return grub_errno;
> >> +  return err;
> >>  }
> >>
> >>  static grub_err_t
> >> @@ -552,7 +562,7 @@ grub_cmd_initrd (grub_command_t cmd __attribute__ 
> >> ((unused)),
> >>  {
> >>err = grub_relocator_alloc_chunk_addr (relocator, , max_addr, 
> >> size);
> >>if (err)
> >> -  return err;
> >> +  goto fail;
> >
> > It looks that this change should not be part of this patch.
>
> Why not? It's correcting a memory leak in case of failure. Like the
> other cases below, too. That's the purpose of this patch, after all.

OK but you are referring to grub_relocator_unload() in commit message
and below you are trying to fix different memory leak in the same patch.
So, I think everything below should be separate patch.

Daniel

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

Re: [Xen-devel] libxl_device handling for nic and vtmp

[Olaf Hering]

On Thu, Feb 18, Wei Liu wrote:

> For example, user might not have specified mac address so the library
> generates one for (s)he. You don't want mac address to regenerate after
> save / restore or migration.  But you don't want to preserve all
> autogenerated state, so you use the original copy as template and fill
> it up as you see fit.

How does that fit into DEFINE_DEVICE_ADD? The functions do 1:1 copies,
calling libxl__update_config_* looks unnecessary.

Olaf

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

Re: [Xen-devel] Stabilising some tools only HVMOPs?

[Wei Liu]

On Thu, Feb 18, 2016 at 09:41:01AM -0700, Jan Beulich wrote:
> >>> On 18.02.16 at 17:28,  wrote:
> > Wei Liu writes ("Re: Stabilising some tools only HVMOPs?"):
> >> I think we come to the conclusion that these HVMOPs should be made
> >> stable. And to do so I'm going to introduce a __XEN_TOOLS_STABLE__ macro
> >> for them to distinguish from __XEN_TOOLS__.  And then libxendevicemodel
> >> will have -D__XEN_TOOLS_STABLE__  only.
> >> 
> >> Does this sound sufficient?
> > 
> > It would be better to rename -D__XEN_TOOLS__ too, to
> > -D__XEN_TOOLS_UNSTABLE.
> 
> Even if a minor one, this will create a compatibility problem for
> out of tree code including the headers: Their builds will all of
> the sudden break, until they figure they need to go and
> #define this new manifest symbol. Otoh maybe we would
> actually like to break their builds this way, to make them aware
> of the fact. In which case maybe __XEN_TOOLS__ should be
> retained for the stable portions?
> 

I think we should break their build but I also want to be a bit nicer.
So off the top of my head, we can have something like:

#if defined (__XEN_TOOLS__)
# error "NOTE: if you want to continue to build against unstable tools 
interface, use __XEN_TOOLS_UNSTABLE__ instead"
#endif

And place this in public headers that used to have __XEN_TOOLS__.

Wei.


> Jan
> 

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

Re: [Xen-devel] [PATCH v2 06/16] xen: sched: tracing: enable TSC tracing for all events

[Dario Faggioli]

On Thu, 2016-02-18 at 11:43 +, George Dunlap wrote:
> On 17/02/16 09:52, Dario Faggioli wrote:
> > 
> > For instance, the thing that you can just change on the fly the way
> > a
> > trace is shown (by tweaking the format file) looks an interesting
> > feature to me, even considering all the limitations of "pure"
> > xentrace.
> > And if one want to change the formats for her own purposes, I feel
> > like
> > it is important that the one that we ship is updated, and can be
> > used
> > as a decent base for that.
> 
> So I certainly agree that xentrace_formats should be maintained so
> that
> it works.  I hadn't thought before about the advantage of being able
> to
> change the formats file more easily than adding new records to
> xenalyze,
> but that's a good point.
> 
Yeah... To be fair, it's much more the exception than the rule, IMO,
that you really need xentrace_format instead of xenalyze... But it can
happen, and that's one possible reason.

> But I do want to ask, how neccessary / useful is it to make the *TSC*
> information available to xentrace_format?
> 
So, when tracing the scheduler, I personally don't see much value in
having the record of an event, if I don't also have the time at which
the event happened.

So, this is an example of xentrace_format with all this series applied,
except for this patch:

CPU0  2970034498098 (+ 9454788)  domain_wake   [ dom:vcpu = 0x0001 ]
CPU0  2970034499304 (+1206)  blocked_to_runnable [ dom:vcpu = 0x0001 ]
CPU0  0 (+   0)  csched:tickle[ cpu = 0 ]
CPU0  2970034511640 (+   12336)  switch_infprev[ old_domid = 0x7fff, 
runtime = 3956318 ]
CPU0  2970034512090 (+ 450)  switch_infnext[ new_domid = 0x, 
time = 4446, r_time = 3000 ]
CPU0  2970034512480 (+ 390)  __enter_scheduler [ prev = 
0x7fff, next = 0x0001 ]
CPU0  2970034513002 (+ 522)  running_to_runnable [ dom:vcpu = 0x7fff ]
CPU0  2970034513422 (+ 420)  runnable_to_running [ dom:vcpu = 0x0001 ]

So, suppose, for instance, I want to figure out how much time passes
between when a pcpu is tickled, and when it actually schedules and pick
up the task that woke up. From just the trace above, I can't do that.

I know that this may not always be reliable when using only
xentrace_format (because of TSC not being synchronized or drifting),
but if used well (e.g., with pinning) or on good/new enough hardware
(with synch and constant rate TSCs), I think it should be possible.

On the other hand this is how a similar trace looks if TSC is enabled,
where the above can be achived:

CPU5  9965509909596 (+ 9268404)  domain_wake   [ dom:vcpu = 0x0004 ]
CPU5  9965509911030 (+1434)  blocked_to_runnable [ dom:vcpu = 0x0004 ]
CPU5  9965509912962 (+1932)  csched:tickle[ cpu = 5 ]
CPU5  9965509924002 (+   11040)  switch_infprev[ old_domid = 0x7fff, 
runtime = 3879052 ]
CPU5  9965509924506 (+ 504)  switch_infnext[ new_domid = 0x, 
time = 5000, r_time = 3000 ]
CPU5  9965509924824 (+ 318)  __enter_scheduler [ prev = 
0x7fff0005, next = 0x0004 ]
CPU5  9965509925478 (+ 654)  running_to_runnable [ dom:vcpu = 0x7fff0005 ]
CPU5  9965509925892 (+ 414)  runnable_to_running [ dom:vcpu = 0x0004 ]

This is not an issue with xenalyze, and I think that is because you
fiddle with timestamps in it, in order to compensate for the per-
cpuness/desynch/etc. issues. I haven't checked the code where that
happens in xenalyze, though, so I don't know whether having the TSC in
more records would also help xenalyze or not.

> The reason most of the traces don't include a timestamp is that it
> increases the record size by a non-negligible amount -- in all the
> cases
> here the traces are 1, 2, or 3 bytes without the tsc, so you're
> basically doubling the size of what gets traced.
> 
I see, but I think it's worth in this case.

Perhaps, we can think of ways of enabling and disabling logging TSC
dynamically, either at compile or run time. Doing at run time, given
the way tracing is currently implemented, will most likely incur in
some overhead. Very small, but still something, and I'm not sure we're
ok introducing it.

Doing it at compile time would be a lot less flexible, but perhaps a
decent compromise, i.e., I at least always have the events... If I want
to know exactly when they happened, for all of them, I need a Xen
version build to provide that (like I need a debug build to have
ASSERT()s and symbols).

> How does adding the TSC significantly help someone using
> xentrace_format?
> 
Hope I answered to this. Let me know what you think. :-)

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing 

Re: [Xen-devel] Is: PVH dom0 - MWAIT detection logic to get deeper C-states exposed in ACPI AML code. Was:Re: [PATCH v2 10/30] xen/x86: Annotate VM applicability in featureset

[Andrew Cooper]

On 18/02/16 16:24, Boris Ostrovsky wrote:
>
>
> On 02/18/2016 10:12 AM, Andrew Cooper wrote:
>> On 18/02/16 15:02, Roger Pau Monné wrote:
>>> El 17/2/16 a les 20:02, Konrad Rzeszutek Wilk ha escrit:
 On Mon, Feb 15, 2016 at 03:41:41PM +, Andrew Cooper wrote:
> On 15/02/16 15:02, Jan Beulich wrote:
> On 15.02.16 at 15:53,  wrote:
>>> On 15/02/16 14:50, Jan Beulich wrote:
>>> On 15.02.16 at 15:38,  wrote:
> On 15/02/16 09:20, Jan Beulich wrote:
> On 12.02.16 at 18:42,  wrote:
>>> On 12/02/16 17:05, Jan Beulich wrote:
>>> On 05.02.16 at 14:42,  wrote:
>   #define X86_FEATURE_MWAITX( 3*32+29) /*   MWAIT
> extension
>>> (MONITORX/MWAITX) */
 Why not exposed to HVM (also for _MWAIT as I now notice)?
>>> Because that is a good chunk of extra work to support.  We
>>> would need to
>>> use 4K monitor widths, and extra p2m handling.
>> I don't understand: The base (_MWAIT) feature being exposed to
>> guests today, and kernels making use of the feature when
>> available
>> suggests to me that things work. Are you saying you know
>> otherwise? (And if there really is a reason to mask the
>> feature all of
>> the sudden, this should again be justified in the commit
>> message.)
> PV guests had it clobbered by Xen in traps.c
>
> HVM guests have:
>
> vmx.c:
>  case EXIT_REASON_MWAIT_INSTRUCTION:
>  case EXIT_REASON_MONITOR_INSTRUCTION:
> [...]
>  hvm_inject_hw_exception(TRAP_invalid_op,
> HVM_DELIVER_NO_ERROR_CODE);
>  break;
>
> and svm.c:
>  case VMEXIT_MONITOR:
>  case VMEXIT_MWAIT:
>  hvm_inject_hw_exception(TRAP_invalid_op,
> HVM_DELIVER_NO_ERROR_CODE);
>  break;
>
> I don't see how a guest could actually use this feature.
 Do you see the respective intercepts getting enabled anywhere?
 (I don't outside of nested code, which I didn't check in detail.)
>>> Yes - the intercepts are always enabled to prevent the guest
>>> actually
>>> putting the processor to sleep.
>> Hmm, you're right, somehow I've managed to ignore the relevant
>> lines grep reported. Yet - how do things work then, without the
>> MWAIT feature flag currently getting cleared?
> I have never observed it being used.  Do you have some local
> patches in
> the SLES hypervisor?
>
> There is some gross layer violation in xen/enlighten.c to pretend
> that
> MWAIT is present to trick the ACPI code into evaluating _CST()
> methods
> to report back to Xen.  (This is yet another PV-ism which will
> cause a
> headache for a DMLite dom0)
 Yes indeed. CC-ing Roger, and Boris.
>>> Yes, all this is indeed not very nice, and we would ideally like to get
>>> rid of it on PVHv2.
>
> We will have to come up with something else: AIUI the whole point of
> xen_check_mwait() is to come up with proper ECX and EDX values for the
> MWAIT CPUID leaf. Those value are expected to be reported from
> xen_cpuid() pv_op so that acpi_processor_ffh_state_probe_cpu() can set
> C states structures properly.
>
> The problem is that PVH executes CPUID instruction natively. (And so
> this must have been broken on PVHv1 as well).

Currently, mwait is unusable by any domains, and will not be offered in
any cpuid policy.

How a particular dom0 goes about deciding to enumerate the ACPI objects
is its own business, but personally I think it is a layering violation
to have the enumeration of an existing ACPI object based on a feature bit.

Dom0, being suitably enlightened, should know that its job is to service
Xen when it comes to ACPI, and unilaterally collect and upload
everything it can.

~Andrew

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

Re: [Xen-devel] [PATCH v3 5/5] mkelf32: Close those file descriptors in the error paths.

[Jan Beulich]

>>> On 18.02.16 at 17:39,  wrote:
> Jan Beulich writes ("Re: [PATCH v3 5/5] mkelf32: Close those file descriptors 
> in the error paths."):
>> On 12.02.16 at 04:08,  wrote:
>> > While we are operating here we may as well fix some of the
>> > file descriptor leaks.
>> 
>> I'm not convinced. The added goto-s make the code uglier to read,
>> and this being a standalone utility there's not really any leak here.
> 
> I don't buy this `uglier to read'.  What `return 1' does is make me
> think `is some resource being leaked' and `do I need to audit this
> thing'.

Certainly a matter of taste to some degree - goto-s are always
ugly to read to my eyes. Irrespective of this I don't buy the leak
aspect for a non-library like, short running build utility. The close()
calls are just more code, with absolutely no added benefit to the
system the code runs on.

Jan


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

Re: [Xen-devel] Stabilising some tools only HVMOPs?

[Ian Jackson]

Jan Beulich writes ("Re: Stabilising some tools only HVMOPs?"):
> On 18.02.16 at 17:28,  wrote:
> > Wei Liu writes ("Re: Stabilising some tools only HVMOPs?"):
> >> I think we come to the conclusion that these HVMOPs should be made
> >> stable. And to do so I'm going to introduce a __XEN_TOOLS_STABLE__ macro
> >> for them to distinguish from __XEN_TOOLS__.  And then libxendevicemodel
> >> will have -D__XEN_TOOLS_STABLE__  only.
> >> 
> >> Does this sound sufficient?
> > 
> > It would be better to rename -D__XEN_TOOLS__ too, to
> > -D__XEN_TOOLS_UNSTABLE.
> 
> Even if a minor one, this will create a compatibility problem for
> out of tree code including the headers: Their builds will all of
> the sudden break, until they figure they need to go and
> #define this new manifest symbol. Otoh maybe we would
> actually like to break their builds this way, to make them aware
> of the fact.

We're talking here mostly about the unstable API, right ?  Well this
is a kind of instability :-).

> In which case maybe __XEN_TOOLS__ should be
> retained for the stable portions?

In principle that might be nice but actually the library split means
they have to change anyway.

Ian.

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

Re: [Xen-devel] [PATCH v3 10/10] xen: add capability to load p2m list outside of kernel mapping

[Daniel Kiper]

On Wed, Feb 17, 2016 at 06:19:37PM +0100, Juergen Gross wrote:
> Modern pvops linux kernels support a p2m list not covered by the
> kernel mapping. This capability is flagged by an elf-note specifying
> the virtual address the kernel is expecting the p2m list to be mapped
> to.
>
> In case the elf-note is set by the kernel don't place the p2m list
> into the kernel mapping, but map it to the given address. This will
> allow to support domains with larger memory, as the kernel mapping is
> limited to 2GB and a domain with huge memory in the TB range will have
> a p2m list larger than this.
>
> Signed-off-by: Juergen Gross 

Reviewed-by: Daniel Kiper 

Daniel

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

Re: [Xen-devel] [PATCH v3 5/5] mkelf32: Close those file descriptors in the error paths.

[Ian Jackson]

Jan Beulich writes ("Re: [PATCH v3 5/5] mkelf32: Close those file descriptors 
in the error paths."):
> On 12.02.16 at 04:08,  wrote:
> > While we are operating here we may as well fix some of the
> > file descriptor leaks.
> 
> I'm not convinced. The added goto-s make the code uglier to read,
> and this being a standalone utility there's not really any leak here.

I don't buy this `uglier to read'.  What `return 1' does is make me
think `is some resource being leaked' and `do I need to audit this
thing'.

Ian.

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

Re: [Xen-devel] [PATCH v3 09/10] xen: modify page table construction

[Daniel Kiper]

On Wed, Feb 17, 2016 at 06:19:36PM +0100, Juergen Gross wrote:
> Modify the page table construction to allow multiple virtual regions
> to be mapped. This is done as preparation for removing the p2m list
> from the initial kernel mapping in order to support huge pv domains.
>
> This allows a cleaner approach for mapping the relocator page by
> using this capability.
>
> The interface to the assembler level of the relocator has to be changed
> in order to be able to process multiple page table areas.
>
> Signed-off-by: Juergen Gross 
> ---
> V3: use constants instead of numbers as requested by Daniel Kiper
> add lots of comments to assembly code as requested by Daniel Kiper
> ---
>  grub-core/lib/i386/xen/relocator.S   |  87 ++
>  grub-core/lib/x86_64/xen/relocator.S | 134 ++-
>  grub-core/lib/xen/relocator.c|  25 ++-
>  grub-core/loader/i386/xen.c  | 325 
> ---
>  include/grub/i386/memory.h   |   7 +
>  include/grub/xen/relocator.h |   6 +-
>  6 files changed, 354 insertions(+), 230 deletions(-)
>
> diff --git a/grub-core/lib/i386/xen/relocator.S 
> b/grub-core/lib/i386/xen/relocator.S
> index 694a54c..f1c729e 100644
> --- a/grub-core/lib/i386/xen/relocator.S
> +++ b/grub-core/lib/i386/xen/relocator.S
> @@ -16,6 +16,8 @@
>   *  along with GRUB.  If not, see .
>   */
>
> +#include 
> +#include 
>  #include 
>  #include 
>
> @@ -23,78 +25,86 @@
>
>  VARIABLE(grub_relocator_xen_remap_start)
>  LOCAL(base):
> - /* mov imm32, %ebx */
> + /* Remap the remapper to it's new address. */
> + /* mov imm32, %ebx - %ebx: new virtual address of remapper */
>   .byte   0xbb
>  VARIABLE(grub_relocator_xen_remapper_virt)
>   .long   0
>
> - /* mov imm32, %ecx */
> + /* mov imm32, %ecx - %ecx: low part of page table entry */
>   .byte   0xb9
>  VARIABLE(grub_relocator_xen_remapper_map)
>   .long   0
>
> - /* mov imm32, %edx */
> + /* mov imm32, %edx  - %edx: high part of page table entry */
>   .byte   0xba
>  VARIABLE(grub_relocator_xen_remapper_map_high)
>   .long   0
>
> - movl%ebx, %ebp
> + movl%ebx, %ebp  /* %ebx is clobbered by hypercall */
>
> - movl$2, %esi
> + movl$UVMF_INVLPG, %esi  /* esi: flags (inv. single entry) */
>   movl$__HYPERVISOR_update_va_mapping, %eax
>   int $0x82
>
>   movl%ebp, %ebx
>   addl   $(LOCAL(cont) - LOCAL(base)), %ebx
>
> - jmp *%ebx
> + jmp *%ebx   /* Continue with new virtual address */
>
>  LOCAL(cont):
> - xorl%eax, %eax
> - movl%eax, %ebp
> + /* Modify mappings of new page tables to be read-only. */
> + /* mov imm32, %eax */
> + .byte   0xb8
> +VARIABLE(grub_relocator_xen_paging_areas_addr)
> + .long   0
> + movl%eax, %ebx
>  1:
> + movl0(%ebx), %ebp   /* Get start pfn of the current area */
> + movlGRUB_TARGET_SIZEOF_LONG(%ebx), %ecx /* Get # of pg tables */
> + testl   %ecx, %ecx  /* 0 -> last area reached */
> + jz  3f
> + addl$(2 * GRUB_TARGET_SIZEOF_LONG), %ebx
> + movl%ebx, %esp  /* Save current area pointer */
>
> +2:
> + movl%ecx, %edi
>   /* mov imm32, %eax */
>   .byte   0xb8
>  VARIABLE(grub_relocator_xen_mfn_list)
>   .long   0
> - movl%eax, %edi
> - movl%ebp, %eax
> - movl0(%edi, %eax, 4), %ecx
> -
> - /* mov imm32, %ebx */
> - .byte   0xbb
> -VARIABLE(grub_relocator_xen_paging_start)
> - .long   0
> - shll$12, %eax
> - addl%eax, %ebx
> + movl0(%eax, %ebp, 4), %ecx  /* mfn */
> + movl%ebp, %ebx
> + shll$PAGE_SHIFT, %ebx   /* virtual address (1:1 mapping) */
>   movl%ecx, %edx
> - shll$12,  %ecx
> - shrl$20,  %edx
> - orl $5, %ecx
> - movl$2, %esi
> + shll$PAGE_SHIFT,  %ecx  /* prepare pte low part */
> + shrl$(32 - PAGE_SHIFT),  %edx   /* pte high part */
> + orl $(GRUB_PAGE_PRESENT | GRUB_PAGE_USER), %ecx /* pte low */
> + movl$UVMF_INVLPG, %esi
>   movl$__HYPERVISOR_update_va_mapping, %eax
> - int $0x82
> + int $0x82   /* parameters: eax, ebx, ecx, edx, esi */
>
> - incl%ebp
> - /* mov imm32, %ecx */
> - .byte   0xb9
> -VARIABLE(grub_relocator_xen_paging_size)
> - .long   0
> - cmpl%ebp, %ecx
> + incl%ebp/* next pfn */
> + movl%edi, %ecx
>
> - ja  1b
> + loop2b
>
> + mov %esp, %ebx  /* restore area poniter */
> + jmp 1b
> +
> +3:
> + /* Switch page tables: pin new L3 pt, load cr3, unpin old L3. */
>   /* mov imm32, %ebx */
>   .byte   0xbb
>  VARIABLE(grub_relocator_xen_mmu_op_addr)
>   .long  0
> - movl   $3, %ecx
> - movl   $0, %edx
> - movl   $0x7FF0, %esi
> + movl   

Re: [Xen-devel] Stabilising some tools only HVMOPs?

[Ian Campbell]

On Thu, 2016-02-18 at 12:51 +, Wei Liu wrote:
> On Wed, Feb 17, 2016 at 05:28:08PM +, Wei Liu wrote:
> > Hi all
> > 
> > Tools people are in the process of splitting libxenctrl into a set of
> > stable libraries. One of the proposed libraries is libxendevicemodel
> > which has a collection of APIs that can be used by device model.
> > 
> > Currently we use QEMU as reference to extract symbols and go through
> > them one by one. Along the way we discover QEMU is using some tools
> > only HVMOPs.
> > 
> > The list of tools only HVMOPs used by QEMU are:
> > 
> >   #define HVMOP_track_dirty_vram6
> >   #define HVMOP_modified_memory7
> >   #define HVMOP_set_mem_type8
> >   #define HVMOP_inject_msi 16
> >   #define HVMOP_create_ioreq_server 17
> >   #define HVMOP_get_ioreq_server_info 18
> >   #define HVMOP_map_io_range_to_ioreq_server 19
> >   #define HVMOP_unmap_io_range_from_ioreq_server 20
> >   #define HVMOP_destroy_ioreq_server 21
> >   #define HVMOP_set_ioreq_server_state 22
> > 
> 
> I think we come to the conclusion that these HVMOPs should be made
> stable. And to do so I'm going to introduce a __XEN_TOOLS_STABLE__ macro
> for them to distinguish from __XEN_TOOLS__.  And then libxendevicemodel
> will have -D__XEN_TOOLS_STABLE__  only.
> 
> Does this sound sufficient?

FWIW it sounds like a lot less faff than the direction I was thinking of
taking this! (moving them to a new DMOP hypercall)

Ian.

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

Re: [Xen-devel] Stabilising some tools only HVMOPs?

[Wei Liu]

On Thu, Feb 18, 2016 at 04:28:16PM +, Ian Jackson wrote:
> Wei Liu writes ("Re: Stabilising some tools only HVMOPs?"):
> > I think we come to the conclusion that these HVMOPs should be made
> > stable. And to do so I'm going to introduce a __XEN_TOOLS_STABLE__ macro
> > for them to distinguish from __XEN_TOOLS__.  And then libxendevicemodel
> > will have -D__XEN_TOOLS_STABLE__  only.
> > 
> > Does this sound sufficient?
> 
> It would be better to rename -D__XEN_TOOLS__ too, to
> -D__XEN_TOOLS_UNSTABLE.
> 

Fine by me, of course.

Wei.

> Ian.

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

Re: [Xen-devel] [PATCH v3 5/5] mkelf32: Close those file descriptors in the error paths.

[Jan Beulich]

>>> On 12.02.16 at 04:08,  wrote:
> While we are operating here we may as well fix some of the
> file descriptor leaks.

I'm not convinced. The added goto-s make the code uglier to read,
and this being a standalone utility there's not really any leak here.

Jan


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

Re: [Xen-devel] Stabilising some tools only HVMOPs?

[Ian Jackson]

Wei Liu writes ("Re: Stabilising some tools only HVMOPs?"):
> I think we come to the conclusion that these HVMOPs should be made
> stable. And to do so I'm going to introduce a __XEN_TOOLS_STABLE__ macro
> for them to distinguish from __XEN_TOOLS__.  And then libxendevicemodel
> will have -D__XEN_TOOLS_STABLE__  only.
> 
> Does this sound sufficient?

It would be better to rename -D__XEN_TOOLS__ too, to
-D__XEN_TOOLS_UNSTABLE.

Ian.

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

Re: [Xen-devel] Is: PVH dom0 - MWAIT detection logic to get deeper C-states exposed in ACPI AML code. Was:Re: [PATCH v2 10/30] xen/x86: Annotate VM applicability in featureset

[Boris Ostrovsky]

On 02/18/2016 10:12 AM, Andrew Cooper wrote:

On 18/02/16 15:02, Roger Pau Monné wrote:

El 17/2/16 a les 20:02, Konrad Rzeszutek Wilk ha escrit:

On Mon, Feb 15, 2016 at 03:41:41PM +, Andrew Cooper wrote:

On 15/02/16 15:02, Jan Beulich wrote:

On 15.02.16 at 15:53,  wrote:

On 15/02/16 14:50, Jan Beulich wrote:

On 15.02.16 at 15:38,  wrote:

On 15/02/16 09:20, Jan Beulich wrote:

On 12.02.16 at 18:42,  wrote:

On 12/02/16 17:05, Jan Beulich wrote:

On 05.02.16 at 14:42,  wrote:

  #define X86_FEATURE_MWAITX( 3*32+29) /*   MWAIT extension

(MONITORX/MWAITX) */

Why not exposed to HVM (also for _MWAIT as I now notice)?

Because that is a good chunk of extra work to support.  We would need to
use 4K monitor widths, and extra p2m handling.

I don't understand: The base (_MWAIT) feature being exposed to
guests today, and kernels making use of the feature when available
suggests to me that things work. Are you saying you know
otherwise? (And if there really is a reason to mask the feature all of
the sudden, this should again be justified in the commit message.)

PV guests had it clobbered by Xen in traps.c

HVM guests have:

vmx.c:
 case EXIT_REASON_MWAIT_INSTRUCTION:
 case EXIT_REASON_MONITOR_INSTRUCTION:
[...]
 hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
 break;

and svm.c:
 case VMEXIT_MONITOR:
 case VMEXIT_MWAIT:
 hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
 break;

I don't see how a guest could actually use this feature.

Do you see the respective intercepts getting enabled anywhere?
(I don't outside of nested code, which I didn't check in detail.)

Yes - the intercepts are always enabled to prevent the guest actually
putting the processor to sleep.

Hmm, you're right, somehow I've managed to ignore the relevant
lines grep reported. Yet - how do things work then, without the
MWAIT feature flag currently getting cleared?

I have never observed it being used.  Do you have some local patches in
the SLES hypervisor?

There is some gross layer violation in xen/enlighten.c to pretend that
MWAIT is present to trick the ACPI code into evaluating _CST() methods
to report back to Xen.  (This is yet another PV-ism which will cause a
headache for a DMLite dom0)

Yes indeed. CC-ing Roger, and Boris.

Yes, all this is indeed not very nice, and we would ideally like to get
rid of it on PVHv2.


We will have to come up with something else: AIUI the whole point of 
xen_check_mwait() is to come up with proper ECX and EDX values for the 
MWAIT CPUID leaf. Those value are expected to be reported from 
xen_cpuid() pv_op so that acpi_processor_ffh_state_probe_cpu() can set C 
states structures properly.


The problem is that PVH executes CPUID instruction natively. (And so 
this must have been broken on PVHv1 as well).


-boris




Could we use the acpica tools (acpidump/acpixtract/acpiexec/...) in
order to fetch this information from user-space and send it to Xen using
privcmd?

AFAIK those tools work on most OSes (or at least the ones we care about
as Dom0).

In general, we can't rely on userspace evaluation of AML.

For trivial AML which evaluates to a constant, it could be interpreted
by userspace, but anything accessing system resources will need
evaluating by the kernel.

~Andrew



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

Re: [Xen-devel] [PATCH v3 MISSING/23] xsplice: Design document (v7).

[Jan Beulich]

>>> On 12.02.16 at 22:57,  wrote:
> +struct xsplice_patch_func {  
> +const char *name;  
> +Elf64_Xwordnew_addr;  

Missing space.

> +Elf64_Xword old_addr;  
> +Elf64_Word new_size;  
> +Elf64_Word long old_size;  

There are still two types left here.

> +### XEN_SYSCTL_XSPLICE_GET (1)
> +
> +Retrieve an status of an specific payload. This caller provides:
> +
> + * A `struct xen_xsplice_name` called `name` which has the unique name.
> + * A `struct xen_xsplice_status` structure which has all members
> +   set to zero: That is:
> +   * `status` *MUST* be set to zero.
> +   * `rc` *MUST* be set to zero.

Why is this?

> +The structure is as follow:
> +
> +
> +struct xen_xsplice_status {  
> +#define XSPLICE_STATUS_LOADED   1  
> +#define XSPLICE_STATUS_CHECKED  2  
> +#define XSPLICE_STATUS_APPLIED  3  
> +int32_t state;  /* OUT: XSPLICE_STATE_*. IN: MUST be 
> zero. */  
> +int32_t rc; /* OUT: 0 if no error, otherwise 
> -XEN_EXX. */  
> +/* IN: MUST be zero. */
> +};  
> +
> +struct xen_sysctl_xsplice_summary {  
> +xen_xsplice_name_t name;/* IN, the name of the payload. */  
> +xen_xsplice_status_t status;/* IN/OUT: status of the payload. */  
> +};  

With the operation being named XEN_SYSCTL_XSPLICE_GET, shouldn't
the structure tag be xen_sysctl_xsplice_get?

> +### XEN_SYSCTL_XSPLICE_LIST (2)
> +
> +Retrieve an array of abbreviated status and names of payloads that are 
> loaded in the
> +hypervisor.
> +
> +The caller provides:
> +
> + * `version`. Initially (on first hypercall) *MUST* be zero.
> + * `idx` index iterator. On first call *MUST* be zero, subsequent calls 
> varies.
> + * `nr` the max number of entries to populate.
> + * `pad` - *MUST* be zero.
> + * `status` virtual address of where to write `struct xen_xsplice_status`
> +   structures. Caller *MUST* allocate up to `nr` of them.
> + * `name` - virtual address of where to write the unique name of the payload.
> +   Caller *MUST* allocate up to `nr` of them. Each *MUST* be of
> +   **XEN_XSPLICE_NAME_SIZE** size.
> + * `len` - virtual address of where to write the length of each unique name
> +   of the payload. Caller *MUST* allocate up to `nr` of them. Each *MUST* be
> +   of sizeof(uint32_t) (4 bytes).
> +
> +If the hypercall returns an positive number, it is the number (upto `nr`
> +provided to the hypercall) of the payloads returned, along with `nr` updated
> +with the number of remaining payloads, `version` updated (it may be the same
> +across hypercalls - if it varies the data is stale and further calls could
> +fail). The `status`, `name`, and `len`' are updated at their designed index
> +value (`idx`) with the returned value of data.
> +
> +If the hypercall returns -XEN_E2BIG the `nr` is too big and should be
> +lowered.
> +
> +If the hypercall returns an zero value that means there are no payloads.

Maybe worth changing to "... there are no (more) payloads",
considering the iterative nature of the operation?

Jan


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

Re: [Xen-devel] [PATCH] travis: Drop bridge-utils and iproute2

[Doug Goldstein]

On 2/18/16 8:36 AM, Andrew Cooper wrote:
> These packages are not permitted inside travis, and are not necessary for
> building Xen.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Doug Goldstein 
> CC: Ian Campbell 
> CC: Ian Jackson 
> CC: Wei Liu 
> ---

Reviewed-by: Doug Goldstein 

-- 
Doug Goldstein



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

Re: [Xen-devel] libxl_device handling for nic and vtmp

[Wei Liu]

On Thu, Feb 18, 2016 at 04:13:21PM +0100, Olaf Hering wrote:
> What is the point of libxl__update_config_nic and
> libxl__update_config_vtmp?
> 
> In libxl__device_type_add (called from DEFINE_DEVICE_ADD) the input
> type is copied with libxl_device_type_copy to type_saved, which is a
> 1:1 copy. If needed, a new devid is assigned to the input. Later the
> copy is updated with one of the two helper functions mentioned above.
> But the helpers do not only update devid, also mac or uuid.
> 
> To me it looks like the double assignment can be removed. The new
> pvusb code does not do it this way, it makes a copy of the fully
> initialized type.
> 
> Perhaps the two helpers are useful in the context of domcreate_complete,
> I have not reviewed that part of the code.
> 

Because in the process of domain building some configurations are
autogenerated and you want to preserve them.

For example, user might not have specified mac address so the library
generates one for (s)he. You don't want mac address to regenerate after
save / restore or migration.  But you don't want to preserve all
autogenerated state, so you use the original copy as template and fill
it up as you see fit.

BTW, I look at my inbox far more often than I look at xen-devel so if
you CC me (relevant maintainers in general) in relevant emails in the
future they are less likely to fall through the crack.

Wei.

> 
> Olaf
> 
> ___
> 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] False positive coverity bug id: 1351218

[Andrew Cooper]

On 18/02/16 15:36, Harmandeep Kaur wrote:
> This is about a Coverity bug (included in the end), which I think is
> a false positive. I don't think pagesize can be zero in any case.
> pagesize = 1 << (((flags >> TMEM_POOL_PAGESIZE_SHIFT) &
> TMEM_POOL_PAGESIZE_MASK) + 12);
>
> Which means "pagesize > bufsize" will always be true and buf can
> not be null in any case if it reaches line 464 (or call may terminate
> if realloc(..) returns NULL).

I would agree that given the "1 <<", pagesize will always be larger than
0, and therefore call realloc().

However, every iteration of the
"while ( read_exact(io_fd, _id, sizeof(pool_id)) == 0 && pool_id != -1 )"
loop leaks buf, as do most of the error paths.

This function is currently orphaned code (since Xen 4.6), and in need of
some re-development before it can be used again.  I wouldn't worry too
much about fixing it up.

~Andrew

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

Re: [Xen-devel] [PATCH] tools/xenalyze: Fix build with clang

[George Dunlap]

On 12/02/16 19:06, Andrew Cooper wrote:
> 1) EXIT_REASON_EXCEPTION_NMI is 0, and Clang complains:
> 
> xenalyze.c:513:33: error: initializer overrides prior initialization of this 
> subobject [-Werror,-Winitializer-overrides]
> [EXIT_REASON_EXCEPTION_NMI]="EXCEPTION_NMI",
> ^~~
> xenalyze.c:512:11: note: previous initialization is here
> [0] = "NONE",
>   ^~
> 
> 2) cr3_time_compare(), eip_compare(), ipi_send() and cr3_compare_start() are
>declared as nested functions, which is a GCCism not supported by Clang.
> 
>As they don't actually make use of the interesting feature offered by
>nested functions (i.e. dynamic scoping), move them to just being normal
>functions.
> 
> 3) clear_interval_summary(), update_cpi() and clear_interval_cpi() are all
>unused.  The former isn't reference anywhere, so is deleted, while the 
> other
>two are called from currently #if 0'd code.
> 
> Signed-off-by: Andrew Cooper 

All looks good, thanks.

Acked-by: George Dunlap 



> ---
> CC: George Dunlap 
> CC: Ian Campbell 
> CC: Ian Jackson 
> CC: Wei Liu 
> ---
>  tools/xentrace/xenalyze.c | 188 
> +++---
>  1 file changed, 92 insertions(+), 96 deletions(-)
> 
> diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
> index 6520790..1651302 100644
> --- a/tools/xentrace/xenalyze.c
> +++ b/tools/xentrace/xenalyze.c
> @@ -509,7 +509,6 @@ struct {
>  #define HVM_VMX_EXIT_REASON_MAX (EXIT_REASON_XSETBV+1)
>  
>  char * hvm_vmx_exit_reason_name[HVM_VMX_EXIT_REASON_MAX] = {
> -[0] = "NONE",
>  [EXIT_REASON_EXCEPTION_NMI]="EXCEPTION_NMI",
>  [EXIT_REASON_EXTERNAL_INTERRUPT]="EXTERNAL_INTERRUPT",
>  [EXIT_REASON_TRIPLE_FAULT]="TRIPLE_FAULT",
> @@ -2270,11 +2269,6 @@ static inline void update_summary(struct 
> event_cycle_summary *s, long long c) {
>  s->count++;
>  }
>  
> -static inline void clear_interval_summary(struct event_cycle_summary *s) {
> -s->interval.count = 0;
> -s->interval.cycles = 0;
> -}
> -
>  static inline void update_cycles(struct cycle_summary *s, long long c) {
>  /* We don't know ahead of time how many samples there are, and working
>   * with dynamic stuff is a pain, and unnecessary.  This algorithm will
> @@ -2322,6 +2316,7 @@ static inline void clear_interval_cycles(struct 
> interval_element *e) {
>  e->instructions = 0;
>  }
>  
> +#if 0
>  static inline void update_cpi(struct weighted_cpi_summary *s,
>unsigned long long i,
>unsigned long long c) {
> @@ -2367,6 +2362,7 @@ static inline void clear_interval_cpi(struct 
> weighted_cpi_summary *s) {
>  s->interval.count = 0;
>  s->interval.instructions = 0;
>  }
> +#endif
>  
>  static inline void print_cpu_affinity(struct cycle_summary *s, char *p) {
>  if(s->count) {
> @@ -2647,6 +2643,23 @@ void interval_cr3_value_check(struct cr3_value_struct 
> *cr3) {
>  }
>  }
>  
> +int cr3_time_compare(const void *_a, const void *_b) {
> +struct cr3_value_struct *a=*(typeof())_a;
> +struct cr3_value_struct *b=*(typeof())_b;
> +
> +if(a->total_time.interval.cycles < b->total_time.interval.cycles)
> +return 1;
> +else if(b->total_time.interval.cycles == a->total_time.interval.cycles) {
> +if(a->total_time.interval.count < b->total_time.interval.count)
> +return 1;
> +else if(a->total_time.interval.count == b->total_time.interval.count)
> +return 0;
> +else
> +return -1;
> +} else
> +return -1;
> +}
> +
>  void interval_cr3_schedule_ordered_output(void) {
>  struct cr3_value_struct *p;
>  int i;
> @@ -2654,23 +2667,6 @@ void interval_cr3_schedule_ordered_output(void) {
>  struct cr3_value_struct **qsort_array;
>  int N=0;
>  
> -int cr3_time_compare(const void *_a, const void *_b) {
> -struct cr3_value_struct *a=*(typeof())_a;
> -struct cr3_value_struct *b=*(typeof())_b;
> -
> -if(a->total_time.interval.cycles < b->total_time.interval.cycles)
> -return 1;
> -else if(b->total_time.interval.cycles == 
> a->total_time.interval.cycles) {
> -if(a->total_time.interval.count < b->total_time.interval.count)
> -return 1;
> -else if(a->total_time.interval.count == 
> b->total_time.interval.count)
> -return 0;
> -else
> -return -1;
> -} else
> -return -1;
> -}
> -
>  for(p=P.cr3.head; p; p=p->gnext)
>  N++;
>  
> @@ -2966,6 +2962,23 @@ void update_eip(struct eip_list_struct **head, 
> unsigned long long eip,
>  update_summary(>summary, cycles);
>  }
>  
> +int eip_compare(const void *_a, const void *_b) 

[Xen-devel] libxl_device handling for nic and vtmp

[Olaf Hering]

What is the point of libxl__update_config_nic and
libxl__update_config_vtmp?

In libxl__device_type_add (called from DEFINE_DEVICE_ADD) the input
type is copied with libxl_device_type_copy to type_saved, which is a
1:1 copy. If needed, a new devid is assigned to the input. Later the
copy is updated with one of the two helper functions mentioned above.
But the helpers do not only update devid, also mac or uuid.

To me it looks like the double assignment can be removed. The new
pvusb code does not do it this way, it makes a copy of the fully
initialized type.

Perhaps the two helpers are useful in the context of domcreate_complete,
I have not reviewed that part of the code.


Olaf

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