[Xen-devel] Make the Wiki 4.6 ready: Xen Project Document Day is Wednesday

[Russ Pavlicek]

OUR THEME OF THE MONTH: "Ready for 4.6"

This month, we continue with the effort to make the Wiki reflect the
realities of the 4.6 release.  Many pages need reviewing and may need
updating.  Main tasks include:

- Add new documentation for new features
- Modify existing documentation for anything which is changing in the
newest release, and
- Deprecate old documentation, letting people know that certain
information is applies only to older releases

Check out the current documentation, and anything which doesn't map to
4.6 (or 4.5, for that matter) commands or best practices will need
improvement.

More detailed information can be found in the TODO document (below).
And, as always, feel free to add any other documentation which you
believe to be necessary.

All the information you need to participate in Document Day is here:

http://wiki.xenproject.org/wiki/Xen_Document_Days

Also take a look at the current TODO list to see other items which
need attention:

http://wiki.xenproject.org/wiki/Xen_Document_Days/TODO

Please think about how you can help out.  If you haven't requested
to be made a Wiki editor, save time and do it now so you are ready to
go on Document Day.  Just fill out the form below:

http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html

We hope to see you Wednesday in #xendocs!

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

Re: [Xen-devel] [Minios-devel] [PATCH MINI-OS v2] xenbus: notify the other end when necessary

[Wei Liu]

On Mon, Oct 26, 2015 at 01:52:47PM +0100, Samuel Thibault wrote:
> Wei Liu, le Mon 26 Oct 2015 12:47:56 +, a écrit :
> > -if (xenstore_buf->rsp_prod - xenstore_buf->rsp_cons < 
> > sizeof(msg))
> > +if (xenstore_buf->rsp_prod - xenstore_buf->rsp_cons < 
> > sizeof(msg)) {
> > +notify_remote_via_evtchn(start_info.store_evtchn);
> >  break;
> > +}
> 
> >  if (xenstore_buf->rsp_prod - xenstore_buf->rsp_cons <
> > -sizeof(msg) + msg.len)
> > +sizeof(msg) + msg.len) {
> > +notify_remote_via_evtchn(start_info.store_evtchn);
> 
> Actually thinking...  In principle we should not need these two
> notifications: we have already notified last time we consumed a message.
> Notifying again shouldn't be bringing anything new.  Do you actually see
> a difference with these?
> 

Yes. The ring still gets stalled somehow without those two
notifications.

Wei.

> Samuel
> 
> ___
> Minios-devel mailing list
> minios-de...@lists.xenproject.org
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/minios-devel

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

Re: [Xen-devel] [PATCH v1 1/5] xsplice: Design document.

[Konrad Rzeszutek Wilk]

On Mon, Oct 26, 2015 at 01:21:46PM +, Ross Lagerwall wrote:
> On 10/26/2015 12:01 PM, Martin Pohlack wrote:
> >On 16.09.2015 23:01, Konrad Rzeszutek Wilk wrote:
> >
> >[...]
> >
> >>+### xsplice_patch
> >>+
> >>+This structure has the binary code (or data) to be patched. Depending on 
> >>the
> >>+type it can either an inline patch (data or text) or require an relocation
> >>+change (which requires a trampoline). Naturally it also points to a blob
> >>+of the binary data to patch in, and the size of the patch.
> >
> >On the Xen developer summit we agreed to start with a minimal approach
> >first.  Based on looking at the last ~50 XSA patches, I do think we can
> >do *without* the in-place patching and would propose to tackle this
> >approach later or not at all.


> >
> 
> Indeed. The prototype V1 that I posted last Friday works at a function
> level. I guess the only reason to make anything more complicated would be to
> patch the asm code in entry.S.

Right, let me move this to the 'v2 improvements thoughts' of the design
document (so we don't lose some of this information, ideas, etc)?

> 
> -- 
> Ross Lagerwall

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

[Xen-devel] (XEN) Fatal machine check

[John Doe]

Hi, i'm getting this problem with linux 4.3.0-rcX branch.
Full log is attached. My hardware is based on intel skylake i7-6700k on
z170 chipset and it is working properly. It does boot correctly with
older kernels (3.12).
With mce=off on xen parameters it does boot unti during pci detection
where it hangs (see attached log).

I tried with both xen 4.4.2 and 4.6.0 with the same effect

[2.957615] VFS: Disk quotas d(XEN) Fatal machine check: MCE: Fatal
error happened on CPUs ff
(XEN)
(XEN) 
(XEN)
(XEN)The processor has reported a hardware error which cannot
(XEN)be recovered from.  Xen will now reboot the machine.
(XEN) mce.c:1533: Begin dump mc_info
(XEN) CPU0: Machine Check Exception:5
(XEN) Bank 4: ba0011000402[   0]
(XEN) CPU0: Machine Check Exception:5
(XEN) Bank 4: ba0011000402[   0]
(XEN) CPU1: Machine Check Exception:5
(XEN) Bank 4: ba0011000402[   0]
(XEN) CPU1: Machine Check Exception:5
(XEN) Bank 4: ba0011000402[   0]
(XEN) CPU2: Machine Check Exception:5
(XEN) Bank 4: ba0011000402[   0]
(XEN) CPU2: Machine Check Exception:5
(XEN) Bank 4: ba0011000402[   0]
(XEN) CPU3: Machine Check Exception:5
(XEN) Bank 4: ba0011000402[   0]
(XEN) CPU3: Machine Check Exception:5
(XEN) Bank 4: ba0011000402[   0]
(XEN) mce.c:1536: End dump mc_info, 8 mcinfo dumped
(XEN)
(XEN) 
(XEN) Panic on CPU 0:
(XEN) HARDWARE ERROR
(XEN) 
(XEN)
(XEN) Reboot in five seconds...

Any help?

Thanks,
John.
Loading Xen 4.4.2 ...
Loading Linux 4.3.0-1.pvops.qubes.x86_64 ...
Loading initial ramdisk ...
 Xen 4.4.2-7.fc21
(XEN) Xen version 4.4.2 (user@) (gcc (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6)) debug=n Tue Oct 20 14:48:15 CEST 2015
(XEN) Latest ChangeSet: 
(XEN) Bootloader: GRUB 2.00
(XEN) Command line: placeholder iommu=pt iommu=1 unrestricted_guest=1 msi=1 swiotlb=force console=ttyS0 com1=115200,8n1 console=com1 dom0_mem=min:1024Mi loglvl=all apic_verbosity=debug e820t
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Initial Xen-e820 RAM map:
(XEN)   - 0009c800 (usable)
(XEN)  0009c800 - 000a (reserved)
(XEN)  000e - 0010 (reserved)
(XEN)  0010 - 63911000 (usable)
(XEN)  63911000 - 63912000 (ACPI NVS)
(XEN)  63912000 - 6395c000 (reserved)
(XEN)  6395c000 - 639af000 (usable)
(XEN)  639af000 - 640b4000 (reserved)
(XEN)  640b4000 - 66b99000 (usable)
(XEN)  66b99000 - 677ab000 (reserved)
(XEN)  677ab000 - 67f9a000 (ACPI NVS)
(XEN)  67f9a000 - 67fff000 (ACPI data)
(XEN)  67fff000 - 6800 (usable)
(XEN)  0001 - 00089200 (usable)
(XEN)  6800 - 6810 (reserved)
(XEN)  e000 - f000 (reserved)
(XEN)  fe00 - fe011000 (reserved)
(XEN)  fec0 - fec01000 (reserved)
(XEN)  fee0 - fee01000 (reserved)
(XEN)  ff00 - 0001 (reserved)
(XEN) Checking MTRR ranges...
(XEN)  MTRR cap: 1d0a type: c06
(XEN) Xen-e820 RAM map:
(XEN)   - 0009c800 (usable)
(XEN)  0009c800 - 000a (reserved)
(XEN)  000e - 0010 (reserved)
(XEN)  0010 - 63911000 (usable)
(XEN)  63911000 - 63912000 (ACPI NVS)
(XEN)  63912000 - 6395c000 (reserved)
(XEN)  6395c000 - 639af000 (usable)
(XEN)  639af000 - 640b4000 (reserved)
(XEN)  640b4000 - 66b99000 (usable)
(XEN)  66b99000 - 677ab000 (reserved)
(XEN)  677ab000 - 67f9a000 (ACPI NVS)
(XEN)  67f9a000 - 67fff000 (ACPI data)
(XEN)  67fff000 - 6800 (usable)
(XEN)  6800 - 6810 (reserved)
(XEN)  e000 - f000 (reserved)
(XEN)  fe00 - fe011000 (reserved)
(XEN)  fec0 - fec01000 (reserved)
(XEN)  fee0 - fee01000 (reserved)
(XEN)  ff00 - 0001 (reserved)
(XEN)  0001 - 00089200 (usable)
(XEN) ACPI: RSDP 000F05B0, 0024 (r2 ALASKA)
(XEN) ACPI: XSDT 67F59098, 00AC (r1 ALASKA   A M I   1072009 AMI 10013)
(XEN) ACPI: FACP 67F7BB20, 010C (r5 ALASKA   A M I   1072009 AMI 10013)
(XEN) ACPI: DSDT 67F591D8, 22943 (r2 ALASKA   A M I   1072009 

Re: [Xen-devel] [PATCH MINI-OS] xenbus: notify the other end when necessary

[Wei Liu]

On Mon, Oct 26, 2015 at 01:02:45PM +0100, Samuel Thibault wrote:
> Hello,
> 
> Indeed, notification seems to have been missing since basically 2006...
> 
> Wei Liu, le Mon 26 Oct 2015 09:47:48 +, a écrit :
> > diff --git a/xenbus/xenbus.c b/xenbus/xenbus.c
> > index 4613ed6..7451161 100644
> > --- a/xenbus/xenbus.c
> > +++ b/xenbus/xenbus.c
> > @@ -205,8 +205,10 @@ static void xenbus_thread_func(void *ign)
> >  prod = xenstore_buf->rsp_prod;
> >  DEBUG("Rsp_cons %d, rsp_prod %d.\n", xenstore_buf->rsp_cons,
> >  xenstore_buf->rsp_prod);
> > -if (xenstore_buf->rsp_prod - xenstore_buf->rsp_cons < 
> > sizeof(msg))
> > +if (xenstore_buf->rsp_prod - xenstore_buf->rsp_cons < 
> > sizeof(msg)) {
> > +notify_remote_via_evtchn(start_info.store_evtchn);
> >  break;
> > +}
> >  rmb();
> >  memcpy_from_ring(xenstore_buf->rsp,
> >  ,
> > @@ -217,8 +219,10 @@ static void xenbus_thread_func(void *ign)
> >  xenstore_buf->rsp_prod - xenstore_buf->rsp_cons,
> >  msg.req_id);
> >  if (xenstore_buf->rsp_prod - xenstore_buf->rsp_cons <
> > -sizeof(msg) + msg.len)
> > +sizeof(msg) + msg.len) {
> > +notify_remote_via_evtchn(start_info.store_evtchn);
> >  break;
> > +}
> >  
> >  DEBUG("Message is good.\n");
> >  
> > @@ -265,6 +269,9 @@ static void xenbus_thread_func(void *ign)
> >  xenstore_buf->rsp_cons += msg.len + sizeof(msg);
> >  wake_up(_info[msg.req_id].waitq);
> >  }
> > +
> > +wmb();
> > +notify_remote_via_evtchn(start_info.store_evtchn);
> >  }
> >  }
> >  }
> 
> The wmb() position seems right, but the notification could be put a bit
> later, after the exit of the while(1) loop.  That'd make it factorized
> for all cases were the processing could want to stop, and make it quite
> naturally enough just before the wait_event call, so something like
> below (untested).
> 
> Samuel
> 
> diff --git a/xenbus/xenbus.c b/xenbus/xenbus.c
> index 4613ed6..858aa98 100644
> --- a/xenbus/xenbus.c
> +++ b/xenbus/xenbus.c
> @@ -265,7 +265,10 @@ static void xenbus_thread_func(void *ign)
>  xenstore_buf->rsp_cons += msg.len + sizeof(msg);
>  wake_up(_info[msg.req_id].waitq);
>  }
> +
> +wmb();
>  }
> +notify_remote_via_evtchn(start_info.store_evtchn);

I am sure your patch works too but there is a subtle difference.  In my
patch, mini-os notifies remote whenever it consumes a message, which I
think it's slightly better because backend can start putting things in
the ring as mini-os processes them.

Wei.

>  }
>  }
>  

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

Re: [Xen-devel] [PATCH 1/2] xen/x86: Helpers for cpu feature manipuation

[Andrew Cooper]

On 26/10/15 12:06, Jan Beulich wrote:
 On 26.10.15 at 12:17,  wrote:
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -202,7 +202,7 @@ static void __init early_cpu_detect(void)
>>  c->x86_mask = tfms & 15;
>>  cap0 &= ~cleared_caps[0];
>>  cap4 &= ~cleared_caps[4];
>> -if (cap0 & (1<<19))
>> +if (cap0 & cpufeat_mask(X86_FEATURE_CLFLSH))
> This one's particularly well spotted! Thanks!

I doubt I have found all instances like this.  I only found this one
because of the associated changes in the subsequent patch.

I will be fixing them as I find them.

~Andrew

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

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

[Jan Beulich]

>>> On 23.10.15 at 11:48,  wrote:
> This patch uses xsaves/xrstors/xsavec instead of xsaveopt/xrstor
> to perform the xsave_area switching so that xen itself
> can benefit from them when available.
> 
> For xsaves/xrstors/xsavec only use compact format. Add format conversion
> support when perform guest os migration.
> 
> Also, pv guest will not support xsaves/xrstors.
> 
> Signed-off-by: Shuai Ruan 
> Reviewed-by: Andrew Cooper 

There were actual bugs fixed from v7 to v8, plus there's a public
interface change, so retaining this tag is wrong.

> @@ -2025,6 +2026,11 @@ static int hvm_load_cpu_ctxt(struct domain *d, 
> hvm_domain_context_t *h)
>  
>  v->arch.hvm_vcpu.msr_tsc_aux = ctxt.msr_tsc_aux;
>  
> +if ( cpu_has_xsaves )
> +v->arch.hvm_vcpu.msr_xss = ctxt.msr_xss;
> +else
> +v->arch.hvm_vcpu.msr_xss = 0;

Cases like this call for use of ?:.

> @@ -2257,10 +2266,10 @@ static int hvm_load_cpu_xsave_states(struct domain 
> *d, hvm_domain_context_t *h)
>  v->arch.xcr0_accum = ctxt->xcr0_accum;
>  if ( ctxt->xcr0_accum & XSTATE_NONLAZY )
>  v->arch.nonlazy_xstate_used = 1;
> -memcpy(v->arch.xsave_area, >save_area,
> -   min(desc->length, size) - offsetof(struct hvm_hw_cpu_xsave,
> -   save_area));
>  
> +compress_xsave_states(v, >save_area,
> +  min(desc->length, size) -
> +  offsetof(struct hvm_hw_cpu_xsave,save_area));
>  return 0;

This change now misplaces the blank line. Please - a little more care
when comments on formatting were already given.

> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -935,9 +935,10 @@ void pv_cpuid(struct cpu_user_regs *regs)
>  goto unsupported;
>  if ( regs->_ecx == 1 )
>  {
> -a &= boot_cpu_data.x86_capability[X86_FEATURE_XSAVEOPT / 32];
> -if ( !cpu_has_xsaves )
> -b = c = d = 0;
> +a &= cpufeat_mask(X86_FEATURE_XSAVEOPT) |
> + cpufeat_mask(X86_FEATURE_XSAVEC) |
> + (cpu_has_xgetbv1 ? cpufeat_mask(X86_FEATURE_XGETBV1) : 0);

Why the cpu_has_xgetbv1 dependency? If you want to do it this
way, it will get unreadable with two or three more features. Why
don't you simply and with the known mask on top of the and with
the capability flags that was already there?

And actually I realize I may have misguided you: xstate_init()
already makes sure boot_cpu_data.x86_capability[] doesn't
contain any unsupported flags, so keeping just the masking
that's already there should be enough.

> +void expand_xsave_states(struct vcpu *v, void *dest, unsigned int size)
> +{
> +struct xsave_struct *xsave = v->arch.xsave_area;
> +u64 xstate_bv = xsave->xsave_hdr.xstate_bv;
> +u64 valid;
> +
> +if ( !cpu_has_xsaves && !cpu_has_xsavec )
> +{
> +memcpy(dest, xsave, size);
> +return;
> +}
> +
> +ASSERT(xsave_area_compressed(xsave));
> +/*
> + * Copy legacy XSAVE area, to avoid complications with CPUID
> + * leaves 0 and 1 in the loop below.
> + */
> +memcpy(dest, xsave, FXSAVE_SIZE);
> +
> +((struct xsave_struct *)dest)->xsave_hdr.xstate_bv = xstate_bv;
> +((struct xsave_struct *)dest)->xsave_hdr.xcomp_bv =  0;

Wouldn't it be more logical to also memcpy() the header? Which
would do away with at least one of these ugly casts, would
allow folding with the memcpy() done right before, _and_ would
eliminate an (apparent or real I'm not sure without looking in
more detail) information leak (the remainder of the header).

> +/*
> + * Copy each region from the possibly compacted offset to the
> + * non-compacted offset.
> + */
> +valid = xstate_bv & ~XSTATE_FP_SSE;
> +while ( valid )
> +{
> +u64 feature = valid & -valid;
> +unsigned int index = fls(feature) - 1;
> +const void *src = get_xsave_addr(xsave, index);
> +
> +if ( src )
> +{
> +ASSERT((xstate_offsets[index] + xstate_sizes[index]) <= size);
> +memcpy(dest + xstate_offsets[index], src, xstate_sizes[index]);
> +}
> +
> +valid &= ~feature;
> +}
> +
> +}

Stray blank line.

> @@ -187,39 +379,24 @@ void xrstor(struct vcpu *v, uint64_t mask)
>  switch ( __builtin_expect(ptr->fpu_sse.x[FPU_WORD_SIZE_OFFSET], 8) )
>  {
>  default:
> -asm volatile ( "1: .byte 0x48,0x0f,0xae,0x2f\n"
> -   ".section .fixup,\"ax\"  \n"
> -   "2: mov %5,%%ecx \n"
> -   "   xor %1,%1\n"
> -   "   rep stosb\n"
> -   "   lea %2,%0\n"
> -   "   mov %3,%1\n"
> -   "   jmp 1b   \n"
> -   ".previous 

Re: [Xen-devel] ovmf fails to build in stagin-4.6

[Wei Liu]

On Mon, Oct 26, 2015 at 12:13:40PM +0100, Olaf Hering wrote:
> On Mon, Oct 26, Wei Liu wrote:
> 
> > Wait, so you're using gcc-5.1.1 but OVMF is reporting gcc-4.4 (see in
> > the path of output string), there might be another problem with
> > toolchain detection then.
> 
> As Linus said: detect old and known to be problematic, everything else has to
> be handled as "current". But see 
> tools/firmware/ovmf-dir-remote/OvmfPkg/build.sh
> 
> gcc_version=$(gcc -v 2>&1 | tail -1 | awk '{print $3}')
> case $gcc_version in
>   4.5.*)
> TARGET_TOOLS=GCC45
> ;;
>   4.6.*)
> TARGET_TOOLS=GCC46
> ;;
>   4.7.*)
> TARGET_TOOLS=GCC47
> ;;
>   4.8.*)
> TARGET_TOOLS=GCC48
> ;;
>   4.9.*|4.1[0-9].*)
> TARGET_TOOLS=GCC49
> ;;
>   *)
> TARGET_TOOLS=GCC44
> ;;
> esac

I think you have a stale repository. Try deleting ovmf-dir-remote ?

I can't comment how they handle toolchain detection though.

Wei.

> 
> Olaf

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

Re: [Xen-devel] [PATCH MINI-OS] xenbus: notify the other end when necessary

[Samuel Thibault]

Wei Liu, le Mon 26 Oct 2015 12:30:28 +, a écrit :
> On Mon, Oct 26, 2015 at 01:21:51PM +0100, Samuel Thibault wrote:
> > Wei Liu, le Mon 26 Oct 2015 12:14:43 +, a écrit :
> > > In my patch, mini-os notifies remote whenever it consumes a message,
> > > which I think it's slightly better because backend can start putting
> > > things in the ring as mini-os processes them.
> > 
> > That makes more notifications, but that can lead to more pipelining
> > indeed.  That's what the Linux driver does, so let's do the same.
> > 
> > Also, I'm realizing: aren't we missing a full memory barrier between
> > the memcpy_from_ring call and xenstore_buf->rsp_cons += ? (in the two
> > places) We need to make sure to have finished copying from the ring
> > before writing the new rsp_cons.
> > 
> 
> You're right.
> 
> I think we should just turn that wmb() into two mb()s and place them
> before xenstore_buf->rsp_cons +=.

