> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Monday, September 28, 2015 6:33 PM
> To: Ian Jackson ;
> xen-de...@lists.xenproject.org
> Cc: Hu, Robert
> Subject: Re: [OSSTEST PATCH 25/26] ts-xen-install: Properly handle hosts
> without a static IP addre
branch xen-unstable
xen branch xen-unstable
job build-armhf-libvirt
test libvirt-build
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced p
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Monday, September 28, 2015 6:19 PM
> To: Ian Jackson ;
> xen-de...@lists.xenproject.org
> Cc: Hu, Robert
> Subject: Re: [OSSTEST PATCH 20/26] sg-run-job: Break out per-host-prep and
> per-host-finish
>
> On
This run is configured for baseline tests only.
flight 38229 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38229/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-win7-amd64 9 windo
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Monday, September 28, 2015 6:16 PM
> To: Ian Jackson ;
> xen-de...@lists.xenproject.org
> Cc: Hu, Robert
> Subject: Re: [OSSTEST PATCH 17/26] await_tcp(): Run check_ip on each loop
> iteration
>
> On Fri, 2
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Monday, September 28, 2015 6:15 PM
> To: Ian Jackson ;
> xen-de...@lists.xenproject.org
> Cc: Hu, Robert
> Subject: Re: [OSSTEST PATCH 16/26] target_check_ip: Rename and improve
> from guest_check_ip
>
> On
Hi All
We encountered a blue screen problem when live migrate
Win8.1/Win2012R2 64bit VM from V3 processor to non-V3
processor sandbox, KVM does not has this problem.
After looking into the MSR capabilities, we found XEN
hypervisor exposed bit 39 and bit 18 to the VM, from
Intel manual bit 39 ref
flight 63366 linux-3.10 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63366/
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. 62642
Regressions which are
> -Original Message-
> From: Hu, Robert
> Sent: Monday, October 12, 2015 11:08 AM
> To: Ian Jackson ;
> xen-de...@lists.xenproject.org
> Cc: Ian Campbell
> Subject: RE: [OSSTEST PATCH 15/26] DhcpWatch::leases: Fix a reporting
> message
>
> > -Original Message-
> > From: Ian Jackso
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Monday, September 28, 2015 6:11 PM
> To: Ian Jackson ;
> xen-de...@lists.xenproject.org
> Cc: Hu, Robert
> Subject: Re: [OSSTEST PATCH 14/26] Nested hosts: Provide PDU power
> method
>
> On Fri, 2015-09-25
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Monday, September 28, 2015 6:02 PM
> To: Ian Jackson ;
> xen-de...@lists.xenproject.org
> Cc: Hu, Robert
> Subject: Re: [OSSTEST PATCH 12/26] selecthost: Minor cleanups
>
> On Fri, 2015-09-25 at 20:15 +0100
flight 63365 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63365/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 6 xen-boot fail REGR. vs. 60684
test-amd64
On 05/10/15 10:04, Jan Beulich wrote:
Daniel,
now that we have MMCFG write intercepts in place, wouldn't it make
sense to move that hook invocation into pci_conf_write_intercept()
for the write case, so that it also covers MMCFG-based writes?
Thanks, Jan
Yes, I think this would be a good idea
This run is configured for baseline tests only.
flight 38228 xen-4.5-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38228/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-winxpsp3 16 guest-
Hi Dario,
2015-10-29 19:04 GMT-04:00 Dario Faggioli :
>
> The insert_vcpu() hook is handled with inconsistent locking.
> In fact, schedule_cpu_switch() calls the hook with runqueue
> lock held, while sched_move_domain() relies on the hook
> implementations to take the lock themselves (and, since t
On 10/10/15 12:26, Quan Xu wrote:
Signed-off-by: Quan Xu
Acked-by: Daniel De Graaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
flight 63363 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63363/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 11 guest-start fail REGR. vs. 63346
Tests which did not succeed,
On Fri, Oct 30, 2015 at 06:32:54PM +, Julien Grall wrote:
[...]
> > Ugh! I though that it is a requirement that every memory/io region user
> > must register it using relevant function. It looks that it is not true.
> > So, there is only one reliable way to get info about used io/memory regio
flight 63361 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63361/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 6 xen-boot fail REGR. vs. 63159
Regressions which
On Fri, Oct 30, 2015 at 11:36:03AM -0700, PGNet Dev wrote:
> On 10/30/2015 11:23 AM, Daniel Kiper wrote:
> >I missed that you are talking about PE executable. However,
> >as it was said you must create xen.cfg in advance and put it in the same
> >directory with xen.efi. Please check xen/docs/misc/e
Having ud2 instructions without associated bugframe entries creates
misleading information when investigating a crash.
This series adds bugframe entries to all ud2 instructions I could
locate, which leads to more useful error messages in failure cases.
Patch 1 is unrelated to the series (and a ba
To allow bug frames can be created inside existing asm() statements. In
order to do so, the current bugframe positional parameters are altered
to be named parameters, to avoid interactions with the parameters of the
existing asm() statement.
No functional change.
Signed-off-by: Andrew Cooper
--
No functional change, other than the failure cases, which now produce a
far more clear error message.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Jun Nakajima
CC: Kevin Tian
---
xen/arch/x86/boot/x86_64.S | 2 +-
xen/arch/x86/hvm/vmx/entry.S| 2 +-
xen/arch/x86/x86_64/entry.
Using local labels causes the stack trace to use the last non-local
label emitted by the compiler in the translation unit, which is almost
always unrelated.
e.g. A (contrived debug) example switches from:
(XEN) [ Xen-4.7-unstable x86_64 debug=y Not tainted ]
(XEN) CPU:0
(XEN)
Combine the almost identical vm_launch_fail() and vm_resume_fail() into a
single vmx_vmentry_failure().
Re-save all GPRs so that domain_crash() prints the real register values,
rather than the stack frame of the vmx_vmentry_failure() call.
Signed-off-by: Andrew Cooper
Acked-by: Kevin Tian
---
C
Using new _ASM_BUGFRAME* internals.
A side effect of complicating the ASM statements is that GCC now chooses to
out-of-line the stub functions, resulting in identical copies being present in
all translation units. As with the stac()/clac() stubs, force them always
inline.
No functional change, o
---
xen/arch/x86/traps.c | 17 +
xen/include/asm-x86/hvm/vmx/vmx.h | 4 +++-
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index b32f696..bc34d56 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
On 30/10/15 17:49, Jan Beulich wrote:
> I was quite surprised to find "cpufreq=off" not doing what one would
> expect it to do. Fix this.
>
> Signed-off-by: Jan Beulich
>
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -391,11 +391,12 @@ If set, force u
On 30/10/15 17:50, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 30/10/15 19:05, Andrew Cooper wrote:
> On 30/10/15 17:46, Jan Beulich wrote:
>> Rather than issuing a (mostly) useless separate message, rely on
>> domain_crash() providing enough data, and leverage the line number
>> information it prints.
>>
>> Signed-off-by: Jan Beulich
> The messages are no
On 30/10/15 17:46, Jan Beulich wrote:
> Rather than issuing a (mostly) useless separate message, rely on
> domain_crash() providing enough data, and leverage the line number
> information it prints.
>
> Signed-off-by: Jan Beulich
The messages are not completely useless, and they do save a round-t
On 30/10/15 17:39, Jan Beulich wrote:
> Since calling the function isn't cheap, try to avoid the call when we
> know up front it won't help; see the code comment for details on those
> conditions.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
On 30/10/15 17:42, Jan Beulich wrote:
> The issue the message points out may have been of relevance during the
> early days, but shouldn't anymore.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xe
On 29/10/15 13:51, Jan Beulich wrote:
> All,
>
> in the course of auditing other code in the context of that
> security issue my attention was caught by the various printk()s
> issued by domain_crash() or around and alike. Within the security
> team we discussed this and decided that a few not rate
flight 63360 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63360/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-migrupgrade 21 guest-migrate/src_host/dst_host fail REGR. vs.
63212
Regression
On 10/30/2015 11:23 AM, Daniel Kiper wrote:
I missed that you are talking about PE executable. However,
as it was said you must create xen.cfg in advance and put it in the same
directory with xen.efi. Please check xen/docs/misc/efi.markdown for more
details.
TBH I'm not clear on whether the ex
These 4 patches were developed during the analysis and fixing of XSA-150
Andrew Cooper (4):
x86/PoD: Make p2m_pod_empty_cache() restartable
x86/PoD: Identify when a domain has already been killed from PoD
exhaustion
x86/mm: Return -ESRCH for an invalid foreign domid
x86/PoD: Command li
For consistency with all other invalid domid handling.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: George Dunlap
A positive effect this will have is causing Linux to break early from
batched foreign mappings, rather than attempting to complete the
mappings, recording -EINVAL failures
PoD is only needed to cover a corner case with memory overcommit
(rebooting a ballooned down VM with insufficient host RAM available).
Its use comes with a performance hit, and inoperability with other
technologies such as PCI Passthrough.
Offer a command line option for administrators who want t
On 30/10/15 17:53, Daniel Kiper wrote:
> Hey Julien,
Hi,
> On Thu, Oct 29, 2015 at 05:24:42PM +, Julien Grall wrote:
>> Hi Daniel,
>>
>> On 29/10/15 16:36, Daniel Kiper wrote:
>>> On Wed, Oct 28, 2015 at 05:32:54PM +, Julien Grall wrote:
(Adding David and Daniel)
On 23/10/1
p2m_pod_demand_populate() can be entered repeatedly during a single path
through the hypervisor, e.g. on a toolstack batch map operation.
The domain might be crashed, but the interface currently lacks a way of
passing an error back through the generic p2m layer.
Longterm the p2m layer needs rewor
This avoids a long running operation when destroying a domain with a
large PoD cache.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: George Dunlap
---
xen/arch/x86/mm/p2m-pod.c | 16 +++-
xen/arch/x86/mm/paging.c | 2 +-
xen/include/asm-x86/p2m.h | 2 +-
3 files changed, 1
A XEN_GUEST_HANDLE_PARAM is used to represent a guest pointer passed as
an hypercall register. It will always be the size of a native register.
This is only used in Xen for type-safety, the guest will directly pass a
pointer in the hypercall parameter.
Note that for ARM we only hide XEN_GUEST_HAN
__guest_handle_param is used to represent a guest pointer stored pass as
an hypercall parameters. They are the same size as the native register
for the architecture. It will be 32-bit on ARM32 and 64-bit on ARM64.
As the __guest_handle_param will always be the size of a native
pointer, there is no
On Fri, Oct 30, 2015 at 10:16 PM, Dario Faggioli
wrote:
> On Fri, 2015-10-30 at 20:39 +0530, Harmandeep Kaur wrote:
> > __runq_insert() takes two arguments, cpu and svc. However,
> > the cpu argument is redundant because we can get all the
> > information we need about cpu from svc.
> >
> > Signe
On Fri, Oct 30, 2015 at 11:06:53AM -0700, PGNet Dev wrote:
> On 10/30/2015 10:29 AM, Daniel Kiper wrote:
> >>Will the aforementioned goals enable direct boot using systemd-boot
> >>on EFI platforms ? Or is it possible even now?
> >
> >If it supports multiboot2 with my extensions then it should wor
Hello all,
The main goal of this series is to rework set_xen_guest_handle_raw which is
not ISO compliant. This is based on the discussion on a previous patch
[1] to switch from typeof to __typeof__.
At the same time, I took the opportunity to clean up some macros used for
guest handle. For each c
The current implementation of set_xen_guest_handle_raw is using the
keyword "typeof" which is not part of C spec.
Furthermore, when the guest handle is defined in ARM32 guest, the
pointer will always be smaller than the handle. Based on the C99 spec
[1] 6.2.6.1#7, the bits that do not correspond t
Currently it's hard to know which __guest_handle* is associated to a
guest handle or a guest handle param.
Rename the types to match the usage. I.e
* __guest_handle is renamed to __guest_handle_param as it's used for
hypercall parameters.
* __guest_handle_64 is renamed to __guest_handl
Hi,
I am an Outreachy (Dec '15 - March '16) applicant. I have a background in
C, C++, Python, bash and Unix like systems. I also have knowledge of
operating systems and networking.
I know it's late, but I am interested in contributing to the Xen project
for this round of Outreachy, if possible. I
On 10/30/2015 10:29 AM, Daniel Kiper wrote:
Will the aforementioned goals enable direct boot using systemd-boot
on EFI platforms ? Or is it possible even now?
If it supports multiboot2 with my extensions then it should work.
However, I do not think it is true because all is in development
stat
Hey Julien,
On Thu, Oct 29, 2015 at 05:24:42PM +, Julien Grall wrote:
> Hi Daniel,
>
> On 29/10/15 16:36, Daniel Kiper wrote:
> > On Wed, Oct 28, 2015 at 05:32:54PM +, Julien Grall wrote:
> >> (Adding David and Daniel)
> >>
> >> On 23/10/15 16:45, Ian Campbell wrote:
> >>> On Fri, 2015-10-
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -671,8 +671,7 @@ static int hap_page_fault(struct vcpu *v
{
struct domain *d = v->domain;
-HAP_ERROR("Intercepted a guest #PF (%u:%u) with HAP enabled.\n",
- d->domain_id, v->vcp
I was quite surprised to find "cpufreq=off" not doing what one would
expect it to do. Fix this.
Signed-off-by: Jan Beulich
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -391,11 +391,12 @@ If set, force use of the performance cou
available support.
###
Rather than issuing a (mostly) useless separate message, rely on
domain_crash() providing enough data, and leverage the line number
information it prints.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_64/compat/traps.c
+++ b/xen/arch/x86/x86_64/compat/traps.c
@@ -77,19 +77,28 @@ unsigned int
No need to issue distinct extra messages, domain_crash() prints file
name and line number, so in the event of a problem allows telling the
cases apart.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -293,9 +293,8 @@ unsigned long do_iret(void)
The issue the message points out may have been of relevance during the
early days, but shouldn't anymore.
Signed-off-by: Jan Beulich
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -1118,8 +1118,8 @@ long do_set_timer_op(s_time_t timeout)
* timeout in this case can burn a lo
Since calling the function isn't cheap, try to avoid the call when we
know up front it won't help; see the code comment for details on those
conditions.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -522,7 +522,6 @@ p2m_pod_decrease_reservation(str
On Fri, Oct 30, 2015 at 08:44:53AM -0700, PGNet Dev wrote:
> Re:
>
> > The final goal is xen.efi binary file which could be loaded by EFI
> > loader, multiboot (v1) protocol (only on legacy BIOS platforms) and
> > multiboot2 protocol. This way we will have:
> > - smaller X
This run is configured for baseline tests only.
flight 38227 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38227/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl3 host-install(3)
flight 63359 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63359/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate
fail like 63216
Tests which d
On Fri, 2015-10-30 at 22:20 +0530, Harmandeep Kaur wrote:
> On Fri, Oct 30, 2015 at 10:16 PM, Dario Faggioli <
> dario.faggi...@citrix.com> wrote:
> > The list of people you Cc-ed, is not really accurate. In fact, Ian
> > Campbell and Ian Jackson are toolstack maintainers, and even Jan,
> > Keir
>
>>> On 30.10.15 at 17:33, wrote:
> On Fri, 2015-10-30 at 10:25 -0600, Jan Beulich wrote:
>> > > > On 30.10.15 at 16:09, wrote:
>> > --- a/xen/common/sched_credit.c
>> > +++ b/xen/common/sched_credit.c
>> > @@ -252,13 +252,12 @@ __runq_elem(struct list_head *elem)
>> > }
>> >
>> > static inlin
On Fri, 2015-10-30 at 20:39 +0530, Harmandeep Kaur wrote:
> __runq_insert() takes two arguments, cpu and svc. However,
> the cpu argument is redundant because we can get all the
> information we need about cpu from svc.
>
> Signed-off-by: Harmandeep Kaur
>
Thanks Harman, this looks good. Just one
On Fri, 2015-10-30 at 10:25 -0600, Jan Beulich wrote:
> > > > On 30.10.15 at 16:09, wrote:
> > --- a/xen/common/sched_credit.c
> > +++ b/xen/common/sched_credit.c
> > @@ -252,13 +252,12 @@ __runq_elem(struct list_head *elem)
> > }
> >
> > static inline void
> > -__runq_insert(unsigned int cpu
>>> On 30.10.15 at 17:20, wrote:
> El 19/10/15 a les 16.23, Jan Beulich ha escrit:
> On 02.10.15 at 17:48, wrote:
>>> Only allow enabling or disabling all the emulated devices inside of Xen,
>>> right now Xen doesn't support enabling specific emulated devices only.
>>>
>>> Signed-off-by: Roge
>>> On 30.10.15 at 16:09, wrote:
> __runq_insert() takes two arguments, cpu and svc. However,
> the cpu argument is redundant because we can get all the
> information we need about cpu from svc.
While true and looking like an improvement at the source level, ...
> --- a/xen/common/sched_credit.c
El 19/10/15 a les 16.23, Jan Beulich ha escrit:
On 02.10.15 at 17:48, wrote:
>> Only allow enabling or disabling all the emulated devices inside of Xen,
>> right now Xen doesn't support enabling specific emulated devices only.
>>
>> Signed-off-by: Roger Pau Monné
>> Reviewed-by: Andrew Coope
__runq_insert() takes two arguments, cpu and svc. However,
the cpu argument is redundant because we can get all the
information we need about cpu from svc.
Signed-off-by: Harmandeep Kaur
---
xen/common/sched_credit.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a
Re:
> The final goal is xen.efi binary file which could be loaded by EFI
> loader, multiboot (v1) protocol (only on legacy BIOS platforms) and
> multiboot2 protocol. This way we will have:
> - smaller Xen code base,
> - one code base for xen.gz and xen.
On 30/10/15 15:34, Roger Pau Monné wrote:
> El 15/10/15 a les 13.30, Paul Durrant ha escrit:
>>> -Original Message-
>>> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
>>> boun...@lists.xen.org] On Behalf Of Andrew Cooper
>>> Sent: 14 October 2015 17:02
>>> To: Jan Beulich; Roger P
On 30/10/15 13:16, Jan Beulich wrote:
On 30.10.15 at 13:50, wrote:
>> El 14/10/15 a les 16.37, Jan Beulich ha escrit:
>> On 02.10.15 at 17:48, wrote:
Signed-off-by: Roger Pau Monné
Cc: Jan Beulich
Cc: Andrew Cooper
---
Changes since v6:
- Return ENODEV i
El 15/10/15 a les 13.30, Paul Durrant ha escrit:
>> -Original Message-
>> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
>> boun...@lists.xen.org] On Behalf Of Andrew Cooper
>> Sent: 14 October 2015 17:02
>> To: Jan Beulich; Roger Pau Monne
>> Cc: xen-de...@lists.xenproject.org
>>
On Fri, Oct 30, 2015 at 09:05:29AM +0800, Yang Hongyang wrote:
> On 2015年10月28日 21:29, Konrad Rzeszutek Wilk wrote:
> >On Wed, Oct 28, 2015 at 04:18:56PM +0800, Yang Hongyang wrote:
> >>On 2015年10月28日 00:26, Konrad Rzeszutek Wilk wrote:
> >>>Hey,
> >>>
> >>>Way back in Shenghai we had a chat about
On Thu, Oct 29, 2015 at 03:11:39AM -0600, Jan Beulich wrote:
> >>> On 28.10.15 at 21:18, wrote:
> >> > @@ -481,6 +489,8 @@ int pt_irq_destroy_bind(
> >> > pirq = pirq_info(d, machine_gsi);
> >> > pirq_dpci = pirq_dpci(pirq);
> >> >
> >> > +spin_lock(&pirq_dpci->lock);
> >>
> >> Co
On Thu, 2015-10-29 at 20:28 +0530, Lasya Venneti wrote:
>
>
> On 29 October 2015 at 15:41, Dario Faggioli <
> dario.faggi...@citrix.com> wrote:
> > On Thu, 2015-10-29 at 10:07 +, Wei Liu wrote:
> > > As for xc_dom_allocate, the only failure path at the moment is
> > malloc
> > > failure, whi
flight 63358 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63358/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 63345
test-amd64-amd64-xl-rtds
On 30.10.2015 15:03, Ross Lagerwall wrote:
> On 10/30/2015 10:39 AM, Martin Pohlack wrote:
>> On 29.10.2015 17:55, Ross Lagerwall wrote:
>>> On 10/27/2015 12:05 PM, Ross Lagerwall wrote:
On 06/12/2015 12:39 PM, Martin Pohlack wrote:
> On 15.05.2015 21:44, Konrad Rzeszutek Wilk wrote:
>
On 10/30/2015 10:39 AM, Martin Pohlack wrote:
On 29.10.2015 17:55, Ross Lagerwall wrote:
On 10/27/2015 12:05 PM, Ross Lagerwall wrote:
On 06/12/2015 12:39 PM, Martin Pohlack wrote:
On 15.05.2015 21:44, Konrad Rzeszutek Wilk wrote:
[...]
## Hypercalls
We will employ the sub operations of the
>>> On 30.10.15 at 13:50, wrote:
> El 14/10/15 a les 16.37, Jan Beulich ha escrit:
> On 02.10.15 at 17:48, wrote:
>>> Signed-off-by: Roger Pau Monné
>>> Cc: Jan Beulich
>>> Cc: Andrew Cooper
>>> ---
>>> Changes since v6:
>>> - Return ENODEV in pmtimer_load if the timer is disabled.
>>> -
Daniel, ping?
What's your opinion on this? I think Quan, as the main author of vTPM
2.0 feature, is an expert in this field. At least he can qualify for
maintaining vTPM 2.0?
Wei.
On Sun, Oct 11, 2015 at 12:26:07AM +0800, Quan Xu wrote:
> Signed-off-by: Quan Xu
> ---
> MAINTAINERS | 1 +
> 1
El 14/10/15 a les 16.37, Jan Beulich ha escrit:
On 02.10.15 at 17:48, wrote:
>> Signed-off-by: Roger Pau Monné
>> Cc: Jan Beulich
>> Cc: Andrew Cooper
>> ---
>> Changes since v6:
>> - Return ENODEV in pmtimer_load if the timer is disabled.
>> - hvm_acpi_power_button and hvm_acpi_sleep_bu
El 15/10/15 a les 3.48, Boris Ostrovsky ha escrit:
> On 10/02/2015 11:48 AM, Roger Pau Monne wrote:
>> Introduce a bitmap in x86 xen_arch_domainconfig that allows enabling or
>> disabling specific devices emulated inside of Xen for HVM guests.
>>
>
> ...
>
>> diff --git a/xen/include/public/arch-
On 29.10.2015 17:55, Ross Lagerwall wrote:
> On 10/27/2015 12:05 PM, Ross Lagerwall wrote:
>> On 06/12/2015 12:39 PM, Martin Pohlack wrote:
>>> On 15.05.2015 21:44, Konrad Rzeszutek Wilk wrote:
>>> [...]
## Hypercalls
We will employ the sub operations of the system management hyperca
flight 38226 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38226/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 3 host-install(3) broken REG
On 09.10.2015 04:56, Konrad Rzeszutek Wilk wrote:
> The XENVER_[compile_info|changeset|commandline] are now
> guarded by an XSM check.
>
> The rest: XENVER_[version|extraversion|capabilities|
> parameters|get_features|page_size|guest_handle] behave
> as before (no XSM check).
I think extraversion
On 09.10.2015 11:31, Ian Campbell wrote:
> On Thu, 2015-10-08 at 22:56 -0400, Konrad Rzeszutek Wilk wrote:
>> The XENVER_[compile_info|changeset|commandline] are now
>> guarded by an XSM check.
>
> I can guess, but please explain/justify why this is the case for these
> here.
>
>> The rest: XENVE
On Fri, Oct 30, 2015 at 12:50 PM, Vladimir 'φ-coder/phcoder'
Serbinenko wrote:
>>
>> But how to deal with xen_initrd ?
>> Could you help me ?
>>
> Just another alias to module. Possibly you might want to add a code to
> xen_initrd tto check that xen_linux was already run
I think we need to be car
On 30.10.2015 09:44, Fu Wei wrote:
> Hi Vladimir,
>
> Great thanks for your suggestion! :-)
>
> On 29 October 2015 at 23:25, Vladimir 'φ-coder/phcoder' Serbinenko
> wrote:
>>> +if [ "x$machine" != xaarch64 ]; then
>>> + multiboot_cmd="multiboot"
>>> + module_linux_cmd="module"
>>> +
Hi Vladimir,
Great thanks for your suggestion! :-)
On 29 October 2015 at 23:25, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
>> +if [ "x$machine" != xaarch64 ]; then
>> + multiboot_cmd="multiboot"
>> + module_linux_cmd="module"
>> + module_initrd_cmd="module --nounzip"
>> +else
>> +
>>> On 29.10.15 at 20:47, wrote:
> On Thu, Oct 29, 2015 at 02:55:25AM -0600, Jan Beulich wrote:
>> >>> On 28.10.15 at 20:00, wrote:
>> > @@ -302,9 +315,14 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void)
>> > arg)
>> > if ( copy_from_guest(&fi, arg, 1) )
>> > return
Hi Vladimir,
yes, Thanks for your modification :-)
I just follow the xen boot protocol :
http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Multiboot
xen_module is just for "--type" option, I will discuss this with Xen
developer for this.
If we need this option, I will resubmit it
flight 63356 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63356/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail
like 63343
test-armhf-armhf-
Hi Vladimir,
Good idea! I can see your patch for it in master branch.
Great thanks for your help, I will try this ASAP :-)
On 29 October 2015 at 20:03, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> On 23.07.2015 07:16, fu@linaro.org wrote:
>> From: Fu Wei
>>
>> Add accessor functions of
94 matches
Mail list logo
