On Thu, Jun 21, 2018 at 01:29:44PM -0400, Boris Ostrovsky wrote:
> Commit 910f8befdf5b ("xen/pirq: fix error path cleanup when binding
> MSIs") fixed a couple of errors in error cleanup path of
> xen_bind_pirq_msi_to_irq(). This cleanup allowed a call to
> __unbind_from_irq() with an unbound irq, w
>>> On 22.06.18 at 00:24, wrote:
>> >>> Working patch by patch isn't feasible because of the renames.
>> >>
>> >> I don't understand - how does path/file naming conflict with working
>> >> patch by patch? Surely a relatively simple sed command could be used
>> >> to change the paths in each patch
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-xsm
testid xen-boot
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/
>>> On 22.06.18 at 04:18, wrote:
> On 21/06/18 19:53, Jan Beulich wrote:
>> We must not leave a vCPU with CR0.TS clear when it is not in fully eager
>> mode and has not touched non-lazy state. Instead of adding a 3rd
>> invocation of stts() to vcpu_restore_fpu_eager(), consolidate all of
>> them i
Hi,
On 06/22/2018 08:42 AM, Jan Beulich wrote:
On 22.06.18 at 00:24, wrote:
Working patch by patch isn't feasible because of the renames.
I don't understand - how does path/file naming conflict with working
patch by patch? Surely a relatively simple sed command could be used
to change the pa
>>> On 22.06.18 at 10:11, wrote:
> On 06/22/2018 08:42 AM, Jan Beulich wrote:
> On 22.06.18 at 00:24, wrote:
>>> Working patch by patch isn't feasible because of the renames.
>>
>> I don't understand - how does path/file naming conflict with working
>> patch by patch? Surely a
>>> On 15.06.18 at 10:58, wrote:
> My original way of thinking here was that this would be set anyway at
> the point state gets reloaded after the adjustments hvmemul_put_fpu()
> does, but the flag should already be set before that - after all the
> guest may never again touch the FPU before e.g.
flight 124508 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124508/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 6 xen-install fail REGR. vs. 124389
Tests which are fail
Other than FXRSTOR, XRSTOR allows for setting components to their
initial state. Utilize this to clear register state immediately after
having saved a vCPU's state (which we don't defer past
__context_switch()), considering that
- this supposedly reduces power consumption,
- this might even free up
On Tue, Jun 12, 2018 at 11:06:16PM +0100, Julien Grall wrote:
> Hi Konrad,
>
> On 12/06/2018 22:17, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jun 12, 2018 at 12:36:37PM +0100, Julien Grall wrote:
> > > During the MMU setup process, Xen will set SCTLR_EL2.WNX
> > > (Write-Non-eXecutable) bit. Becaus
>>> On 08.06.18 at 17:07, wrote:
> No functional change.
>
> Signed-off-by: Roger Pau Monné
Assuming a subsequent patch re-uses the function
Acked-by: Jan Beulich
It would be nice though to convert ...
> --- a/xen/arch/x86/hvm/vpt.c
> +++ b/xen/arch/x86/hvm/vpt.c
> @@ -265,6 +265,41 @@ stati
>>> On 08.06.18 at 17:07, wrote:
> @@ -316,7 +317,9 @@ int pt_update_irq(struct vcpu *v)
> if ( pt->pending_intr_nr )
> {
> /* RTC code takes care of disabling the timer itself. */
> -if ( (pt->irq != RTC_IRQ || !pt->priv) && pt_irq_masked(pt) )
> +
What I did so far:
Installed Arch Linux inside of Qemu virtual machine.
Inside of virtual machine I added these lines to /etc/default/grub
GRUB_TERMINAL="serial"
GRUB_SERIAL_COMMAND="serial --speed=9600 --unit=0 --word=8 --parity=no --stop=1"
and called grub-mkconfig -o /boot/grub/grub.cfg
Now
flight 124532 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124532/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 xen-bootfail REGR. vs. 122969
test-amd64-amd64-libv
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-4.18-rc2-tag
xen: fixes for 4.18-rc2
It contains the following fixes/cleanups:
- the removal of a BUG_ON() which wasn't necessary and which could
trigger now due to a recent change
>>> On 08.06.18 at 17:07, wrote:
> --- a/xen/arch/x86/hvm/hpet.c
> +++ b/xen/arch/x86/hvm/hpet.c
> @@ -223,6 +223,17 @@ static void hpet_stop_timer(HPETState *h, unsigned int
> tn,
> hpet_get_comparator(h, tn, guest_time);
> }
>
> +static void hpet_timer_fired(struct vcpu *v, void *data)
From: Michal Hocko
There are several blockable mmu notifiers which might sleep in
mmu_notifier_invalidate_range_start and that is a problem for the
oom_reaper because it needs to guarantee a forward progress so it cannot
depend on any sleepable locks. Currently we simply back off and mark an
oom
Hi Michal,
[Adding Felix as well]
Well first of all you have a misconception why at least the AMD graphics
driver need to be able to sleep in an MMU notifier: We need to sleep
because we need to wait for hardware operations to finish and *NOT*
because we need to wait for locks.
I'm not sure
On Fri 22-06-18 17:13:02, Christian König wrote:
> Hi Michal,
>
> [Adding Felix as well]
>
> Well first of all you have a misconception why at least the AMD graphics
> driver need to be able to sleep in an MMU notifier: We need to sleep because
> we need to wait for hardware operations to finish
On Fri, Jun 22, 2018 at 08:23:02AM -0600, Jan Beulich wrote:
> >>> On 08.06.18 at 17:07, wrote:
> > @@ -316,7 +317,9 @@ int pt_update_irq(struct vcpu *v)
> > if ( pt->pending_intr_nr )
> > {
> > /* RTC code takes care of disabling the timer itself. */
> > -
>>> On 13.06.18 at 10:52, wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -3592,7 +3592,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
> }
> }
>
> -if ( idx != vcpu_altp2m(v).p2midx )
> +if ( idx != INVALID_ALTP2M
On Fri, Jun 22, 2018 at 09:00:27AM -0600, Jan Beulich wrote:
> >>> On 08.06.18 at 17:07, wrote:
> > --- a/xen/arch/x86/hvm/hpet.c
> > +++ b/xen/arch/x86/hvm/hpet.c
> > @@ -223,6 +223,17 @@ static void hpet_stop_timer(HPETState *h, unsigned int
> > tn,
> > hpet_get_comparator(h, tn, guest_tim
Quoting Michal Hocko (2018-06-22 16:02:42)
> Hi,
> this is an RFC and not tested at all. I am not very familiar with the
> mmu notifiers semantics very much so this is a crude attempt to achieve
> what I need basically. It might be completely wrong but I would like
> to discuss what would be a bett
>>> On 18.06.18 at 17:17, wrote:
> From: Isaila Alexandru
>
> This patch adds access rights for the NPT pages. The access rights are
> saved in a radix tree with the root saved in p2m_domain.
Sounds resource intensive. How many nodes would such a radix tree have
on average?
> --- a/xen/arch/x8
>>> On 22.06.18 at 17:24, wrote:
> On Fri, Jun 22, 2018 at 08:23:02AM -0600, Jan Beulich wrote:
>> >>> On 08.06.18 at 17:07, wrote:
>> > @@ -316,7 +317,9 @@ int pt_update_irq(struct vcpu *v)
>> > if ( pt->pending_intr_nr )
>> > {
>> > /* RTC code takes care of disab
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemut-ws16-amd64
testid xen-boot
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-trad
On Fri, Jun 22, 2018 at 09:53:26AM -0600, Jan Beulich wrote:
> >>> On 22.06.18 at 17:24, wrote:
> > On Fri, Jun 22, 2018 at 08:23:02AM -0600, Jan Beulich wrote:
> >> >>> On 08.06.18 at 17:07, wrote:
> >> > @@ -316,7 +317,9 @@ int pt_update_irq(struct vcpu *v)
> >> > if ( pt->pending_intr
On Fri 22-06-18 16:36:49, Chris Wilson wrote:
> Quoting Michal Hocko (2018-06-22 16:02:42)
> > Hi,
> > this is an RFC and not tested at all. I am not very familiar with the
> > mmu notifiers semantics very much so this is a crude attempt to achieve
> > what I need basically. It might be completely
>>> On 22.06.18 at 17:31, wrote:
> On Fri, Jun 22, 2018 at 09:00:27AM -0600, Jan Beulich wrote:
>> >>> On 08.06.18 at 17:07, wrote:
>> > --- a/xen/arch/x86/hvm/hpet.c
>> > +++ b/xen/arch/x86/hvm/hpet.c
>> > @@ -223,6 +223,17 @@ static void hpet_stop_timer(HPETState *h, unsigned
>> > int
> tn,
>
On Fri, Jun 22, 2018 at 10:00:41AM -0600, Jan Beulich wrote:
> >>> On 22.06.18 at 17:31, wrote:
> > On Fri, Jun 22, 2018 at 09:00:27AM -0600, Jan Beulich wrote:
> >> >>> On 08.06.18 at 17:07, wrote:
> >> > --- a/xen/arch/x86/hvm/hpet.c
> >> > +++ b/xen/arch/x86/hvm/hpet.c
> >> > @@ -223,6 +223,17
On Fri, Jun 22, 2018 at 05:57:16PM +0200, Michal Hocko wrote:
> On Fri 22-06-18 16:36:49, Chris Wilson wrote:
> > Quoting Michal Hocko (2018-06-22 16:02:42)
> > > Hi,
> > > this is an RFC and not tested at all. I am not very familiar with the
> > > mmu notifiers semantics very much so this is a cru
[Hmm, the cc list got mangled somehow - you have just made many people
to work for suse ;) and to kvack.org in the preious one - fixed up
hopefully]
On Fri 22-06-18 17:07:21, Chris Wilson wrote:
> Quoting Michal Hocko (2018-06-22 16:57:16)
> > On Fri 22-06-18 16:36:49, Chris Wilson wrote:
> > > Qu
[Resnding with the CC list fixed]
On Fri 22-06-18 18:40:26, Michal Hocko wrote:
> On Fri 22-06-18 12:18:46, Jerome Glisse wrote:
> > On Fri, Jun 22, 2018 at 05:57:16PM +0200, Michal Hocko wrote:
> > > On Fri 22-06-18 16:36:49, Chris Wilson wrote:
> > > > Quoting Michal Hocko (2018-06-22 16:02:42)
On 06/22/2018 06:28 PM, Jan Beulich wrote:
On 13.06.18 at 10:52, wrote:
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -3592,7 +3592,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>> }
>> }
>>
>> -if ( idx != vcpu_altp2m
On Fri, Jun 22, 2018 at 06:42:43PM +0200, Michal Hocko wrote:
> [Resnding with the CC list fixed]
>
> On Fri 22-06-18 18:40:26, Michal Hocko wrote:
> > On Fri 22-06-18 12:18:46, Jerome Glisse wrote:
> > > On Fri, Jun 22, 2018 at 05:57:16PM +0200, Michal Hocko wrote:
> > > > On Fri 22-06-18 16:36:4
This run is configured for baseline tests only.
flight 74899 seabios real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74899/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail baseline
flight 74900 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74900/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-armhf-jessie-netboot-pygrub 10 debian-di-install fail like
74872
baseline version:
fl
flight 124571 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124571/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8e586296c114f630188cfe4c76df91a1e2b7a5b2
baseline version:
ovmf 855abe0204cb932c8059a
This run is configured for baseline tests only.
flight 74901 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74901/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8e586296c114f630188cfe4c76df91a1e2b7a5b2
baseline v
flight 124551 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124551/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10
fail in 124469 pass in 124551
flight 124585 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124585/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 124521
Tests which did not suc
flight 124566 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124566/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 124057
test-armhf-armhf-libvirt-xsm 14 save
flight 124580 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124580/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814
build-amd64-libvirt
Ian,
could you please branch off Xen 4.11 at current master (commit
437211cb696515ee5bd5dae0ab72866c9f382a33)? There has been a push, so I
believe its time.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org
flight 12 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/12/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-rtds broken
test-armhf-armhf-xl-cubietruck
flight 124582 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124582/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 124232
test-amd64-amd64-
46 matches
Mail list logo