We *also* need some barrier between rsp_cons += and the notification,
otherwise the notified domain may miss the rsp_cons update and thus
believe it was a spurious notification.

Samuel

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

[Xen-devel] [PATCH MINI-OS v2] xenbus: notify the other end when necessary

[Wei Liu]

The xenbus thread didn't send notification to other end when it expected
more data or consumed responses, which led to stalling the ring from
time to time.

This is the culprit that guest was less responsive when using stubdom
because the device model was stalled.

Fix this by sending notification to the other end at the right places.

Signed-off-by: Wei Liu 
---
Cc: Ian Campbell 
Cc: Ian Jackson 
Cc: Samuel Thibault 

v2: add two more mb()s.

With this path I can migrate a guest with stubdom a few thousand times
without any issue, while before I could easily trigger time out
within a few iterations. This should make OSSTest stubdom test case more
reliable.

Ian, this is a patch suitable for backporting to 4.6. It's good time
branch mini-os now.
---
 xenbus/xenbus.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/xenbus/xenbus.c b/xenbus/xenbus.c
index 4613ed6..bc669f2 100644
--- a/xenbus/xenbus.c
+++ b/xenbus/xenbus.c
@@ -205,8 +205,10 @@ static void xenbus_thread_func(void *ign)
 prod = xenstore_buf->rsp_prod;
 DEBUG("Rsp_cons %d, rsp_prod %d.\n", xenstore_buf->rsp_cons,
 xenstore_buf->rsp_prod);
-if (xenstore_buf->rsp_prod - xenstore_buf->rsp_cons < sizeof(msg))
+if (xenstore_buf->rsp_prod - xenstore_buf->rsp_cons < sizeof(msg)) 
{
+notify_remote_via_evtchn(start_info.store_evtchn);
 break;
+}
 rmb();
 memcpy_from_ring(xenstore_buf->rsp,
 ,
@@ -217,8 +219,10 @@ static void xenbus_thread_func(void *ign)
 xenstore_buf->rsp_prod - xenstore_buf->rsp_cons,
 msg.req_id);
 if (xenstore_buf->rsp_prod - xenstore_buf->rsp_cons <
-sizeof(msg) + msg.len)
+sizeof(msg) + msg.len) {
+notify_remote_via_evtchn(start_info.store_evtchn);
 break;
+}
 
 DEBUG("Message is good.\n");
 
@@ -237,6 +241,7 @@ static void xenbus_thread_func(void *ign)
event->path = data;
event->token = event->path + strlen(event->path) + 1;
 
+mb();
 xenstore_buf->rsp_cons += msg.len + sizeof(msg);
 
 for (watch = watches; watch; watch = watch->next)
@@ -262,9 +267,13 @@ static void xenbus_thread_func(void *ign)
 req_info[msg.req_id].reply,
 MASK_XENSTORE_IDX(xenstore_buf->rsp_cons),
 msg.len + sizeof(msg));
+mb();
 xenstore_buf->rsp_cons += msg.len + sizeof(msg);
 wake_up(_info[msg.req_id].waitq);
 }
+
+wmb();
+notify_remote_via_evtchn(start_info.store_evtchn);
 }
 }
 }
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v2 4/5] x86/mm: build map_domain_gfn() just once

[Andrew Cooper]

On 26/10/15 11:52, Jan Beulich wrote:
> It doesn't depend on GUEST_PAGING_LEVELS. Moving the function to p2m.c
> at once allows a bogus #define/#include pair to be removed from
> hap/nested_ept.c.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v1 1/5] xsplice: Design document.

[Ross Lagerwall]

On 10/26/2015 12:01 PM, Martin Pohlack wrote:

On 16.09.2015 23:01, Konrad Rzeszutek Wilk wrote:

[...]


+### xsplice_patch
+
+This structure has the binary code (or data) to be patched. Depending on the
+type it can either an inline patch (data or text) or require an relocation
+change (which requires a trampoline). Naturally it also points to a blob
+of the binary data to patch in, and the size of the patch.


On the Xen developer summit we agreed to start with a minimal approach
first.  Based on looking at the last ~50 XSA patches, I do think we can
do *without* the in-place patching and would propose to tackle this
approach later or not at all.



Indeed. The prototype V1 that I posted last Friday works at a function 
level. I guess the only reason to make anything more complicated would 
be to patch the asm code in entry.S.


--
Ross Lagerwall

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

Re: [Xen-devel] [PATCH v1 1/5] xsplice: Design document.

[Jan Beulich]

>>> On 26.10.15 at 13:01,  wrote:
> On 16.09.2015 23:01, Konrad Rzeszutek Wilk wrote:
>> +The convention for file-type symbols (that would allow to map many
>> +symbols to their compilation unit) says that only the basename (i.e.,
>> +without directories) is embedded.  This creates another layer of
>> +confusion for duplicate file names in the build tree.
>> +
>> +That would have to be resolved.
> 
> Another approach here would be to qualify symbol names by the
> object-file name which contains them + a unique path component, for example:
> 
> drivers/pci/pci.o
> arch/x86/pci.o
> arch/x86/x86_64/pci.o

I wouldn't want to do this uniformly. A patch series doing this where
needed has been proposed already:
http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg02702.html

Jan


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

Re: [Xen-devel] [PATCH MINI-OS] xenbus: notify the other end when necessary

[Samuel Thibault]

Hello,

Indeed, notification seems to have been missing since basically 2006...

Wei Liu, le Mon 26 Oct 2015 09:47:48 +, a écrit :
> diff --git a/xenbus/xenbus.c b/xenbus/xenbus.c
> index 4613ed6..7451161 100644
> --- a/xenbus/xenbus.c
> +++ b/xenbus/xenbus.c
> @@ -205,8 +205,10 @@ static void xenbus_thread_func(void *ign)
>  prod = xenstore_buf->rsp_prod;
>  DEBUG("Rsp_cons %d, rsp_prod %d.\n", xenstore_buf->rsp_cons,
>  xenstore_buf->rsp_prod);
> -if (xenstore_buf->rsp_prod - xenstore_buf->rsp_cons < 
> sizeof(msg))
> +if (xenstore_buf->rsp_prod - xenstore_buf->rsp_cons < 
> sizeof(msg)) {
> +notify_remote_via_evtchn(start_info.store_evtchn);
>  break;
> +}
>  rmb();
>  memcpy_from_ring(xenstore_buf->rsp,
>  ,
> @@ -217,8 +219,10 @@ static void xenbus_thread_func(void *ign)
>  xenstore_buf->rsp_prod - xenstore_buf->rsp_cons,
>  msg.req_id);
>  if (xenstore_buf->rsp_prod - xenstore_buf->rsp_cons <
> -sizeof(msg) + msg.len)
> +sizeof(msg) + msg.len) {
> +notify_remote_via_evtchn(start_info.store_evtchn);
>  break;
> +}
>  
>  DEBUG("Message is good.\n");
>  
> @@ -265,6 +269,9 @@ static void xenbus_thread_func(void *ign)
>  xenstore_buf->rsp_cons += msg.len + sizeof(msg);
>  wake_up(_info[msg.req_id].waitq);
>  }
> +
> +wmb();
> +notify_remote_via_evtchn(start_info.store_evtchn);
>  }
>  }
>  }

The wmb() position seems right, but the notification could be put a bit
later, after the exit of the while(1) loop.  That'd make it factorized
for all cases were the processing could want to stop, and make it quite
naturally enough just before the wait_event call, so something like
below (untested).

Samuel

diff --git a/xenbus/xenbus.c b/xenbus/xenbus.c
index 4613ed6..858aa98 100644
--- a/xenbus/xenbus.c
+++ b/xenbus/xenbus.c
@@ -265,7 +265,10 @@ static void xenbus_thread_func(void *ign)
 xenstore_buf->rsp_cons += msg.len + sizeof(msg);
 wake_up(_info[msg.req_id].waitq);
 }
+
+wmb();
 }
+notify_remote_via_evtchn(start_info.store_evtchn);
 }
 }
 

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

Re: [Xen-devel] [PATCH MINI-OS] xenbus: notify the other end when necessary

[Samuel Thibault]

Wei Liu, le Mon 26 Oct 2015 12:14:43 +, a écrit :
> In my patch, mini-os notifies remote whenever it consumes a message,
> which I think it's slightly better because backend can start putting
> things in the ring as mini-os processes them.

That makes more notifications, but that can lead to more pipelining
indeed.  That's what the Linux driver does, so let's do the same.

Also, I'm realizing: aren't we missing a full memory barrier between
the memcpy_from_ring call and xenstore_buf->rsp_cons += ? (in the two
places) We need to make sure to have finished copying from the ring
before writing the new rsp_cons.

Samuel

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

Re: [Xen-devel] [PATCH MINI-OS] xenbus: notify the other end when necessary

[Wei Liu]

On Mon, Oct 26, 2015 at 01:21:51PM +0100, Samuel Thibault wrote:
> Wei Liu, le Mon 26 Oct 2015 12:14:43 +, a écrit :
> > In my patch, mini-os notifies remote whenever it consumes a message,
> > which I think it's slightly better because backend can start putting
> > things in the ring as mini-os processes them.
> 
> That makes more notifications, but that can lead to more pipelining
> indeed.  That's what the Linux driver does, so let's do the same.
> 
> Also, I'm realizing: aren't we missing a full memory barrier between
> the memcpy_from_ring call and xenstore_buf->rsp_cons += ? (in the two
> places) We need to make sure to have finished copying from the ring
> before writing the new rsp_cons.
> 

You're right.

I think we should just turn that wmb() into two mb()s and place them
before xenstore_buf->rsp_cons +=.

Wei.

> Samuel

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

Re: [Xen-devel] [V8 3/4] x86/xsaves: enable xsaves/xrstors for hvm guest

[Jan Beulich]

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

I said before that without xstate_offsets being used anywhere outside
this file it shouldn't be made non-static.

Also please note that the saving/restoring of XSS really belongs
here instead of in patch 2.

Jan


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

Re: [Xen-devel] Ping: [PATCH v3] x86/HVM: correct page dirty marking in hvm_map_guest_frame_rw()

[Ian Jackson]

