Hi,
Would anyone please help with a question on xen-netfront.c code?
In xen-netfront.c, the return value of gnttab_claim_grant_reference() is
checked with "BUG_ON((signed short)ref < 0);". Why we use signed short here
while the return value is of uint32_t?
Am I missing anything or can I send a
flight 101716 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101716/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101690
test-amd64-amd64-xl-qemuu-win7-a
This run is configured for baseline tests only.
flight 67943 linux-3.18 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67943/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/
This is to fix some lock holder preemption issues. Some other locks
implementation do a spin loop before acquiring the lock itself.
Currently kernel has an interface of bool vcpu_is_preempted(int cpu). It
takes the cpu as parameter and return true if the cpu is preempted. Then
kernel can break the
Support the vcpu_is_preempted() functionality under KVM. This will
enhance lock performance on overcommitted hosts (more runnable vcpus
than physical cpus in the system) as doing busy waits for preempted
vcpus will hurt system performance far worse than early yielding.
Use one field of struct kvm_
This is to fix some lock holder preemption issues. Some other locks
implementation do a spin loop before acquiring the lock itself.
Currently kernel has an interface of bool vcpu_is_preempted(int cpu). It
takes the cpu as parameter and return true if the cpu is preempted.
Then kernel can break the
change from v5:
spilt x86/kvm patch into guest/host part.
introduce kvm_write_guest_offset_cached.
fix some typos.
rebase patch onto 4.9.2
change from v4:
spilt x86 kvm vcpu preempted check into two patches.
add documentation patch.
add x86 vc
This patch support to fix lock holder preemption issue.
For kernel users, we could use bool vcpu_is_preempted(int cpu) to detech if
one vcpu is preempted or not.
The default implementation is a macro defined by false. So compiler can
wrap it out if arch dose not support such vcpu pteempted check.
Commit ("x86, kvm: support vcpu preempted check") add one field "__u8
preempted" into struct kvm_steal_time. This field tells if one vcpu is
running or not.
It is zero if 1) some old KVM deos not support this filed. 2) the vcpu is
not preempted. Other values means the vcpu has been preempted.
Sig
From: Juergen Gross
Support the vcpu_is_preempted() functionality under Xen. This will
enhance lock performance on overcommitted hosts (more runnable vcpus
than physical cpus in the system) as doing busy waits for preempted
vcpus will hurt system performance far worse than early yielding.
A quic
Support the vcpu_is_preempted() functionality under KVM. This will
enhance lock performance on overcommitted hosts (more runnable vcpus
than physical cpus in the system) as doing busy waits for preempted
vcpus will hurt system performance far worse than early yielding.
struct kvm_steal_time::preem
It allows us to update some status or field of one struct partially.
We can also save one kvm_read_guest_cached if we just update one filed
of the struct regardless of its current value.
Signed-off-by: Pan Xinhui
---
include/linux/kvm_host.h | 2 ++
virt/kvm/kvm_main.c | 20 ++
From: Christian Borntraeger
this implements the s390 backend for commit
"kernel/sched: introduce vcpu preempted check interface"
by reworking the existing smp_vcpu_scheduled into
arch_vcpu_is_preempted. We can then also get rid of the
local cpu_is_preempted function by moving the
CIF_ENABLED_WAIT
An over-committed guest with more vCPUs than pCPUs has a heavy overload in
the two spin_on_owner. This blames on the lock holder preemption issue.
Kernel has an interface bool vcpu_is_preempted(int cpu) to see if a vCPU is
currently running or not. So break the spin loops on true condition.
test-
An over-committed guest with more vCPUs than pCPUs has a heavy overload in
osq_lock().
This is because vCPU A hold the osq lock and yield out, vCPU B wait per_cpu
node->locked to be set. IOW, vCPU B wait vCPU A to run and unlock the osq
lock.
Kernel has an interface bool vcpu_is_preempted(int cpu
flight 101715 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101715/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail REGR. vs. 101401
test-armhf-armhf-lib
Hello,
I've been trying to set COLO replication to work but i'm stuck on a problem
when migrating de primary VM to secondary host.
I have been following the instructions from this wiki
- http://wiki.xenproject.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping
and this mail thread
-
http://xen.markma
This run is configured for baseline tests only.
flight 67944 seabios real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67944/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-i
Use type-safe structure assignment instead of memcpy()
Use sizeof(*iremap_entry). Besides that, this patch also
handle another cleanup, in msi_msg_to_remap_entry() we don't
need to copy all the content of old IRTE to the new IRE, we
only need to save the 'IM' field to 'new_ire' if the entry
is pres
We may hit the last ASSERT() in vmx_vcpu_block in the current code,
since vmx_vcpu_block() may get called before vmx_pi_switch_to()
has been installed or executed. Here We use cmpxchg to update
the NDST field, this can make sure we only update the NDST when
vmx_pi_switch_to() has not been called. S
We don't set the affinity for posted format IRTE, since the
destination of these interrupts is vCPU and the vCPU affinity
is set during vCPU scheduling.
Signed-off-by: Feng Wu
---
v6:
- Make pi_can_suppress_irte_update() a check-only function
- Introduce another function pi_get_new_irte() to upda
PI hook vmx_pi_switch_to() is needed even when any previously
assigned device is detached from the domain. Since 'SN' bit is
also used to control the CPU side PI and we change the state of
SN bit in these two functions, then evaluate this bit in
vmx_deliver_posted_intr() when trying to deliver the
This patch handles some corner cases when the last assigned device
is removed from the domain. In this case we should carefully handle
pi descriptor and the per-cpu blocking list, to make sure:
- all the PI descriptor are in the right state when next time a
devices is assigned to the domain again.
We should remove the vCPU from the per-cpu blocking list
if it is going to be destroyed.
Signed-off-by: Feng Wu
---
v6:
- Use vmx_pi_unblock_vcpu() instead of vmx_pi_list_remove()
v5:
- Use vmx_pi_list_remove() instead of vmx_pi_list_cleanup()
v4:
- Call vmx_pi_list_cleanup() before vmx_destroy
The current VT-d PI related code may operate incorrectly in the
following scenarios:
1. When the last assigned device is dettached from the domain, all
the PI related hooks are removed then, however, the vCPU can be
blocked, switched to another pCPU, etc, all without the aware of
PI. After the next
When cpu is offline, we need to move all the vcpus in its blocking
list to another online cpu, this patch handles it.
Signed-off-by: Feng Wu
---
v6:
- Carefully suppress 'SN' to avoid missing notification event
during moving the vcpu to the new list
v5:
- Add some comments to explain why it does
On Wed, 28 Sep 2016, Andre Przywara wrote:
> Upon receiving an LPI, we need to find the right VCPU and virtual IRQ
> number to get this IRQ injected.
> Iterate our two-level LPI table to find this information quickly when
> the host takes an LPI. Call the existing injection function to let the
> GI
On Wed, 28 Sep 2016, Andre Przywara wrote:
> For the same reason that allocating a struct irq_desc for each
> possible LPI is not an option, having a struct pending_irq for each LPI
> is also not feasible. However we actually only need those when an
> interrupt is on a vCPU (or is about to be injec
flight 101718 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101718/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 322819a7a9bdee04a7d0a0168550293ab139d8fd
baseline version:
xtf a78dbe70cd6ea14a02a524
On Wed, 28 Sep 2016, Andre Przywara wrote:
> The ITS uses device IDs to map LPIs to a device. Dom0 will later use
> those IDs, which we directly pass on to the host.
> For this we have to map each device that Dom0 may request to a host
> ITS device with the same identifier.
> Allocate the respectiv
On Wed, 28 Sep 2016, Andre Przywara wrote:
> The number of LPIs on a host can be potentially huge (millions),
> although in practise will be mostly reasonable. So prematurely allocating
> an array of struct irq_desc's for each LPI is not an option.
> However Xen itself does not care about LPIs, as
flight 101707 linux-3.10 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101707/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm6 xen-boot fail REGR. vs. 100648
test-amd64-amd64-amd
This run is configured for baseline tests only.
flight 67942 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67942/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xtf 3 host-install
- On 27 Oct, 2016, at 09:53, Wei Liu wei.l...@citrix.com wrote:
> For the second part, xenstored.pid normally would be stored under
> /var/run, which should be cleared whenever the system is booted [0].
I know but the /var/run/xenstored.pid stays but anyway
RC4 is not so stable - I have r
On Wed, 26 Oct 2016, Stefano Stabellini wrote:
> > +/* ITS command definitions */
> > +#define ITS_CMD_SIZE32
> > +
> > +#define GITS_CMD_MOVI 0x01
> > +#define GITS_CMD_INT0x03
> > +#define GITS_CMD_CLEAR 0x04
> > +#define
flight 101711 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101711/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw 14 guest-start/debian.repeat fail REGR. vs. 101677
Regressions which are
flight 101710 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101710/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0a18956d54cfe70b736b029c62ce53f29b903745
baseline version:
ovmf 4e908975c645bedd40ac7
flight 101703 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101703/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt-xsm 15 guest-start/debian.repeat fail in 101676 pass
in 101703
test-armhf-armhf-xl-r
On Thu, 27 Oct 2016, Sander Eikelenboom wrote:
> Thursday, October 27, 2016, 3:51:09 PM, you wrote:
>
> > Xen's toolstack is in charge of building ACPI tables. Skip ACPI table
> > building and loading in QEMU by setting has_acpi_build to false for
> > xenfv machine.
>
> > This issue is discovered
flight 101698 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101698/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-5 44 xtf/test-hvm64-xsa-186 fail REGR. vs. 101673
test-amd64-i386-xl
flight 101722 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101722/
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 1
On 10/27/2016 11:00 AM, Andrew Cooper wrote:
On 27/10/16 15:25, Boris Ostrovsky wrote:
On 10/14/2016 03:01 PM, Boris Ostrovsky wrote:
On 10/14/2016 02:41 PM, Andrew Cooper wrote:
On 14/10/16 19:05, Boris Ostrovsky wrote:
PVH guests don't receive ACPI hotplug interrupts and therefore
need
>>> On 25.08.16 at 21:23, wrote:
> This implements a lockless per-cpu tasklet mechanism.
How does this correlate with the title? IOW, how is this new form of
tasklets "for" softirq? Perhaps part of the sentence above would be
a better fit for the title?
> The existing tasklet mechanism has a sin
On Thu, Oct 27, 2016 at 09:20:00AM -0600, Jan Beulich wrote:
> >>> On 27.10.16 at 17:04, wrote:
> > I prefer this solution because it seems simpler and less likely to cause
> > future issues, but if this seems like too much fuss I can always try to
> > place the RSDP on top of the original one a
On 27/10/16 17:00, Juergen Gross wrote:
> On 27/10/16 15:56, Jan Beulich wrote:
> On 27.10.16 at 11:55, wrote:
>>> + /* Offset behind list: just return a list with an empty string. */
>>> + if (off >= node->childlen) {
>>
>> Is it perhaps worth separating the == and > cases? The former is
On Thu, 2016-10-27 at 16:01 +0100, George Dunlap wrote:
> On 25/10/16 09:18, Dario Faggioli wrote:
> > All this being said, what's the next step? Is there anything more I
> > should do, here in this thread? Should we wait for other people to
> > weigh in? Should I resend this patch, with a non empt
>>> On 27.10.16 at 17:04, wrote:
> I prefer this solution because it seems simpler and less likely to cause
> future issues, but if this seems like too much fuss I can always try to
> place the RSDP on top of the original one and shadow that page. From the
> information I've been able to find o
On Thu, Oct 27, 2016 at 10:40:52AM -0400, Boris Ostrovsky wrote:
>
>
> On 10/27/2016 10:30 AM, Jan Beulich wrote:
> > > > > On 27.10.16 at 16:15, wrote:
> > > On 10/27/2016 10:02 AM, Jan Beulich wrote:
> > > > > > > On 27.10.16 at 15:51, wrote:
> > > > > I re-read this thread and I am not sure
c/s 5eeca68f introduced the 64bit ABI for HVM guests, and chose to explicitly
truncate the index, despite the fact that the `mov $imm32, %eax` in the
hypercall page already provides the expected truncation.
The truncation isn't very obvious, and is counterintuitive, seeing as all
other 64bit param
On 25/10/16 09:18, Dario Faggioli wrote:
> On Fri, 2016-10-14 at 11:42 +0100, George Dunlap wrote:
>> On 14/10/16 11:17, Dario Faggioli wrote:
>>>
>>> Signed-off-by: Dario Faggioli
>>
>> We don't have a general framework for declaring things "supported"
>> yet,
>> and at the moment we only have a
On 27/10/16 15:25, Boris Ostrovsky wrote:
>
>
> On 10/14/2016 03:01 PM, Boris Ostrovsky wrote:
>> On 10/14/2016 02:41 PM, Andrew Cooper wrote:
>>> On 14/10/16 19:05, Boris Ostrovsky wrote:
PVH guests don't receive ACPI hotplug interrupts and therefore
need to monitor xenstore for CPU hotp
On 27/10/16 15:56, Jan Beulich wrote:
On 27.10.16 at 11:55, wrote:
>> +static void send_directory_part(struct connection *conn,
>> +struct buffered_data *in)
>> +{
>> +unsigned int off, len, maxlen, genlen;
>> +char *name, *child, *data;
>> +struct node
Thursday, October 27, 2016, 3:51:09 PM, you wrote:
> Xen's toolstack is in charge of building ACPI tables. Skip ACPI table
> building and loading in QEMU by setting has_acpi_build to false for
> xenfv machine.
> This issue is discovered due to direct kernel boot on Xen doesn't boot
> anymore, be
On Wed, Mar 30, 2016 at 05:06:15PM +0200, Daniel Kiper wrote:
> Hi,
>
> This patch series:
> - enables EFI boot services usage in loaded images
> by multiboot2 protocol,
> - add support for multiboot2 protocol compatible
> relocatable images.
FYI, applied...
Daniel
__
On 10/27/2016 10:30 AM, Jan Beulich wrote:
On 27.10.16 at 16:15, wrote:
On 10/27/2016 10:02 AM, Jan Beulich wrote:
On 27.10.16 at 15:51, wrote:
I re-read this thread and I am not sure I understand why we can't keep
host's RSDP descriptor. We are not mapping dom0 memory 1:1 (right?) so
we c
>>> On 27.10.16 at 16:15, wrote:
> On 10/27/2016 10:02 AM, Jan Beulich wrote:
> On 27.10.16 at 15:51, wrote:
>>> I re-read this thread and I am not sure I understand why we can't keep
>>> host's RSDP descriptor. We are not mapping dom0 memory 1:1 (right?) so
>>> we can place our versions of R
Hi Juergen,
On Mon, Oct 17, 2016 at 08:52:58AM +0200, Daniel Kiper wrote:
> On Tue, Oct 11, 2016 at 04:00:58PM +0200, Juergen Gross wrote:
> > On 04/07/16 12:53, Daniel Kiper wrote:
> > > On Mon, Jul 04, 2016 at 12:33:17PM +0200, Juergen Gross wrote:
> > >> On 12/05/16 07:35, Juergen Gross wrote:
Hi,
I have used xen on Ubuntu platform and have run different linux distro as
guest OS.
Now I am trying to port xen on Qualcomm 410 platform, so before I begin,
just wanted to know that is it possible to port xen on Qualcomm platform?
I have seen this post
https://lists.xenproject.org/archives/h
On 10/14/2016 03:01 PM, Boris Ostrovsky wrote:
On 10/14/2016 02:41 PM, Andrew Cooper wrote:
On 14/10/16 19:05, Boris Ostrovsky wrote:
PVH guests don't receive ACPI hotplug interrupts and therefore
need to monitor xenstore for CPU hotplug event.
Why not? If they don't, they should. As we ar
On 10/27/2016 10:02 AM, Jan Beulich wrote:
On 27.10.16 at 15:51, wrote:
I re-read this thread and I am not sure I understand why we can't keep
host's RSDP descriptor. We are not mapping dom0 memory 1:1 (right?) so
we can place our versions of RSDT/XSDT at the address that the
descriptor point
flight 101695 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101695/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 6 xen-boot fail REGR. vs. 92983
test-amd64-i386-xl-qe
On Thu, 27 Oct 2016 14:51:09 +0100
Wei Liu wrote:
> Xen's toolstack is in charge of building ACPI tables. Skip ACPI table
> building and loading in QEMU by setting has_acpi_build to false for
> xenfv machine.
>
> This issue is discovered due to direct kernel boot on Xen doesn't boot
> anymore, b
>>> On 27.10.16 at 15:51, wrote:
> I re-read this thread and I am not sure I understand why we can't keep
> host's RSDP descriptor. We are not mapping dom0 memory 1:1 (right?) so
> we can place our versions of RSDT/XSDT at the address that the
> descriptor points to.
>
> Unless that address is
On Wed, 2016-10-26 at 19:47 +0100, Juergen Schinker wrote:
> * Hardware:
> Intel(R) Xeon(R) CPU E3-1220L V2 @ 2.30GHz
> Sandisk SSD
> 32G Ram
> * Software:
>
> Debian Stretch/testing is dom0
>
> * Guest operating systems:
>
> Guests Ubuntu 14.04 LTS Debian Stretch/Sid
>
> Ubuntu 16.10 yaki
>>> On 27.10.16 at 11:55, wrote:
> +static void send_directory_part(struct connection *conn,
> + struct buffered_data *in)
> +{
> + unsigned int off, len, maxlen, genlen;
> + char *name, *child, *data;
> + struct node *node;
> + char gen[24];
> +
> +
Xen's toolstack is in charge of building ACPI tables. Skip ACPI table
building and loading in QEMU by setting has_acpi_build to false for
xenfv machine.
This issue is discovered due to direct kernel boot on Xen doesn't boot
anymore, because the new ACPI tables cause the guest to exceed its
memory
On 10/27/2016 07:13 AM, Roger Pau Monne wrote:
On Wed, Oct 26, 2016 at 01:14:16PM -0400, Boris Ostrovsky wrote:
I've initially used a back-listing approach. We can always change this later
on.
So I've ended up crafting a new MADT, XSDT and RSDP. Note that I'm not
crafting a new custom RSDT
Sorry, I accidentally sent out the previous email...
On Thu, Oct 27, 2016 at 6:03 AM, Wei Liu wrote:
> On Thu, Oct 27, 2016 at 11:14:36AM +0200, Dario Faggioli wrote:
>> On Wed, 2016-10-26 at 15:06 -0400, Meng Xu wrote:
>> > We keep last_start updated whenever cur_budget is updated.
>> > This avo
On Thu, Oct 27, 2016 at 09:42:56AM -0400, Meng Xu wrote:
> Sorry, I accidentally sent out the previous email...
>
> On Thu, Oct 27, 2016 at 6:03 AM, Wei Liu wrote:
> > On Thu, Oct 27, 2016 at 11:14:36AM +0200, Dario Faggioli wrote:
> >> On Wed, 2016-10-26 at 15:06 -0400, Meng Xu wrote:
> >> > We
Hi Wei and Dario,
On Thu, Oct 27, 2016 at 6:03 AM, Wei Liu wrote:
> On Thu, Oct 27, 2016 at 11:14:36AM +0200, Dario Faggioli wrote:
>> On Wed, 2016-10-26 at 15:06 -0400, Meng Xu wrote:
>> > We keep last_start updated whenever cur_budget is updated.
>> > This avoids subtle bugs in case burn_budge
>>> On 27.10.16 at 14:55, wrote:
> On 27/10/16 08:12, Jan Beulich wrote:
> On 26.10.16 at 20:19, wrote:
>>> On 24/10/16 12:13, Jan Beulich wrote:
>>> On 24.10.16 at 12:25, wrote:
> Yes we very much are at liberty to change things. Viridian would not
> function without using that
flight 101717 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101717/
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 1
On Thu, 27 Oct 2016 12:29:58 +0100
Wei Liu wrote:
> On Thu, Oct 27, 2016 at 01:26:49PM +0200, Igor Mammedov wrote:
> > On Thu, 27 Oct 2016 12:10:58 +0100
> > Wei Liu wrote:
> >
> > > On Thu, Oct 27, 2016 at 12:03:42PM +0100, Wei Liu wrote:
> > > > Cc Sander
> > > >
> > > > On Thu, Oct 27,
flight 67941 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67941/
Perfect :-)
All tests in this flight passed as required
baseline version:
flight 67913
jobs:
build-amd64 pass
build-armh
On 27/10/16 08:12, Jan Beulich wrote:
On 26.10.16 at 20:19, wrote:
>> On 24/10/16 12:13, Jan Beulich wrote:
>> On 24.10.16 at 12:25, wrote:
Yes we very much are at liberty to change things. Viridian would not
function without using that page (as the hypercalls would be confuse
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 27 October 2016 12:38
> To: xen-devel
> Cc: Paul Durrant
> Subject: purpose of struct buf_ioreq's dir field
>
> Hello,
>
> can anyone shed some light on the purpose of that field? Since
> buffered ioreq-s by the
Hello,
can anyone shed some light on the purpose of that field? Since
buffered ioreq-s by their nature don't have any response, I don't
see what good they can be for when not doing writes.
Thanks, Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
On Thu, Oct 27, 2016 at 01:26:49PM +0200, Igor Mammedov wrote:
> On Thu, 27 Oct 2016 12:10:58 +0100
> Wei Liu wrote:
>
> > On Thu, Oct 27, 2016 at 12:03:42PM +0100, Wei Liu wrote:
> > > Cc Sander
> > >
> > > On Thu, Oct 27, 2016 at 12:54:02PM +0200, Igor Mammedov wrote:
> > > > On Wed, 26 Oct
On Thu, 27 Oct 2016 12:10:58 +0100
Wei Liu wrote:
> On Thu, Oct 27, 2016 at 12:03:42PM +0100, Wei Liu wrote:
> > Cc Sander
> >
> > On Thu, Oct 27, 2016 at 12:54:02PM +0200, Igor Mammedov wrote:
> > > On Wed, 26 Oct 2016 16:22:34 +0100
> > > Wei Liu wrote:
> > >
> > > > On Wed, Oct 26, 2016
>>> On 27.10.16 at 13:13, wrote:
> On Wed, Oct 26, 2016 at 01:14:16PM -0400, Boris Ostrovsky wrote:
>> I've initially used a back-listing approach. We can always change this
>> later
>> on.
>>
>> So I've ended up crafting a new MADT, XSDT and RSDP. Note that I'm not
>>
On Wed, 26 Oct 2016 16:22:34 +0100
Wei Liu wrote:
> On Wed, Oct 26, 2016 at 05:09:52PM +0200, Igor Mammedov wrote:
> > On Tue, 25 Oct 2016 18:28:04 +0100
> > Wei Liu wrote:
> >
> > > Xen's toolstack is in charge of building ACPI tables. Skip acpi table
> > > building if running on Xen.
> > >
On Wed, Oct 26, 2016 at 01:14:16PM -0400, Boris Ostrovsky wrote:
>
> I've initially used a back-listing approach. We can always change this
> later
> on.
>
> So I've ended up crafting a new MADT, XSDT and RSDP. Note that I'm not
> crafting a new custom RSDT (and in
On Thu, Oct 27, 2016 at 12:03:42PM +0100, Wei Liu wrote:
> Cc Sander
>
> On Thu, Oct 27, 2016 at 12:54:02PM +0200, Igor Mammedov wrote:
> > On Wed, 26 Oct 2016 16:22:34 +0100
> > Wei Liu wrote:
> >
> > > On Wed, Oct 26, 2016 at 05:09:52PM +0200, Igor Mammedov wrote:
> > > > On Tue, 25 Oct 2016 1
On Thu, Oct 27, 2016 at 01:25:40AM -0600, Jan Beulich wrote:
> >>> On 26.10.16 at 18:03, wrote:
> > On Wed, Oct 26, 2016 at 09:16:55AM -0600, Jan Beulich wrote:
> >> >>> On 26.10.16 at 17:08, wrote:
> >> > On Wed, Oct 26, 2016 at 08:10:50AM -0600, Jan Beulich wrote:
> >> >> >>> On 26.10.16 at 13:
Cc Sander
On Thu, Oct 27, 2016 at 12:54:02PM +0200, Igor Mammedov wrote:
> On Wed, 26 Oct 2016 16:22:34 +0100
> Wei Liu wrote:
>
> > On Wed, Oct 26, 2016 at 05:09:52PM +0200, Igor Mammedov wrote:
> > > On Tue, 25 Oct 2016 18:28:04 +0100
> > > Wei Liu wrote:
> > >
> > > > Xen's toolstack is i
On Wed, 26 Oct 2016 16:22:34 +0100
Wei Liu wrote:
> On Wed, Oct 26, 2016 at 05:09:52PM +0200, Igor Mammedov wrote:
> > On Tue, 25 Oct 2016 18:28:04 +0100
> > Wei Liu wrote:
> >
> > > Xen's toolstack is in charge of building ACPI tables. Skip acpi table
> > > building if running on Xen.
> > >
flight 101690 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101690/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101666
test-amd64-amd64-xl-qemuu-win7-a
flight 101713 xen-4.7-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/101713/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-rtds queued
test-amd64-amd64-
flight 101700 linux-3.18 running [real]
http://logs.test-lab.xenproject.org/osstest/logs/101700/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-xsm 2 hosts-allocate running
test-a
flight 101705 xen-4.6-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/101705/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-rtds queued
test-amd64-amd64-
osstest service owner writes ("[linux-3.18 test] 101675: regressions - FAIL"):
> flight 101675 linux-3.18 real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/101675/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-
On 27/10/16 12:15, Wei Liu wrote:
> On Thu, Oct 27, 2016 at 11:55:52AM +0200, Juergen Gross wrote:
>> add_change_node() in xenstored is used to add a modified node to the
>> list of changed nodes of one transaction. It is being called with the
>> recurse parameter set to true when removing a node i
Jan Beulich writes ("Re: [Xen-devel] [xen-4.6-testing test] 101679: regressions
- FAIL"):
> Aren't these the failures you alluded to in an earlier mail would need
> force pushing? If so, same for 4.7 flight 101683?
Indeed they are.
Ian.
___
Xen-devel
osstest service owner writes ("[xen-4.7-testing test] 101683: regressions -
FAIL"):
> flight 101683 xen-4.7-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/101683/
>
> Regressions :-(
...
>
> Tests which did not succeed and are blocking,
> including tests which could not b
osstest service owner writes ("[xen-4.6-testing test] 101679: regressions -
FAIL"):
> flight 101679 xen-4.6-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/101679/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be ru
On Thu, Oct 27, 2016 at 11:55:52AM +0200, Juergen Gross wrote:
> add_change_node() in xenstored is used to add a modified node to the
> list of changed nodes of one transaction. It is being called with the
> recurse parameter set to true when removing a node in order to get
> watches for children o
On Thu, Oct 27, 2016 at 11:14:36AM +0200, Dario Faggioli wrote:
> On Wed, 2016-10-26 at 15:06 -0400, Meng Xu wrote:
> > We keep last_start updated whenever cur_budget is updated.
> > This avoids subtle bugs in case burn_budget() will be called
> > in other places in the future.
> >
> I'd change th
On Thu, Oct 27, 2016 at 10:54:23AM +0200, Dario Faggioli wrote:
> On Wed, 2016-10-26 at 15:06 -0400, Meng Xu wrote:
> > Fix:
> > We keeps last_start always within the current period for a VCPU, so
> > that
> > we only deduct the time spent in the current period from the VCPU
> > budget.
> > We alwa
flight 101687 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101687/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail REGR. vs. 101401
test-armhf-armhf-lib
This will enable all users of libxenstore to handle xenstore nodes
with a huge amount of children.
In order to not depend completely on the XS_DIRECTORY_PART
functionality use it only in case of E2BIG returned by XS_DIRECTORY.
Signed-off-by: Juergen Gross
---
tools/xenstore/xs.c | 80 ++
1 - 100 of 116 matches
Mail list logo
