flight 112691 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112691/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 7 reboot fail REGR. vs. 110515
test-amd64-amd64-xl
flight 112692 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112692/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 112655
test-amd64-i386-li
flight 112693 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112693/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a
build-arm64-libvirt 1 build-check(1)
flight 112705 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112705/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64-pvops 2 hos
On 08/18/2017 05:02 PM, christopher.w.cl...@gmail.com wrote:
From: Christopher Clark
Isolation of devices passed through to domains usually requires an
active IOMMU. The existing method of requiring an IOMMU is via a Xen
boot parameter ("iommu=force") which will abort boot if an IOMMU is not
av
flight 112689 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112689/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-vhd 14 guest-saverestorefail REGR. vs. 110906
test-amd64-i386
From: Christopher Clark
Isolation of devices passed through to domains usually requires an
active IOMMU. The existing method of requiring an IOMMU is via a Xen
boot parameter ("iommu=force") which will abort boot if an IOMMU is not
available.
More graceful degradation of behaviour when an IOMMU
Hi Andrii,
On Tue, Aug 1, 2017 at 4:02 AM, Andrii Anisov wrote:
> Hello Meng Xu,
>
> I've get back to this stuff.
Sorry for the late response. I'm not sure if you have already solved this.
>
>
> On 03.07.17 17:58, Andrii Anisov wrote:
>>
>> That's why we are going to keep configuration (of gues
flight 112703 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112703/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64-pvops 2 hos
This run is configured for baseline tests only.
flight 71992 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71992/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3a424c5f49239b810e08aa23368945a9f0360d4c
baseline v
These routines are first called via CPU_UP_PREPARE notifier by the BSP
and then by the booting ASP from vmx_cpu_up()/_svm_cpu_up().
Avoid the unnecessary second call. Becasue BSP doesn't go through
CPU_UP_PREPARE it is a special case and so we pass 'bsp' flag to
hvm_funcs.cpu_up() to help it decid
On Fri, Aug 18, 2017 at 05:00:18PM +0100, Anthony PERARD wrote:
> > > > >
> > > > > Clean it up after 2.10.
> > > > >
> > >
> > > So is the v2 good enough or do I need to resend it?
> > Do you really need it in 2.10?
> > it's only 2 days left till release so unless it's blocker
> > I'd wait ti
On Fri, Aug 18, 2017 at 04:19:57PM +0200, Igor Mammedov wrote:
> > > >
> > > > Clean it up after 2.10.
> > > >
> >
> > So is the v2 good enough or do I need to resend it?
> Do you really need it in 2.10?
> it's only 2 days left till release so unless it's blocker
> I'd wait till after release
On Thu, Aug 17, 2017 at 5:50 AM, Alexandru Isaila
wrote:
> In some introspection usecases, an in-guest agent needs to communicate
> with the external introspection agent. An existing mechanism is
> HVMOP_guest_request_vm_event, but this is restricted to kernel usecases
> like all other hypercalls
flight 112685 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112685/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-4 48 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 112667
test-amd64-i386
If a CPU has a callback queued, it must be ready to invoke
it, as soon as all the other CPUs involved in the grace period
has gone through a quiescent state.
But if we let such CPU go idle, we can't really tell when (if!)
it will realize that it is actually time to invoke the callback.
To solve th
Hey,
I know, v2 of this series just went out. But since I leave for 2 weeks, I
wanted the version with as much as possible comments addressed to be on the
list, and since it was rather quick to do that (and test it), for latest Tim's
comment, here I am.
So, basically, this is v2, as here:
https
On the CPU where a callback is queued, cpu_is_haltable()
returns false (due to rcu_needs_cpu() being itself false).
That means the CPU would spin inside idle_loop(), continuously
calling do_softirq(), and, in there, continuously checking
rcu_pending(), in a tight loop.
Let's instead allow the CPU
Idea is: the more CPUs are still active in a grace period,
the more we can wait to check whether it's time to invoke
the callbacks (on those CPUs that have already quiesced,
are idle, and have callbacks queued).
What we're trying to avoid is one of those idle CPUs to
wake up, only to discover that
Xen is a tickless (micro-)kernel, i.e., when a CPU becomes
idle there is no timer tick that will periodically wake the
CPU up.
OTOH, when we imported RCU from Linux, Linux was (on x86) a
ticking kernel, i.e., there was a periodic timer tick always
running, even on idle CPUs. This was bad for power
Since commit 964fae8ac ("cpuidle: suspend/resume scheduler
tick timer during cpu idle state entry/exit"), if a scheduler
has a periodic tick timer, we stop it when going idle.
This, however, is only true for x86. Make it true for ARM as
well.
Signed-off-by: Dario Faggioli
Reviewed-by: Stefano St
In fact, right now, we read it at every iteration of the loop.
The reason it's done like this is how context switch was handled
on IA64 (see commit ae9bfcdc, "[XEN] Various softirq cleanups" [1]).
However:
1) we don't have IA64 any longer, and all the achitectures that
we do support, are ok wit
On Fri, Aug 18, 2017 at 10:29:15AM -0400, annie li wrote:
>
> On 8/18/2017 5:14 AM, Roger Pau Monné wrote:
> > On Thu, Aug 17, 2017 at 06:43:46PM -0400, Annie Li wrote:
> > > If there is inflight I/O in any non-last queue, blkback returns -EBUSY
> > > directly, and never stops thread of remaining
This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file". See:
https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg03047.html
Then plan is to use XENMEM_add_to_physmap_batch to map the shared pages from
one domU to another and use XENMEM_remove
On Thu, 2017-08-17 at 14:03 +0100, Tim Deegan wrote:
> At 18:45 +0200 on 16 Aug (1502909149), Dario Faggioli wrote:
> > +
> > +/*
> > + * The CPU is becoming idle, so no more read side critical
> > + * sections, and one more step toward grace period.
> > + */
> > +void rcu_idle_enter(unsigned int c
On 18/08/2017 18:38, Eduardo Habkost wrote:
>>> I think you still need to do a check for vIOMMU being enabled.
>>
>> Yes, this will be done in the Xen tool stack and Qemu doesn't have such
>> knowledge. Operations of create, destroy Xen vIOMMU will be done in the
>> Xen tool stack.
>
> Shouldn't we
flight 112700 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112700/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64-pvops 2 hos
On Thu, Aug 17, 2017 at 09:37:10AM +0800, Lan Tianyu wrote:
> On 2017年08月16日 19:21, Paolo Bonzini wrote:
> > On 16/08/2017 02:22, Lan Tianyu wrote:
> >> Xen vIOMMU device model will be in Xen hypervisor. Skip vIOMMU
> >> check for Xen here when vcpu number is more than 255.
> >
> > I think you sti
flight 112687 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112687/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3a424c5f49239b810e08aa23368945a9f0360d4c
baseline version:
ovmf d75b8ac278bc9f0159aa7
On 18/08/17 16:55, Konrad Rzeszutek Wilk wrote:
> On Wed, Aug 16, 2017 at 06:47:23PM +, Andri Möll wrote:
>
>> (d1) Invoking OVMF ...
>> (XEN) MMIO emulation failed: d1v0 16bit @ f000:ff54 -> 66 ea 5c ff ff ff
>> 10 00 b8 40 06 00 00 0f 22
> That code is:
> cripts/decodecode
> Code: 66 ea
On Fri, Aug 18, 2017 at 04:19:57PM +0200, Igor Mammedov wrote:
> On Fri, 18 Aug 2017 14:31:07 +0100
> Anthony PERARD wrote:
>
> > On Fri, Aug 18, 2017 at 11:37:34AM +0200, Igor Mammedov wrote:
> > > On Fri, 18 Aug 2017 04:40:02 +0300
> > > "Michael S. Tsirkin" wrote:
> > >
> > > > On Thu, Aug
On Wed, Aug 16, 2017 at 06:47:23PM +, Andri Möll wrote:
> Hey,
>
> As per Andrew [Cooper]'s suggestion, writing here instead of #xen on
> Freenode.
>
> I'm trying out Xen (4.9.0) with OVMF (r21243.3858b4a1ff-1) and having it
OK, so this is
ommit 3858b4a1ff09d3243fea8d07bd135478237cb8f7
Autho
This commit implements the Xen part of the cap mechanism for
Credit2.
A cap is how much, in terms of % of physical CPU time, a domain
can execute at most.
For instance, a domain that must not use more than 1/4 of
one physical CPU, must have a cap of 25%; one that must not
use more than 1+1/2 of p
Note that a cap is considered valid only if
it is within the [1, nr_vcpus]% interval.
Signed-off-by: Dario Faggioli
Acked-by: George Dunlap
Acked-by: Wei Liu
---
Cc: Ian Jackson
---
tools/libxl/libxl_sched.c | 21 +
tools/xl/xl_cmdtable.c|1 +
tools/xl/xl_sched.c
Instead of letting the vCPU that for first tries to get
some budget take it all (although temporarily), allow each
vCPU to only get a specific quota of the total budget.
This improves fairness, allows for more parallelism, and
prevents vCPUs from not being able to get any budget (e.g.,
because som
As cap is already present in Credit1, as a parameter, all
the wiring is there already for it to be percolate down
to csched2_dom_cntl() too.
In this commit, we actually deal with it, and implement
setting, changing or disabling the cap of a domain.
Signed-off-by: Dario Faggioli
---
Cc: George Du
This is v2 of the 'caps for Credit2' series.
Posting of v1 is here:
https://lists.xen.org/archives/html/xen-devel/2017-06/msg00700.html
No change wrt that, apart from taking care of the review comments. The patch
that required more rework is patch 1, as I changed how a corner case (budget
overr
flight 112684 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112684/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-5 48 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 112664
test-amd64-i386
At 09:04 -0600 on 18 Aug (1503047077), Jan Beulich wrote:
> >>> On 18.08.17 at 16:47, wrote:
> > At 01:48 -0600 on 17 Aug (1502934495), Jan Beulich wrote:
> >> >>> On 16.08.17 at 18:47, wrote:
> >> > On 16/08/17 16:23, Jan Beulich wrote:
> >> > On 16.08.17 at 13:22, wrote:
> >> >>> --- a/xen
At 15:47 +0100 on 18 Aug (1503071247), Tim Deegan wrote:
> At 01:48 -0600 on 17 Aug (1502934495), Jan Beulich wrote:
> > >>> On 16.08.17 at 18:47, wrote:
> > > atomic_read() is not free to be reordered by the compiler. It is an asm
> > > volatile with a volatile memory reference.
> >
> > Oh, rig
On 08/17/2017 02:07 PM, Andrew Cooper wrote:
> On 17/08/17 17:51, Boris Ostrovsky wrote:
>> @@ -1589,7 +1585,7 @@ const struct hvm_function_table * __init
>> start_svm(void)
>>
>> svm_host_osvw_reset();
>>
>> -if ( _svm_cpu_up(true) )
>> +if ( svm_cpu_up_prepare(smp_processor_id()
>>> On 18.08.17 at 16:47, wrote:
> At 01:48 -0600 on 17 Aug (1502934495), Jan Beulich wrote:
>> >>> On 16.08.17 at 18:47, wrote:
>> > On 16/08/17 16:23, Jan Beulich wrote:
>> > On 16.08.17 at 13:22, wrote:
>> >>> --- a/xen/arch/x86/mm/shadow/multi.c
>> >>> +++ b/xen/arch/x86/mm/shadow/multi.
flight 112699 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112699/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64-pvops 2 hos
At 01:48 -0600 on 17 Aug (1502934495), Jan Beulich wrote:
> >>> On 16.08.17 at 18:47, wrote:
> > On 16/08/17 16:23, Jan Beulich wrote:
> > On 16.08.17 at 13:22, wrote:
> >>> --- a/xen/arch/x86/mm/shadow/multi.c
> >>> +++ b/xen/arch/x86/mm/shadow/multi.c
> >>> @@ -3112,7 +3112,6 @@ static int
Hi,
On 18/08/17 15:21, Julien Grall wrote:
>
>
> On 17/08/17 18:06, Andre Przywara wrote:
>> Hi,
>
> Hi Andre,
>
>> On 11/08/17 15:10, Julien Grall wrote:
>>> Hi Andre,
>>>
>>> On 21/07/17 20:59, Andre Przywara wrote:
Since the GICs MMIO access always covers a number of IRQs at
once
On 8/18/2017 5:14 AM, Roger Pau Monné wrote:
On Thu, Aug 17, 2017 at 06:43:46PM -0400, Annie Li wrote:
If there is inflight I/O in any non-last queue, blkback returns -EBUSY
directly, and never stops thread of remaining queue and processs them. When
removing vbd device with lots of disk I/O loa
On 18/08/17 15:23, Tim Deegan wrote:
> Use the smp_ variants, as we're only synchronizing against other CPUs.
>
> Add a write barrier before incrementing the version.
>
> x86's memory ordering rules and the presence of various out-of-unit
> function calls mean that this code worked OK before, and t
Use the smp_ variants, as we're only synchronizing against other CPUs.
Add a write barrier before incrementing the version.
x86's memory ordering rules and the presence of various out-of-unit
function calls mean that this code worked OK before, and the barriers
are mostly decorative.
Signed-off-
On 17/08/17 18:06, Andre Przywara wrote:
Hi,
Hi Andre,
On 11/08/17 15:10, Julien Grall wrote:
Hi Andre,
On 21/07/17 20:59, Andre Przywara wrote:
Since the GICs MMIO access always covers a number of IRQs at once,
introduce wrapper functions which loop over those IRQs, take their
locks and
On Fri, 18 Aug 2017 14:31:07 +0100
Anthony PERARD wrote:
> On Fri, Aug 18, 2017 at 11:37:34AM +0200, Igor Mammedov wrote:
> > On Fri, 18 Aug 2017 04:40:02 +0300
> > "Michael S. Tsirkin" wrote:
> >
> > > On Thu, Aug 17, 2017 at 05:23:46PM +0100, Anthony PERARD wrote:
> > > > This means that
At 14:55 +0100 on 18 Aug (1503068128), Tim Deegan wrote:
> At 12:22 +0100 on 16 Aug (1502886128), Andrew Cooper wrote:
> > diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
> > index c9c2252..1e3dfaf 100644
> > --- a/xen/arch/x86/mm/shadow/multi.c
> > +++ b/xen/arch/x86/m
>>> On 18.08.17 at 15:45, wrote:
> On Fri, Aug 18, 2017 at 01:45:50PM +0800, Chao Gao wrote:
>> >
>> >> > +}
>> >> > +}
>> >> > +}
>> >>
>> >> This still looks wrong to me. How do you know acpi_modules[0] is DMAR
>> >> table?
>> >>
>> >
>> >Oh, I sorta see why you do this
At 12:22 +0100 on 16 Aug (1502886128), Andrew Cooper wrote:
> diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
> index c9c2252..1e3dfaf 100644
> --- a/xen/arch/x86/mm/shadow/multi.c
> +++ b/xen/arch/x86/mm/shadow/multi.c
> @@ -3112,7 +3112,6 @@ static int sh_page_fault(s
On Fri, Aug 18, 2017 at 02:30:03PM +0100, Julien Grall wrote:
> Hi Wei,
>
> On 15/08/17 10:49, Wei Liu wrote:
> > On Thu, Aug 10, 2017 at 06:51:24PM +0100, Julien Grall wrote:
> > > > > > The interface between Xen and xenconsoled can be asynchronous, it
> > > > > > can
> > > > > > opt to queue X
This run is configured for baseline tests only.
flight 71990 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71990/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 12 guest-start
On Fri, Aug 18, 2017 at 01:45:50PM +0800, Chao Gao wrote:
> >
> >> > +}
> >> > +}
> >> > +}
> >>
> >> This still looks wrong to me. How do you know acpi_modules[0] is DMAR
> >> table?
> >>
> >
> >Oh, I sorta see why you do this, but I still think this is wrong. The
> >DMAR
On Thu, Aug 17, 2017 at 08:22:16PM -0400, Lan Tianyu wrote:
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index b22aacc..d1f9b10 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -396,6 +396,9 @@ struct domain *domain_create(domid_t domid, unsigned int
> domcr_flags,
On Fri, Aug 18, 2017 at 11:37:34AM +0200, Igor Mammedov wrote:
> On Fri, 18 Aug 2017 04:40:02 +0300
> "Michael S. Tsirkin" wrote:
>
> > On Thu, Aug 17, 2017 at 05:23:46PM +0100, Anthony PERARD wrote:
> > > This means that the function will be call and the property
> > > acpi-pcihp-bsel will be se
Hi Wei,
On 15/08/17 10:49, Wei Liu wrote:
On Thu, Aug 10, 2017 at 06:51:24PM +0100, Julien Grall wrote:
The interface between Xen and xenconsoled can be asynchronous, it can
opt to queue X characters before sending an event, also setup a oneshot
timer to avoid hanging.
This however has some ot
On 08/16/2017 01:31 PM, Juergen Gross wrote:
> Xen's paravirt patch function xen_patch() does some special casing for
> irq_ops functions to apply relocations when those functions can be
> patched inline instead of calls.
>
> Unfortunately none of the special case function replacements is small
> e
At 12:22 +0100 on 16 Aug (1502886127), Andrew Cooper wrote:
> * Drop trailing whitespace.
> * Move amd_nonfatal_mcheck_init() into .init.text and drop a trailing
> return.
> * Drop unnecessary wmb()'s. Because of Xen's implementation, they are only
> compiler barriers anyway, and each w
On 08/18/2017 05:11 AM, Jan Beulich wrote:
On 16.08.17 at 20:33, wrote:
>> .. so that it's easy to find pages that need to be scrubbed (those pages are
>> now marked with _PGC_need_scrub bit).
>>
>> We keep track of the first unscrubbed page in a page buddy using first_dirty
>> field. For now
flight 112683 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112683/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 112661
test-amd64-i38
>>> On 18.08.17 at 12:27, wrote:
> * Delete trailing whitespace
> * Switch to using mfn_t for mfn_to_page()/page_to_mfn()
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
again with Wei's remark addressed.
Jan
___
Xen-devel mailing list
Xe
On 18/08/17 13:16, Jan Beulich wrote:
On 18.08.17 at 12:27, wrote:
>> To avoid breaking the build elsewhere, the l{1..4}e_{from,get}_page() macros
>> are switched to using __mfn_to_page() and __page_to_mfn().
>>
>> Most changes are wrapping or removing _mfn()/mfn_x() from existing callsites.
>>> On 18.08.17 at 12:27, wrote:
> To avoid breaking the build elsewhere, the l{1..4}e_{from,get}_page() macros
> are switched to using __mfn_to_page() and __page_to_mfn().
>
> Most changes are wrapping or removing _mfn()/mfn_x() from existing callsites.
>
> However, {alloc,free}_l1_table() are
On 18/08/17 13:08, Wei Liu wrote:
> On Fri, Aug 18, 2017 at 04:08:44AM -0600, Jan Beulich wrote:
>>
>> If it can't be static anymore, and considering it's just a wrapper
>> around another function call, would there be anything wrong with
>> making it an inline function in the header?
> Yes it can b
On Fri, Aug 18, 2017 at 04:08:44AM -0600, Jan Beulich wrote:
> >>> On 17.08.17 at 16:44, wrote:
> > @@ -5138,13 +5140,6 @@ static int ptwr_emulated_cmpxchg(
> > container_of(ctxt, struct ptwr_emulate_ctxt, ctxt));
> > }
> >
> > -static int pv_emul_is_mem_write(const struct x86_emulate_
On Fri, Aug 18, 2017 at 12:46:23PM +0100, Anthony PERARD wrote:
> On Fri, Aug 18, 2017 at 09:54:01AM +0100, Roger Pau Monn303251 wrote:
> > On Thu, Aug 17, 2017 at 04:23:11PM -0700, Bart Van Assche wrote:
> > > Signed-off-by: Bart Van Assche
> > > Cc: Konrad Rzeszutek Wilk
> > > Cc: Roger Pau Mon
On Fri, Aug 18, 2017 at 11:27:27AM +0100, Andrew Cooper wrote:
> * Delete trailing whitespace
> * Switch to using mfn_t for mfn_to_page()/page_to_mfn()
>
> Signed-off-by: Andrew Cooper
>
[...]
> +/* Override macros from asm/mm.h to make them work with mfn_t */
Same here.
Otherwise:
Reviewe
On Fri, Aug 18, 2017 at 11:27:26AM +0100, Andrew Cooper wrote:
> To avoid breaking the build elsewhere, the l{1..4}e_{from,get}_page() macros
> are switched to using __mfn_to_page() and __page_to_mfn().
>
> Most changes are wrapping or removing _mfn()/mfn_x() from existing callsites.
>
> However,
On Fri, Aug 18, 2017 at 09:54:01AM +0100, Roger Pau Monn303251 wrote:
> On Thu, Aug 17, 2017 at 04:23:11PM -0700, Bart Van Assche wrote:
> > Signed-off-by: Bart Van Assche
> > Cc: Konrad Rzeszutek Wilk
> > Cc: Roger Pau Monn303251
> > Cc: xen-de...@lists.xenproject.org
> > ---
> > drivers/block
On Thu, Aug 17, 2017 at 07:36:20PM +0200, Andreas Kinzler wrote:
> On Tue, 15 Aug 2017 11:55:10 +0200, Roger Pau Monné
> wrote:
> > Could you please try the patch below and paste the output you get on
> > the Xen console?
>
> Output is in attached file. Does it help?
Yes, thanks. I'm quite sure
To avoid breaking the build elsewhere, the l{1..4}e_{from,get}_page() macros
are switched to using __mfn_to_page() and __page_to_mfn().
Most changes are wrapping or removing _mfn()/mfn_x() from existing callsites.
However, {alloc,free}_l1_table() are switched to using __map_domain_page(), as
thei
* Delete trailing whitespace
* Switch to using mfn_t for mfn_to_page()/page_to_mfn()
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
---
xen/arch/x86/smpboot.c | 32 +++-
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/xen/arch/x86/smp
On 17/08/17 15:44, Wei Liu wrote:
> Signed-off-by: Wei Liu
> ---
> xen/arch/x86/hvm/Makefile | 1 +
> xen/arch/x86/hvm/grant_table.c | 89
> ++
> xen/arch/x86/mm.c | 53 -
> 3 files changed, 90 insertions(+), 53 d
>>> On 17.08.17 at 16:44, wrote:
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
flight 112682 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112682/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 4 host-install(4)broken REGR. vs. 112647
test-armhf-armh
>>> On 17.08.17 at 16:44, wrote:
> Signed-off-by: Wei Liu
Looks to be pure code movement, so
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Hi Boris,
On 17/08/17 18:36, Boris Ostrovsky wrote:
On 08/17/2017 12:14 PM, Julien Grall wrote:
When booting Linux as Xen guest with CONFIG_DEBUG_ATOMIC, the following
splat appears:
[0.002323] Mountpoint-cache hash table entries: 1024 (order: 1, 8192 bytes)
[0.019717] ASID allocator i
On Fri, Aug 18, 2017 at 03:17:37PM +0800, Lan Tianyu wrote:
> On 2017年08月17日 19:19, Wei Liu wrote:
> > On Wed, Aug 09, 2017 at 04:34:05PM -0400, Lan Tianyu wrote:
> >> +Now just suppport single vIOMMU for one VM and introduced domctls are
> >> compatible
> >> +with multi-vIOMMU support.
> >
> > I
>>> On 17.08.17 at 16:44, wrote:
> And at once make it an inline function. Add declarations of
> replace_grant_{hvm,pv}_mapping to respective header files.
Same remark on function name.
> @@ -38,6 +40,12 @@ static inline int create_grant_p2m_mapping(uint64_t addr,
> unsigned long frame,
>
On Fri, Aug 18, 2017 at 03:09:55PM +0800, Lan Tianyu wrote:
> On 2017年08月17日 19:18, Wei Liu wrote:
> > On Wed, Aug 09, 2017 at 04:34:03PM -0400, Lan Tianyu wrote:
> >> This patch is to add irq request callback for platform implementation
> >> to deal with irq remapping request.
> >>
> >> Signed-off
>>> On 17.08.17 at 16:44, wrote:
> And at once make create_grant_host_mapping an inline function. This
> requires making create_grant_{hvm,pv}_mapping non-static. Provide
> {hvm,pv}/grant_table.h. Include the headers where necessary.
>
> The two functions create_grant_{hvm,pv}_mapping will be m
>>> On 17.08.17 at 16:44, wrote:
> @@ -5138,13 +5140,6 @@ static int ptwr_emulated_cmpxchg(
> container_of(ctxt, struct ptwr_emulate_ctxt, ctxt));
> }
>
> -static int pv_emul_is_mem_write(const struct x86_emulate_state *state,
> -struct x86_emulate_ctxt
flight 71989 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71989/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-armhf-jessie-netboot-pygrub 1 build-check(1) blocked n/a
build-arm64
On Thu, 17 Aug 2017 17:23:46 +0100
Anthony PERARD wrote:
> This means that the function will be call and the property
> acpi-pcihp-bsel will be set even if ACPI build is disable.
s/call/called/
s/disable/disabled/
Maybe something along this lines:
HW part of APCI PCI hotplug in QEMU depends on
On Fri, 18 Aug 2017 04:40:02 +0300
"Michael S. Tsirkin" wrote:
> On Thu, Aug 17, 2017 at 05:23:46PM +0100, Anthony PERARD wrote:
> > This means that the function will be call and the property
> > acpi-pcihp-bsel will be set even if ACPI build is disable.
> >
> > To do PCI passthrough with Xen, t
On 17-08-18 11:32:08, Chao Peng wrote:
>
> > +if ( feat->mba_info.linear )
> > +{
> > +unsigned int mod;
> > +
> > +if ( feat->mba_info.thrtl_max >= 100 )
> > +return false;
>
> Can we do this check earlier, e.g. when it gets enumerated from CPUID?
>
Ok, sound
Juergen Gross writes:
> On 17/08/17 11:20, Vitaly Kuznetsov wrote:
>> On x86 software page-table walkers depend on the fact that remote TLB flush
>> does an IPI: walk is performed lockless but with interrupts disabled and in
>> case the pagetable is freed the freeing CPU will get blocked as remot
On Thu, Aug 17, 2017 at 06:43:46PM -0400, Annie Li wrote:
> If there is inflight I/O in any non-last queue, blkback returns -EBUSY
> directly, and never stops thread of remaining queue and processs them. When
> removing vbd device with lots of disk I/O load, some queues with inflight
> I/O still ha
>>> On 16.08.17 at 20:33, wrote:
> .. so that it's easy to find pages that need to be scrubbed (those pages are
> now marked with _PGC_need_scrub bit).
>
> We keep track of the first unscrubbed page in a page buddy using first_dirty
> field. For now it can have two values, 0 (whole buddy needs sc
On 17/08/17 11:20, Vitaly Kuznetsov wrote:
> On x86 software page-table walkers depend on the fact that remote TLB flush
> does an IPI: walk is performed lockless but with interrupts disabled and in
> case the pagetable is freed the freeing CPU will get blocked as remote TLB
> flush is required. On
On Thu, Aug 17, 2017 at 04:23:11PM -0700, Bart Van Assche wrote:
> Signed-off-by: Bart Van Assche
> Cc: Konrad Rzeszutek Wilk
> Cc: Roger Pau Monn303251
> Cc: xen-de...@lists.xenproject.org
> ---
> drivers/block/xen-blkfront.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --
On 2017年08月18日 16:41, Jan Beulich wrote:
On 18.08.17 at 02:22, wrote:
>> This patch is to introduct an abstract layer for arch vIOMMU implementation
>> to deal with requests from dom0. Arch vIOMMU code needs to provide callback
>> to perform create, destroy and query capabilities operation.
>
>>> On 18.08.17 at 02:22, wrote:
> This patch is to introduct an abstract layer for arch vIOMMU implementation
> to deal with requests from dom0. Arch vIOMMU code needs to provide callback
> to perform create, destroy and query capabilities operation.
>
> Signed-off-by: Lan Tianyu
What is this?
On 08/18/2017 01:23 AM, Bart Van Assche wrote:
> Avoid that smatch reports the following warning when building with
> C=2 CHECK="smatch -p=kernel":
>
> drivers/block/xen-blkback/blkback.c:710 xen_blkbk_unmap_prepare() warn:
> inconsistent indenting
>
> Signed-off-by: Bart Van Assche
> Cc: Konra
On 08/18/2017 01:23 AM, Bart Van Assche wrote:
> Signed-off-by: Bart Van Assche
> Cc: Konrad Rzeszutek Wilk
> Cc: Roger Pau Monn303251
> Cc: xen-de...@lists.xenproject.org
> ---
> drivers/block/xen-blkback/blkback.c | 1 +
> drivers/block/xen-blkback/xenbus.c | 3 ++-
> 2 files changed, 3 inse
On 08/18/2017 10:17 AM, Takashi Sakamoto wrote:
On Aug 18 2017 14:56, Oleksandr Andrushchenko wrote:
Taking into account the fact that the backend we have is a user-space
application
running on top of ALSA/PulseAudio we cannot get HW pointers from actual
hardware by any means (PulseAudio use-c
On 2017年08月17日 19:19, Wei Liu wrote:
> On Wed, Aug 09, 2017 at 04:34:05PM -0400, Lan Tianyu wrote:
>> +Now just suppport single vIOMMU for one VM and introduced domctls are
>> compatible
>> +with multi-vIOMMU support.
>
> Is this still true?
Yes, the patchset just supports single vIOMMU for one
1 - 100 of 105 matches
Mail list logo