Wei Liu writes ("Re: [Xen-devel] Ping: [PATCH v3] x86/HVM: correct page dirty 
marking in hvm_map_guest_frame_rw()"):
> On Mon, Oct 26, 2015 at 07:09:06AM -0600, Jan Beulich wrote:
> > Tools maintainers, could I please get an ack or otherwise on this
> > adjustment?

I confess I'm out of my depth here.  But thanks to Andrew Cooper's
review, I'm happy to ack it without understanding it, except:

> Does it make sense to use inverse logic that you set a flag to not
> mark permanent pages dirty? I think that's a bit awkward, not sure if it
> is worth it.
> 
> I also realise that libxenctrl doesn't have stable interface so I'm a
> bit two-minded for this.

What kind of out of tree callers are going to use xc_shadow_control ?

Not qemu, AFAICT, which would be my main worry.

Ian.

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

Re: [Xen-devel] [PATCH] x86/PV: properly populate descriptor tables

[David Vrabel]

On 26/10/15 15:08, Jan Beulich wrote:
 On 26.10.15 at 15:58,  wrote:
>> On 26/10/15 14:55, Andrew Cooper wrote:
>>> On 26/10/15 14:43, David Vrabel wrote:
 On 23/09/15 16:34, Jan Beulich wrote:
> Us extending the GDT limit past the Xen descriptors so far meant that
> guests (including user mode programs) accessing any descriptor table
> slot above the original OS'es limit but below the first Xen descriptor
> caused a #PF, converted to a #GP in our #PF handler. Which is quite
> different from the native behavior, where some of such accesses (LAR
> and LSL) don't fault. Mimic that behavior by mapping a blank page into
> unused slots.
>
> While not strictly required, treat the LDT the same for consistency.
 This change causes a 32-bit userspace process running in a 32-bit PV
 guest to segfault.

 The process is a Go program and it is using the modify_ldt() system call
 (which is successful) but loading %gs with the new descriptor causes a
 fault.  Even a minimal (empty main()) go program faults.
>>> D'uh - its obvious now you point it out.
>>>
>>> By filling the shadow ldt slots as present, zero entries, we break their
>>> demand-faulting.
>>>
>>> We can't be safe to incorrect faults from LAR/LSL, *and* perform demand
>>> faulting of the LDT.
>>
>> Wait.  Yes we can.  I am talking nonsense.
>>
>> Hunk 2 should be reverted, and the demand fault handler should populate
>> a zero entry rather than passing #GP back to the guest.
> 
> Considering this
> 
> "While not strictly required, treat the LDT the same for consistency."
> 
> in the changelog, simply reverting the LDT part would seem
> sufficient to me (albeit that's more than just hunk 2 afaics).

Apply this partial revert fixes the problem for me.

8<
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -502,8 +502,8 @@ void update_cr3(struct vcpu *v)
 static void invalidate_shadow_ldt(struct vcpu *v, int flush)
 {
 l1_pgentry_t *pl1e;
-unsigned int i;
-unsigned long pfn, zero_pfn = PFN_DOWN(__pa(zero_page));
+int i;
+unsigned long pfn;
 struct page_info *page;
 
 BUG_ON(unlikely(in_irq()));
@@ -524,9 +523,8 @@ static void invalidate_shadow_ldt(struct vcpu *v, int flush)
 for ( i = 16; i < 32; i++ )
 {
 pfn = l1e_get_pfn(pl1e[i]);
-if ( !(l1e_get_flags(pl1e[i]) & _PAGE_PRESENT) || pfn == zero_pfn )
-continue;
-l1e_write([i], l1e_from_pfn(zero_pfn, __PAGE_HYPERVISOR_RO));
+if ( pfn == 0 ) continue;
+l1e_write([i], l1e_empty());
 page = mfn_to_page(pfn);
 ASSERT_PAGE_IS_TYPE(page, PGT_seg_desc_page);
 ASSERT_PAGE_IS_DOMAIN(page, v->domain);



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

[Xen-devel] [linux-3.14 test] 63309: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvops 5 kernel-build  fail REGR. vs. 62648

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-credit2   3 host-install(3)  broken in 63286 pass in 63309
 test-amd64-i386-qemut-rhel6hvm-amd 3 host-install(3) broken in 63286 pass in 
63309
 test-amd64-i386-rumpuserxen-i386  3 host-install(3)   broken pass in 63225
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3) broken pass in 63286
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken 
pass in 63286
 test-amd64-i386-xl-raw3 host-install(3)   broken pass in 63286
 test-amd64-amd64-libvirt-vhd  3 host-install(3)   broken pass in 63286
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail in 63225 pass in 63309
 test-amd64-amd64-rumpuserxen-amd64 10 guest-start  fail in 63286 pass in 63309
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail in 63286 pass 
in 63309

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16 
guest-localmigrate/x10 fail in 63286 blocked in 62648
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 62648
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail like 62648
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 62648
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 62648

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail in 63225 never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-check fail in 63225 never pass
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass

version targeted for testing:
 linux67e128d68505fa37da2b9ae6b532f11db1624a2f
baseline version:
 linux1230ae0e99e05ced8a945a1a2c5762ce5c6c97c9

Last test of basis62648  2015-10-03 22:43:24 Z   22 days
Testing same since63225  2015-10-22 22:20:24 Z3 days3 attempts


People who touched revisions under test:
  "Eric W. Biederman" 
  Adam Radford 
  Adrian Hunter 
  Al Viro 
  Alexey Klimov 
  Andreas Schwab 
  Andrew Morton 
  Andy Lutomirski 
  Andy Shevchenko 
  Antoine Tenart 
  Antoine Ténart 
  Ard Biesheuvel 
  Arnaldo Carvalho de Melo 
  Ben Dooks 
  Ben Hutchings 
  Brian Norris 
  Christoph Biedl 
  Christoph Hellwig 
  Christoph Lameter 
  cov...@ccs.covici.com 
  Daniel Vetter 
  Daniel Vetter 
  Dave Airlie 
  David 

Re: [Xen-devel] Ping: [PATCH v3] x86/HVM: correct page dirty marking in hvm_map_guest_frame_rw()

[Ian Jackson]

Wei Liu writes ("Re: [Xen-devel] Ping: [PATCH v3] x86/HVM: correct page dirty 
marking in hvm_map_guest_frame_rw()"):
> I was assuming some random third party tools make use of
> xc_shadow_control just to get the dirty bitmap of the guest.
> 
> I don't have concrete examples at hand though.  Maybe I'm too paranoid.

I would say "maybe we should change the name or prototype of the
function, to make those people get errors".

But Ian Campbell is reorganising libxc so (a) this is happening anyway
(b) an attempt to do that would probably be lost.

Ian.

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

Re: [Xen-devel] Ping: [PATCH v3] x86/HVM: correct page dirty marking in hvm_map_guest_frame_rw()

[Wei Liu]

On Mon, Oct 26, 2015 at 03:52:55PM +, Ian Jackson wrote:
> Wei Liu writes ("Re: [Xen-devel] Ping: [PATCH v3] x86/HVM: correct page dirty 
> marking in hvm_map_guest_frame_rw()"):
> > I was assuming some random third party tools make use of
> > xc_shadow_control just to get the dirty bitmap of the guest.
> > 
> > I don't have concrete examples at hand though.  Maybe I'm too paranoid.
> 
> I would say "maybe we should change the name or prototype of the
> function, to make those people get errors".
> 
> But Ian Campbell is reorganising libxc so (a) this is happening anyway
> (b) an attempt to do that would probably be lost.
> 

Right.

So this patch:

Reviewed-by: Wei Liu 

> Ian.

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

[Xen-devel] [RFC PATCH v2 05/16] libxl: Load guest BIOS from file

[Anthony PERARD]

The path to the BIOS blob can be override by the xl's bios_override option,
or provided by u.hvm.bios_filename in the domain_build_info struct by other
libxl user.

Signed-off-by: Anthony PERARD 
---
 tools/libxl/libxl_dom.c | 66 +
 tools/libxl/libxl_types.idl |  1 +
 tools/libxl/xl_cmdimpl.c| 11 +---
 3 files changed, 75 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index b40d744..27a0021 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -858,6 +858,42 @@ err:
 return ret;
 }
 
+static const char *seabios_path(libxl__gc *gc)
+{
+return SEABIOS_PATH;
+}
+
+static const char *ovmf_path(libxl__gc *gc)
+{
+return OVMF_PATH;
+}
+
+static int libxl__load_hvm_firmware_module(libxl__gc *gc,
+   const char *filename,
+   const char *what,
+   struct xc_hvm_firmware_module *m)
+{
+int datalen = 0;
+void *data = NULL;
+int e;
+
+LOG(DEBUG, "Loading %s: %s", what, filename);
+e = libxl_read_file_contents(CTX, filename, , );
+if (e) {
+LOGEV(ERROR, e, "failed to read %s file %s",
+  what,
+  filename);
+return ERROR_FAIL;
+}
+libxl__ptr_add(gc, data);
+if (datalen) {
+/* Only accept non-empty files */
+m->data = data;
+m->length = (uint32_t)datalen;
+}
+return 0;
+}
+
 static int libxl__domain_firmware(libxl__gc *gc,
   libxl_domain_build_info *info,
   struct xc_dom_image *dom)
@@ -910,6 +946,36 @@ static int libxl__domain_firmware(libxl__gc *gc,
 goto out;
 }
 
+if (info->device_model_version != LIBXL_DEVICE_MODEL_VERSION_NONE) {
+const char *bios_filename;
+// Look for BIOS and load it
+if (info->u.hvm.bios_filename) {
+bios_filename = info->u.hvm.bios_filename;
+} else {
+switch (info->u.hvm.bios)
+{
+case LIBXL_BIOS_TYPE_ROMBIOS:
+bios_filename = libxl__abs_path(gc, "rombios.bin",
+libxl__xenfirmwaredir_path());
+break;
+case LIBXL_BIOS_TYPE_SEABIOS:
+bios_filename = seabios_path(gc);
+break;
+case LIBXL_BIOS_TYPE_OVMF:
+bios_filename = ovmf_path(gc);
+break;
+default:
+LOG(ERROR, "invalid bios version %d", info->u.hvm.bios);
+rc = ERROR_FAIL;
+goto out;
+}
+}
+
+rc = libxl__load_hvm_firmware_module(gc, bios_filename, "BIOS",
+ >bios_module);
+if (rc) goto out;
+}
+
 if (info->u.hvm.smbios_firmware) {
 data = NULL;
 e = libxl_read_file_contents(ctx, info->u.hvm.smbios_firmware,
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 082fed8..a3fbcab 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -468,6 +468,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
 ("u", KeyedUnion(None, libxl_domain_type, "type",
 [("hvm", Struct(None, [("firmware", string),
("bios", libxl_bios_type),
+   ("bios_filename",string),
("pae",  libxl_defbool),
("apic", libxl_defbool),
("acpi", libxl_defbool),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 840d73f..27d7c25 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1500,12 +1500,17 @@ static void parse_config_data(const char *config_source,
 
 xlu_cfg_replace_string (config, "firmware_override",
 _info->u.hvm.firmware, 0);
-if (!xlu_cfg_get_string(config, "bios", , 0) &&
-libxl_bios_type_from_string(buf, _info->u.hvm.bios)) {
+xlu_cfg_replace_string (config, "bios_override",
+_info->u.hvm.bios_filename, 0);
+if (!xlu_cfg_get_string(config, "bios", , 0)) {
+if (libxl_bios_type_from_string(buf, _info->u.hvm.bios)) {
 fprintf(stderr, "ERROR: invalid value \"%s\" for \"bios\"\n",
 buf);
 exit (1);
-}
+}
+} else if (b_info->u.hvm.bios_filename)
+fprintf(stderr, "WARNING: "
+"bios_override given without specific bios name\n");
 
 xlu_cfg_get_defbool(config, "pae", _info->u.hvm.pae, 0);
 

[Xen-devel] [RFC PATCH v2 10/16] hvmloader: Load OVMF from modules

[Anthony PERARD]

... and do not include the OVMF ROM into hvmloader anymore.

Signed-off-by: Anthony PERARD 
---
 tools/firmware/hvmloader/ovmf.c | 22 +++---
 1 file changed, 7 insertions(+), 15 deletions(-)

diff --git a/tools/firmware/hvmloader/ovmf.c b/tools/firmware/hvmloader/ovmf.c
index 2be9752..3c0ec91 100644
--- a/tools/firmware/hvmloader/ovmf.c
+++ b/tools/firmware/hvmloader/ovmf.c
@@ -34,17 +34,9 @@
 #include 
 #include 
 
-#define ROM_INCLUDE_OVMF
-#include "roms.inc"
-
-#define OVMF_SIZE   (sizeof(ovmf))
-#define OVMF_MAXOFFSET  0x000FULL
-#define OVMF_BEGIN  (0x1ULL - ((OVMF_SIZE + 
OVMF_MAXOFFSET) & ~OVMF_MAXOFFSET))
-#define OVMF_END(OVMF_BEGIN + OVMF_SIZE)
 #define LOWCHUNK_BEGIN  0x000F
 #define LOWCHUNK_SIZE   0x0001
 #define LOWCHUNK_MAXOFFSET  0x
-#define LOWCHUNK_END(OVMF_BEGIN + OVMF_SIZE)
 #define OVMF_INFO_PHYSICAL_ADDRESS 0x1000
 
 extern unsigned char dsdt_anycpu[];
@@ -96,12 +88,16 @@ static void ovmf_finish_bios_info(void)
 static void ovmf_load(const struct bios_config *config,
   void *bios_addr, uint32_t bios_length)
 {
+#define OVMF_MAXOFFSET  0x000FULL
+#define OVMF_BEGIN  (0x1ULL - ((bios_length + OVMF_MAXOFFSET) & 
~OVMF_MAXOFFSET))
+#define OVMF_END(OVMF_BEGIN + bios_length)
 xen_pfn_t mfn;
 uint64_t addr = OVMF_BEGIN;
+unsigned int dest = OVMF_BEGIN;
 
 /* Copy low-reset vector portion. */
-memcpy((void *) LOWCHUNK_BEGIN, (uint8_t *) config->image
-   + OVMF_SIZE
+memcpy((void *) LOWCHUNK_BEGIN, (uint8_t *) bios_addr
+   + bios_length
- LOWCHUNK_SIZE,
LOWCHUNK_SIZE);
 
@@ -114,7 +110,7 @@ static void ovmf_load(const struct bios_config *config,
 }
 
 /* Copy FD. */
-memcpy((void *) OVMF_BEGIN, config->image, OVMF_SIZE);
+memcpy((void *) dest, bios_addr, bios_length);
 }
 
 static void ovmf_acpi_build_tables(void)
@@ -151,10 +147,6 @@ static void ovmf_setup_e820(void)
 struct bios_config ovmf_config =  {
 .name = "OVMF",
 
-.image = ovmf,
-.image_size = sizeof(ovmf),
-
-.bios_address = OVMF_BEGIN,
 .bios_load = ovmf_load,
 
 .load_roms = 0,
-- 
Anthony PERARD


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

Re: [Xen-devel] Ping: [PATCH v3] x86/HVM: correct page dirty marking in hvm_map_guest_frame_rw()

[Jan Beulich]

>>> On 26.10.15 at 17:05,  wrote:
> On Mon, Oct 26, 2015 at 10:00:26AM -0600, Jan Beulich wrote:
>> >>> On 26.10.15 at 16:20,  wrote:
>> > On Mon, Oct 26, 2015 at 07:09:06AM -0600, Jan Beulich wrote:
>> >> >>> On 19.10.15 at 16:53,  wrote:
>> >> > --- a/tools/libxc/xc_sr_save.c
>> >> > +++ b/tools/libxc/xc_sr_save.c
>> >> > @@ -537,7 +537,8 @@ static int suspend_and_send_dirty(struct
>> >> >  if ( xc_shadow_control(
>> >> >   xch, ctx->domid, XEN_DOMCTL_SHADOW_OP_CLEAN,
>> >> >   HYPERCALL_BUFFER(dirty_bitmap), ctx->save.p2m_size,
>> >> > - NULL, 0, ) != ctx->save.p2m_size )
>> >> > + NULL, XEN_DOMCTL_SHADOW_LOGDIRTY_FINAL, ) !=
>> >> > + ctx->save.p2m_size )
>> >> >  {
>> >> >  PERROR("Failed to retrieve logdirty bitmap");
>> >> >  rc = -1;
>> >> 
>> >> Tools maintainers, could I please get an ack or otherwise on this
>> >> adjustment?
>> >> 
>> > 
>> > Er, there seems to be behaviour change that would cause external users
>> > of xc_shadow_control cease to function properly.
>> 
>> What behavioral change do you see? So far we simply didn't care
>> about those permanently mapped pages. Now we provide an
>> option to include them.
> 
> Oh, this is fine then. I thought before we had always included the
> permanent mapped pages in dirty bitmap. I was wrong. Sorry about the
> noise.

No problem at all. Now - does that represent some non-standard
for of an ack?

Jan


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

[Xen-devel] [xen-unstable-smoke test] 63320: trouble: broken/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-i386 3 host-install(3) broken REGR. vs. 
63260

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  d8ba3a9e444c6943199130eea32904bc245a6d27
baseline version:
 xen  cd84a2baadd4a5767d2568b1c01b055328cc84db

Last test of basis63260  2015-10-23 14:00:55 Z3 days
Testing same since63320  2015-10-26 14:01:22 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  George Dunlap 
  Ian Campbell 
  Jan Beulich 
  Julien Grall 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 broken  
 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

broken-step test-amd64-amd64-xl-qemuu-debianhvm-i386 host-install(3)

Not pushing.


commit d8ba3a9e444c6943199130eea32904bc245a6d27
Author: Andrew Cooper 
Date:   Mon Oct 26 14:02:30 2015 +0100

x86: remove assumptions about the layout of x86_capabilities

Future work will rearange it, invalidating these assumptions.

No functional change.

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

commit 7729eed1a51b417c029a32d1e6b94eb0751d1643
Author: Andrew Cooper 
Date:   Mon Oct 26 14:01:50 2015 +0100

x86: helpers for cpu feature manipulation

Expose them to assembly code, and replace open-coded versions.

No functional change.

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

commit 69176a4b9c27796bb4cde1e13f28f5eace425400
Author: Julien Grall 
Date:   Mon Oct 26 13:58:35 2015 +0100

x86/mm: pod: use the correct memory flags for alloc_domheap_page{,s}

The last parameter of alloc_domheap_page{s,} contain the memory flags and
not the order of the allocation.

Use 0 for the call in p2m_pod_set_cache_target as it was before
1069d63c5ef2510d08b83b2171af660e5bb18c63 "x86/mm/p2m: use defines for
page sizes". Note that PAGE_ORDER_4K is also equal to 0 so the behavior
stays the same.

For the call in p2m_pod_offline_or_broken_replace we want to allocate
the new page on the same numa node as the previous page. So retrieve the
numa node and pass it in the memory flags.

Signed-off-by: Julien Grall 
Tested-by: Dario Faggioli 
Acked-by: George Dunlap 

commit e896ad9a9164a432538789fa2993a1084fd0a387
Author: Jan Beulich 
Date:   Mon Oct 26 13:56:39 2015 +0100

arm: don't build core parking code

It's wired up on x86 only.

Signed-off-by: Jan Beulich 
Acked-by: Ian Campbell 
(qemu changes not included)

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

[Xen-devel] [qemu-mainline baseline-only test] 38213: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-xsm  21 guest-start/debian.repeatfail   like 38204
 test-amd64-amd64-xl  21 guest-start/debian.repeatfail   like 38204
 test-amd64-amd64-xl-credit2  21 guest-start/debian.repeatfail   like 38204
 test-amd64-amd64-xl-qemuu-winxpsp3  9 windows-install  fail like 38204

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

version targeted for testing:
 qemuubc79082e4cd12c1241fa03b0abceacf45f537740
baseline version:
 qemuu426c0df9e3e6e64c7ea489092c57088ca4d227d0

Last test of basis38204  2015-10-23 10:50:51 Z3 days
Testing same since38213  2015-10-26 09:49:39 Z0 days1 attempts


People who touched revisions under test:
  Alexey Kardashevskiy 
  Andreas Färber 
  Andrew Jones 
  Aurelien Jarno 
  Benjamin Herrenschmidt 
  Bharata B Rao 
  Christian Borntraeger 
  Cornelia Huck 
  Daniel P. Berrange 
  David Gibson 
  David Hildenbrand 
  Eduardo Habkost 
  Eduardo Otubo 
  Igor Mammedov 
  James Hogan 
  Knut Omang 
  Laszlo Ersek 
  Laurent Vivier 
  Leon Alrae 
  Marc-André Lureau 
  Max Filippov 
  Michael Roth 
  Michael S. Tsirkin 
  Michael Walle 
  Paolo Bonzini 
  Peter Crosthwaite 
  Peter Crosthwaite 
  Peter Maydell 
  Richard Henderson 
  Thibaut Collet 
  Thomas Huth 
  Tony Krowiak 
  zhanghailiang 
  Zhu Guihua 

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

Re: [Xen-devel] Ping: [PATCH v3] x86/HVM: correct page dirty marking in hvm_map_guest_frame_rw()

[Wei Liu]

On Mon, Oct 26, 2015 at 07:09:06AM -0600, Jan Beulich wrote:
> >>> On 19.10.15 at 16:53,  wrote:
> > --- a/tools/libxc/xc_sr_save.c
> > +++ b/tools/libxc/xc_sr_save.c
> > @@ -537,7 +537,8 @@ static int suspend_and_send_dirty(struct
> >  if ( xc_shadow_control(
> >   xch, ctx->domid, XEN_DOMCTL_SHADOW_OP_CLEAN,
> >   HYPERCALL_BUFFER(dirty_bitmap), ctx->save.p2m_size,
> > - NULL, 0, ) != ctx->save.p2m_size )
> > + NULL, XEN_DOMCTL_SHADOW_LOGDIRTY_FINAL, ) !=
> > + ctx->save.p2m_size )
> >  {
> >  PERROR("Failed to retrieve logdirty bitmap");
> >  rc = -1;
> 
> Tools maintainers, could I please get an ack or otherwise on this
> adjustment?
> 

Er, there seems to be behaviour change that would cause external users
of xc_shadow_control cease to function properly.

Does it make sense to use inverse logic that you set a flag to not
mark permanent pages dirty? I think that's a bit awkward, not sure if it
is worth it.

I also realise that libxenctrl doesn't have stable interface so I'm a
bit two-minded for this.

Ian and Ian, what do you think?

Wei.

> > --- a/xen/include/public/domctl.h
> > +++ b/xen/include/public/domctl.h
> > @@ -208,6 +208,13 @@ struct xen_domctl_getpageframeinfo3 {
> >*/
> >  #define XEN_DOMCTL_SHADOW_ENABLE_EXTERNAL  (1 << 4)
> >  
> > +/* Mode flags for XEN_DOMCTL_SHADOW_OP_{CLEAN,PEEK}. */
> > + /*
> > +  * This is the final iteration: Requesting to include pages mapped
> > +  * writably by the hypervisor in the dirty bitmap.
> > +  */
> > +#define XEN_DOMCTL_SHADOW_LOGDIRTY_FINAL   (1 << 0)
> > +
> >  struct xen_domctl_shadow_op_stats {
> >  uint32_t fault_count;
> >  uint32_t dirty_count;
> > @@ -219,8 +226,9 @@ struct xen_domctl_shadow_op {
> >  /* IN variables. */
> >  uint32_t   op;   /* XEN_DOMCTL_SHADOW_OP_* */
> >  
> > -/* OP_ENABLE */
> > -uint32_t   mode; /* XEN_DOMCTL_SHADOW_ENABLE_* */
> > +/* OP_ENABLE: XEN_DOMCTL_SHADOW_ENABLE_* */
> > +/* OP_PEAK / OP_CLEAN: XEN_DOMCTL_SHADOW_LOGDIRTY_* */
> > +uint32_t   mode;
> >  
> >  /* OP_GET_ALLOCATION / OP_SET_ALLOCATION */
> >  uint32_t   mb;   /* Shadow memory allocation in MB */
> 
> "REST" maintainers, could I please get an ack or otherwise on this
> interface change?
> 
> Thanks, Jan
> 

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

Re: [Xen-devel] Ping: [PATCH] use clear_domain_page() instead of open coding it

[Ian Jackson]

Jan Beulich writes ("Ping: [PATCH] use clear_domain_page() instead of open 
coding it"):
> "REST" maintainers, could I please get an ack or otherwise on this
> common code change?

I'm not qualified to review this, but I would have thought an ack from
George should be sufficient ?

(Also is your patch "no functional change" ?  If so it helps IMO to
say so.)

Thanks,
Ian.

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

Re: [Xen-devel] Ping: [PATCH v3] x86/HVM: correct page dirty marking in hvm_map_guest_frame_rw()

[Jan Beulich]

>>> On 26.10.15 at 16:20,  wrote:
> On Mon, Oct 26, 2015 at 07:09:06AM -0600, Jan Beulich wrote:
>> >>> On 19.10.15 at 16:53,  wrote:
>> > --- a/tools/libxc/xc_sr_save.c
>> > +++ b/tools/libxc/xc_sr_save.c
>> > @@ -537,7 +537,8 @@ static int suspend_and_send_dirty(struct
>> >  if ( xc_shadow_control(
>> >   xch, ctx->domid, XEN_DOMCTL_SHADOW_OP_CLEAN,
>> >   HYPERCALL_BUFFER(dirty_bitmap), ctx->save.p2m_size,
>> > - NULL, 0, ) != ctx->save.p2m_size )
>> > + NULL, XEN_DOMCTL_SHADOW_LOGDIRTY_FINAL, ) !=
>> > + ctx->save.p2m_size )
>> >  {
>> >  PERROR("Failed to retrieve logdirty bitmap");
>> >  rc = -1;
>> 
>> Tools maintainers, could I please get an ack or otherwise on this
>> adjustment?
>> 
> 
> Er, there seems to be behaviour change that would cause external users
> of xc_shadow_control cease to function properly.

What behavioral change do you see? So far we simply didn't care
about those permanently mapped pages. Now we provide an
option to include them.

Jan


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

Re: [Xen-devel] [PATCH] x86/PV: properly populate descriptor tables

[David Vrabel]

On 26/10/15 15:58, Jan Beulich wrote:
 On 26.10.15 at 16:41,  wrote:
>> Apply this partial revert fixes the problem for me.
> 
> This would need some cleaning up, but I could do that. May I put your
> S-o-b underneath it (with or without the extra cleanup)?

If you want, but I don't think I really did any work here so feel free
to just put your own name on it.

David

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

[Xen-devel] [RFC PATCH v2 06/16] libxl: Load guest ACPI table from file

[Anthony PERARD]

The path to the ACPI tables blob can be override by xl's option
acpi_table_override or by acpi_tables_filename in the domain_build_info
struct for libxl user.

Signed-off-by: Anthony PERARD 
---
 tools/libxl/libxl_dom.c | 17 +
 tools/libxl/libxl_types.idl |  1 +
 tools/libxl/xl_cmdimpl.c|  3 +++
 3 files changed, 21 insertions(+)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 27a0021..b340fa4 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -948,6 +948,7 @@ static int libxl__domain_firmware(libxl__gc *gc,
 
 if (info->device_model_version != LIBXL_DEVICE_MODEL_VERSION_NONE) {
 const char *bios_filename;
+const char *acpi_tables_filename;
 // Look for BIOS and load it
 if (info->u.hvm.bios_filename) {
 bios_filename = info->u.hvm.bios_filename;
@@ -970,10 +971,26 @@ static int libxl__domain_firmware(libxl__gc *gc,
 goto out;
 }
 }
+if (info->u.hvm.acpi_tables_filename) {
+acpi_tables_filename = info->u.hvm.acpi_tables_filename;
+} else {
+// this would depend on which machine we emulate
+// this is going to be eathier qemu-trad or qemu-xen
+// (later, there will be qemu-xen-q35)
+acpi_tables_filename = libxl__abs_path(gc,
+   "dsdt_anycpu_qemu_xen.aml",
+   
libxl__xenfirmwaredir_path());
+}
 
 rc = libxl__load_hvm_firmware_module(gc, bios_filename, "BIOS",
  >bios_module);
 if (rc) goto out;
+
+rc = libxl__load_hvm_firmware_module(gc,
+ acpi_tables_filename,
+ "ACPI tables",
+ >acpi_table_module);
+if (rc) goto out;
 }
 
 if (info->u.hvm.smbios_firmware) {
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index a3fbcab..d7eaa8d 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -469,6 +469,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
 [("hvm", Struct(None, [("firmware", string),
("bios", libxl_bios_type),
("bios_filename",string),
+   ("acpi_tables_filename", string),
("pae",  libxl_defbool),
("apic", libxl_defbool),
("acpi", libxl_defbool),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 27d7c25..1fb1300 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1512,6 +1512,9 @@ static void parse_config_data(const char *config_source,
 fprintf(stderr, "WARNING: "
 "bios_override given without specific bios name\n");
 
+xlu_cfg_replace_string(config, "acpi_table_override",
+   _info->u.hvm.acpi_tables_filename, 0);
+
 xlu_cfg_get_defbool(config, "pae", _info->u.hvm.pae, 0);
 xlu_cfg_get_defbool(config, "apic", _info->u.hvm.apic, 0);
 xlu_cfg_get_defbool(config, "acpi", _info->u.hvm.acpi, 0);
-- 
Anthony PERARD


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

[Xen-devel] [RFC PATCH v2 12/16] hvmloader: Load ACPI tables from hvm_start_info module

[Anthony PERARD]

... and use it with both SeaBIOS and OVMF.

This may change the behavior of guest using OVMF as the ACPI tables
currently loaded are the one for qemu-xen-traditionnal. After this change,
the ACPI tables will the one intended for the device model used.

Signed-off-by: Anthony PERARD 
---
 tools/firmware/hvmloader/config.h| 2 +-
 tools/firmware/hvmloader/hvmloader.c | 6 +-
 tools/firmware/hvmloader/ovmf.c  | 9 +++--
 tools/firmware/hvmloader/seabios.c   | 9 +++--
 4 files changed, 12 insertions(+), 14 deletions(-)

diff --git a/tools/firmware/hvmloader/config.h 
b/tools/firmware/hvmloader/config.h
index 0ddd897..1df5fd9 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -22,7 +22,7 @@ struct bios_config {
 
 void (*e820_setup)(void);
 
-void (*acpi_build_tables)(void);
+void (*acpi_build_tables)(void* addr, uint32_t size);
 void (*create_mp_tables)(void);
 void (*create_smbios_tables)(void);
 void (*create_pir_tables)(void);
diff --git a/tools/firmware/hvmloader/hvmloader.c 
b/tools/firmware/hvmloader/hvmloader.c
index b131b1d..9e5b9d4 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -407,8 +407,12 @@ int main(void)
 
 if ( bios->acpi_build_tables )
 {
+const struct hvm_modlist_entry *acpi_module;
+acpi_module = get_module_entry(hvmlite_start_info, "acpi_tables");
+BUG_ON(!acpi_module);
 printf("Loading ACPI ...\n");
-bios->acpi_build_tables();
+bios->acpi_build_tables((void*)acpi_module->paddr,
+acpi_module->size);
 }
 
 acpi_enable_sci();
diff --git a/tools/firmware/hvmloader/ovmf.c b/tools/firmware/hvmloader/ovmf.c
index 3c0ec91..1a9d457 100644
--- a/tools/firmware/hvmloader/ovmf.c
+++ b/tools/firmware/hvmloader/ovmf.c
@@ -39,9 +39,6 @@
 #define LOWCHUNK_MAXOFFSET  0x
 #define OVMF_INFO_PHYSICAL_ADDRESS 0x1000
 
-extern unsigned char dsdt_anycpu[];
-extern int dsdt_anycpu_len;
-
 #define OVMF_INFO_MAX_TABLES 4
 struct ovmf_info {
 char signature[14]; /* XenHVMOVMF\0\0\0\0 */
@@ -113,11 +110,11 @@ static void ovmf_load(const struct bios_config *config,
 memcpy((void *) dest, bios_addr, bios_length);
 }
 
-static void ovmf_acpi_build_tables(void)
+static void ovmf_acpi_build_tables(void *addr, uint32_t length)
 {
 struct acpi_config config = {
-.dsdt_anycpu = dsdt_anycpu,
-.dsdt_anycpu_len = dsdt_anycpu_len,
+.dsdt_anycpu = addr,
+.dsdt_anycpu_len = length,
 .dsdt_15cpu = NULL, 
 .dsdt_15cpu_len = 0
 };
diff --git a/tools/firmware/hvmloader/seabios.c 
b/tools/firmware/hvmloader/seabios.c
index 766bd6b..4cd035e 100644
--- a/tools/firmware/hvmloader/seabios.c
+++ b/tools/firmware/hvmloader/seabios.c
@@ -27,9 +27,6 @@
 #include "smbios_types.h"
 #include "acpi/acpi2_0.h"
 
-extern unsigned char dsdt_anycpu_qemu_xen[];
-extern int dsdt_anycpu_qemu_xen_len;
-
 struct seabios_info {
 char signature[14]; /* XenHVMSeaBIOS\0 */
 uint8_t length; /* Length of this struct */
@@ -87,12 +84,12 @@ static void add_table(uint32_t t)
 info->tables_nr++;
 }
 
-static void seabios_acpi_build_tables(void)
+static void seabios_acpi_build_tables(void *addr, uint32_t length)
 {
 uint32_t rsdp = (uint32_t)scratch_alloc(sizeof(struct acpi_20_rsdp), 0);
 struct acpi_config config = {
-.dsdt_anycpu = dsdt_anycpu_qemu_xen,
-.dsdt_anycpu_len = dsdt_anycpu_qemu_xen_len,
+.dsdt_anycpu = addr,
+.dsdt_anycpu_len = length,
 .dsdt_15cpu = NULL,
 .dsdt_15cpu_len = 0,
 };
-- 
Anthony PERARD


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

[Xen-devel] [RFC PATCH v2 03/16] configure: #define SEABIOS_PATH and OVMF_PATH

[Anthony PERARD]

Those paths are to be used by libxl, in order to load the firmware in
memory. If a system path is not define, then this default to the Xen
firmware directory.

Signed-off-by: Anthony PERARD 

---
Please, run ./autogen.sh on this patch.
---
 tools/configure.ac | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/tools/configure.ac b/tools/configure.ac
index 6c70040..6929006 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -212,6 +212,9 @@ AC_ARG_WITH([system-seabios],
 esac
 ],[])
 AC_SUBST(seabios_path)
+AC_DEFINE_UNQUOTED([SEABIOS_PATH],
+   ["${seabios_path:-$XENFIRMWAREDIR/seabios.bin}"],
+   [SeaBIOS path])
 
 AC_ARG_WITH([system-ovmf],
 AS_HELP_STRING([--with-system-ovmf@<:@=PATH@:>@],
@@ -223,6 +226,9 @@ AC_ARG_WITH([system-ovmf],
 esac
 ],[])
 AC_SUBST(ovmf_path)
+AC_DEFINE_UNQUOTED([OVMF_PATH],
+   ["${ovmf_path:-$XENFIRMWAREDIR/ovmf.bin}"],
+   [OVMF path])
 
 AC_ARG_WITH([extra-qemuu-configure-args],
 AS_HELP_STRING([--with-extra-qemuu-configure-args@<:@="--ARG1 ..."@:>@],
-- 
Anthony PERARD


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

[Xen-devel] [RFC PATCH v2 13/16] hvmloader/makefile: Compile out SeaBIOS and OVMF ROM blob

[Anthony PERARD]

Those are not used anymore by hvmloader.

Signed-off-by: Anthony PERARD 
---
 tools/firmware/hvmloader/Makefile | 26 --
 1 file changed, 26 deletions(-)

diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index 0560a7b..da6491b 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -43,9 +43,7 @@ endif
 
 CIRRUSVGA_DEBUG ?= n
 
-OVMF_DIR := ../ovmf-dir
 ROMBIOS_DIR := ../rombios
-SEABIOS_DIR := ../seabios-dir
 
 ifeq ($(CONFIG_ROMBIOS),y)
 STDVGA_ROM:= ../vgabios/VGABIOS-lgpl-latest.bin
@@ -62,12 +60,6 @@ ROMS :=
 ifeq ($(CONFIG_OVMF),y)
 OBJS += ovmf.o
 CFLAGS += -DENABLE_OVMF
-ifeq ($(OVMF_PATH),)
-   OVMF_ROM := $(OVMF_DIR)/ovmf.bin
-else
-   OVMF_ROM := $(OVMF_PATH)
-endif
-ROMS += $(OVMF_ROM)
 endif
 
 ifeq ($(CONFIG_ROMBIOS),y)
@@ -80,12 +72,6 @@ endif
 ifeq ($(CONFIG_SEABIOS),y)
 OBJS += seabios.o
 CFLAGS += -DENABLE_SEABIOS
-ifeq ($(SEABIOS_PATH),)
-   SEABIOS_ROM := $(SEABIOS_DIR)/out/bios.bin
-else
-   SEABIOS_ROM := $(SEABIOS_PATH)
-endif
-ROMS += $(SEABIOS_ROM)
 endif
 
 .PHONY: all
@@ -109,18 +95,6 @@ ifneq ($(ROMBIOS_ROM),)
echo "#endif" >> $@.new
 endif
 
-ifneq ($(SEABIOS_ROM),)
-   echo "#ifdef ROM_INCLUDE_SEABIOS" >> $@.new
-   sh ./mkhex seabios $(SEABIOS_ROM) >> $@.new
-   echo "#endif" >> $@.new
-endif
-
-ifneq ($(OVMF_ROM),)
-   echo "#ifdef ROM_INCLUDE_OVMF" >> $@.new
-   sh ./mkhex ovmf $(OVMF_ROM) >> $@.new
-   echo "#endif" >> $@.new 
-endif 
-
 ifneq ($(STDVGA_ROM),)
echo "#ifdef ROM_INCLUDE_VGABIOS" >> $@.new
sh ./mkhex vgabios_stdvga $(STDVGA_ROM) >> $@.new
-- 
Anthony PERARD


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

[Xen-devel] [RFC PATCH v2 14/16] hvmloader: Always build-in SeaBIOS and OVMF loader

[Anthony PERARD]

Signed-off-by: Anthony PERARD 
---
 tools/firmware/hvmloader/Makefile| 6 --
 tools/firmware/hvmloader/hvmloader.c | 4 
 2 files changed, 10 deletions(-)

diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index da6491b..9921781 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -57,10 +57,7 @@ endif
 
 ROMS := 
 
-ifeq ($(CONFIG_OVMF),y)
 OBJS += ovmf.o
-CFLAGS += -DENABLE_OVMF
-endif
 
 ifeq ($(CONFIG_ROMBIOS),y)
 OBJS += optionroms.o 32bitbios_support.o rombios.o
@@ -69,10 +66,7 @@ ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
 ROMS += $(ROMBIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) $(ETHERBOOT_ROMS)
 endif
 
-ifeq ($(CONFIG_SEABIOS),y)
 OBJS += seabios.o
-CFLAGS += -DENABLE_SEABIOS
-endif
 
 .PHONY: all
 all: subdirs-all
diff --git a/tools/firmware/hvmloader/hvmloader.c 
b/tools/firmware/hvmloader/hvmloader.c
index 9e5b9d4..4a1872e 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -205,12 +205,8 @@ struct bios_info {
 #ifdef ENABLE_ROMBIOS
 { "rombios", _config, },
 #endif
-#ifdef ENABLE_SEABIOS
 { "seabios", _config, },
-#endif
-#ifdef ENABLE_OVMF
 { "ovmf", _config, },
-#endif
 { NULL, NULL }
 };
 
-- 
Anthony PERARD


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

[Xen-devel] [RFC PATCH v2 04/16] firmware/makefile: install BIOS and ACPI blob ...

[Anthony PERARD]

... into the firmware directory, along with hvmloader.

Signed-off-by: Anthony PERARD 
---
 .gitignore |  1 +
 tools/firmware/Makefile| 15 +++
 tools/firmware/hvmloader/acpi/Makefile |  2 +-
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/.gitignore b/.gitignore
index 9ead7c4..7c7bb56 100644
--- a/.gitignore
+++ b/.gitignore
@@ -117,6 +117,7 @@ tools/firmware/hvmloader/acpi/mk_dsdt
 tools/firmware/hvmloader/acpi/dsdt*.c
 tools/firmware/hvmloader/acpi/dsdt_*.asl
 tools/firmware/hvmloader/acpi/ssdt_*.h
+tools/firmware/hvmloader/acpi/dsdt_anycpu_qemu_xen.aml
 tools/firmware/hvmloader/hvmloader
 tools/firmware/hvmloader/roms.h
 tools/firmware/hvmloader/roms.inc
diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile
index 6cc86ce..9c63991 100644
--- a/tools/firmware/Makefile
+++ b/tools/firmware/Makefile
@@ -19,6 +19,10 @@ SUBDIRS-y += hvmloader
 
 LD32BIT-$(CONFIG_FreeBSD) := LD32BIT_FLAG=-melf_i386_fbsd
 
+SEABIOS_ROM := seabios-dir/out/bios.bin
+OVMF_ROM := ovmf-dir/ovmf.bin
+ACPI_TABLE_QEMU_PC_I440FX = hvmloader/acpi/dsdt_anycpu_qemu_xen.aml
+
 ovmf-dir:
GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh $(OVMF_UPSTREAM_URL) 
$(OVMF_UPSTREAM_REVISION) ovmf-dir
cp ovmf-makefile ovmf-dir/Makefile;
@@ -45,6 +49,17 @@ endif
 install: all
[ -d $(INST_DIR) ] || $(INSTALL_DIR) $(INST_DIR)
[ ! -e $(TARGET) ] || $(INSTALL_DATA) $(TARGET) $(INST_DIR)
+ifeq ($(CONFIG_SEABIOS),y)
+ifeq ($(SEABIOS_PATH),)
+   [ ! -e $(SEABIOS_ROM) ] || $(INSTALL_DATA) $(SEABIOS_ROM) 
$(INST_DIR)/seabios.bin
+endif
+endif
+ifeq ($(CONFIG_OVMF),y)
+ifeq ($(OVMF_PATH),)
+   [ ! -e $(OVMF_ROM) ] || $(INSTALL_DATA) $(OVMF_ROM) $(INST_DIR)/ovmf.bin
+endif
+endif
+   [ ! -e $(ACPI_TABLE_QEMU_PC_I440FX) ] || $(INSTALL_DATA) 
$(ACPI_TABLE_QEMU_PC_I440FX) $(INST_DIR)
 
 .PHONY: clean
 clean: subdirs-clean
diff --git a/tools/firmware/hvmloader/acpi/Makefile 
b/tools/firmware/hvmloader/acpi/Makefile
index d3e882a..3d8dd21 100644
--- a/tools/firmware/hvmloader/acpi/Makefile
+++ b/tools/firmware/hvmloader/acpi/Makefile
@@ -46,7 +46,7 @@ $(filter dsdt_%.c,$(C_SRC)): %.c: iasl %.asl
iasl -vs -p $* -tc $*.asl
sed -e 's/AmlCode/$*/g' $*.hex >$@
echo "int $*_len=sizeof($*);" >>$@
-   rm -f $*.aml $*.hex
+   rm -f $*.hex
 
 iasl:
@echo
-- 
Anthony PERARD


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

[Xen-devel] [RFC PATCH v2 02/16] libxc: Load BIOS and ACPI table into guest memory

[Anthony PERARD]

... and prepare a cmdline for hvmloader with the order of the modules.

Signed-off-by: Anthony PERARD 
---
 tools/libxc/include/xc_dom.h   |  4 ++
 tools/libxc/xc_dom_hvmloader.c | 44 +
 tools/libxc/xc_dom_x86.c   | 90 ++
 3 files changed, 130 insertions(+), 8 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 4939f76..c7003a4 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -203,6 +203,10 @@ struct xc_dom_image {
 
 /* Extra SMBIOS structures passed to HVMLOADER */
 struct xc_hvm_firmware_module smbios_module;
+
+/* BIOS as module */
+struct xc_hvm_firmware_module bios_module;
+struct xc_hvm_firmware_module acpi_table_module;
 };
 
 /* --- pluggable kernel loader - */
diff --git a/tools/libxc/xc_dom_hvmloader.c b/tools/libxc/xc_dom_hvmloader.c
index 79a3b99..3987ed8 100644
--- a/tools/libxc/xc_dom_hvmloader.c
+++ b/tools/libxc/xc_dom_hvmloader.c
@@ -129,6 +129,18 @@ static elf_errorstatus xc_dom_parse_hvm_kernel(struct 
xc_dom_image *dom)
 return rc;
 }
 
+static uint64_t module_init(struct xc_hvm_firmware_module *module,
+uint64_t mstart)
+{
+#define MODULE_ALIGN 1UL << 7
+#define MKALIGN(x, a) (((uint64_t)(x) + (a) - 1) & ~(uint64_t)((a) - 1))
+if ( module->length != 0 ) {
+module->guest_addr_out = mstart;
+return MKALIGN(module->length, MODULE_ALIGN);
+} else
+return 0;
+}
+
 static int modules_init(struct xc_dom_image *dom,
 uint64_t vend, struct elf_binary *elf,
 uint64_t *mstart_out, uint64_t *mend_out)
@@ -136,33 +148,47 @@ static int modules_init(struct xc_dom_image *dom,
 #define MODULE_ALIGN 1UL << 7
 #define MB_ALIGN 1UL << 20
 #define MKALIGN(x, a) (((uint64_t)(x) + (a) - 1) & ~(uint64_t)((a) - 1))
-uint64_t total_len = 0, offset1 = 0;
+uint64_t total_len = 0, offset1 = 0, offset0;
+uint64_t mstart;
 
-if ( dom->acpi_module.length == 0 && dom->smbios_module.length == 0 )
-return 0;
+/* Want to place the modules 1Mb+change behind the loader image. */
+mstart = MKALIGN(elf->pend, MB_ALIGN) + (MB_ALIGN);
 
 /* Find the total length for the firmware modules with a reasonable large
  * alignment size to align each the modules.
  */
-total_len = MKALIGN(dom->acpi_module.length, MODULE_ALIGN);
+total_len += module_init(>bios_module, mstart + total_len);
+total_len += module_init(>acpi_table_module, mstart + total_len);
+offset0 = total_len;
+total_len += MKALIGN(dom->acpi_module.length, MODULE_ALIGN);
 offset1 = total_len;
 total_len += MKALIGN(dom->smbios_module.length, MODULE_ALIGN);
 
-/* Want to place the modules 1Mb+change behind the loader image. */
-*mstart_out = MKALIGN(elf->pend, MB_ALIGN) + (MB_ALIGN);
+if ( total_len == 0 )
+return 0;
+
+*mstart_out = mstart;
 *mend_out = *mstart_out + total_len;
 
 if ( *mend_out > vend )
 return -1;
 
 if ( dom->acpi_module.length != 0 )
-dom->acpi_module.guest_addr_out = *mstart_out;
+dom->acpi_module.guest_addr_out = *mstart_out + offset0;
 if ( dom->smbios_module.length != 0 )
 dom->smbios_module.guest_addr_out = *mstart_out + offset1;
 
 return 0;
 }
 
+static void loadmodule(struct xc_hvm_firmware_module *module,
+   uint8_t *dest, uint64_t mstart)
+{
+if ( module->length != 0 )
+memcpy(dest + (module->guest_addr_out - mstart),
+   module->data, module->length);
+}
+
 static int loadmodules(struct xc_dom_image *dom,
uint64_t mstart, uint64_t mend,
uint32_t domid)
@@ -201,9 +227,11 @@ static int loadmodules(struct xc_dom_image *dom,
 memset(dest, 0, pages << PAGE_SHIFT);
 
 /* Load modules into range */
+loadmodule(>bios_module, dest, mstart);
+loadmodule(>acpi_table_module, dest, mstart);
 if ( dom->acpi_module.length != 0 )
 {
-memcpy(dest,
+memcpy(dest + (dom->acpi_module.guest_addr_out - mstart),
dom->acpi_module.data,
dom->acpi_module.length);
 }
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index c3bb7a3..2444cc2 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -511,6 +511,27 @@ static void build_hvm_info(void *hvm_info_page, struct 
xc_dom_image *dom)
 hvm_info->checksum = -sum;
 }
 
+static void add_module_to_list(struct xc_hvm_firmware_module *module,
+   const char *name, char *cmdline, size_t n,
+   struct hvm_modlist_entry *modlist,
+   size_t modlist_size, int *module_nr)
+{
+if ( module->length == 0 )
+return;
+
+/* assert(*module_nr < modlist_size); */

[Xen-devel] [RFC PATCH v2 00/16] Load BIOS via toolstack instead of been embedded in hvmloader.

[Anthony PERARD]

Hi all,

I've start to look at loading the BIOS and the ACPI tables via the
toolstack instead of having them embedded in the hvmloader binary. After
this patch series, hvmloader compilation would be indenpendant from SeaBIOS
and OVMF compilation.

Compare to the V1, this is now done via the struct hvm_start_info from
Roger's patch series "Introduce HVM without dm and new boot ABI".

Here is a general view of the few step to load the BIOS:
- libxl load the BIOS blob into it's memory and add it to struct
  xc_hvm_build_args.bios_module
- libxc load the blob into the guest memory and fill the struct
  hvm_start_info, with a cmdline which would contain the order in which the
  modules (bios, acpi_table) are loaded into the modlist.
- hvmloader read the addresses from the hvm_start_info, find out which
  module are which by reading the cmdline and copy the blob to the right
  place.

Right now, this patch series would only work for SeaBIOS and OVMF. I have
not look into what to do about qemu-xen-traditionnal and rombios.

A git tree can be found here:
git://xenbits.xen.org/people/aperard/xen-unstable.git
tag: hvmloader-with-separated-bios-v2

Regards,

Anthony PERARD (16):
  hvmloader: Fix scratch_alloc to avoid overlaps
  libxc: Load BIOS and ACPI table into guest memory
  configure: #define SEABIOS_PATH and OVMF_PATH
  firmware/makefile: install BIOS and ACPI blob ...
  libxl: Load guest BIOS from file
  libxl: Load guest ACPI table from file
  hvmloader: Grab the hvmlite info page and parse the cmdline
  hvmloader: Locate the BIOS blob
  hvmloader: Load SeaBIOS from hvm_start_info modules ...
  hvmloader: Load OVMF from modules
  hvmloader: No BIOS ROM image allowed to be compiled in
  hvmloader: Load ACPI tables from hvm_start_info module
  hvmloader/makefile: Compile out SeaBIOS and OVMF ROM blob
  hvmloader: Always build-in SeaBIOS and OVMF loader
  hvmloader: Compile out the qemu-xen ACPI tables
  hvmloader: do not depend on SEABIOS_PATH or OVMF_PATH ...

 .gitignore |   1 +
 tools/configure.ac |  12 +++-
 tools/firmware/Makefile|  15 ++--
 tools/firmware/hvmloader/Makefile  |  32 -
 tools/firmware/hvmloader/acpi/Makefile |   8 ++-
 tools/firmware/hvmloader/config.h  |  11 +--
 tools/firmware/hvmloader/hvmloader.c   | 127 -
 tools/firmware/hvmloader/ovmf.c|  34 -
 tools/firmware/hvmloader/seabios.c |  33 -
 tools/firmware/hvmloader/util.c|   2 +-
 tools/libxc/include/xc_dom.h   |   4 ++
 tools/libxc/xc_dom_hvmloader.c |  44 +---
 tools/libxc/xc_dom_x86.c   |  90 +++
 tools/libxl/libxl_dom.c|  83 +
 tools/libxl/libxl_types.idl|   2 +
 tools/libxl/xl_cmdimpl.c   |  14 +++-
 16 files changed, 394 insertions(+), 118 deletions(-)

-- 
Anthony PERARD


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

[Xen-devel] [RFC PATCH v2 09/16] hvmloader: Load SeaBIOS from hvm_start_info modules ...

[Anthony PERARD]

... and do not include the SeaBIOS ROM into hvmloader anymore.

Signed-off-by: Anthony PERARD 
---
 tools/firmware/hvmloader/seabios.c | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/tools/firmware/hvmloader/seabios.c 
b/tools/firmware/hvmloader/seabios.c
index c6b3d9f..766bd6b 100644
--- a/tools/firmware/hvmloader/seabios.c
+++ b/tools/firmware/hvmloader/seabios.c
@@ -27,9 +27,6 @@
 #include "smbios_types.h"
 #include "acpi/acpi2_0.h"
 
-#define ROM_INCLUDE_SEABIOS
-#include "roms.inc"
-
 extern unsigned char dsdt_anycpu_qemu_xen[];
 extern int dsdt_anycpu_qemu_xen_len;
 
@@ -121,6 +118,7 @@ static void seabios_create_pir_tables(void)
 add_table(create_pir_tables());
 }
 
+unsigned int seabios_bios_address = 0;
 static void seabios_setup_e820(void)
 {
 struct seabios_info *info = (void *)BIOS_INFO_PHYSICAL_ADDRESS;
@@ -128,21 +126,27 @@ static void seabios_setup_e820(void)
 info->e820 = (uint32_t)e820;
 
 /* SeaBIOS reserves memory in e820 as necessary so no low reservation. */
-info->e820_nr = build_e820_table(e820, 0, 0x10-sizeof(seabios));
+BUG_ON(seabios_bios_address == 0);
+info->e820_nr = build_e820_table(e820, 0, seabios_bios_address);
 dump_e820_table(e820, info->e820_nr);
 }
 
-struct bios_config seabios_config = {
-.name = "SeaBIOS",
+static void seabios_load(const struct bios_config *bios,
+ void *bios_addr, uint32_t bios_length)
+{
+unsigned int bios_dest = 0x10 - bios_length;
+seabios_bios_address = 0x10 - bios_length;
 
-.image = seabios,
-.image_size = sizeof(seabios),
+BUG_ON(bios_dest + bios_length > HVMLOADER_PHYSICAL_ADDRESS);
+memcpy((void *)bios_dest, bios_addr, bios_length);
+}
 
-.bios_address = 0x10 - sizeof(seabios),
+struct bios_config seabios_config = {
+.name = "SeaBIOS",
 
 .load_roms = NULL,
 
-.bios_load = NULL,
+.bios_load = seabios_load,
 
 .bios_info_setup = seabios_setup_bios_info,
 .bios_info_finish = seabios_finish_bios_info,
-- 
Anthony PERARD


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

[Xen-devel] [RFC PATCH v2 08/16] hvmloader: Locate the BIOS blob

[Anthony PERARD]

The BIOS can be found in one of the entry of the modlist of the
hvm_start_info struct. The order of the modules are define by the command
line option "modules".

The found BIOS blob is not loaded by this patch, but only passed as
argument to bios_load() function. It is going to be used by the next few
patches.

Signed-off-by: Anthony PERARD 
---
 tools/firmware/hvmloader/config.h|  2 +-
 tools/firmware/hvmloader/hvmloader.c | 34 +-
 tools/firmware/hvmloader/ovmf.c  |  3 ++-
 3 files changed, 36 insertions(+), 3 deletions(-)

diff --git a/tools/firmware/hvmloader/config.h 
b/tools/firmware/hvmloader/config.h
index b838cf9..c4539cc 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -22,7 +22,7 @@ struct bios_config {
 /* ROMS */
 void (*load_roms)(void);
 
-void (*bios_load)(const struct bios_config *config);
+void (*bios_load)(const struct bios_config *config, void* addr, uint32_t 
size);
 
 void (*bios_info_setup)(void);
 void (*bios_info_finish)(void);
diff --git a/tools/firmware/hvmloader/hvmloader.c 
b/tools/firmware/hvmloader/hvmloader.c
index 9df12ac..02d7f96 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -309,11 +309,39 @@ void cmdline_parser(const char *the_cmdline)
 }
 }
 
+const struct hvm_modlist_entry *get_module_entry(
+const struct hvm_start_info *info,
+const char *name)
+{
+const char *p = module_list_order;
+const char *q;
+unsigned name_length = strlen(name);
+unsigned current_module_nr = 0;
+const struct hvm_modlist_entry *modlist =
+(struct hvm_modlist_entry *)info->modlist_paddr;
+
+if ( !module_list_order )
+return NULL;
+
+for ( ; *p && current_module_nr < info->nr_modules; p++ )
+{
+for ( q = p; *q && *q != ','; q++ )
+;
+if ( !strncmp(name, p, max_t(unsigned, name_length, q - p)) )
+return [current_module_nr];
+p = q;
+current_module_nr++;
+}
+printf("module '%s' not found\n", name);
+return NULL;
+}
+
 int main(void)
 {
 const struct bios_config *bios;
 int acpi_enabled;
 const struct hvm_start_info *hvmlite_start_info;
+const struct hvm_modlist_entry *bios_module;
 
 /* Load hvmlite start info pointer from ebx. */
 asm volatile ( "mov %%ebx,%0" : "=r" (hvmlite_start_info) );
@@ -353,9 +381,13 @@ int main(void)
 bios->create_smbios_tables();
 }
 
+// XXX check that the values exist and are correct
+bios_module = get_module_entry(hvmlite_start_info, "bios");
+BUG_ON(!bios_module);
+
 printf("Loading %s ...\n", bios->name);
 if ( bios->bios_load )
-bios->bios_load(bios);
+bios->bios_load(bios, (void*)(bios_module->paddr), bios_module->size);
 else
 {
 BUG_ON(bios->bios_address + bios->image_size >
diff --git a/tools/firmware/hvmloader/ovmf.c b/tools/firmware/hvmloader/ovmf.c
index bb3da93..2be9752 100644
--- a/tools/firmware/hvmloader/ovmf.c
+++ b/tools/firmware/hvmloader/ovmf.c
@@ -93,7 +93,8 @@ static void ovmf_finish_bios_info(void)
 info->checksum = -checksum;
 }
 
-static void ovmf_load(const struct bios_config *config)
+static void ovmf_load(const struct bios_config *config,
+  void *bios_addr, uint32_t bios_length)
 {
 xen_pfn_t mfn;
 uint64_t addr = OVMF_BEGIN;
-- 
Anthony PERARD


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

[Xen-devel] [RFC PATCH v2 07/16] hvmloader: Grab the hvmlite info page and parse the cmdline

[Anthony PERARD]

Signed-off-by: Anthony PERARD 
---
 tools/firmware/hvmloader/hvmloader.c | 69 +++-
 1 file changed, 68 insertions(+), 1 deletion(-)

diff --git a/tools/firmware/hvmloader/hvmloader.c 
b/tools/firmware/hvmloader/hvmloader.c
index 716d03c..9df12ac 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -62,7 +62,7 @@ asm (
 "mov  %ax,%ss\n"
 /* Initialise all 32-bit GPRs to zero. */
 "xor  %eax,%eax  \n"
-"xor  %ebx,%ebx  \n"
+/* Keep ebx, for HVMLite start info */
 "xor  %ecx,%ecx  \n"
 "xor  %edx,%edx  \n"
 "xor  %esp,%esp  \n"
@@ -249,15 +249,82 @@ static void acpi_enable_sci(void)
 BUG_ON(!(pm1a_cnt_val & ACPI_PM1C_SCI_EN));
 }
 
+static const char *module_list_order = NULL;
+void cmdline_parser(const char *the_cmdline)
+{
+char cmdline[MAX_GUEST_CMDLINE];
+char *p, *q;
+char *optval;
+
+strncpy(cmdline, the_cmdline, sizeof (cmdline));
+cmdline[MAX_GUEST_CMDLINE-1] = '\0';
+
+for ( p = cmdline; p < (cmdline + MAX_GUEST_CMDLINE) && *p; p++ )
+{
+if ( *p == ' ' )
+continue;
+
+/* search for the end of the parameter name */
+for ( q = p; *q && *q != '=' && *q != ' '; q++ )
+;
+
+/* search for the end of the optional paremeter value */
+if ( *q == '=' )
+{
+optval = q+1;
+if (*optval == '\0' || *optval == ' ') {
+optval = NULL;
+}
+} else
+optval = NULL;
+*q = '\0';
+
+if ( optval )
+{
+for ( q = optval; *q && *q != ' '; q++ )
+;
+*q = '\0';
+}
+
+/* compare known parameters */
+if ( !strcmp(p, "modules") )
+{
+printf("  cmdline: found '%s', with val '%s'\n", p, optval);
+if ( optval )
+{
+unsigned size = strlen(optval) + 1;
+char *tmp = scratch_alloc(size, 0);
+strncpy(tmp, optval, size);
+module_list_order = tmp;
+}
+} else {
+printf("  Unknown cmdline option '%s'", p);
+if ( optval )
+printf(" with val '%s'\n", optval);
+else
+printf("\n");
+}
+
+p = q;
+}
+}
+
 int main(void)
 {
 const struct bios_config *bios;
 int acpi_enabled;
+const struct hvm_start_info *hvmlite_start_info;
+
+/* Load hvmlite start info pointer from ebx. */
+asm volatile ( "mov %%ebx,%0" : "=r" (hvmlite_start_info) );
 
 /* Initialise hypercall stubs with RET, rendering them no-ops. */
 memset((void *)HYPERCALL_PHYSICAL_ADDRESS, 0xc3 /* RET */, PAGE_SIZE);
 
 printf("HVM Loader\n");
+BUG_ON(hvmlite_start_info->magic != HVM_START_MAGIC_VALUE);
+printf("cmdline: %s\n", (char*)hvmlite_start_info->cmdline_paddr);
+cmdline_parser((char*)hvmlite_start_info->cmdline_paddr);
 
 init_hypercalls();
 
-- 
Anthony PERARD


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

[Xen-devel] [RFC PATCH v2 15/16] hvmloader: Compile out the qemu-xen ACPI tables

[Anthony PERARD]

It should now be loaded by libxl.

Signed-off-by: Anthony PERARD 
---
 tools/firmware/hvmloader/acpi/Makefile | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/Makefile 
b/tools/firmware/hvmloader/acpi/Makefile
index 3d8dd21..e444c8c 100644
--- a/tools/firmware/hvmloader/acpi/Makefile
+++ b/tools/firmware/hvmloader/acpi/Makefile
@@ -17,13 +17,13 @@
 XEN_ROOT = $(CURDIR)/../../../..
 include $(XEN_ROOT)/tools/firmware/Rules.mk
 
-C_SRC = build.c dsdt_anycpu.c dsdt_15cpu.c static_tables.c 
dsdt_anycpu_qemu_xen.c
+C_SRC = build.c dsdt_anycpu.c dsdt_15cpu.c static_tables.c
 OBJS  = $(patsubst %.c,%.o,$(C_SRC))
 
 CFLAGS += $(CFLAGS_xeninclude)
 
 vpath iasl $(PATH)
-all: acpi.a
+all: acpi.a dsdt_anycpu_qemu_xen.aml
 
 ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
iasl -vs -p $* -tc $<
@@ -47,6 +47,8 @@ $(filter dsdt_%.c,$(C_SRC)): %.c: iasl %.asl
sed -e 's/AmlCode/$*/g' $*.hex >$@
echo "int $*_len=sizeof($*);" >>$@
rm -f $*.hex
+dsdt_anycpu_qemu_xen.aml: %.aml: iasl %.asl
+   iasl -vs -p $* $*.asl
 
 iasl:
@echo
-- 
Anthony PERARD


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

Re: [Xen-devel] [PATCH MINI-OS v2] xenbus: notify the other end when necessary

[Ian Jackson]

Wei Liu writes ("[PATCH MINI-OS v2] xenbus: notify the other end when 
necessary"):
> The xenbus thread didn't send notification to other end when it expected
> more data or consumed responses, which led to stalling the ring from
> time to time.

Thanks for investigating this.  I haven't attempted to prove correct
(or incorrect) the ring handling after this patch.

But:

> This is the culprit that guest was less responsive when using stubdom
> because the device model was stalled.

ISTM with my stable tree maintainer hat on that this is a good
backport candidate.

Ian.

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

Re: [Xen-devel] Ping: [PATCH v3] x86/HVM: correct page dirty marking in hvm_map_guest_frame_rw()

[Wei Liu]

On Mon, Oct 26, 2015 at 03:42:07PM +, Ian Jackson wrote:
> Wei Liu writes ("Re: [Xen-devel] Ping: [PATCH v3] x86/HVM: correct page dirty 
> marking in hvm_map_guest_frame_rw()"):
> > On Mon, Oct 26, 2015 at 07:09:06AM -0600, Jan Beulich wrote:
> > > Tools maintainers, could I please get an ack or otherwise on this
> > > adjustment?
> 
> I confess I'm out of my depth here.  But thanks to Andrew Cooper's
> review, I'm happy to ack it without understanding it, except:
> 
> > Does it make sense to use inverse logic that you set a flag to not
> > mark permanent pages dirty? I think that's a bit awkward, not sure if it
> > is worth it.
> > 
> > I also realise that libxenctrl doesn't have stable interface so I'm a
> > bit two-minded for this.
> 
> What kind of out of tree callers are going to use xc_shadow_control ?
> 

I was assuming some random third party tools make use of
xc_shadow_control just to get the dirty bitmap of the guest.

I don't have concrete examples at hand though.  Maybe I'm too paranoid.

> Not qemu, AFAICT, which would be my main worry.
> 

OK. If you don't have further concern I'm happy to ack this patch.

Wei.

> Ian.

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

Re: [Xen-devel] [PATCH] x86/PV: properly populate descriptor tables

[Jan Beulich]

>>> On 26.10.15 at 16:41,  wrote:
> Apply this partial revert fixes the problem for me.

This would need some cleaning up, but I could do that. May I put your
S-o-b underneath it (with or without the extra cleanup)?

Jan

> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -502,8 +502,8 @@ void update_cr3(struct vcpu *v)
>  static void invalidate_shadow_ldt(struct vcpu *v, int flush)
>  {
>  l1_pgentry_t *pl1e;
> -unsigned int i;
> -unsigned long pfn, zero_pfn = PFN_DOWN(__pa(zero_page));
> +int i;
> +unsigned long pfn;
>  struct page_info *page;
>  
>  BUG_ON(unlikely(in_irq()));
> @@ -524,9 +523,8 @@ static void invalidate_shadow_ldt(struct vcpu *v, int 
> flush)
>  for ( i = 16; i < 32; i++ )
>  {
>  pfn = l1e_get_pfn(pl1e[i]);
> -if ( !(l1e_get_flags(pl1e[i]) & _PAGE_PRESENT) || pfn == zero_pfn )
> -continue;
> -l1e_write([i], l1e_from_pfn(zero_pfn, __PAGE_HYPERVISOR_RO));
> +if ( pfn == 0 ) continue;
> +l1e_write([i], l1e_empty());
>  page = mfn_to_page(pfn);
>  ASSERT_PAGE_IS_TYPE(page, PGT_seg_desc_page);
>  ASSERT_PAGE_IS_DOMAIN(page, v->domain);




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

Re: [Xen-devel] Ping: [PATCH] use clear_domain_page() instead of open coding it

[Jan Beulich]

>>> On 26.10.15 at 16:47,  wrote:
> Jan Beulich writes ("Ping: [PATCH] use clear_domain_page() instead of open 
> coding it"):
>> "REST" maintainers, could I please get an ack or otherwise on this
>> common code change?
> 
> I'm not qualified to review this, but I would have thought an ack from
> George should be sufficient ?

Not according to ./MAINTAINERS.

> (Also is your patch "no functional change" ?  If so it helps IMO to
> say so.)

It is, and indeed I could have said so.

Jan


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

[Xen-devel] [RFC PATCH v2 01/16] hvmloader: Fix scratch_alloc to avoid overlaps

[Anthony PERARD]

scratch_alloc() set scratch_start to the last byte of the current
allocation.  The value of scratch_start is then reused as is (if it is
already aligned) in the next allocation.  This result in a potential reuse
of the last byte of the previous allocation.

Signed-off-by: Anthony PERARD 
---
 tools/firmware/hvmloader/util.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index d779fd7..42e8af4 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -479,7 +479,7 @@ void *scratch_alloc(uint32_t size, uint32_t align)
 align = 16;
 
 s = (scratch_start + align - 1) & ~(align - 1);
-e = s + size - 1;
+e = s + size;
 
 BUG_ON(e < s);
 
-- 
Anthony PERARD


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

[Xen-devel] [RFC PATCH v2 11/16] hvmloader: No BIOS ROM image allowed to be compiled in

[Anthony PERARD]

Signed-off-by: Anthony PERARD 
---
 tools/firmware/hvmloader/config.h|  7 ---
 tools/firmware/hvmloader/hvmloader.c | 16 
 2 files changed, 4 insertions(+), 19 deletions(-)

diff --git a/tools/firmware/hvmloader/config.h 
b/tools/firmware/hvmloader/config.h
index c4539cc..0ddd897 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -12,13 +12,6 @@ extern unsigned long igd_opregion_pgbase;
 struct bios_config {
 const char *name;
 
-/* BIOS ROM image bits */
-void *image;
-unsigned int image_size;
-
-/* Physical address to load at */
-unsigned int bios_address;
-
 /* ROMS */
 void (*load_roms)(void);
 
diff --git a/tools/firmware/hvmloader/hvmloader.c 
b/tools/firmware/hvmloader/hvmloader.c
index 02d7f96..b131b1d 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -386,15 +386,7 @@ int main(void)
 BUG_ON(!bios_module);
 
 printf("Loading %s ...\n", bios->name);
-if ( bios->bios_load )
-bios->bios_load(bios, (void*)(bios_module->paddr), bios_module->size);
-else
-{
-BUG_ON(bios->bios_address + bios->image_size >
-   HVMLOADER_PHYSICAL_ADDRESS);
-memcpy((void *)bios->bios_address, bios->image,
-   bios->image_size);
-}
+bios->bios_load(bios, (void*)(bios_module->paddr), bios_module->size);
 
 if ( (hvm_info->nr_vcpus > 1) || hvm_info->apic_mode )
 {
@@ -432,9 +424,9 @@ int main(void)
 if ( SCRATCH_PHYSICAL_ADDRESS != scratch_start )
 printf(" %05x-%05lx: Scratch space\n",
SCRATCH_PHYSICAL_ADDRESS, scratch_start);
-printf(" %05x-%05x: Main BIOS\n",
-   bios->bios_address,
-   bios->bios_address + bios->image_size - 1);
+/* printf(" %05x-%05x: Main BIOS\n", */
+   /* bios->bios_address, */
+   /* bios->bios_address + bios->image_size - 1); */
 
 if ( bios->e820_setup )
 bios->e820_setup();
-- 
Anthony PERARD


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

[Xen-devel] [RFC PATCH v2 16/16] hvmloader: do not depend on SEABIOS_PATH or OVMF_PATH ...

[Anthony PERARD]

... to compile SeaBIOS and OVMF. Only depends on CONFIG_*.

If --with-system-* configure option is used, then set *_CONFIG=n to not
compile SEABIOS and OVMF.

Signed-off-by: Anthony PERARD 

---
Please, run ./autogen.sh on this patch.
---
 tools/configure.ac  | 6 --
 tools/firmware/Makefile | 8 
 2 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/tools/configure.ac b/tools/configure.ac
index 6929006..0cff3fc 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -206,12 +206,13 @@ AC_ARG_WITH([system-seabios],
 AS_HELP_STRING([--with-system-seabios@<:@=PATH@:>@],
[Use system supplied seabios PATH instead of building and installing
 our own version]),[
+# Disable compilation of SeaBIOS.
+seabios=n
 case $withval in
 no) seabios_path= ;;
 *)  seabios_path=$withval ;;
 esac
 ],[])
-AC_SUBST(seabios_path)
 AC_DEFINE_UNQUOTED([SEABIOS_PATH],
["${seabios_path:-$XENFIRMWAREDIR/seabios.bin}"],
[SeaBIOS path])
@@ -220,12 +221,13 @@ AC_ARG_WITH([system-ovmf],
 AS_HELP_STRING([--with-system-ovmf@<:@=PATH@:>@],
[Use system supplied OVMF PATH instead of building and installing
 our own version]),[
+# Disable compilation of OVMF.
+ovmf=n
 case $withval in
 no) ovmf_path= ;;
 *)  ovmf_path=$withval ;;
 esac
 ],[])
-AC_SUBST(ovmf_path)
 AC_DEFINE_UNQUOTED([OVMF_PATH],
["${ovmf_path:-$XENFIRMWAREDIR/ovmf.bin}"],
[OVMF path])
diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile
index 9c63991..d9e525e 100644
--- a/tools/firmware/Makefile
+++ b/tools/firmware/Makefile
@@ -6,12 +6,8 @@ TARGET  := hvmloader/hvmloader
 INST_DIR := $(DESTDIR)$(XENFIRMWAREDIR)
 
 SUBDIRS-y :=
-ifeq ($(OVMF_PATH),)
 SUBDIRS-$(CONFIG_OVMF) += ovmf-dir
-endif
-ifeq ($(SEABIOS_PATH),)
 SUBDIRS-$(CONFIG_SEABIOS) += seabios-dir
-endif
 SUBDIRS-$(CONFIG_ROMBIOS) += rombios
 SUBDIRS-$(CONFIG_ROMBIOS) += vgabios
 SUBDIRS-$(CONFIG_ROMBIOS) += etherboot
@@ -50,15 +46,11 @@ install: all
[ -d $(INST_DIR) ] || $(INSTALL_DIR) $(INST_DIR)
[ ! -e $(TARGET) ] || $(INSTALL_DATA) $(TARGET) $(INST_DIR)
 ifeq ($(CONFIG_SEABIOS),y)
-ifeq ($(SEABIOS_PATH),)
[ ! -e $(SEABIOS_ROM) ] || $(INSTALL_DATA) $(SEABIOS_ROM) 
$(INST_DIR)/seabios.bin
 endif
-endif
 ifeq ($(CONFIG_OVMF),y)
-ifeq ($(OVMF_PATH),)
[ ! -e $(OVMF_ROM) ] || $(INSTALL_DATA) $(OVMF_ROM) $(INST_DIR)/ovmf.bin
 endif
-endif
[ ! -e $(ACPI_TABLE_QEMU_PC_I440FX) ] || $(INSTALL_DATA) 
$(ACPI_TABLE_QEMU_PC_I440FX) $(INST_DIR)
 
 .PHONY: clean
-- 
Anthony PERARD


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

Re: [Xen-devel] RFC: Survey on release cycle

[Ian Jackson]

Wei Liu writes ("[Xen-devel] RFC: Survey on release cycle"):
> Please express your preference with -2 (strongly argue against), -1
> (not happy but not against), +1 (happy but won't argue for) and +2
> (happy and argue for).
> 
> # 6 months release cycle + current stable release scheme
> 
> The same stable release scheme applies (18 months full support + 18
> months security fixes). Encourage more people to step up to share the
> maintenance burden if necessary. Automate part of the workflow to
> maintain stable releases. Write down guideline for maintainers.

+2

> # 6 months release cycle + LTS scheme
> 
> Pick LTS release every 4 releases. Announce LTS before hand. Non-LTS
> releases receive shorter support. Encourage more people to step up to
> share the maintenance burden if necessary. Automate part of the
> workflow to maintain stable releases and LTS releases. Write down
> guideline for maintainers.

+1

> The length of support hasn't been discussed thoroughly -- but to make
> LTS scheme stand out the length of support would be longer than what
> we have now (18 + 18).
> 
> # 9 months release cycle + current stable release scheme

-2

Ian.

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

Re: [Xen-devel] RFC: Survey on release cycle

[Ian Jackson]

Ian Campbell writes ("Re: [Xen-devel] RFC: Survey on release cycle"):
> On Mon, 2015-10-12 at 18:32 +0100, Wei Liu wrote:
> > The same stable release scheme applies (18 months full support + 18
> > months security fixes). Encourage more people to step up to share the
> > maintenance burden if necessary. Automate part of the workflow to
> > maintain stable releases. Write down guideline for maintainers.
> 
> I think this "current stable release scheme" and "18 months full support",
> implies an increase in the number of supported stable releases at any given
> time.
> 
> I'd therefore like to also propose:
> 
> # 6 months release cycle + extended security support

This would also be acceptable to me (+1 in Wei's notation).

Ian.

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

Re: [Xen-devel] Ping: [PATCH v3] x86/HVM: correct page dirty marking in hvm_map_guest_frame_rw()

[Wei Liu]

On Mon, Oct 26, 2015 at 10:00:26AM -0600, Jan Beulich wrote:
> >>> On 26.10.15 at 16:20,  wrote:
> > On Mon, Oct 26, 2015 at 07:09:06AM -0600, Jan Beulich wrote:
> >> >>> On 19.10.15 at 16:53,  wrote:
> >> > --- a/tools/libxc/xc_sr_save.c
> >> > +++ b/tools/libxc/xc_sr_save.c
> >> > @@ -537,7 +537,8 @@ static int suspend_and_send_dirty(struct
> >> >  if ( xc_shadow_control(
> >> >   xch, ctx->domid, XEN_DOMCTL_SHADOW_OP_CLEAN,
> >> >   HYPERCALL_BUFFER(dirty_bitmap), ctx->save.p2m_size,
> >> > - NULL, 0, ) != ctx->save.p2m_size )
> >> > + NULL, XEN_DOMCTL_SHADOW_LOGDIRTY_FINAL, ) !=
> >> > + ctx->save.p2m_size )
> >> >  {
> >> >  PERROR("Failed to retrieve logdirty bitmap");
> >> >  rc = -1;
> >> 
> >> Tools maintainers, could I please get an ack or otherwise on this
> >> adjustment?
> >> 
> > 
> > Er, there seems to be behaviour change that would cause external users
> > of xc_shadow_control cease to function properly.
> 
> What behavioral change do you see? So far we simply didn't care
> about those permanently mapped pages. Now we provide an
> option to include them.
> 

Oh, this is fine then. I thought before we had always included the
permanent mapped pages in dirty bitmap. I was wrong. Sorry about the
noise.

Wei.

> Jan

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

[Xen-devel] [PATCH] x86/PV: don't zero-map LDT

[Jan Beulich]

This effectvely reverts the LDT related part of commit cf6d39f819
("x86/PV: properly populate descriptor tables"), which broke demand
paged LDT handling in guests.

Reported-by: David Vrabel 
Diagnosed-by: Andrew Cooper 
Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -508,7 +508,6 @@ static void invalidate_shadow_ldt(struct
 {
 l1_pgentry_t *pl1e;
 unsigned int i;
-unsigned long pfn, zero_pfn = PFN_DOWN(__pa(zero_page));
 struct page_info *page;
 
 BUG_ON(unlikely(in_irq()));
@@ -523,11 +522,10 @@ static void invalidate_shadow_ldt(struct
 
 for ( i = 16; i < 32; i++ )
 {
-pfn = l1e_get_pfn(pl1e[i]);
-if ( !(l1e_get_flags(pl1e[i]) & _PAGE_PRESENT) || pfn == zero_pfn )
+if ( !(l1e_get_flags(pl1e[i]) & _PAGE_PRESENT) )
 continue;
-l1e_write([i], l1e_from_pfn(zero_pfn, __PAGE_HYPERVISOR_RO));
-page = mfn_to_page(pfn);
+page = l1e_get_page(pl1e[i]);
+l1e_write([i], l1e_empty());
 ASSERT_PAGE_IS_TYPE(page, PGT_seg_desc_page);
 ASSERT_PAGE_IS_DOMAIN(page, v->domain);
 put_page_and_type(page);



x86/PV: don't zero-map LDT

This effectvely reverts the LDT related part of commit cf6d39f819
("x86/PV: properly populate descriptor tables"), which broke demand
paged LDT handling in guests.

Reported-by: David Vrabel 
Diagnosed-by: Andrew Cooper 
Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -508,7 +508,6 @@ static void invalidate_shadow_ldt(struct
 {
 l1_pgentry_t *pl1e;
 unsigned int i;
-unsigned long pfn, zero_pfn = PFN_DOWN(__pa(zero_page));
 struct page_info *page;
 
 BUG_ON(unlikely(in_irq()));
@@ -523,11 +522,10 @@ static void invalidate_shadow_ldt(struct
 
 for ( i = 16; i < 32; i++ )
 {
-pfn = l1e_get_pfn(pl1e[i]);
-if ( !(l1e_get_flags(pl1e[i]) & _PAGE_PRESENT) || pfn == zero_pfn )
+if ( !(l1e_get_flags(pl1e[i]) & _PAGE_PRESENT) )
 continue;
-l1e_write([i], l1e_from_pfn(zero_pfn, __PAGE_HYPERVISOR_RO));
-page = mfn_to_page(pfn);
+page = l1e_get_page(pl1e[i]);
+l1e_write([i], l1e_empty());
 ASSERT_PAGE_IS_TYPE(page, PGT_seg_desc_page);
 ASSERT_PAGE_IS_DOMAIN(page, v->domain);
 put_page_and_type(page);
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Ping: [PATCH v3] x86/HVM: correct page dirty marking in hvm_map_guest_frame_rw()

[Wei Liu]

On Mon, Oct 26, 2015 at 10:15:13AM -0600, Jan Beulich wrote:
> >>> On 26.10.15 at 17:05,  wrote:
> > On Mon, Oct 26, 2015 at 10:00:26AM -0600, Jan Beulich wrote:
> >> >>> On 26.10.15 at 16:20,  wrote:
> >> > On Mon, Oct 26, 2015 at 07:09:06AM -0600, Jan Beulich wrote:
> >> >> >>> On 19.10.15 at 16:53,  wrote:
> >> >> > --- a/tools/libxc/xc_sr_save.c
> >> >> > +++ b/tools/libxc/xc_sr_save.c
> >> >> > @@ -537,7 +537,8 @@ static int suspend_and_send_dirty(struct
> >> >> >  if ( xc_shadow_control(
> >> >> >   xch, ctx->domid, XEN_DOMCTL_SHADOW_OP_CLEAN,
> >> >> >   HYPERCALL_BUFFER(dirty_bitmap), ctx->save.p2m_size,
> >> >> > - NULL, 0, ) != ctx->save.p2m_size )
> >> >> > + NULL, XEN_DOMCTL_SHADOW_LOGDIRTY_FINAL, ) !=
> >> >> > + ctx->save.p2m_size )
> >> >> >  {
> >> >> >  PERROR("Failed to retrieve logdirty bitmap");
> >> >> >  rc = -1;
> >> >> 
> >> >> Tools maintainers, could I please get an ack or otherwise on this
> >> >> adjustment?
> >> >> 
> >> > 
> >> > Er, there seems to be behaviour change that would cause external users
> >> > of xc_shadow_control cease to function properly.
> >> 
> >> What behavioral change do you see? So far we simply didn't care
> >> about those permanently mapped pages. Now we provide an
> >> option to include them.
> > 
> > Oh, this is fine then. I thought before we had always included the
> > permanent mapped pages in dirty bitmap. I was wrong. Sorry about the
> > noise.
> 
> No problem at all. Now - does that represent some non-standard
> for of an ack?
> 

Reviewed-by: Wei Liu 

> Jan

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

Re: [Xen-devel] [PATCH v2 5/5] xl: improve return and exit codes of parse related functions

[Wei Liu]

On Sat, Oct 24, 2015 at 11:01:36AM +0530, Harmandeep Kaur wrote:
> turning  parsing related functions xl exit codes towards using the
> EXIT_[SUCCESS|FAILURE] macros, instead of instead of arbitrary numbers

They are constants, not macros -- I'm a being pedantic here. :-)

> or libxl return codes.
> 
> it doesn't include parse_config_data() which is big enough to deserve its
> own patch
> 

Please capitalise first word of the sentence.

> Signed-off-by: Harmandeep Kaur 
> ---
>  tools/libxl/xl_cmdimpl.c | 71 
> ++--
>  1 file changed, 32 insertions(+), 39 deletions(-)
> 
[...]
> @@ -841,17 +841,15 @@ static int update_cpumap_range(const char *str, 
> libxl_bitmap *cpumap)
>  static int cpurange_parse(const char *cpu, libxl_bitmap *cpumap)
>  {
>  char *ptr, *saveptr = NULL, *buf = strdup(cpu);
> -int rc = 0;
>  
>  for (ptr = strtok_r(buf, ",", ); ptr;
>   ptr = strtok_r(NULL, ",", )) {
> -rc = update_cpumap_range(ptr, cpumap);
> -if (rc)
> +if (update_cpumap_range(ptr, cpumap))
>  break;
>  }
>  free(buf);
>  
> -return rc;
> +return 0;

This is not wrong. You return 0 even when there is error.

>  }
>  
>  static void parse_top_level_vnc_options(XLU_Config *config,
> @@ -902,7 +900,7 @@ static char *parse_cmdline(XLU_Config *config)
>  
>  if ((buf || root || extra) && !cmdline) {
>  fprintf(stderr, "Failed to allocate memory for cmdline\n");
> -exit(1);
> +exit(EXIT_FAILURE);
>  }
>  
>  return cmdline;
> @@ -946,11 +944,11 @@ static void parse_vcpu_affinity(libxl_domain_build_info 
> *b_info,
>  libxl_bitmap_init(_affinity_array[j]);
>  if (libxl_cpu_bitmap_alloc(ctx, _affinity_array[j], 0)) {
>  fprintf(stderr, "Unable to allocate cpumap for vcpu %d\n", 
> j);
> -exit(1);
> +exit(EXIT_FAILURE);
>  }
>  
>  if (cpurange_parse(buf, _affinity_array[j]))
> -exit(1);
> +exit(EXIT_FAILURE);
>  
>  j++;
>  }
> @@ -963,17 +961,17 @@ static void parse_vcpu_affinity(libxl_domain_build_info 
> *b_info,
>  libxl_bitmap_init(_affinity_array[0]);
>  if (libxl_cpu_bitmap_alloc(ctx, _affinity_array[0], 0)) {
>  fprintf(stderr, "Unable to allocate cpumap for vcpu 0\n");
> -exit(1);
> +exit(EXIT_FAILURE);
>  }
>  
>  if (cpurange_parse(buf, _affinity_array[0]))
> -exit(1);
> +exit(EXIT_FAILURE);
>  
>  for (i = 1; i < b_info->max_vcpus; i++) {
>  libxl_bitmap_init(_affinity_array[i]);
>  if (libxl_cpu_bitmap_alloc(ctx, _affinity_array[i], 0)) {
>  fprintf(stderr, "Unable to allocate cpumap for vcpu %d\n", 
> i);
> -exit(1);
> +exit(EXIT_FAILURE);
>  }
>  libxl_bitmap_copy(ctx, _affinity_array[i],
>_affinity_array[0]);
> @@ -1064,7 +1062,7 @@ static unsigned long parse_ulong(const char *str)
>  val = strtoul(str, , 10);
>  if (endptr == str || val == ULONG_MAX) {
>  fprintf(stderr, "xl: failed to convert \"%s\" to number\n", str);
> -exit(1);
> +exit(EXIT_FAILURE);
>  }
>  return val;
>  }
> @@ -1086,7 +1084,7 @@ static void parse_vnuma_config(const XLU_Config *config,
>  if (libxl_get_physinfo(ctx, ) != 0) {
>  libxl_physinfo_dispose();
>  fprintf(stderr, "libxl_get_physinfo failed\n");
> -exit(1);
> +exit(EXIT_FAILURE);
>  }
>  
>  nr_nodes = physinfo.nr_nodes;
> @@ -1105,7 +1103,7 @@ static void parse_vnuma_config(const XLU_Config *config,
>  libxl_bitmap_init(_parsed[i]);
>  if (libxl_cpu_bitmap_alloc(ctx, _parsed[i], b_info->max_vcpus)) 
> {
>  fprintf(stderr, "libxl_node_bitmap_alloc failed.\n");
> -exit(1);
> +exit(EXIT_FAILURE);
>  }
>  }
>  
> @@ -1130,7 +1128,7 @@ static void parse_vnuma_config(const XLU_Config *config,
>  xlu_cfg_value_get_list(config, vnode_spec, _config_list, 0);
>  if (!vnode_config_list) {
>  fprintf(stderr, "xl: cannot get vnode config option list\n");
> -exit(1);
> +exit(EXIT_FAILURE);
>  }
>  
>  for (conf_count = 0;
> @@ -1152,7 +1150,7 @@ static void parse_vnuma_config(const XLU_Config *config,
> _untrimmed)) {
>  fprintf(stderr, "xl: failed to split \"%s\" into pair\n",
>  buf);
> -exit(1);
> +exit(EXIT_FAILURE);
>  }
>  trim(isspace, option_untrimmed, );
>  trim(isspace, value_untrimmed, );
> @@ -1162,7 +1160,7 @@ static void 

[Xen-devel] Cannot boot into Dom0 after reading vcpu_info in sched_credit

[amin.fall...@gmail.com]

Hi there
I need to access event channel mask and pending bits for a vcpu in
sched_credit.c. Thus I'm trying to get and print this info in runq_insert
using vcpu_info like this:
printk("\nhello %d %d
\n",vcpu_info(svc->vcpu,evtchn_upcall_mask),vcpu_info(svc->vcpu,evtchn_upcall_pending));

After compiling and resinstalling (of course without any errors) I reboot
my Dom0 but the machine does not boot with Xen and gets rebooted after
bootloader.
The same printk works without any problem when I use it in event_channel.c
to print those info.
So there are a few questions:
1. Any idea what is the reason of reboot and how to fix it?
2. Any idea how can I examine logs to find out the problem? Where and what
should I look for?
3. Any ideas to access per vcpu mask and pending bits in sched_credit.c
functions (e.g. runq_insert or runq_sort)
Thanks all
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[osstest service owner]

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

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  d8ba3a9e444c6943199130eea32904bc245a6d27
baseline version:
 xen  cd84a2baadd4a5767d2568b1c01b055328cc84db

Last test of basis63260  2015-10-23 14:00:55 Z3 days
Testing same since63320  2015-10-26 14:01:22 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  George Dunlap 
  Ian Campbell 
  Jan Beulich 
  Julien Grall 

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

Re: [Xen-devel] [PATCH v2 1/5] xl: convert exit codes to EXIT_[SUCCESS|FAILURE]

[Wei Liu]

On Sat, Oct 24, 2015 at 11:01:32AM +0530, Harmandeep Kaur wrote:
> turning main function xl exit codes towards using the
> EXIT_[SUCCESS|FAILURE] macros, instead of instead of arbitrary numbers
> or libxl return codes.
> 
> also includes a document comment in xl.h stating xl process should
> always return EXIT_FOO and main_* can be treated as main() as if
> they are returning a process exit status and not a function return
> value)
> 
> Signed-off-by: Harmandeep Kaur 
> ---
>  tools/libxl/xl.c | 12 ++--
>  tools/libxl/xl.h |  6 ++
>  2 files changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
> index 5316ad9..dfae84a 100644
> --- a/tools/libxl/xl.c
> +++ b/tools/libxl/xl.c
> @@ -318,7 +318,7 @@ int main(int argc, char **argv)
>  break;
>  default:
>  fprintf(stderr, "unknown global option\n");
> -exit(2);
> +exit(EXIT_FAILURE);
>  }
>  }
>  
> @@ -326,13 +326,13 @@ int main(int argc, char **argv)
>  
>  if (!cmd) {
>  help(NULL);
> -exit(1);
> +exit(EXIT_FAILURE);
>  }
>  opterr = 0;
>  
>  logger = xtl_createlogger_stdiostream(stderr, minmsglevel,
>  (progress_use_cr ? XTL_STDIOSTREAM_PROGRESS_USE_CR : 0));
> -if (!logger) exit(1);
> +if (!logger) exit(EXIT_FAILURE);
>  
>  atexit(xl_ctx_free);
>  
> @@ -355,16 +355,16 @@ int main(int argc, char **argv)
>  if (cspec) {
>  if (dryrun_only && !cspec->can_dryrun) {
>  fprintf(stderr, "command does not implement -N (dryrun) 
> option\n");
> -ret = 1;
> +ret = EXIT_FAILURE;
>  goto xit;
>  }
>  ret = cspec->cmd_impl(argc, argv);
>  } else if (!strcmp(cmd, "help")) {
>  help(argv[1]);
> -ret = 0;
> +ret = EXIT_SUCCESS;
>  } else {
>  fprintf(stderr, "command not implemented\n");
> -ret = 1;
> +ret = EXIT_FAILURE;
>  }
>  
>   xit:
> diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
> index 0021112..0533398 100644
> --- a/tools/libxl/xl.h
> +++ b/tools/libxl/xl.h
> @@ -30,6 +30,12 @@ struct cmd_spec {
>  char *cmd_option;
>  };
>  
> +/*
> +*xl process should always return EXIT_FOO and main_* can be treated
> +*as main() as if they are returning a process exit status and not a
> +*function return value.

Please correctly format this comment. 

 /*
  * xl process should always return EXIT_FOO and main_* can be treated
  * as main() as if they are returning a process exit status and not a
  * function return value.
  */

Note the alignment.

>  int main_vcpulist(int argc, char **argv);
>  int main_info(int argc, char **argv);
>  int main_sharing(int argc, char **argv);
> -- 
> 1.9.1

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

Re: [Xen-devel] [PATCH 00/13] tools: do cleanups related to libxc python bindings

[Wei Liu]

On Fri, Oct 23, 2015 at 03:04:59PM +0200, Juergen Gross wrote:
> This series is a combination of my previous patches:
> 
> "libxc: remove most of tools/libxc/xc_dom_compat_linux.c" 
> "tools: remove unused wrappers for python"
> 
> I have split it up as requested by Ian Campbell, thus it consists of
> 13 patches instead just of 2, but the functionality is roughly the
> same. I have just kept more python bindings compared to the first
> version, as there have been reports of some out of tree uses. Asking
> for more such use case on xen-devel and xen-user didn't result in
> requests for more interfaces to be kept, so I delete them.
> 
> Juergen Gross (13):
>   libxc: remove most of tools/libxc/xc_dom_compat_linux.c
>   libxc: remove xc_get_bit_size() from tools/libxc/xc_dom_compat_linux.c
>   python: remove flask related libxc python bindings
>   python: remove cpupool related libxc python bindings
>   python: remove cpuid related libxc python bindings
>   python: remove device related libxc python bindings
>   python: remove scheduler related libxc python bindings
>   python: remove unused memory related libxc python bindings
>   python: remove domain handling related libxc python bindings
>   python: remove vcpu related libxc python bindings
>   python: remove hvm related libxc python bindings
>   python: remove  permission related libxc python bindings
>   python: remove unused other libxc python bindings
> 

I think it's good riddance of dead code.  I only skim this series since
they look rather low risk to me.  If anyone shouts we can easily
resurrect necessary bits from git history.

So whole series:

Acked-by: Wei Liu 

Wei.

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

Re: [Xen-devel] [PATCH] x86/PV: don't zero-map LDT

[David Vrabel]

On 26/10/15 16:14, Jan Beulich wrote:
> This effectvely reverts the LDT related part of commit cf6d39f819
> ("x86/PV: properly populate descriptor tables"), which broke demand
> paged LDT handling in guests.
> 
> Reported-by: David Vrabel 
> Diagnosed-by: Andrew Cooper 
> Signed-off-by: Jan Beulich 

Tested-by: David Vrabel 

Thanks.

David

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

Re: [Xen-devel] [Minios-devel] [PATCH MINI-OS v2] xenbus: notify the other end when necessary

[Wei Liu]

On Mon, Oct 26, 2015 at 05:37:51PM +0100, Samuel Thibault wrote:
> Ian Jackson, le Mon 26 Oct 2015 16:32:10 +, a écrit :
> > Samuel Thibault writes ("Re: [Minios-devel] [PATCH MINI-OS v2] xenbus: 
> > notify the other end when necessary"):
> > > Ok...  This is still very worrying.  The more I'm thinking about it,
> > > the more I believe we shouldn't *have* to do this.  Which version of
> > > the xenstore are you testing with, exactly?  I guess that while we
> > > investigate this oddness we can apply this fix to stable trees, so as to
> > > be safer than sorry.
> > 
> > I would rather have only a proper fix for the stable trees, that we
> > have confidence in.  So I'll wait.
> 
> Well, at least the patch can not hurt.
> 
> > Would one of you let me know if you need me to stare hard at the ring
> > handling ?
> 
> Let's check which version we need to stare hard at first :)
> 

The oxenstored in staging. Sorry I haven't got around to investigate
more -- need to clear some patches in my inbox first.

Wei.

> Samuel

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

Re: [Xen-devel] [PATCH net-next 3/8] xen-netback: support multiple extra info segments passed from frontend

[Wei Liu]

On Wed, Oct 21, 2015 at 11:36:20AM +0100, Paul Durrant wrote:
> The code does not currently allow a frontend to pass multiple extra info
> segments to the backend in a tx request. A subsequent patch in this series
> needs this functionality so it is added here, without any other
> modification, for better bisectability.
> 
> Signed-off-by: Paul Durrant 
> Cc: Ian Campbell 
> Cc: Wei Liu 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH net-next 8/8] xen-netback: add support for toeplitz hashing

[Wei Liu]

On Wed, Oct 21, 2015 at 11:36:25AM +0100, Paul Durrant wrote:
> This patch adds all the necessary infrastructure to allow a frontend to
> specify toeplitz hashing of network packets on its receive side. (See
> netif.h for details of the xenbus protocol).
> 
> The toeplitz hash algorithm itself was based on pseudo-code provided by
> Microsoft at:
> 
> https://msdn.microsoft.com/en-us/library/windows/hardware/ff570725.aspx
> 
> Signed-off-by: Paul Durrant 
> Cc: Ian Campbell 
> Cc: Wei Liu 
[...]
>  
> diff --git a/drivers/net/xen-netback/interface.c 
> b/drivers/net/xen-netback/interface.c
> index 0c7da7b..38eee4f 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -142,17 +142,122 @@ void xenvif_wake_queue(struct xenvif_queue *queue)
>   netif_tx_wake_queue(netdev_get_tx_queue(dev, id));
>  }
>  

I skipped the hash implementation because I don't think I know enough to
tell if it is correct or not, and protocol negotiation because I think
that's going to change in next version.

> +
> +
> +static void xen_net_read_toeplitz_key(struct xenvif *vif,
> +   const char *node)
> +{
> + struct xenbus_device *dev = xenvif_to_xenbus_device(vif);
> + char *str, *token;
> + u8 key[40];

This should use the macro.

> + unsigned int n, i;
> +
> + str = xenbus_read(XBT_NIL, node, "key", NULL);
> + if (IS_ERR(str))
> + goto fail1;
> +
> + memset(key, 0, sizeof(key));
> +
> + n = 0;
> + while ((token = strsep(, ",")) != NULL) {
> + int rc;
> +
> + if (n >= ARRAY_SIZE(vif->hash_params.toeplitz.key)) {
> + pr_err("%s: key too big\n",
> +dev->nodename);
> + goto fail2;
> + }
> +
> + rc = kstrtou8(token, 0, [n]);
> + if (rc < 0) {
> + pr_err("%s: invalid key value (%s at index %u)\n",
> +dev->nodename, token, n);
> + goto fail2;
> + }
> +
> + n++;
> + }
> +
> + for (i = 0; i < ARRAY_SIZE(vif->hash_params.toeplitz.key); i++)
> + vif->hash_params.toeplitz.key[i] = key[i];
> +
> + kfree(str);
> + return;
> +
> +fail2:
> + kfree(str);
> +fail1:
> + vif->hash_params.toeplitz.types = 0;
> +}
> +
[...]
> +
> +static void xen_hash_changed(struct xenbus_watch *watch,
> +  const char **vec, unsigned int len)
> +{
> + struct xenvif *vif = container_of(watch, struct xenvif, hash_watch);
> +
> + xen_net_read_hash(vif);

I think the same question for previous patch applies here, too.

Is there any concern of correctness and security implication that you
just change the hash without stopping the vif?

Wei.

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

Re: [Xen-devel] [PATCH net-next 1/8] xen-netback: re-import canonical netif header

[Wei Liu]

On Wed, Oct 21, 2015 at 11:36:18AM +0100, Paul Durrant wrote:
> The canonical netif header (in the Xen source repo) and the Linux variant
> have diverged significantly. Recently much documentation has been added to
> the canonical header and new definitions and types to support packet hash
> configuration. Subsequent patches in this series add support for packet
> hash configuration in xen-netback so this patch re-imports the canonical
> header in readiness.
> 
> To maintain compatibility and some style consistency with the old Linux
> variant, the header was stripped of its emacs boilerplate, and
> post-processed and copied into place with the following commands:
> 
> ed -s netif.h << EOF
> H
> ,s/NETTXF_/XEN_NETTXF_/g
> ,s/NETRXF_/XEN_NETRXF_/g
> ,s/NETIF_RSP/XEN_NETIF_RSP/g
> ,s/netif_tx/xen_netif_tx/g
> ,s/netif_rx/xen_netif_rx/g
> ,s/netif_extra_info/xen_netif_extra_info/g
> w
> EOF
> 
> indent --linux-style netif.h -o include/xen/interface/io/netif.h
> 
> Signed-off-by: Paul Durrant 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Boris Ostrovsky 
> Cc: David Vrabel 
> Cc: Wei Liu 
> ---
> 
> Whilst awaiting review of my patches to the canonical netif.h, import has
> been done from my staging branch using:
> 
> wget 
> http://xenbits.xen.org/gitweb/?p=people/pauldu/xen.git;a=blob_plain;f=xen/include/public/io/netif.h;hb=refs/heads/netif

There is on-going discussion on this so I'm going to skip this patch for
now.

Wei.

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

Re: [Xen-devel] [PATCH net-next 6/8] xen-netback: pass an L4 or L3 skb hash value to the frontend

[Wei Liu]

On Wed, Oct 21, 2015 at 11:36:23AM +0100, Paul Durrant wrote:
> If the frontend indicates it's capable (see netif.h for details) and an
> skb has an L4 or L3 hash value then pass the value to the frontend in
> a xen_netif_extra_info segment.
> 
> Signed-off-by: Paul Durrant 
> Cc: Ian Campbell 
> Cc: Wei Liu 

Reviewed-by: Wei Liu 

>  static int xenvif_rx_ring_slots_needed(struct xenvif *vif)
>  {
> - if (vif->gso_mask)
> - return DIV_ROUND_UP(vif->dev->gso_max_size, PAGE_SIZE) + 1;
> + int needed;
> +
> + if (vif->gso_mask || vif->gso_prefix_mask)

It seems like this line should become a patch for -stable?

>   xenvif_add_frag_responses(queue, status,
> diff --git a/drivers/net/xen-netback/xenbus.c 
> b/drivers/net/xen-netback/xenbus.c
> index 2fa8a16..a31bcee 100644
> --- a/drivers/net/xen-netback/xenbus.c
> +++ b/drivers/net/xen-netback/xenbus.c
> @@ -1037,6 +1037,11 @@ static int read_xenbus_vif_flags(struct backend_info 
> *be)
>   val = 0;
>   vif->multicast_control = !!val;
>  
> + if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-hash",
> +  "%d", ) < 0)
> + val = 0;

Again, feel free to retain my reviewed-by if this changes in next
version.

Wei.

> + vif->hash_extra = !!val;
> +
>   return 0;
>  }
>  
> -- 
> 2.1.4

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

Re: [Xen-devel] [Minios-devel] [PATCH MINI-OS v2] xenbus: notify the other end when necessary

[Samuel Thibault]

Wei Liu, le Mon 26 Oct 2015 16:41:15 +, a écrit :
> The oxenstored in staging.

Ok.  For a first, one fishy thing at quick sight is that the only
occurence of rsp_cons (except at closure) is when writing, and not when
going to sleep.  One issue there is that ml_interface_write only writes
a contiguous piece of data, so when crossing the ring bound, it will
return a short write while there *is* room!

One quick test you could do is calling Xs_ring.write a second time in
tools/ocaml/libs/xb/xb.ml's write_mmap, something like below (untested,
and my caml is old, so it's ugly, but you get the idea).

Samuel

diff --git a/tools/ocaml/libs/xb/xb.ml b/tools/ocaml/libs/xb/xb.ml
index 50944b5..33298d2 100644
--- a/tools/ocaml/libs/xb/xb.ml
+++ b/tools/ocaml/libs/xb/xb.ml
@@ -91,10 +91,12 @@ let write_fd back con s len =
Unix.write back.fd s 0 len
 
 let write_mmap back con s len =
-   let ws = Xs_ring.write back.mmap s len in
-   if ws > 0 then
+   let ws = ref (Xs_ring.write back.mmap s len) in
+   if !ws < len then
+   ws := !ws + Xs_ring.write back.mmap (String.sub s !ws 
(len-!ws)) (len-!ws);
+   if !ws > 0 then
back.eventchn_notify ();
-   ws
+   !ws
 
 let write con s len =
match con.backend with

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

Re: [Xen-devel] [PATCH v2 3/5] x86/mm: override stored file names for multiply built sources

[George Dunlap]

On 26/10/15 11:51, Jan Beulich wrote:
> To make it possible to tell apart the static symbols therein, use their
> object file names instead of their source ones.
> 
> Signed-off-by: Jan Beulich 

Acked-by: George Dunlap 

> ---
> v2: Introduce __OBJECT_FILE__.
> 
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -42,10 +42,10 @@ ALL_OBJS-y   += $(BASEDIR)/x
>  ALL_OBJS-y   += $(BASEDIR)/arch/$(TARGET_ARCH)/built_in.o
>  ALL_OBJS-$(x86)  += $(BASEDIR)/crypto/built_in.o
>  
> -CFLAGS += -fno-builtin -fno-common
> +CFLAGS += -nostdinc -fno-builtin -fno-common
>  CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith
>  CFLAGS += -pipe -g -D__XEN__ -include $(BASEDIR)/include/xen/config.h
> -CFLAGS += -nostdinc
> +CFLAGS += '-D__OBJECT_FILE__="$@"'
>  
>  CFLAGS-$(XSM_ENABLE)+= -DXSM_ENABLE
>  CFLAGS-$(FLASK_ENABLE)  += -DFLASK_ENABLE
> --- a/xen/arch/x86/mm/guest_walk.c
> +++ b/xen/arch/x86/mm/guest_walk.c
> @@ -21,6 +21,9 @@
>   * along with this program; If not, see .
>   */
>  
> +/* Allow uniquely identifying static symbols in the 3 generated objects. */
> +asm(".file \"" __OBJECT_FILE__ "\"");
> +
>  #include 
>  #include 
>  #include 
> --- a/xen/arch/x86/mm/hap/guest_walk.c
> +++ b/xen/arch/x86/mm/hap/guest_walk.c
> @@ -18,6 +18,8 @@
>   * this program; If not, see .
>   */
>  
> +/* Allow uniquely identifying static symbols in the 3 generated objects. */
> +asm(".file \"" __OBJECT_FILE__ "\"");
>  
>  #include 
>  #include 
> --- a/xen/arch/x86/mm/shadow/multi.c
> +++ b/xen/arch/x86/mm/shadow/multi.c
> @@ -20,7 +20,9 @@
>   * along with this program; If not, see .
>   */
>  
> -#include 
> +/* Allow uniquely identifying static symbols in the 3 generated objects. */
> +asm(".file \"" __OBJECT_FILE__ "\"");
> +
>  #include 
>  #include 
>  #include 
> 
> 
> 


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

Re: [Xen-devel] [Minios-devel] [PATCH MINI-OS v2] xenbus: notify the other end when necessary

[Samuel Thibault]

Wei Liu, le Mon 26 Oct 2015 13:55:31 +, a écrit :
> On Mon, Oct 26, 2015 at 01:52:47PM +0100, Samuel Thibault wrote:
> > Wei Liu, le Mon 26 Oct 2015 12:47:56 +, a écrit :
> > > -if (xenstore_buf->rsp_prod - xenstore_buf->rsp_cons < 
> > > sizeof(msg))
> > > +if (xenstore_buf->rsp_prod - xenstore_buf->rsp_cons < 
> > > sizeof(msg)) {
> > > +notify_remote_via_evtchn(start_info.store_evtchn);
> > >  break;
> > > +}
> > 
> > >  if (xenstore_buf->rsp_prod - xenstore_buf->rsp_cons <
> > > -sizeof(msg) + msg.len)
> > > +sizeof(msg) + msg.len) {
> > > +notify_remote_via_evtchn(start_info.store_evtchn);
> > 
> > Actually thinking...  In principle we should not need these two
> > notifications: we have already notified last time we consumed a message.
> > Notifying again shouldn't be bringing anything new.  Do you actually see
> > a difference with these?
> > 
> 
> Yes. The ring still gets stalled somehow without those two
> notifications.

Ok...  This is still very worrying.  The more I'm thinking about it,
the more I believe we shouldn't *have* to do this.  Which version of
the xenstore are you testing with, exactly?  I guess that while we
investigate this oddness we can apply this fix to stable trees, so as to
be safer than sorry.

Samuel

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

Re: [Xen-devel] [Minios-devel] [PATCH MINI-OS v2] xenbus: notify the other end when necessary

[Ian Jackson]

Samuel Thibault writes ("Re: [Minios-devel] [PATCH MINI-OS v2] xenbus: notify 
the other end when necessary"):
> Ok...  This is still very worrying.  The more I'm thinking about it,
> the more I believe we shouldn't *have* to do this.  Which version of
> the xenstore are you testing with, exactly?  I guess that while we
> investigate this oddness we can apply this fix to stable trees, so as to
> be safer than sorry.

I would rather have only a proper fix for the stable trees, that we
have confidence in.  So I'll wait.

Would one of you let me know if you need me to stare hard at the ring
handling ?

Ian.

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

Re: [Xen-devel] [Minios-devel] [PATCH MINI-OS v2] xenbus: notify the other end when necessary

[Wei Liu]

On Mon, Oct 26, 2015 at 05:43:53PM +0100, Samuel Thibault wrote:
> Also, just to make sure: you tested with the third and fourth hooks of
> your v2 patch applied, only first and second hooks were removed?
> 
> Samuel

See the patch below.

>From 0643a821ce2795e7e65e199e7caaa657f27bafcf Mon Sep 17 00:00:00 2001
From: Wei Liu 
Date: Fri, 23 Oct 2015 20:01:06 +0100
Subject: [PATCH] Test patch

---
 xenbus/xenbus.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/xenbus/xenbus.c b/xenbus/xenbus.c
index 4613ed6..0ab387a 100644
--- a/xenbus/xenbus.c
+++ b/xenbus/xenbus.c
@@ -237,6 +237,7 @@ static void xenbus_thread_func(void *ign)
event->path = data;
event->token = event->path + strlen(event->path) + 1;
 
+mb();
 xenstore_buf->rsp_cons += msg.len + sizeof(msg);
 
 for (watch = watches; watch; watch = watch->next)
@@ -262,9 +263,13 @@ static void xenbus_thread_func(void *ign)
 req_info[msg.req_id].reply,
 MASK_XENSTORE_IDX(xenstore_buf->rsp_cons),
 msg.len + sizeof(msg));
+mb();
 xenstore_buf->rsp_cons += msg.len + sizeof(msg);
 wake_up(_info[msg.req_id].waitq);
 }
+
+wmb();
+notify_remote_via_evtchn(start_info.store_evtchn);
 }
 }
 }
-- 
2.1.4


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

Re: [Xen-devel] [PATCH net-next 7/8] xen-netback: add support for a multi-queue hash mapping table

[Wei Liu]

On Wed, Oct 21, 2015 at 11:36:24AM +0100, Paul Durrant wrote:
> Advertise the capability to handle a hash mapping specified by the
> frontend (see netif.h for details).
> 
> Add an ndo_select() entry point so that, of the frontend does specify a

"if the frontend ..."

> hash mapping, the skb hash is extracted and mapped to a queue. If no
> mapping is specified then the fallback queue selection function is
> called so there is no change in behaviour.
> 
> Signed-off-by: Paul Durrant 
[...]
> +static void xen_hash_mapping_changed(struct xenbus_watch *watch,
> +  const char **vec, unsigned int len)
> +{
> + struct xenvif *vif = container_of(watch, struct xenvif,
> +   hash_mapping_watch);
> +
> + xen_net_read_multi_queue_hash_mapping(vif);

Is it safe / correct to not stop the vif before changing mapping table?

Wei.

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

Re: [Xen-devel] [PATCH net-next 4/8] xen-netback: accept an L4 or L3 skb hash value from the frontend

[Wei Liu]

On Wed, Oct 21, 2015 at 11:36:21AM +0100, Paul Durrant wrote:
> This patch adds an indication that netback is capable of handling hash
> values passed from the frontend (see netif.h for details), and the code
> necessary to process the additional xen_netif_extra_info segment and
> set a hash on the skb.
> 
> Signed-off-by: Paul Durrant 
> Cc: Ian Campbell 
> Cc: Wei Liu 

Reviewed-by: Wei Liu 

[...]
>  
> + /* We support hash values. */
> + err = xenbus_printf(xbt, dev->nodename,
> + "feature-hash", "%d", 1);
> + if (err) {
> + message = "writing feature-hash";
> + goto abort_transaction;

Feel free to retain my reviewed-by if this changes in next version.

Wei.

> + }
> +
>   err = xenbus_transaction_end(xbt, 0);
>   } while (err == -EAGAIN);
>  
> -- 
> 2.1.4

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

Re: [Xen-devel] [PATCH net-next 2/8] xen-netback: remove GSO information from xenvif_rx_meta

[Wei Liu]

On Wed, Oct 21, 2015 at 11:36:19AM +0100, Paul Durrant wrote:
> The code in net_rx_action() that builds rx responses has direct access
> to the skb so there is no need to copy this information into the meta
> structure.
> 
> This patch removes the extraneous fields, saves space in the array and
> removes many lines of code.
> 
> Signed-off-by: Paul Durrant 
> Cc: Ian Campbell 
> Cc: Wei Liu 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH] tools: create XEN_DUMP_DIR with mode 0700

[Wei Liu]

On Thu, Oct 22, 2015 at 05:32:57PM +0100, Ian Campbell wrote:
> On Wed, 2015-10-21 at 15:15 +0100, Wei Liu wrote:
> > That directory is used to store guest memory dump which contains
> > sensitive information.
> > 
> > Signed-off-by: Wei Liu 
> 
> Acked-by: Ian Campbell 
> 
> Have you audited all the paths we create and determined that this is the
> only one which needs adjusting in this way?
> 

No, I haven't audited all paths. I fixed this as I noticed it needed
fixing.

> OOI, what lead you to be concerned about the permissions on the directories
> we are creating (first the xenpaging one, now this)?
> 

I noticed the permission of xenpaging and dumpdir were different when I
was doing some random things.  And I wrongly assumed that xenpaging
directory should be fixed. Now this patch does the right thing -- it's
dumpdir's permission that should be fixed.

Wei.

> Ian.

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

Re: [Xen-devel] [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'

[Ian Jackson]

Hu, Robert writes ("RE: [OSSTEST PATCH 26/26] ts-xen-install: networking: 
Rename `nodhcp' to `ensurebridge'"):
> > From: Hu, Robert
...
> > Root cause found: Dom0 kernel boot cmd line: console=xvc0 matters, shall
> > be
> > hvc0 in nested environment.
> [Hu, Robert] 

Thanks for the update.  I'm glad to hear you seem to be making
good progress.

I think from reading this thread that this is not in fact a bug in
anything except your osstest series, because the dom0 that is dying is
the L1 ?  I think it's just dying because it can't find its console.
Is that right ?


> A patch for this: in ts-xen-install, after exact kernel and xen,
> check if 'kernkind' for this host exist, if not, set it with
> existing runvar.

I think that it would be better to change the default for kernkind.

At the moment kernkind runvars are looked at only in
target_kernkind_check, which has three possible paths:

(a) eq 'pvops'
(b) m/2618/
(c) the rest (including undef, although undef prints a warning)

I propose to change the semantics of a missing kernkind runvar from
(c) to (a).


This is safe only if no existing flights would be affected.  (That is,
the meaning of no existing sets of runvars would be changed.)

To check whether this would make any difference I did some database
searches.  Since any time target_kernkind_check is called it sets a
corresponding `console' runvar, I can search for `console' without a
corresponding `kernkind'.  I ran this query:

  select * from (select *, (select name from runvars r2 where
  r2.flight=r1.flight and r2.job=r1.job and r2.name=
  replace(r1.name,'console','kernkind')) kk from runvars r1 where
  r1.name like '%console') iq where kk is null order by flight desc;

and it found nothing since flight 7682.  So I think we can change the
default.


I therefore suggest something like this:

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index f9eba6b..48b8ffd 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -2006,7 +2006,7 @@ sub target_var ($$) {
 sub target_kernkind_check ($) {
 my ($gho) = @_;
 my $pfx= target_var_prefix($gho);
-my $kernkind= $r{$pfx."kernkind"};
+my $kernkind= $r{$pfx."kernkind"} // 'pvops';
 my $isguest= exists $gho->{Guest};
 if ($kernkind eq 'pvops') {
 store_runvar($pfx."rootdev", 'xvda') if $isguest;


If you agree and this works for you please put that into your series
with a proper commit message.  Please quote my words about existing
flights (including the database query etc.) in the commit message.

Signed-off-by: Ian Jackson 


Thanks,
Ian.

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

Re: [Xen-devel] Ping: [PATCH v3] x86/HVM: correct page dirty marking in hvm_map_guest_frame_rw()

[Ian Jackson]

Wei Liu writes ("Re: [Xen-devel] Ping: [PATCH v3] x86/HVM: correct page dirty 
marking in hvm_map_guest_frame_rw()"):
> On Mon, Oct 26, 2015 at 03:52:55PM +, Ian Jackson wrote:
> > Wei Liu writes ("Re: [Xen-devel] Ping: [PATCH v3] x86/HVM: correct page 
> > dirty marking in hvm_map_guest_frame_rw()"):
> > > I was assuming some random third party tools make use of
> > > xc_shadow_control just to get the dirty bitmap of the guest.
> > > 
> > > I don't have concrete examples at hand though.  Maybe I'm too paranoid.
> > 
> > I would say "maybe we should change the name or prototype of the
> > function, to make those people get errors".
> > 
> > But Ian Campbell is reorganising libxc so (a) this is happening anyway
> > (b) an attempt to do that would probably be lost.
> 
> Right.
> 
> So this patch:
> Reviewed-by: Wei Liu 

FTR

Acked-by: Ian Jackson 

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

Re: [Xen-devel] (XEN) Fatal machine check

[Konrad Rzeszutek Wilk]

On Mon, Oct 26, 2015 at 01:04:03PM +0100, John Doe wrote:
> Hi, i'm getting this problem with linux 4.3.0-rcX branch.
> Full log is attached. My hardware is based on intel skylake i7-6700k on
> z170 chipset and it is working properly. It does boot correctly with
> older kernels (3.12).
> With mce=off on xen parameters it does boot unti during pci detection
> where it hangs (see attached log).

You have some Linux specific options in the Xen command line. For
example:

iommu=pt iommu=1 unrestricted_guest=1 msi=1 swiotlb=force console=ttyS0 
com1=115200,8n1 console=com1 dom0_mem=min:1024Mi loglvl=all 
apic_verbosity=debug e820f

'swiotlb' is a Linux one. The 'Mi' looks buggy. Did you mean 1024M ?

e820f?

And I am not seeing the 'mce=off' on the Xen line?

Anyhow, if you boot with 'sync_console' you may get more on the console.

Doing 'mcelog --ascii' to figure out the MCE does not get much:

Hardware event. This is not a software error.
CPU 0 BANK 4 
MISC 0 
STATUS ba0011000402 MCGSTATUS 0

Which  I am not sure what it means .. That would require looking
up in the Intel SDM to figure out those bits.


> 
> I tried with both xen 4.4.2 and 4.6.0 with the same effect
> 
> [2.957615] VFS: Disk quotas d(XEN) Fatal machine check: MCE: Fatal
> error happened on CPUs ff
> (XEN)
> (XEN) 
> (XEN)
> (XEN)The processor has reported a hardware error which cannot
> (XEN)be recovered from.  Xen will now reboot the machine.
> (XEN) mce.c:1533: Begin dump mc_info
> (XEN) CPU0: Machine Check Exception:5
> (XEN) Bank 4: ba0011000402[   0]
> (XEN) CPU0: Machine Check Exception:5
> (XEN) Bank 4: ba0011000402[   0]
> (XEN) CPU1: Machine Check Exception:5
> (XEN) Bank 4: ba0011000402[   0]
> (XEN) CPU1: Machine Check Exception:5
> (XEN) Bank 4: ba0011000402[   0]
> (XEN) CPU2: Machine Check Exception:5
> (XEN) Bank 4: ba0011000402[   0]
> (XEN) CPU2: Machine Check Exception:5
> (XEN) Bank 4: ba0011000402[   0]
> (XEN) CPU3: Machine Check Exception:5
> (XEN) Bank 4: ba0011000402[   0]
> (XEN) CPU3: Machine Check Exception:5
> (XEN) Bank 4: ba0011000402[   0]
> (XEN) mce.c:1536: End dump mc_info, 8 mcinfo dumped
> (XEN)
> (XEN) 
> (XEN) Panic on CPU 0:
> (XEN) HARDWARE ERROR
> (XEN) 
> (XEN)
> (XEN) Reboot in five seconds...
> 
> Any help?
> 
> Thanks,
> John.

> Loading Xen 4.4.2 ...
> Loading Linux 4.3.0-1.pvops.qubes.x86_64 ...
> Loading initial ramdisk ...
>  Xen 4.4.2-7.fc21
> (XEN) Xen version 4.4.2 (user@) (gcc (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6)) 
> debug=n Tue Oct 20 14:48:15 CEST 2015
> (XEN) Latest ChangeSet: 
> (XEN) Bootloader: GRUB 2.00
> (XEN) Command line: placeholder iommu=pt iommu=1 unrestricted_guest=1 msi=1 
> swiotlb=force console=ttyS0 com1=115200,8n1 console=com1 dom0_mem=min:1024Mi 
> loglvl=all apic_verbosity=debug e820t
> (XEN) Video information:
> (XEN)  VGA is text mode 80x25, font 8x16
> (XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
> (XEN) Disc information:
> (XEN)  Found 1 MBR signatures
> (XEN)  Found 1 EDD information structures
> (XEN) Initial Xen-e820 RAM map:
> (XEN)   - 0009c800 (usable)
> (XEN)  0009c800 - 000a (reserved)
> (XEN)  000e - 0010 (reserved)
> (XEN)  0010 - 63911000 (usable)
> (XEN)  63911000 - 63912000 (ACPI NVS)
> (XEN)  63912000 - 6395c000 (reserved)
> (XEN)  6395c000 - 639af000 (usable)
> (XEN)  639af000 - 640b4000 (reserved)
> (XEN)  640b4000 - 66b99000 (usable)
> (XEN)  66b99000 - 677ab000 (reserved)
> (XEN)  677ab000 - 67f9a000 (ACPI NVS)
> (XEN)  67f9a000 - 67fff000 (ACPI data)
> (XEN)  67fff000 - 6800 (usable)
> (XEN)  0001 - 00089200 (usable)
> (XEN)  6800 - 6810 (reserved)
> (XEN)  e000 - f000 (reserved)
> (XEN)  fe00 - fe011000 (reserved)
> (XEN)  fec0 - fec01000 (reserved)
> (XEN)  fee0 - fee01000 (reserved)
> (XEN)  ff00 - 0001 (reserved)
> (XEN) Checking MTRR ranges...
> (XEN)  MTRR cap: 1d0a type: c06
> (XEN) Xen-e820 RAM map:
> (XEN)   - 0009c800 (usable)
> (XEN)  0009c800 - 000a (reserved)
> (XEN)  000e - 0010 (reserved)
> (XEN)  0010 - 63911000 (usable)
> (XEN)  63911000 - 63912000 (ACPI NVS)
> (XEN)  63912000 - 6395c000 (reserved)
> (XEN)  6395c000 - 

Re: [Xen-devel] [Minios-devel] [PATCH MINI-OS v2] xenbus: notify the other end when necessary

[Samuel Thibault]

Ian Jackson, le Mon 26 Oct 2015 16:32:10 +, a écrit :
> Samuel Thibault writes ("Re: [Minios-devel] [PATCH MINI-OS v2] xenbus: notify 
> the other end when necessary"):
> > Ok...  This is still very worrying.  The more I'm thinking about it,
> > the more I believe we shouldn't *have* to do this.  Which version of
> > the xenstore are you testing with, exactly?  I guess that while we
> > investigate this oddness we can apply this fix to stable trees, so as to
> > be safer than sorry.
> 
> I would rather have only a proper fix for the stable trees, that we
> have confidence in.  So I'll wait.

Well, at least the patch can not hurt.

> Would one of you let me know if you need me to stare hard at the ring
> handling ?

Let's check which version we need to stare hard at first :)

Samuel

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

Re: [Xen-devel] [Minios-devel] [PATCH MINI-OS v2] xenbus: notify the other end when necessary

[Samuel Thibault]

Also, just to make sure: you tested with the third and fourth hooks of
your v2 patch applied, only first and second hooks were removed?

Samuel

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

Re: [Xen-devel] xSplice prototype

[Ross Lagerwall]

On 10/26/2015 03:03 PM, Konrad Rzeszutek Wilk wrote:

On Mon, Oct 26, 2015 at 08:35:30AM +, Ross Lagerwall wrote:


It was added as a way to do signature checking and any other type
of checking that needed to be done. And which may take quite a while
to get done - hence doing it asynchronously.


OK. There are many things that need to be done to load an xSplice module,
almost all of which are dependent on the size of the module and may also
fail (e.g. resolving symbols, performing relocations, copying allocated
sections, etc). I think signature checking should be as part of the load
procedure, and if that needs to be done asynchronously, then so be it. The
nice thing about doing signature checking at load time is that (if it's
implemented as per Linux's signature checking) once the load phase is
complete, the original uploaded payload can be freed from memory. It might
be handy to think of the load procedure as equivalent to a basic version of
the Linux kernel module loader (which is pretty much what I did when
implementing it).

And while I remember, I think the REVERTED state is unnecessary. It seems
exactly equivalent to the LOADED state, which is just confusing.


Perhaps it should just move automatically from REVERT to LOADED? You have
to do some action to trigger it to unload.

And perhaps 'UNLOAD' is better than 'REVERT' ?



I think separating the actions from the state makes it clearer. So for 
example (ignoring CHECK for now), there are 2 states:

LOADED, APPLIED
and 4 actions:
LOAD paired with UNLOAD
APPLY paired with REVERT

LOAD loads the payload
APPLY moves the payload from LOADED to APPLIED
REVERT moves the payload from APPLIED to LOADED
UNLOAD removes the payload from the hypervisor completely

Does this make sense?

--
Ross Lagerwall

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

Re: [Xen-devel] [Minios-devel] [PATCH MINI-OS v2] xenbus: notify the other end when necessary

[Wei Liu]

On Mon, Oct 26, 2015 at 06:11:04PM +0100, Samuel Thibault wrote:
> Wei Liu, le Mon 26 Oct 2015 16:41:15 +, a écrit :
> > The oxenstored in staging.
> 
> Ok.  For a first, one fishy thing at quick sight is that the only
> occurence of rsp_cons (except at closure) is when writing, and not when
> going to sleep.  One issue there is that ml_interface_write only writes
> a contiguous piece of data, so when crossing the ring bound, it will
> return a short write while there *is* room!
> 
> One quick test you could do is calling Xs_ring.write a second time in
> tools/ocaml/libs/xb/xb.ml's write_mmap, something like below (untested,
> and my caml is old, so it's ugly, but you get the idea).
> 
> Samuel
> 
> diff --git a/tools/ocaml/libs/xb/xb.ml b/tools/ocaml/libs/xb/xb.ml
> index 50944b5..33298d2 100644
> --- a/tools/ocaml/libs/xb/xb.ml
> +++ b/tools/ocaml/libs/xb/xb.ml
> @@ -91,10 +91,12 @@ let write_fd back con s len =
>   Unix.write back.fd s 0 len
>  
>  let write_mmap back con s len =
> - let ws = Xs_ring.write back.mmap s len in
> - if ws > 0 then
> + let ws = ref (Xs_ring.write back.mmap s len) in
> + if !ws < len then
> + ws := !ws + Xs_ring.write back.mmap (String.sub s !ws 
> (len-!ws)) (len-!ws);
> + if !ws > 0 then
>   back.eventchn_notify ();
> - ws
> + !ws
>  
>  let write con s len =
>   match con.backend with

I'm now running a slightly modified version of this diff (to fix
compilation) and a mini-os only notifies the other end when it consumes
message.

The result is looking good, but I will let it run overnight to be sure.

If the backend is to blame, I think we need to accept the fact it is now
the de facto behaviour of xenstore ring and work around it in the
frontend...

Wei.

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

Re: [Xen-devel] [PATCH for-4.6] xen/public: arm: Use __typeof__ rather than typeof

[Julien Grall]

Hi,

On 23/10/15 15:55, Ian Campbell wrote:
> On Fri, 2015-10-23 at 15:44 +0100, Julien Grall wrote:
>> On 23/10/15 15:37, Jan Beulich wrote:
>> On 23.10.15 at 16:31,  wrote:
 On Fri, 2015-10-23 at 08:16 -0600, Jan Beulich wrote:
> No, the validating script is a nice-to-have, but nothing more. What
> I was referring to was a patch to drop the use of this gcc
> extension.

 Then I'm confused. This patch turns a typeof into a __typeof__. In <
 56126d870278000a8...@prv-mh.provo.novell.com> you said "typeof()
 is a
 gcc extension".

 Are you now saying that __typeof__ also a gcc extension too?

 I was under the impression that __typeof__ was standard (by some cxx
 at
 least) and your mail reinforced that (possibly wrong) impression.
>>>
>>> There's no typeof or __typeof__ in C11 or any earlier standard.
>>> I'm sorry if earlier replies of mine gave a different impression.
>>>
 https://gcc.gnu.org/onlinedocs/gcc/Typeof.html also says that "If you
 are
 writing a header file that must work when included in ISO C programs,
 write
 __typeof__ instead of typeof", which also lead me to believe
 __typeof__ was
 OK from this PoV.
>>>
>>> That's solely to prevent name space issues - __typeof__ is a
>>> reserved name, while typeof isn't.
>>
>> Thank you for the explanation. I think we can do the same as x86 does
>> i.e:
>>
>> #define set_xen_guest_handle_raw(hnd, val)  \
>> do { if ( sizeof(hnd) == 8 ) *(uint64_t *)&(hnd) = 0;   \
>>  (hnd).p = val; \
>> } while ( 0 )
> 
> This evaluates hnd twice, which I assumed we wanted to avoid.
> 
> But if that is OK for x86 in this situation then there is no harm doing it
> on ARM too[0].
> 
> But in that case I think we would just do
>   (hnd).q = val ; (hnd).p = val
> rather than messing with &, casts and *.

Which is, based on the ISO C spec [1], unspecified. See 6.2.6.1#7:

"When a value is stored in a member of an object of union type, the
bytes of the object representation that do not correspond to that member
but do correspond to other members take unspecified values, but the
value of the union object shall not thereby become a trap
representation."

I've been looking to the solution suggested by Ian Jackson on IRC
friday. I.e smth like:

typedef union {
 uint64_t actual;
 type *for_check }




#define set_xen_guest_handle_raw(hnd, val)  \
  do {  \
hnd.actual = (uint64_t)(val);   \
sizeof((val) == ((hnd).for_check)
  }

Unfortunately this may not work because we would have to use for_check
for type safety when the pointer is retrieved as we may not have the
type in hand (for instance in get_xen_guest_handle) and accessing
another member than the currently used is not clearly specified (see [2])

However, IIUC, the get_xen_guest_handle is only exposed to the tools and
therefore possible to modify it in order to pass the type. Am I wrong?
FWIW, I haven't seen any usage in the tools directory.

Note that I've also explored the solution to use a structure for ARM32
with contain a padding. I.e smth like:
   struct {
  type *p;
  uint32_t pad;
   }

But it's not possible to set all the fields in one assignation with
(type) { val, 0 } because we don't have the type in hand in
set_xen_guest_handle_raw.

So if we can modify the get_xen_guest_handle to pass a type, Ian's
solution would be the best way forward. Any opinions?

Regards,

[1] http://www.dii.uchile.cl/~daespino/files/Iso_C_1999_definition.pdf
[2] http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_283.htm

-- 
Julien Grall

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

Re: [Xen-devel] Cannot boot into Dom0 after reading vcpu_info in sched_credit

[Dario Faggioli]

On Mon, 2015-10-26 at 17:28 +, amin.fall...@gmail.com wrote:

> The same printk works without any problem when I use it in
> event_channel.c to print those info.
> So there are a few questions:
> 1. Any idea what is the reason of reboot and how to fix it?
> 2. Any idea how can I examine logs to find out the problem? Where and
> what should I look for?
>
You should setup a serial console. Have a look here:

http://wiki.xen.org/wiki/Xen_Serial_Console

Consider whether you need to pass the 'noreboot' parameter to Xen.

( http://xenbits.xen.org/docs/4.2-testing/misc/xen-command-line.html )

> 3. Any ideas to access per vcpu mask and pending bits in
> sched_credit.c functions (e.g. runq_insert or runq_sort)
>
Let's first see the logs.

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