flight 101548 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101548/
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. 101443
test-armhf-armhf
On 19/10/16 21:20, Stefano Stabellini wrote:
> On Wed, 19 Oct 2016, Stefano Stabellini wrote:
>> On Wed, 19 Oct 2016, Juergen Gross wrote:
>>> On 19/10/16 12:46, Wei Liu wrote:
Reference to PAGE_SIZE slipped in to two public header files. QEMU build on
ARM64 is broken by this.
T
On 19/10/16 21:21, stef...@aporeto.com wrote:
> Reference to PAGE_SIZE slipped in to two public header files. QEMU build on
> ARM64 is broken by this. PAGE_SIZE should not be used because it could
> be undefined or it could be defined differently on different operating
> systems.
>
> Stefano Stabe
On Mon, Oct 17, 2016 at 5:32 AM, Wei Liu wrote:
> On Fri, Oct 14, 2016 at 12:47:36PM -0700, Kyle Huey wrote:
>> On HVM guests, the cpuid triggers a vm exit, so we can check the emulated
>> faulting state in vmx_do_cpuid and inject a GP(0) if CPL > 0. Notably no
>> hardware support for faulting on
flight 101554 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101554/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f17c0ab617c86210d1b3de4ec493ee2f2ed3e1e6
baseline version:
ovmf 4f0624e87a89afce8408a
This run is configured for baseline tests only.
flight 67911 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67911/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 4f0624e87a89afce8408a87997482b383e7ba131
baseline v
flight 101546 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101546/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 101491
test-amd64-i386-xl-qemut-wi
flight 101549 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101549/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 4f0624e87a89afce8408a87997482b383e7ba131
baseline version:
ovmf 04344b4696de8fbdd795f
flight 101541 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101541/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs.
101000
test-amd64-i386
On Wed, Oct 19, 2016 at 04:46:26PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Oct 19, 2016 at 10:37:52AM +0100, Wei Liu wrote:
> > On Tue, Oct 18, 2016 at 03:53:31AM +0200, Marek Marczykowski-Górecki wrote:
> > > HVM domains use IOMMU and device model assistance for communicating with
> > > PCI
On Wed, Oct 19, 2016 at 10:37:52AM +0100, Wei Liu wrote:
> On Tue, Oct 18, 2016 at 03:53:31AM +0200, Marek Marczykowski-Górecki wrote:
> > HVM domains use IOMMU and device model assistance for communicating with
> > PCI devices, xen-pcifront/pciback is used only in PV domains.
>
> This bit of desc
Moving altp2m domain startup and teardown into altp2m_domain_init()
and altp2m_domain_teardown() respectively.
In hap_enable(), upon partial success of altp2m_domain_init(), unravel
the partial p2m_alloc_table() and unravel hap_set_allocation().
Moving hvm_altp2m_supported() check into functions th
The altp2m clean work is motivated by the following URLs:
https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04454.html
Most of the work has been:
Lots of white space, indentation, and other coding style preference
corrections.
Lots of moving altp2m functions to the altp2m file.
Lo
The was requested in:
https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04323.html
Renamed p2m_init_altp2m_helper() to p2m_init_altp2m_ept().
Signed-off-by: Paul Lai
Reviewed-by: Konrad Rzeszutek Wilk
---
v11
Fixing length of title that was reqested in v9, but missed in v10.
---
On Mon, 10 Oct 2016, Jun Sun wrote:
> Currently function p2m_restore_state() would clear HCR_VM bit, i.e.,
> disabling stage2 translation, before updating VTTBR register. After
> some research and talking to ARM support, I got confirmed that this is not
> necessary. We are currently working on a ne
Do not reference PAGE_SIZE directly: it could be undefined, or it could
have different values in the frontend or in the backend.
Define USBIF_RING_SIZE as 4096, assuming all users of usbif.h have 4K
page granularity. Replace PAGE_SIZE with USBIF_RING_SIZE.
Signed-off-by: Stefano Stabellini
---
Reference to PAGE_SIZE slipped in to two public header files. QEMU build on
ARM64 is broken by this. PAGE_SIZE should not be used because it could
be undefined or it could be defined differently on different operating
systems.
Stefano Stabellini (2):
usbif.h: replace PAGE_SIZE with USBIF_RIN
Do not reference PAGE_SIZE directly: it could be undefined, or it could
have different values in the frontend or in the backend.
Define VSCSIIF_PAGE_SIZE as 4096, assuming all users of vscsiif.h have
4K page granularity. Replace PAGE_SIZE with VSCSIIF_PAGE_SIZE.
Signed-off-by: Stefano Stabellini
On Wed, 19 Oct 2016, Stefano Stabellini wrote:
> On Wed, 19 Oct 2016, Juergen Gross wrote:
> > On 19/10/16 12:46, Wei Liu wrote:
> > > Reference to PAGE_SIZE slipped in to two public header files. QEMU build
> > > on
> > > ARM64 is broken by this.
> > >
> > > This series tries to fix that. The ap
On Wed, 19 Oct 2016, Juergen Gross wrote:
> On 19/10/16 12:46, Wei Liu wrote:
> > Reference to PAGE_SIZE slipped in to two public header files. QEMU build on
> > ARM64 is broken by this.
> >
> > This series tries to fix that. The approach is discussed at [0].
> >
> > QEMU will need to update its
On Wed, 19 Oct 2016, David Vrabel wrote:
> On 19/10/16 11:46, Wei Liu wrote:
> > If it is present, use it; otherwise use 4096. Also provide two new
> > macros to let user have control over the page size used to do
> > calculation.
> [...]
> > index 4053c24..ac38318 100644
> > --- a/xen/include/publ
On Wed, 19 Oct 2016, Wei Liu wrote:
> On Wed, Oct 19, 2016 at 11:40:40AM +0200, Juergen Gross wrote:
> > On 19/10/16 11:22, Wei Liu wrote:
> > > On Wed, Oct 19, 2016 at 11:09:21AM +0200, Juergen Gross wrote:
> > >> On 19/10/16 10:50, Wei Liu wrote:
> > >>> On Tue, Oct 18, 2016 at 12:09:55PM -0700,
This run is configured for baseline tests only.
flight 67910 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67910/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 04344b4696de8fbdd795fa2d692c72d82ee85d62
baseline v
在 2016/10/19 23:58, Juergen Gross 写道:
On 19/10/16 12:20, Pan Xinhui wrote:
change from v3:
add x86 vcpu preempted check patch
change from v2:
no code change, fix typos, update some comments
change from v1:
a simplier definition of default vcpu_is_preempted
skip m
c/s 373923ed9c2 "x86emul: fix pushing of selector registers" redirected
all push %sreg instructions into the general push path. However, this
ends up hitting the assertion at the head of the push path.
Annotate All push and pop %sreg instructions as Mov, indicating that
they do not read the desti
On 19/10/16 12:20, Pan Xinhui wrote:
> change from v3:
> add x86 vcpu preempted check patch
> change from v2:
> no code change, fix typos, update some comments
> change from v1:
> a simplier definition of default vcpu_is_preempted
> skip mahcine type check on ppc, and add co
On Wed, Oct 19, 2016 at 11:13:54AM -0400, Meng Xu wrote:
> The bug is introduced in Xen 4.7 when we converted RTDS scheduler
> from quantum-driven model to event-driven model.
> We assumed rt_schedule() is always called for a VCPU
> before the VCPUs budget replenished handler.
> This assumption doe
flight 101536 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101536/
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. 101443
test-armhf-armhf
[cc. Tianyang...]
On Wed, Oct 19, 2016 at 11:45 AM, Wei Liu wrote:
> On Wed, Oct 19, 2016 at 11:13:54AM -0400, Meng Xu wrote:
>> The bug is introduced in Xen 4.7 when we converted RTDS scheduler
>> from quantum-driven model to event-driven model.
>> We assumed rt_schedule() is always called for a
flight 101544 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101544/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 04344b4696de8fbdd795fa2d692c72d82ee85d62
baseline version:
ovmf 0613ccbd1357b1f6aecab
On Wed, Oct 19, 2016 at 11:13 AM, Meng Xu wrote:
> The bug is introduced in Xen 4.7 when we converted RTDS scheduler
> from quantum-driven model to event-driven model.
> We assumed rt_schedule() is always called for a VCPU
> before the VCPUs budget replenished handler.
> This assumption does not h
This run is configured for baseline tests only.
flight 67908 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67908/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0613ccbd1357b1f6aecab27a2e72dde328d36f6d
baseline v
The bug is introduced in Xen 4.7 when we converted RTDS scheduler
from quantum-driven model to event-driven model.
We assumed rt_schedule() is always called for a VCPU
before the VCPUs budget replenished handler.
This assumption does not hold, when system is overloaded, or
when the VCPU budget is a
Correct the mistakes in the example command
Correct a simple typo.
Signed-off-by: Meng Xu
---
Cc: Meng Xu
Cc: Dario Faggioli
Cc: Wei Liu
Cc: Lars Kurth
Cc: George Dunlap
Cc: Chong Li
---
docs/features/sched_rtds.pandoc | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --
flight 101533 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101533/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs.
101491
test-armhf-
In the Xen Project colo, we do not grant our hosts (including the
controller) general internet access.
We did have the IP address of scan.coverity.com configured in our
firewall. But Coverity use a CDN now and the IP address is not even
slightly stable any more.
Using the squid works (using CONN
On 19/10/16 11:46, Wei Liu wrote:
> If it is present, use it; otherwise use 4096. Also provide two new
> macros to let user have control over the page size used to do
> calculation.
[...]
> index 4053c24..ac38318 100644
> --- a/xen/include/public/io/usbif.h
> +++ b/xen/include/public/io/usbif.h
> @
On Wed, Oct 19, 2016 at 12:45:31PM +0100, Andrew Cooper wrote:
> On 19/10/16 11:46, Wei Liu wrote:
> > If it is present, use it; otherwise use 4096. Also provide two new
> > macros to let user have control over the page size used to do
> > calculation.
> >
> > Signed-off-by: Wei Liu
> > ---
> > Cc
flight 101538 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101538/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail REGR. vs.
101477
test-armhf-armhf-li
flight 101540 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101540/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0613ccbd1357b1f6aecab27a2e72dde328d36f6d
baseline version:
ovmf 67e11e4d5902dc77fc648
On 19/10/16 11:46, Wei Liu wrote:
> If it is present, use it; otherwise use 4096. Also provide two new
> macros to let user have control over the page size used to do
> calculation.
>
> Signed-off-by: Wei Liu
> ---
> Cc: Andrew Cooper
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Jan Beulich
> C
This run is configured for baseline tests only.
flight 67906 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67906/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 67e11e4d5902dc77fc64876da5b71122bf128837
baseline v
On 19/10/16 12:46, Wei Liu wrote:
> Reference to PAGE_SIZE slipped in to two public header files. QEMU build on
> ARM64 is broken by this.
>
> This series tries to fix that. The approach is discussed at [0].
>
> QEMU will need to update its copy of usbif.h.
There is no QEMU copy of Xen headers.
Hi all,
I am co-organizing the FOSDEM 2017 Virtualization & IaaS DevRoom next year
again. The CfP for the DevRoom is now open at
http://www.ovirt.org/blog/2016/10/call-for-proposal-fosdem-2017/
Feel free to contact me with any questions
Regards
Lars
___
If it is present, use it; otherwise use 4096. Also provide two new
macros to let user have control over the page size used to do
calculation.
Signed-off-by: Wei Liu
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: T
Reference to PAGE_SIZE slipped in to two public header files. QEMU build on
ARM64 is broken by this.
This series tries to fix that. The approach is discussed at [0].
QEMU will need to update its copy of usbif.h.
It would be good if we can have this fixed either by this series or some other
metho
If it is present, use it; otherwise use 4096. Also provide a new macro
to let user have control over the page size used to do calculation.
Signed-off-by: Wei Liu
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim
On Wed, Oct 19, 2016 at 10:38:04AM +0100, Wei Liu wrote:
> On Tue, Oct 18, 2016 at 03:53:33AM +0200, Marek Marczykowski-Górecki wrote:
> > Stubdomain do not have it's own config file - its configuration is
> > derived from target domains. Do not try to manipulate it when attaching
> > PCI device.
>
flight 101542 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101542/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
coverity-amd646 coverity-upload fail REGR. vs. 101279
version t
On Wed, Oct 19, 2016 at 11:40:40AM +0200, Juergen Gross wrote:
> On 19/10/16 11:22, Wei Liu wrote:
> > On Wed, Oct 19, 2016 at 11:09:21AM +0200, Juergen Gross wrote:
> >> On 19/10/16 10:50, Wei Liu wrote:
> >>> On Tue, Oct 18, 2016 at 12:09:55PM -0700, Stefano Stabellini wrote:
> Hi all,
> >>>
flight 67905 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67905/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-amd64-squeeze-netboot-pygrub 9 debian-di-install fail like
67865
test-amd64-
On Tue, Oct 18, 2016 at 03:53:33AM +0200, Marek Marczykowski-Górecki wrote:
> Stubdomain do not have it's own config file - its configuration is
> derived from target domains. Do not try to manipulate it when attaching
> PCI device.
>
> This bug prevented starting HVM with stubdomain and PCI passt
On Tue, Oct 18, 2016 at 03:53:32AM +0200, Marek Marczykowski-Górecki wrote:
> When qemu is running in stubdomain, handling "pci-ins" command will fail
> if pcifront is not initialized already. Fix this by sending such command
> only after confirming that pciback/front is running.
>
> It is possibl
On Tue, Oct 18, 2016 at 03:53:31AM +0200, Marek Marczykowski-Górecki wrote:
> HVM domains use IOMMU and device model assistance for communicating with
> PCI devices, xen-pcifront/pciback is used only in PV domains.
This bit of description is in line with my understanding of how PCI
passthrough wor
On 19/10/16 11:22, Wei Liu wrote:
> On Wed, Oct 19, 2016 at 11:09:21AM +0200, Juergen Gross wrote:
>> On 19/10/16 10:50, Wei Liu wrote:
>>> On Tue, Oct 18, 2016 at 12:09:55PM -0700, Stefano Stabellini wrote:
Hi all,
While I was investigating the recent libxl ARM64 build issue, I foun
On Wed, Oct 19, 2016 at 11:09:21AM +0200, Juergen Gross wrote:
> On 19/10/16 10:50, Wei Liu wrote:
> > On Tue, Oct 18, 2016 at 12:09:55PM -0700, Stefano Stabellini wrote:
> >> Hi all,
> >>
> >> While I was investigating the recent libxl ARM64 build issue, I found
> >> another ARM64 build problem. T
flight 101532 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101532/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs.
101000
test-amd64-i386
On 19/10/16 10:50, Wei Liu wrote:
> On Tue, Oct 18, 2016 at 12:09:55PM -0700, Stefano Stabellini wrote:
>> Hi all,
>>
>> While I was investigating the recent libxl ARM64 build issue, I found
>> another ARM64 build problem. This one is in QEMU:
>>
>>
>> CChw/usb/xen-usb.o
>> hw/usb/xen-usb.c:
flight 101534 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101534/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 67e11e4d5902dc77fc64876da5b71122bf128837
baseline version:
ovmf 09bd67f09573ad5a40875
On Tue, Oct 18, 2016 at 12:09:55PM -0700, Stefano Stabellini wrote:
> Hi all,
>
> While I was investigating the recent libxl ARM64 build issue, I found
> another ARM64 build problem. This one is in QEMU:
>
>
> CChw/usb/xen-usb.o
> hw/usb/xen-usb.c: In function ‘usbback_gnttab_map’:
> hw/us
SMEP/SMAP is a security feature to prevent kernel executing/accessing
user address involuntarily, any such behavior will lead to a page fault.
SMEP/SMAP is open (in CR4) for both Xen and HVM guest in earlier code.
SMEP/SMAP bit set in Xen CR4 would enforce security checking for 32-bit
PV guest whi
This run is configured for baseline tests only.
flight 67903 seabios real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67903/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 9 debian-hvm-in
62 matches
Mail list logo
