flight 93717 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93717/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-amd64-xl-qemuu-ov
flight 93638 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93638/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-i386-rumpuserxen6 xen-buildfail like 93587
build-amd64-rumpuserxen
flight 93642 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93642/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-amd64-xl-qemuu-ov
On Wed, 2016-05-04 at 11:53 -0400, Meng Xu wrote:
> On Wed, May 4, 2016 at 11:51 AM, George Dunlap com> wrote:
> > On 03/05/16 22:46, Dario Faggioli wrote:
> > > This also made it possible to improve the replenishment
> > > timer handling logic, such that now the timer is always
> > > kept on one
flight 93633 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93633/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-amd64-xl-qemuu-ov
flight 93612 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93612/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail REGR. vs.
93587
Regressions which
flight 93616 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93616/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-amd64-xl-qemuu-ov
flight 93623 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93623/
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 12
The following images should be placed in the osstest images folder:
ftp://ftp.freebsd.org/pub/FreeBSD/releases/VM-IMAGES/10.3-RELEASE/amd64/Latest/FreeBSD-10.3-RELEASE-amd64.raw.xz
ftp://ftp.freebsd.org/pub/FreeBSD/releases/VM-IMAGES/10.3-RELEASE/i386/Latest/FreeBSD-10.3-RELEASE-i386.raw.xz
Signe
Hi everyone,
I still owe this list the minutes of the session we had at the
hackathon about scheduling.
It was a round table with status updates being given on ongoing
activities, as well as a few ideas for future work/improvements being
tossed, so nothing too structured, but here we go.
I did n
On Fri, May 06, 2016 at 01:48:08PM +0100, Ross Lagerwall wrote:
> On 05/03/2016 11:55 AM, Roger Pau Monne wrote:
> >The calling convention used by the FreeBSD ELF OSABI is exactly the same as
> >the the one defined by System V, so payloads with a FreeBSD OSABI should be
> >accepted by the xsplice m
Sector-based blk_aio_readv() and blk_aio_writev() should die; switch
to byte-based blk_aio_preadv() and blk_aio_pwritev() instead.
Signed-off-by: Eric Blake
---
hw/block/xen_disk.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/hw/block/xen_disk.c b/hw/block/xen_d
On 6 May 2016 at 02:32, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Add a new function to parse DT parameters for Xen specific UEFI just
> like the way for normal UEFI. Then it could reuse the existing codes.
>
> If Xen supports EFI, initialize runtime services.
>
> CC: Matt Fleming
> Signed-of
Wei Liu writes ("cc-option in Config.mk and -Og"):
> $(call cc-option-add,CFLAGS,CC,-Og)
>
> However the output of -O option is different from what cc-option
> expects:
I think cc-option is only suitable for use with warning options.
Sorry for leaving this bear trap.
> Any thought on how to sol
Hi,
I discover an issue with cc-option in Config.mk.
# cc-option: Check if compiler supports first option, else fall back to second.
# This is complicated by the fact that unrecognised -Wno-* options:
# (a) are
When using xsplice, use of __LINE__ can generate spurious changes in
functions due to embedded line numbers. For release builds, remove the
use of these line numbers in BOOT_BUG_ON() and print the current text
address instead.
Signed-off-by: Ross Lagerwall
---
xen/common/page_alloc.c | 8 ++
When using xsplice, use of __LINE__ can generate spurious changes in
functions due to embedded line numbers. For release builds, remove the
use of these line numbers in the ACPI code and print the current text
address instead.
Signed-off-by: Ross Lagerwall
---
xen/drivers/acpi/utilities/utmisc.
Remove the unused x86 implementation.
Signed-off-by: Ross Lagerwall
---
xen/common/lib.c| 12
xen/include/asm-x86/processor.h | 10 --
xen/include/xen/lib.h | 2 ++
3 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/xen/common/lib.c b
When using xsplice, use of __LINE__ can generate spurious changes in
functions due to embedded line numbers. For release builds, remove the
use of these line numbers in IOMMU_WAIT_OP() and print the current text
address instead.
Signed-off-by: Ross Lagerwall
---
xen/drivers/passthrough/vtd/dmar
When building with -ffunction-sections -fdata-sections, it will generate
section names like .text.show_handlers and .data.payload_list. These
sections are in the same namespace as the special sections that Xen
uses, such as .text.kexec and .data.schedulers. To prevent conflicts,
prefix Xen's specia
Instead of using a locking order based on line numbers which doesn't
play nicely with xSplice, statically define the locking order.
Signed-off-by: Ross Lagerwall
---
xen/arch/x86/mm/mm-locks.h | 29 -
1 file changed, 20 insertions(+), 9 deletions(-)
diff --git a/xen/
When using xsplice, use of __LINE__ can generate spurious changes in
functions due to embedded line numbers. For release builds, remove the
use of these line numbers in domain_crash*() and print the current text
address instead.
Signed-off-by: Ross Lagerwall
---
xen/include/xen/sched.h | 14 +++
Here is a set of changes to make building xSplice patches easier.
Tested to boot on x86.
Compile-tested on arm.
This is probably too late to make it into 4.7, but hey, if someone wants
to put it in I've CC'd Wei.
Ross Lagerwall (7):
lib: Add a generic implementation of current_text_addr()
sch
On Fri, May 6, 2016 at 4:31 PM, Wei Liu wrote:
> On Fri, May 06, 2016 at 08:24:28AM -0600, Jan Beulich wrote:
>> On x86, iommu_get_ops() BUG()s when running on non-Intel, non-AMD
>> hardware. While, with our current code, that's a correct prerequisite
>> assumption for IOMMU presence, this is wron
On Fri, May 06, 2016 at 01:41:38PM +, Zytaruk, Kelly wrote:
>
>
> > -Original Message-
> > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan
> > Beulich
> > Sent: Friday, May 06, 2016 8:54 AM
> > To: Zytaruk, Kelly
> > Cc: xen-devel@lists.xen.org
> > Subject: R
On 06/05/16 15:57, Andrew Cooper wrote:
> On 06/05/16 15:25, Roger Pau Monne wrote:
>> Because it's undefined behaviour.
>>
>> Signed-off-by: Roger Pau Monné
>> ---
>> Cc: Andrew Cooper
>> ---
>> include/arch/x86/processor.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --g
On 06/05/16 15:25, Roger Pau Monne wrote:
> Because it's undefined behaviour.
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Andrew Cooper
> ---
> include/arch/x86/processor.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/arch/x86/processor.h b/include/arch/x86
On Fri, May 06, 2016 at 08:37:31AM -0500, Doug Goldstein wrote:
> On 4/29/16 10:11 AM, Wei Liu wrote:
> > On my Debian Jessie build box gcc complains about various maybe
> > uninitialised
> > variables when -g is in use. In fact gcc -Wmaybe-uninitialized is not very
> > reliable according to gcc m
On 06/05/16 15:25, Roger Pau Monne wrote:
> Hello,
>
> This is a series of very small fixes for XTF, the first two are code fixes,
> while the last one is a build system fix.
>
> Thanks, Roger.
1 and 3 look fine - I will take them straight as-is.
2 is slightly more problematic - comment on that
Previously, subscribing to MSR write events was an all-or-none
approach, with special cases for introspection MSR-s. This patch
allows the vm_event consumer to specify exactly what MSR-s it is
interested in, and as a side-effect gets rid of the
vmx_introspection_force_enabled_msrs[] special case.
T
On Fri, May 06, 2016 at 08:24:28AM -0600, Jan Beulich wrote:
> On x86, iommu_get_ops() BUG()s when running on non-Intel, non-AMD
> hardware. While, with our current code, that's a correct prerequisite
> assumption for IOMMU presence, this is wrong on systems without IOMMU.
> Hence iommu_enabled (an
On Fri, Apr 29, 2016 at 03:35:51AM -0600, Jan Beulich wrote:
> As discussed on the hackathon, avoid us having to issue security
> advisories for issues affecting only heavily disaggregated tool stack
> setups, which no-one appears to use (or else they should step up to get
> things into shape).
>
Because it's undefined behaviour.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
---
include/arch/x86/processor.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/arch/x86/processor.h b/include/arch/x86/processor.h
index c9f253f..841953c 100644
--- a/include/arc
On FreeBSD __noinline is already defined in cdefs.h
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
---
include/xtf/compiler.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/xtf/compiler.h b/include/xtf/compiler.h
index 47d929c..251b853 100644
--- a/include/xtf/compiler.h
++
"-executable" is a GNU only extension to find. Instead replace it with a
POSIX compatible one.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 7657e19..fd8c3e0 100644
--- a/Makefile
+
Hello,
This is a series of very small fixes for XTF, the first two are code fixes,
while the last one is a build system fix.
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On x86, iommu_get_ops() BUG()s when running on non-Intel, non-AMD
hardware. While, with our current code, that's a correct prerequisite
assumption for IOMMU presence, this is wrong on systems without IOMMU.
Hence iommu_enabled (and alike) checks should be done prior to calling
that function, not af
flight 93611 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93611/
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 12
On Fri, May 06, 2016 at 03:21:40PM +0200, Dario Faggioli wrote:
> On Wed, 2016-05-04 at 18:34 +0100, George Dunlap wrote:
> > On 04/05/16 18:21, Dario Faggioli wrote:
> > >
> > > After all, I'm fine with an ASSERT() too, but then I think we
> > > should
> > > add one to the same effect to csched_s
> -Original Message-
> From: David Vrabel [mailto:david.vra...@citrix.com]
> Sent: Friday, May 06, 2016 9:04 AM
> To: Zytaruk, Kelly; Konrad Rzeszutek Wilk
> Cc: xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] Debugging Xen early boot
>
> On 06/05/16 13:31, Zytaruk, Kelly wrote:
> >
>
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan
> Beulich
> Sent: Friday, May 06, 2016 8:54 AM
> To: Zytaruk, Kelly
> Cc: xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] Debugging Xen early boot
>
> >>> On 06.05.16 at 14:31, wrote:
> >
On May 06, 2016 9:36 PM, Jan Beulich wrote:
> >>> On 06.05.16 at 14:21, wrote:
> > If i didn't miss something, there is still no comment for this patch set.
> > I think this patch set is close to being ready. I hope this patch set
> > is still in your waiting-review list, but not missed.:)
>
> A
flight 93609 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93609/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-amd64-xl-qemuu-ov
On 4/29/16 10:11 AM, Wei Liu wrote:
> On my Debian Jessie build box gcc complains about various maybe uninitialised
> variables when -g is in use. In fact gcc -Wmaybe-uninitialized is not very
> reliable according to gcc manpage, various search results and answer from
> someone on freenode #gcc cha
>>> On 06.05.16 at 14:21, wrote:
> If i didn't miss something, there is still no comment for this patch set.
> I think this patch set is close to being ready. I hope this patch set is
> still in your waiting-review list, but not missed.:)
As said before, with this series going on top of the othe
On Wed, 2016-05-04 at 18:34 +0100, George Dunlap wrote:
> On 04/05/16 18:21, Dario Faggioli wrote:
> >
> > After all, I'm fine with an ASSERT() too, but then I think we
> > should
> > add one to the same effect to csched_switch_sched() too.
> Well an ASSERT() is sort of like a comment, in that if
This run is configured for baseline tests only.
flight 44392 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44392/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm 15 guest-start/deb
On 06/05/16 13:31, Zytaruk, Kelly wrote:
>
> As for the other question I am still curious as to how to debug
> early Xen. How was __start_xen written and tested, what sort of tools were
> used to debug it and get it working right? What do I do in situations
> where I absolutely can't get serial wo
>>> On 06.05.16 at 14:31, wrote:
> As for the other question I am still curious as to how to debug early Xen.
> How was __start_xen written and tested, what sort of tools were used to debug
> it and get it working right?
I don't know how it was done here, but having been through the
exercise o
Hello Peng,
On 03/05/16 14:58, Peng Fan wrote:
On Tue, May 03, 2016 at 11:58:17AM +0100, Julien Grall wrote:
On 29/04/16 15:28, Peng Fan wrote:
Hi Julien,
Hello Peng,
On Thu, Apr 28, 2016 at 02:14:58PM +0100, Julien Grall wrote:
Is there any big difference between XEN SMMU driver and linu
On 05/03/2016 11:55 AM, Roger Pau Monne wrote:
The calling convention used by the FreeBSD ELF OSABI is exactly the same as
the the one defined by System V, so payloads with a FreeBSD OSABI should be
accepted by the xsplice machinery.
Signed-off-by: Roger Pau Monné
---
Cc: Konrad Rzeszutek Wilk
flight 93607 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93607/
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 12
Konrad, immediate problem is solved although I don't know why. I tried putting
the serial card into a different PCIe slot and it works properly. Must be
something wrong with the slot. I will leave that as a problem for another day.
As for the other question I am still curious as to how to deb
hi,
If i didn't miss something, there is still no comment for this patch set.
I think this patch set is close to being ready. I hope this patch set is still
in your waiting-review list, but not missed.:)
Thanks in advance!!
Quan
On 22 Apr 2016, at 18:38:49 +0800, Quan Xu wrote:
> This patches
flight 93605 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93605/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-amd64-xl-qemuu-ov
Looking at the qdisk backend implementation I wondered whether
blkif_get_x86_32_req() is really correct, especially for the
BLKIF_OP_DISCARD case. The Linux kernel based blk backend seems to
distinguish 32- and 64-bit layouts of blkif_request_discard while
qemu treats them to be the same.
Am I com
On Fri, Apr 29, 2016 at 04:11:11PM +0100, Wei Liu wrote:
> On my Debian Jessie build box gcc complains about various maybe uninitialised
> variables when -g is in use. In fact gcc -Wmaybe-uninitialized is not very
> reliable according to gcc manpage, various search results and answer from
> someone
On Wed, May 04, 2016 at 08:59:35PM +0800, Big Strong wrote:
[...]
>
>
> The code always stops at the xc_altp2m_set_vcpu_enable_notify, which is
> used to assign the new page as #VE info page. As I can't debug the Xen
> source code, I don't why xc_altp2m_set_vcpu_enable_notify always return -1.
>
Ack + release ack and queued both patches
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
flight 93587 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93587/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail in
93563 pass in 93587
test-armhf-armhf-x
On Fri, 6 May 2016, Shannon Zhao wrote:
> On 2016/5/6 16:51, Julien Grall wrote:
> > Hi Shannon,
> >
> > On 06/05/16 03:33, Shannon Zhao wrote:
> >> Below is the output of xenstore-ls:
> >>
> >> root@genericarmv8:/home# xenstore-ls -f
> >> /tool = ""
> >> /tool/xenstored = ""
> >> /local = ""
> >>
>>> On 06.05.16 at 11:30, wrote:
> Hello.I want to start my first VM via Xen and need your advice :1- How can I
> setup a NIC for my VM? Is it Bridge?2- My computer have two partitions and I
> want to dedicate second partition for my VMs, Must I create LVM or...? How
> can I dedicate 80 GB virt
flight 93591 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93591/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-amd64-xl-qemuu-ov
>>> On 06.05.16 at 10:50, wrote:
> Changes since V7:
> - Added Kevin Tian's ack.
> - Moved memset()s from arch_monitor_init_domain() to
>arch_monitor_cleanup_domain(), as suggested by Jan Beulich.
> - Now using sizeof() instead of ARRAY_SIZE() in
>monitor_bitmap_for_msr().
> - d->arch.
On 2016/5/6 16:51, Julien Grall wrote:
> Hi Shannon,
>
> On 06/05/16 03:33, Shannon Zhao wrote:
>> Below is the output of xenstore-ls:
>>
>> root@genericarmv8:/home# xenstore-ls -f
>> /tool = ""
>> /tool/xenstored = ""
>> /local = ""
>> /local/domain = ""
>> /local/domain/0 = ""
>> /local/domain
On Fri, May 06, 2016 at 01:56:36AM -0600, Jan Beulich wrote:
> >>> On 06.05.16 at 09:49, wrote:
> On 06.05.16 at 07:01, wrote:
> >> On 05/05/16 11:22, Wei Liu wrote:
> >>> On Thu, May 05, 2016 at 11:10:33AM +0200, Juergen Gross wrote:
> On 05/05/16 11:02, Wei Liu wrote:
> > On Thu,
On Fri, May 06, 2016 at 07:01:12AM +0200, Juergen Gross wrote:
> On 05/05/16 11:22, Wei Liu wrote:
> > On Thu, May 05, 2016 at 11:10:33AM +0200, Juergen Gross wrote:
> >> On 05/05/16 11:02, Wei Liu wrote:
> >>> On Thu, May 05, 2016 at 08:36:45AM +0200, Juergen Gross wrote:
> The pvusb request
flight 93589 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93589/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 14 guest-saverestore fail REGR. vs. 91479
test-amd64-amd64-libvirt-
On 6/05/2016 7:09 PM, Roger Pau Monné wrote:
> On Thu, May 05, 2016 at 03:52:30PM +1000, Steven Haigh wrote:
>> On 2016-05-05 12:32, Steven Haigh wrote:
>>> Overview
>>>
>>> If you're using iSCSI, you can mount a target by multiple Dom0
>>> machines on the same target. For non-cluster aware filesys
Introduce a new dummy system device serving as parent for virtual
buses. This will enable new pv backends to introduce virtual buses
which are removable again opposed to system buses which are meant
to stay once added.
Signed-off-by: Juergen Gross
Acked-by: Anthony PERARD
---
V2: NOT changed, ev
Add a backend for para-virtualized USB devices for xen domains.
The backend is using host-libusb to forward USB requests from a
domain via libusb to the real device(s) passed through.
Signed-off-by: Juergen Gross
---
V3: multiple small changes as requested by Anthony Perard
check for full ri
This series adds a Xen pvUSB backend driver to qemu. USB devices
connected to the host can be passed through to a Xen guest. The
devices are specified via Xenstore. Access to the devices is done
via host-libusb.c
I've tested the backend with various USB devices (memory sticks,
keyboard, ...).
Cha
Add a Xenstore directory for each supported pv backend. This will allow
Xen tools to decide which backend type to use in case there are
multiple possibilities.
The information is added under
/local/domain//device-model//backends
before the "running" state is written to Xenstore. Using a directory
On Thu, May 05, 2016 at 03:52:30PM +1000, Steven Haigh wrote:
> On 2016-05-05 12:32, Steven Haigh wrote:
> > Overview
> >
> > If you're using iSCSI, you can mount a target by multiple Dom0
> > machines on the same target. For non-cluster aware filesystems, this
> > can lead to disk corruption and
Propagate the IOMMU Device-TLB flush error up to the iommu_iotlb_flush{,_all}.
This patch fixes the leaf ones.
Signed-off-by: Quan Xu
Acked-by: Kevin Tian
CC: Stefano Stabellini
CC: Julien Grall
CC: Jan Beulich
CC: Kevin Tian
CC: Feng Wu
---
xen/drivers/passthrough/arm/smmu.c | 12 +
When IOMMU mapping is failed, we issue a best effort rollback, stopping
IOMMU mapping, unmapping the previous IOMMU maps and then reporting the
error up to the call trees. When rollback is not feasible (in early
initialization phase or trade-off of complexity) for the hardware domain,
we do things
The propagation value from IOMMU flush interfaces may be positive, which
indicates callers need to flush cache, not one of faliures.
when the propagation value is positive, this patch fixes this flush issue
as follows:
- call iommu_flush_write_buffer() to flush cache.
- return zero.
Signed-of
Propagate the IOMMU Device-TLB flush error up to IOMMU suspending.
Signed-off-by: Quan Xu
CC: Jan Beulich
CC: Liu Jinsong
CC: Keir Fraser
CC: Andrew Cooper
CC: Suravee Suthikulpanit
CC: Stefano Stabellini
CC: Julien Grall
CC: Kevin Tian
CC: Feng Wu
---
xen/arch/x86/acpi/power.c
Propagate the IOMMU Device-TLB flush error up to ME phantom function
mapping and unmapping.
Signed-off-by: Quan Xu
CC: Jan Beulich
CC: Kevin Tian
CC: Feng Wu
---
xen/drivers/passthrough/vtd/extern.h | 3 ++-
xen/drivers/passthrough/vtd/iommu.c | 18 ++
xen/drivers/passthrou
This patch set is a prereq patch set for Patch:'VT-d Device-TLB flush issue'.
While IOMMU Device-TLB flush timed out, xen calls panic() at present. However
the existing panic()
is going to be eliminated, so we must propagate the IOMMU Device-TLB flush
error up to the call trees.
This patch set
Propagate the IOMMU Device-TLB flush error up to IOMMU unmapping.
Signed-off-by: Quan Xu
Acked-by: Kevin Tian
CC: Kevin Tian
CC: Feng Wu
CC: Jan Beulich
---
xen/drivers/passthrough/vtd/iommu.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/xen/drivers/pa
Propagate the IOMMU Device-TLB flush error up to IOMMU mapping.
Signed-off-by: Quan Xu
Acked-by: Kevin Tian
CC: Kevin Tian
CC: Feng Wu
CC: Jan Beulich
---
xen/drivers/passthrough/vtd/iommu.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/xen/drivers/passthrough/vtd
Propagate the IOMMU Device-TLB flush error up to the ept_set_entry(),
when VT-d shares EPT page table.
Signed-off-by: Quan Xu
Acked-by: Kevin Tian
CC: Jun Nakajima
CC: Kevin Tian
CC: George Dunlap
CC: Jan Beulich
CC: Andrew Cooper
CC: Feng Wu
---
xen/arch/x86/mm/p2m-ept.c | 3 +
Propagate the IOMMU Device-TLB flush error up to the iommu_iotlb_flush{,_all}.
This patch fixes the top level ones (this patch doesn't fix the leaf ones but
the next patch does).
Signed-off-by: Quan Xu
CC: Stefano Stabellini
CC: Julien Grall
CC: Jan Beulich
CC: Kevin Tian
---
xen/arch/arm/
Treat IOMMU mapping and unmapping failures as a fatal to the domain
(with the exception of the hardware domain).
If IOMMU mapping and unmapping failed, crash the domain (with the
exception of the hardware domain) and propagate the error up to the
call trees.
Signed-off-by: Quan Xu
Reviewed-by: K
On Tue, May 03, 2016 at 09:37:01AM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, May 03, 2016 at 02:29:20PM +0100, Wei Liu wrote:
> > On Tue, May 03, 2016 at 09:27:23AM -0400, Konrad Rzeszutek Wilk wrote:
> > > On Tue, May 03, 2016 at 12:55:07PM +0200, Roger Pau Monne wrote:
> > > > Avoid using sys
Hi Shannon,
On 06/05/16 03:33, Shannon Zhao wrote:
Below is the output of xenstore-ls:
root@genericarmv8:/home# xenstore-ls -f
/tool = ""
/tool/xenstored = ""
/local = ""
/local/domain = ""
/local/domain/0 = ""
/local/domain/0/domid = "0"
/local/domain/0/name = "Domain-0"
/vm = ""
/libxl = ""
Previously, subscribing to MSR write events was an all-or-none
approach, with special cases for introspection MSR-s. This patch
allows the vm_event consumer to specify exactly what MSR-s it is
interested in, and as a side-effect gets rid of the
vmx_introspection_force_enabled_msrs[] special case.
T
hi Jan
On 06.05.16 at 08:55, wrote:
>> in p2m_pod_demand_populate
>> i see：
>> p2m_pod_demand_populate
>>- pod_eager_reclaim
>>- pod_eager_record
>>
>> if gfn is pod， will get mfn from pod cache and set entry。
>> but i did not know why call pod_eager_reclaim、pod_eager_record in
>> p
From: Shannon Zhao
Add a new function to parse DT parameters for Xen specific UEFI just
like the way for normal UEFI. Then it could reuse the existing codes.
If Xen supports EFI, initialize runtime services.
CC: Matt Fleming
Signed-off-by: Shannon Zhao
---
Drop using of EFI_PARAVIRT. Discussi
>>> On 29.04.16 at 11:35, wrote:
> As discussed on the hackathon, avoid us having to issue security
> advisories for issues affecting only heavily disaggregated tool stack
> setups, which no-one appears to use (or else they should step up to get
> things into shape).
>
> Signed-off-by: Jan Beulic
>>> On 06.05.16 at 08:55, wrote:
> in p2m_pod_demand_populate
> i see：
> p2m_pod_demand_populate
>- pod_eager_reclaim
>- pod_eager_record
>
> if gfn is pod， will get mfn from pod cache and set entry。
> but i did not know why call pod_eager_reclaim、pod_eager_record in
> p2m_pod_demand_pop
>>> On 06.05.16 at 09:49, wrote:
On 06.05.16 at 07:01, wrote:
>> On 05/05/16 11:22, Wei Liu wrote:
>>> On Thu, May 05, 2016 at 11:10:33AM +0200, Juergen Gross wrote:
On 05/05/16 11:02, Wei Liu wrote:
> On Thu, May 05, 2016 at 08:36:45AM +0200, Juergen Gross wrote:
>> The pvusb r
>>> On 06.05.16 at 07:01, wrote:
> On 05/05/16 11:22, Wei Liu wrote:
>> On Thu, May 05, 2016 at 11:10:33AM +0200, Juergen Gross wrote:
>>> On 05/05/16 11:02, Wei Liu wrote:
On Thu, May 05, 2016 at 08:36:45AM +0200, Juergen Gross wrote:
> The pvusb request structure contains the transfer_f
flight 44393 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44393/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-armhf-pvops 3 host-install(3) broken like 44370
build-armhf
On May 06, 2016 3:03 PM, Jan Beulich wrote:
> >>> On 05.05.16 at 12:18, wrote:
> > What about this one as below:
>
> If done properly (coding style, comments to silence Coverity, consistency
> throughout not just your change, but its effects on the rest of the code in
> that
> file), that's cer
>>> On 05.05.16 at 12:18, wrote:
> What about this one as below:
If done properly (coding style, comments to silence Coverity,
consistency throughout not just your change, but its effects on
the rest of the code in that file), that's certainly an option.
Jan
> --- a/xen/arch/x86/acpi/power.c
>
97 matches
Mail list logo
