flight 95674 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95674/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 3 host-install(3) broken REGR. vs. 94728
test-amd64-amd64-qemuu
flight 95666 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95666/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 10 guest-startfail REGR. vs. 94729
Tests which are failing
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-freebsd10-amd64
testid guest-start
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-tradit
>>> On 14.06.16 at 19:57, wrote:
> We still have an unanswered question about the forthcoming 4.6.x
> stable release. To summarise:
>
> After tagging qemu-xen-4.6.2, a build issue was discovered: qemu-xen
> wanted a new patch to fix the build on recent Ubuntu. We decided to
> include this patch
>>> On 15.06.16 at 03:54, wrote:
> Jan,
> Could you help me review patch 7? Thanks.
> Then, I can send out next v9 soon and get started to focus on next patch
> set.
That patch is fine now from my pov, feel free to stick my R-b on it.
I actually have it queued for committing already, pending
>>> On 14.06.16 at 17:03, wrote:
> On 14/06/16 15:33, Jan Beulich wrote:
>> @@ -525,6 +526,35 @@ void vcpu_show_execution_state(struct vc
>> vcpu_unpause(v);
>> }
>>
>> +static cpumask_t nmi_show_state_mask;
>> +static bool_t opt_nmi_show_all;
>> +
>> +static int __init get_nmi_show_all(vo
On 06/14/2016 04:35 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Jun 10, 2016 at 12:02:44PM +0100, Ross Lagerwall wrote:
Remove the old --xen-debug option, and instead, require the user to pass
a .config file matching the original build's .config.
Hm, that throws this off a bit for the older hyper
>>> On 14.06.16 at 18:33, wrote:
>> +/* Check for continuation if it's not the last iteration. */
>> +if ( limit > ++bulk->start && hypercall_preempt_check() )
>
> I surprised the compiler didn't complain to you about lack of parenthesis.
I'm puzzled - what kind of warning would
On June 15, 2016 3:45 PM, Jan Beulich wrote:
> >>> On 15.06.16 at 03:54, wrote:
> > Jan,
> > Could you help me review patch 7? Thanks.
> > Then, I can send out next v9 soon and get started to focus on next
> > patch set.
>
> That patch is fine now from my pov, feel free to stick my R-b on it.
> From: Xu, Quan
> Sent: Wednesday, June 15, 2016 4:16 PM
>
> On June 15, 2016 3:45 PM, Jan Beulich wrote:
> > >>> On 15.06.16 at 03:54, wrote:
> > > Jan,
> > > Could you help me review patch 7? Thanks.
> > > Then, I can send out next v9 soon and get started to focus on next
> > > patch set.
>
On June 13, 2016 11:17 PM, Xu, Quan wrote:
> From: Quan Xu
>
> Signed-off-by: Quan Xu
> Acked-by: Kevin Tian
> Acked-by: Suravee Suthikulpanit
> Reviewed-by: Jan Beulich
>
> CC: Suravee Suthikulpanit
> CC: Stefano Stabellini
> CC: Julien Grall
> CC: Kevin Tian
> CC: Feng Wu
> CC: Jan B
>>> On 15.06.16 at 01:49, wrote:
> Just tested latest xen-unstable 4.8 (xen_changeset git:d337764),
> but one of the latest commits seems to have broken boot of HVM guests
> (using qemu-xen) previous build with xen_changeset git:6e908ee worked
> fine.
Primary suspects would seem to be 67fc274bbe
On Tue, Jun 14, 2016 at 6:27 PM, Andrew Cooper
wrote:
> On 13/06/16 15:11, Ian Jackson wrote:
>> George Dunlap writes ("Re: [Xen-devel] xenbits "official" repo for XTF (was
>> Re: [PATCH 0/2] xtf: add launcher (+1 bugfix)"):
>>> On Mon, Jun 13, 2016 at 11:10 AM, Andrew Cooper
I am not comple
flight 95705 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95705/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-pair 3 host-install/src_host(3) broken REGR. vs. 95460
test
On June 15, 2016 4:22 PM, Tian, Kevin wrote:
> > From: Xu, Quan
> > Sent: Wednesday, June 15, 2016 4:16 PM
> >
> > On June 15, 2016 3:45 PM, Jan Beulich wrote:
> > > >>> On 15.06.16 at 03:54, wrote:
> > > > Jan,
> > > > Could you help me review patch 7? Thanks.
> > > > Then, I can send out nex
On 06/08/2016 03:47 PM, Konrad Rzeszutek Wilk wrote:
On Wed, Jun 08, 2016 at 02:46:38PM +0800, Bob Liu wrote:
On 06/07/2016 11:25 PM, Konrad Rzeszutek Wilk wrote:
On Wed, Jun 01, 2016 at 01:49:23PM +0800, Bob Liu wrote:
On 06/01/2016 04:33 AM, Konrad Rzeszutek Wilk wrote:
On Tue, May 31, 20
>>> On 15.06.16 at 10:35, wrote:
> On June 15, 2016 4:22 PM, Tian, Kevin wrote:
>> > From: Xu, Quan
>> > Sent: Wednesday, June 15, 2016 4:16 PM
>> >
>> > On June 15, 2016 3:45 PM, Jan Beulich wrote:
>> > > >>> On 15.06.16 at 03:54, wrote:
>> > > > Jan,
>> > > > Could you help me review patch 7?
On Wed, Jun 15, 2016 at 08:41:18AM +0800, Dongli Zhang wrote:
> Local variable "j" would be used only when "i == ARRAY_SIZE(main_options)"
> is true. Thus, it is not necessary to update "j" when "i ==
> ARRAY_SIZE(main_options)" is false.
>
> Signed-off-by: Dongli Zhang
Your original patch has b
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-qemuu-nested-intel
testid xen-boot/l1
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-tr
On June 15, 2016 4:42 PM, Jan Beulich wrote:
> >>> On 15.06.16 at 10:35, wrote:
> > On June 15, 2016 4:22 PM, Tian, Kevin wrote:
> >> > From: Xu, Quan
> >> > Sent: Wednesday, June 15, 2016 4:16 PM
> >> >
> >> > On June 15, 2016 3:45 PM, Jan Beulich wrote:
> >> > > >>> On 15.06.16 at 03:54, wro
Wednesday, June 15, 2016, 10:29:37 AM, you wrote:
On 15.06.16 at 01:49, wrote:
>> Just tested latest xen-unstable 4.8 (xen_changeset git:d337764),
>> but one of the latest commits seems to have broken boot of HVM guests
>> (using qemu-xen) previous build with xen_changeset git:6e908ee worke
On 14/06/16 20:27, Konrad Rzeszutek Wilk wrote:
>> And, we ought not to let this issue delay the actual point release and
>> it is close to being on the critical path. A decision is needed.
>
> My personal preferred color is 4.6.2.1 (and I believe we did a similar
> release in the past: RELEASE-4
On Wed, Jun 15, 2016 at 01:38:41AM -0600, Jan Beulich wrote:
> >>> On 14.06.16 at 19:57, wrote:
> > We still have an unanswered question about the forthcoming 4.6.x
> > stable release. To summarise:
> >
> > After tagging qemu-xen-4.6.2, a build issue was discovered: qemu-xen
> > wanted a new pat
On Wed, Jun 15, Wei Liu wrote:
> To fix the breakage, please check out staging branch and write a patch
> to fix it. And maybe the commit message should say something like
> "initialise j to 0 to make some versions of gcc happy".
Not "some", but rather "at least gcc4.5/4.3" or similar.
There are
On Tue, Jun 14, 2016 at 09:08:59PM +0100, David Scott wrote:
>
> > On 14 Jun 2016, at 10:36, Wei Liu wrote:
> >
> > On Mon, Jun 13, 2016 at 08:50:02PM +0100, David Scott wrote:
> >>
> >>> On 13 Jun 2016, at 16:22, Wei Liu wrote:
> >>>
> >>> On Mon, Jun 13, 2016 at 04:19:59PM +0100, Ian Jackso
On Wed, Jun 15, 2016 at 11:04:40AM +0200, Olaf Hering wrote:
> On Wed, Jun 15, Wei Liu wrote:
>
> > To fix the breakage, please check out staging branch and write a patch
> > to fix it. And maybe the commit message should say something like
> > "initialise j to 0 to make some versions of gcc happy
... because the available vcpu bitmap can change during domain life time
due to cpu hotplug and unplug.
For QEMU upstream, we interrogate QEMU for the number of vcpus. For
others, we look directly into xenstore for information.
Reported-by: Jan Beulich
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
This function is used to return the memory needed for a guest. It's not
in a position to modify the b_info passed in (note the _setdefault
function).
Use a copy of b_info to do the calculation. Define a macro to mark the
change in API.
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
v3: new
Any sug
It interrogates QEMU for CPUs and update the bitmap accordingly.
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
Cc: Anthony PERARD
v3:
1. Initialise rc in error path.
2. Fix comment in header and a typo in log message.
---
tools/libxl/libxl_internal.h | 3 +++
tools/libxl/libxl_qmp.c | 38 +
Patch 1 and 2 are new in v3.
Patch 3 is changed to fix a minor bug.
Patch 4 is changed to fix a bug.
Patch 5 is unchanged.
See individual patch for detalied changelog.
Wei.
Wei Liu (5):
libxl: libxl_domain_need_memory shouldn't modify b_info
libxl: factor out libxl__get_device_modlel_vers
Calculate the final bitmap for CPUs to add to avoid having annoying
error messages complaining those CPUs are already present.
We can also properly handle error from QMP now.
Signed-off-by: Wei Liu
Reviewed-by: Anthony PERARD
---
Cc: Ian Jackson
Cc: Anthony PERARD
v3:
1. Add Anthony's Review
Factor out the logic to determine device model version to a function. It
will be used later. Note that code now also checks if the stbudom field
is actually set before trying to extract a value from it.
No functional change.
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
Cc: Anthony PERARD
v3: ne
branch xen-unstable
xenbranch xen-unstable
job build-i386-libvirt
testid libvirt-build
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen
On 15/06/16 08:38, Jan Beulich wrote:
> As said on IRC this morning, while I continue to by unconvinced of the
> arguments, being the only one wanting to stick with 4.6.2 I'm not going
> to argue any further on this - be it 4.6.3 then. The only thing I would
> really like to ask is that this time
Wednesday, June 15, 2016, 10:57:03 AM, you wrote:
> Wednesday, June 15, 2016, 10:29:37 AM, you wrote:
> On 15.06.16 at 01:49, wrote:
>>> Just tested latest xen-unstable 4.8 (xen_changeset git:d337764),
>>> but one of the latest commits seems to have broken boot of HVM guests
>>> (using qemu-
1: x86/time: adjust local system time initialization
2: x86: also generate assembler usable equates for synthesized features
3: x86/time: introduce and use rdtsc_ordered()
4: x86/time: calibrate TSC against platform timer
5: x86/time: correctly honor late clearing of TSC related feature flags
6: x8
>>> On 15.06.16 at 10:57, wrote:
> On 14/06/16 20:27, Konrad Rzeszutek Wilk wrote:
>>> And, we ought not to let this issue delay the actual point release and
>>> it is close to being on the critical path. A decision is needed.
>>
>> My personal preferred color is 4.6.2.1 (and I believe we did a
On 14/06/16 14:31, Jan Beulich wrote:
On 14.06.16 at 15:13, wrote:
>> On 14/06/16 11:45, Jan Beulich wrote:
+ struct hvm_ioreq_server *s)
+{
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
+int rc;
+
+spin_lock(&p2m->ioreq.lock);
>>> On 15.06.16 at 11:03, wrote:
> On Wed, Jun 15, 2016 at 01:38:41AM -0600, Jan Beulich wrote:
>> >>> On 14.06.16 at 19:57, wrote:
>> > We still have an unanswered question about the forthcoming 4.6.x
>> > stable release. To summarise:
>> >
>> > After tagging qemu-xen-4.6.2, a build issue was
>>> On 15.06.16 at 11:35, wrote:
> On 15/06/16 08:38, Jan Beulich wrote:
>
>> As said on IRC this morning, while I continue to by unconvinced of the
>> arguments, being the only one wanting to stick with 4.6.2 I'm not going
>> to argue any further on this - be it 4.6.3 then. The only thing I woul
>>> On 15.06.16 at 11:38, wrote:
> Wednesday, June 15, 2016, 10:57:03 AM, you wrote:
>
>> Wednesday, June 15, 2016, 10:29:37 AM, you wrote:
>
>> On 15.06.16 at 01:49, wrote:
Just tested latest xen-unstable 4.8 (xen_changeset git:d337764),
but one of the latest commits seems to hav
On 15/06/16 11:04, Jan Beulich wrote:
On 15.06.16 at 11:35, wrote:
>> On 15/06/16 08:38, Jan Beulich wrote:
>>
>>> As said on IRC this morning, while I continue to by unconvinced of the
>>> arguments, being the only one wanting to stick with 4.6.2 I'm not going
>>> to argue any further on thi
On Wed, Jun 15, 2016 at 03:56:20AM -0600, Jan Beulich wrote:
> >>> On 15.06.16 at 11:03, wrote:
> > On Wed, Jun 15, 2016 at 01:38:41AM -0600, Jan Beulich wrote:
> >> >>> On 14.06.16 at 19:57, wrote:
> >> > We still have an unanswered question about the forthcoming 4.6.x
> >> > stable release. To
>>> On 15.06.16 at 11:50, wrote:
> On 14/06/16 14:31, Jan Beulich wrote:
> On 14.06.16 at 15:13, wrote:
>>> On 14/06/16 11:45, Jan Beulich wrote:
Locking is somewhat strange here: You protect against the "set"
counterpart altering state while you retrieve it, but you don't
prot
On Tue, 14 Jun 2016, George Dunlap wrote:
> On 14/06/16 11:01, Stefano Stabellini wrote:
> > On Tue, 14 Jun 2016, George Dunlap wrote:
> >> On 14/06/16 10:40, Stefano Stabellini wrote:
> >>> On Mon, 13 Jun 2016, George Dunlap wrote:
> Point xen, qemu, and qemu-trad to stable-4.5 and -4.6 branc
>>> On 15.06.16 at 12:13, wrote:
> On 15/06/16 11:04, Jan Beulich wrote:
> On 15.06.16 at 11:35, wrote:
>>> The version of qemu-xen that was tagged with 4.6 had been through
>>> several rounds of RCs, months of osstesting, and even through a slew of
>>> builds on Travis (which does build Ubun
Using the bare return value from read_platform_stime() is not suitable
when local_time_calibration() is going to use its fast path: Divergence
of several dozen microseconds between NOW() return values on different
CPUs results when platform and local time don't stay in close sync.
Latch local and
... to make it possible to base alternative instruction patching upon
such.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -219,7 +219,8 @@ long arch_do_sysctl(
}
/* Clip the number of entries. */
-nr = min(sysctl->u.cpu_features
Matching Linux commit 03b9730b76 ("x86/asm/tsc: Add rdtsc_ordered() and
use it in trivial call sites") and earlier ones it builds upon, let's
make sure timing loops don't have their rdtsc()-s re-ordered, as that
would harm precision of the result (values were observed to be several
hundred clocks o
... instead of unconditionally against the PIT. This allows for local
and master system times to remain in better sync (which matters even
when, on any modern system, the master time is really used only during
secondary CPU bringup, as the error between the two is in fact
noticable in cross-CPU NOW
As such clearing of flags may have an impact on the selected rendezvous
function, handle such in a central place.
But don't allow such feature flags to be cleared during CPU hotplug:
Platform and local system times may have diverged significantly by
then, potentially causing noticably (even if onl
I have no idea why we didn't do so from the beginning.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/acpi/boot.c
+++ b/xen/arch/x86/acpi/boot.c
@@ -481,22 +481,23 @@ static int __init acpi_parse_fadt(struct
if (fadt->header.revision >= FADT2_REVISION_ID) {
/* FADT rev. 2
flight 95769 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95769/
Perfect :-)
All tests in this flight passed
version targeted for testing:
xen d337764d9b8e89eb9cb9d5be509823d9286f00c4
baseline version:
xen 6e908ee108caec78f9
If that had been done from the beginning, mistakes like the one
corrected in commit b64438c7c1 ("x86/time: use correct (local) time
stamp in constant-TSC calibration fast path") would likely never have
happened.
Also add a few "const" to make more obvious when things aren't expected
to change.
Si
Common code between time_calibration_{std,tsc}_rendezvous() can better
live in a single place, eliminating the risk of adjusting one without
the other.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -1263,6 +1263,18 @@ struct calibration_rendezvous {
u64 m
On 15/06/16 11:25, Jan Beulich wrote:
On 15.06.16 at 12:13, wrote:
>> On 15/06/16 11:04, Jan Beulich wrote:
>> On 15.06.16 at 11:35, wrote:
The version of qemu-xen that was tagged with 4.6 had been through
several rounds of RCs, months of osstesting, and even through a slew of
>>> On 15.06.16 at 12:26, wrote:
The title of this was (of course) meant to be
x86/time: adjust local system time initialization
Jan
> Using the bare return value from read_platform_stime() is not suitable
> when local_time_calibration() is going to use its fast path: Divergence
> of several d
On 15/06/16 11:24, Stefano Stabellini wrote:
> On Tue, 14 Jun 2016, George Dunlap wrote:
>> On 14/06/16 11:01, Stefano Stabellini wrote:
>>> On Tue, 14 Jun 2016, George Dunlap wrote:
On 14/06/16 10:40, Stefano Stabellini wrote:
> On Mon, 13 Jun 2016, George Dunlap wrote:
>> Point xen,
On Tue, 14 Jun 2016, Anthony PERARD wrote:
> On Tue, Jun 14, 2016 at 11:34:43AM +0100, George Dunlap wrote:
> > On 14/06/16 11:31, Stefano Stabellini wrote:
> > > On Tue, 14 Jun 2016, George Dunlap wrote:
> > >> On 14/06/16 11:08, Stefano Stabellini wrote:
> > >>> On Tue, 14 Jun 2016, George Dunlap
On 15/06/16 11:39, Stefano Stabellini wrote:
> On Tue, 14 Jun 2016, Anthony PERARD wrote:
>> On Tue, Jun 14, 2016 at 11:34:43AM +0100, George Dunlap wrote:
>>> On 14/06/16 11:31, Stefano Stabellini wrote:
On Tue, 14 Jun 2016, George Dunlap wrote:
> On 14/06/16 11:08, Stefano Stabellini wro
>>> On 15.06.16 at 12:30, wrote:
> On 15/06/16 11:25, Jan Beulich wrote:
> On 15.06.16 at 12:13, wrote:
>>> On 15/06/16 11:04, Jan Beulich wrote:
>>> On 15.06.16 at 11:35, wrote:
> The version of qemu-xen that was tagged with 4.6 had been through
> several rounds of RCs, months o
In reply to -
http://lists.xen.org/archives/html/xen-devel/2016-06/msg00622.html
HI, I am working with Jurgen on the issue, as per Jan's request I tried to
write explicitly only latency timer to be written -
bool force_write = false;
if ((dev_data->permissive || xen_pcibk_permissive) &&
On Wed, 15 Jun 2016, George Dunlap wrote:
> On 15/06/16 11:24, Stefano Stabellini wrote:
> > On Tue, 14 Jun 2016, George Dunlap wrote:
> >> On 14/06/16 11:01, Stefano Stabellini wrote:
> >>> On Tue, 14 Jun 2016, George Dunlap wrote:
> On 14/06/16 10:40, Stefano Stabellini wrote:
> > On Mon
flight 95693 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95693/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 94748
test-amd64-amd64-
On 15/06/16 08:55, Jan Beulich wrote:
>>> @@ -570,6 +600,15 @@ void fatal_trap(const struct cpu_user_re
>>> printk("Faulting linear address: %p\n", _p(cr2));
>>> show_page_walk(cr2);
>>> }
>>> +else if ( trapnr == TRAP_nmi )
>>> +{
>>> +
On 6/14/2016 6:04 PM, Jan Beulich wrote:
On 19.05.16 at 11:05, wrote:
@@ -5507,6 +5507,8 @@ long do_hvm_op(unsigned long op,
XEN_GUEST_HANDLE_PARAM(void) arg)
get_gfn_query_unlocked(d, a.pfn, &t);
if ( p2m_is_mmio(t) )
a.mem_type = HVMMEM_mmio_dm
On 6/14/2016 6:45 PM, Jan Beulich wrote:
On 19.05.16 at 11:05, wrote:
A new HVMOP - HVMOP_map_mem_type_to_ioreq_server, is added to
let one ioreq server claim/disclaim its responsibility for the
handling of guest pages with p2m type p2m_ioreq_server. Users
of this HVMOP can specify which kind
Store xldevd.pid under XEN_RUN_DIR. Note that this will change the
default location from /var/run to /var/run/xen.
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
Cc: Roger Pau Monné
---
tools/hotplug/NetBSD/rc.d/xendriverdomain.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
Store xldevd.pid under XEN_RUN_DIR. Note that the default location would
change from /var/run to /var/run/xen.
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
Cc: Roger Pau Monné
---
tools/hotplug/FreeBSD/rc.d/xendriverdomain.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/to
Store various PID files under XEN_RUN_DIR. Note that this change the
default location from /var/run to /var/run/xen.
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
Cc: Roger Pau Monné
---
tools/hotplug/Linux/init.d/xencommons.in | 6 +++---
tools/hotplug/Linux/init.d/xendriverdomain.in | 2 +-
Place the PID file under XEN_RUN_DIR by default. Note this change the
default location from /var/run to /var/run/xen.
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
---
tools/console/daemon/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/console/daemon/main.c b/tool
On 15/06/16 11:53, Stefano Stabellini wrote:
> On Wed, 15 Jun 2016, George Dunlap wrote:
>> On 15/06/16 11:24, Stefano Stabellini wrote:
>>> On Tue, 14 Jun 2016, George Dunlap wrote:
On 14/06/16 11:01, Stefano Stabellini wrote:
> On Tue, 14 Jun 2016, George Dunlap wrote:
>> On 14/06/16
This series deals with hard-coded /var/run in code.
Wei Liu (7):
xenconsoled: honour XEN_RUN_DIR
tools/helper: honour XEN_RUN_DIR in init-xenstore-domain.c
hotplug/FreeBSD: honour XEN_RUN_DIR
hotplug/NetBSD: honour XEN_RUN_DIR
hotplug/Linux: honour XEN_RUN_DIR
libxenstat: honour XEN_RU
Move default the pid file under XEN_RUN_DIR. Note that it changes the
location from /var/run to /var/run/xen.
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
Cc: Dave Scott
---
tools/ocaml/xenstored/xenstored.ml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/ocaml/xenstor
This is because libxl uses XEN_RUN_DIR to generate the socket path for
libxenstat while libxenstat itself uses hard-coded path, which is not
necessary in sync with libxl.
Generate a _paths.h because it is required to make this change work.
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
---
.gitign
Place the PID file under XEN_RUN_DIR. Note that this change the default
location from /var/run to /var/run/xen.
Generate a _paths.h as that is required to make this change work.
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
---
.gitignore | 1 +
tools/helpers/Makefile
On 06/04/16 16:17, Juergen Gross wrote:
Add generic virtualization support for pinning the current vcpu to a
specified physical cpu. As this operation isn't performance critical
(a very limited set of operations like BIOS calls and SMIs is expected
to need this) just add a hypervisor specific ind
On 06/04/16 16:17, Juergen Gross wrote:
Use smp_call_on_cpu() to raise SMI on cpu 0.
Make call secure by adding get_online_cpus() to avoid e.g. suspend
resume cycles in between.
Signed-off-by: Juergen Gross
Could please some maintainer comment on this patch?
Juergen
---
V4: add call to ge
On 15/06/16 11:21, Jan Beulich wrote:
>> I think you've tripped over "changing coding styles" in unfamiliar code
>> before too, so you know how frustrating it is to try to follow the
>> existing coding style only to be told that you did it wrong. :-)
>
> Agreed, you caught me on this one. Albeit w
flight 95718 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95718/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-migrupgrade 3 host-install/src_host(3) broken in 95645 pass
in 95718
test-amd64-amd64-xl-qem
In order to support reading another vcpu's mapped vcpu_runstate_info
an indicator for an occurring update of the runstate information is
needed.
Add the possibility to activate setting this indicator in the highest
bit of state_entry_time via a vm_assist hypercall. When activated the
update indica
Up to now the vm_assist hypercall hasn't been supported on ARM, as
there are only x86 specific features to switch. Add support of
vm_assist on ARM for future use.
Signed-off-by: Juergen Gross
Reviewed-by: Julien Grall
---
V2: readded the #ifdef's as requested by Jan Beulich
---
xen/arch/arm/tra
A guest mapping vcpu_runstate_info into its memory can't read this
information from another cpu but the one the data is referring to.
Reason is there is no reliable way for the guest to detect a concurrent
data update by the hypervisor.
This patch series adds an update flag to the mapped data whic
On 15/06/16 11:46, Jan Beulich wrote:
On 15.06.16 at 12:30, wrote:
>> On 15/06/16 11:25, Jan Beulich wrote:
>> On 15.06.16 at 12:13, wrote:
On 15/06/16 11:04, Jan Beulich wrote:
On 15.06.16 at 11:35, wrote:
>> The version of qemu-xen that was tagged with 4.6 had been t
On Tue, Jun 14, 2016 at 12:32:19PM +0200, Andrea Genuise wrote:
[...]
> libxl: debug: libxl_aoutils.c:88:xswait_timeout_callback: backend
> /local/domain/748/backend/vtpm/749/0/state (hoping for state change to 6):
> xswait timeout (path=/local/domain/748/backend/vtpm/749/0/state)
> libxl: debug: l
Wednesday, June 15, 2016, 12:12:37 PM, you wrote:
On 15.06.16 at 11:38, wrote:
>> Wednesday, June 15, 2016, 10:57:03 AM, you wrote:
>>
>>> Wednesday, June 15, 2016, 10:29:37 AM, you wrote:
>>
>>> On 15.06.16 at 01:49, wrote:
> Just tested latest xen-unstable 4.8 (xen_changeset gi
>>> On 15.06.16 at 12:52, wrote:
> On 6/14/2016 6:45 PM, Jan Beulich wrote:
> On 19.05.16 at 11:05, wrote:
>>> A new HVMOP - HVMOP_map_mem_type_to_ioreq_server, is added to
>>> let one ioreq server claim/disclaim its responsibility for the
>>> handling of guest pages with p2m type p2m_ioreq_s
>>> On 15.06.16 at 14:00, wrote:
> Wednesday, June 15, 2016, 12:12:37 PM, you wrote:
> On 15.06.16 at 11:38, wrote:
>>> Wednesday, June 15, 2016, 10:57:03 AM, you wrote:
Wednesday, June 15, 2016, 10:29:37 AM, you wrote:
On 15.06.16 at 01:49, wrote:
>> Just tested latest xen
>>> On 15.06.16 at 13:03, wrote:
> On 15/06/16 08:55, Jan Beulich wrote:
@@ -570,6 +600,15 @@ void fatal_trap(const struct cpu_user_re
printk("Faulting linear address: %p\n", _p(cr2));
show_page_walk(cr2);
}
+else if ( trapnr == T
Initialise j to 0 to make some versions of gcc (e.g., gcc4.5/4.3) happy to
avoid compilation error by commit beba3693f7243e68bbe31fe3794da91068eeea5b.
Signed-off-by: Dongli Zhang
---
tools/misc/xen-livepatch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/misc/xen-liv
>>> On 15.06.16 at 12:45, wrote:
> In reply to -
> http://lists.xen.org/archives/html/xen-devel/2016-06/msg00622.html
>
> HI, I am working with Jurgen on the issue, as per Jan's request I tried to
> write explicitly only latency timer to be written -
> bool force_write = false;
> if ((dev_data->
On 15/06/16 13:59, Jan Beulich wrote:
On 15.06.16 at 13:03, wrote:
>> On 15/06/16 08:55, Jan Beulich wrote:
> @@ -570,6 +600,15 @@ void fatal_trap(const struct cpu_user_re
> printk("Faulting linear address: %p\n", _p(cr2));
> show_page_walk(cr2);
>
Hi,
after installing xen 4.7, the output of xl list is empty and
dom0 is not found. what could be the problem ?
The dmesg content is attached.
Xen 4.7.0-rc
(XEN) Xen version 4.7.0-rc (root@) (gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4)
debug=y Wed Jun 15 17:30:18 IRDT 2016
(XEN) Latest ChangeSet:
Drop xen-devel to BCC, add xen-users
This question is more suitable for xen-users.
On Wed, Jun 15, 2016 at 05:45:52PM +0430, sepanta s wrote:
> Hi,
>
> after installing xen 4.7, the output of xl list is empty and
> dom0 is not found. what could be the problem ?
> The dmesg content is attached.
On Wed, 2016-06-15 at 10:31 +0100, Wei Liu wrote:
> Factor out the logic to determine device model version to a function.
> It
> will be used later. Note that code now also checks if the stbudom
> field
> is actually set before trying to extract a value from it.
>
> No functional change.
>
> Sign
On Wed, 2016-06-15 at 10:31 +0100, Wei Liu wrote:
> This function is used to return the memory needed for a guest. It's
> not
> in a position to modify the b_info passed in (note the _setdefault
> function).
>
> Use a copy of b_info to do the calculation. Define a macro to mark
> the
> change in A
On Wed, 2016-06-15 at 10:31 +0100, Wei Liu wrote:
> It interrogates QEMU for CPUs and update the bitmap accordingly.
>
> Signed-off-by: Wei Liu
> ---
> Cc: Ian Jackson
> Cc: Anthony PERARD
>
Reviewed-by: Dario Faggioli
Regards,
Dario
--
<> (Raistlin Majere)
-
On Wed, Jun 15, 2016 at 03:31:46PM +0200, Dario Faggioli wrote:
> On Wed, 2016-06-15 at 10:31 +0100, Wei Liu wrote:
> > This function is used to return the memory needed for a guest. It's
> > not
> > in a position to modify the b_info passed in (note the _setdefault
> > function).
> >
> > Use a co
Xen will crash on platform where GICv2m is not available with the
following error:
(XEN) Can't find ranges property for the gic node
(XEN) Device tree generation failed (-15).
(XEN)
(XEN)
(XEN) Panic on CPU 0:
(XEN) Could not set up DOM0 guest OS
(XEN)
Wednesday, June 15, 2016, 2:48:55 PM, you wrote:
On 15.06.16 at 14:00, wrote:
>> Wednesday, June 15, 2016, 12:12:37 PM, you wrote:
>> On 15.06.16 at 11:38, wrote:
Wednesday, June 15, 2016, 10:57:03 AM, you wrote:
> Wednesday, June 15, 2016, 10:29:37 AM, you wrote:
> On
1 - 100 of 172 matches
Mail list logo
