On 2019-06-12 2:15 p.m., Andrew Cooper wrote:
On 09/05/2019 18:25, Ankur Arora wrote:
Allow for different hypercall implementations for different xenhost types.
Nested xenhost, which has two underlying xenhosts, can use both
simultaneously.
The hypercall macros (HYPERVISOR_*) implicitly use the
flight 137668 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137668/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 6 xen-buildfail REGR. vs. 130965
build-i386-prev
On 14.06.19 09:20, Ankur Arora wrote:
On 2019-06-12 2:15 p.m., Andrew Cooper wrote:
On 09/05/2019 18:25, Ankur Arora wrote:
Allow for different hypercall implementations for different xenhost
types.
Nested xenhost, which has two underlying xenhosts, can use both
simultaneously.
The hypercall
On 14/06/2019 08:35, Juergen Gross wrote:
> On 14.06.19 09:20, Ankur Arora wrote:
>> On 2019-06-12 2:15 p.m., Andrew Cooper wrote:
>>> On 09/05/2019 18:25, Ankur Arora wrote:
Allow for different hypercall implementations for different xenhost
types.
Nested xenhost, which has two unde
flight 137673 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137673/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 1f3b25e11df9b37a3d833be52de6c9c83d29a644
baseline version:
freebsd 9694d3c1a70
>>> On 13.06.19 at 19:47, wrote:
> On Thu, Jun 13, 2019 at 08:08:46AM -0600, Jan Beulich wrote:
>> >>> On 13.06.19 at 16:05, wrote:
>> > On Wed, Jun 12, 2019 at 01:38:31AM -0600, Jan Beulich wrote:
>> > On 11.06.19 at 18:04, wrote:
>> >>> On Tue, Jun 11, 2019 at 08:46:04PM +0800, Chao Gao wr
On Thu, Jun 13, 2019 at 08:36:19AM -0600, Jan Beulich wrote:
> >>> On 07.06.19 at 11:22, wrote:
> > @@ -817,7 +811,7 @@ static u64 read_pci_mem_bar(u16 seg, u8 bus, u8 slot,
> > u8 func, u8 bir, int vf)
> > if ( ++bir >= limit )
> > return 0;
> > return addr + disp
>>> On 14.06.19 at 11:06, wrote:
> On Thu, Jun 13, 2019 at 08:36:19AM -0600, Jan Beulich wrote:
>> >>> On 07.06.19 at 11:22, wrote:
>> > --- a/xen/drivers/passthrough/vtd/quirks.c
>> > +++ b/xen/drivers/passthrough/vtd/quirks.c
>> > @@ -128,9 +128,11 @@ static void __init map_igd_reg(void)
>> >
>>> On 13.06.19 at 17:14, wrote:
> Could we include following commit?
>
> Subject: libxl: keep assigned pci devices across domain reboots
> From: Roger Pau Monne roger@citrix.com Thu Sep 20 12:40:25 2018 +0200
> Date: Fri Sep 21 17:13:00 2018 +0100:
> Git: 99a9c70583bd6dc2555b242353821a32cf19
flight 137670 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137670/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-examine 11 examine-serial/bootloaderfail like 137572
test-amd64-amd64-xl-qemut-win7-amd64
It is currently difficult to know how/when/why the userdata lock is
supposed to be used. Add some pointers to the hotplug comments.
Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
---
tools/libxl/libxl_internal.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/tools/libxl/libxl_in
Hi,
Changes in v2:
- New libxl__ev_lock, which actually respect lock hierarchy (it's outside of
CTX_LOCK).
- some smaller changes detailed in patch notes.
This patch series fix libxl_cdrom_insert to work with a depriviledge QEMU. For
that, we need to use libxl__ev_qmp. For that, we need a new
That comment as been separated from the function it defines by
4197d3abbb3055d3798254eb7ba239bfb5824360, but then was not useful
anymore when the libxl__device_disk_add() prototype was removed by
22ea8ad02e465e32cd40887c750b55c3a997a288.
Signed-off-by: Anthony PERARD
Acked-by: Wei Liu
Acked-by:
.. and rename them to libxl__qmp_param_*.
This is to allow other files than libxl_qmp.c to make QMP calls with
parameters.
Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
---
tools/libxl/libxl_internal.h | 15
tools/libxl/libxl_qmp.c | 75 +---
.. and use a new "slow" lock to avoid holding the userdata lock across
several functions.
This patch cuts libxl_cdrom_insert into different step/function but
there are still called synchronously. (Taking the ev_lock is the only
step that might be asynchronous.) A later patch will call them
asynchr
It will often be the case that the lock is free to grab. So we first
try to grab it before we have to fork. Even though in this case the
locks are grabbed in the wrong order in the lock hierarchy (ev_lock
should be outside of CTX_LOCK), it is fine to try without blocking. If
that failed, we will re
After the patch "libxl_disk: Use ev_qmp in libxl_cdrom_insert"
there will not be any kind of timeout, add one back.
Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
---
Notes:
Ian, in this patch, the timeout is setup after we have aquired the lock.
Should we change that to also have
Make libxl_cdrom_insert asynchronous when QEMU is involved. And
have the cdrom opened by libxl, sending a file descriptor to QEMU.
The "opaque" parameter of the "add-fd" can help to figure out what a
fdset in QEMU is used for. It can be queried by "query-fdsets".
Signed-off-by: Anthony PERARD
A
The current lock `domain_userdata_lock' can't be used when modification
to a guest is done by sending command to QEMU, this is a slow process
and requires to call CTX_UNLOCK, which is not possible while holding
the `domain_userdata_lock'.
To resolve this issue, we create a new lock which can take
This is in preparation of cutting libxl_cdrom_insert into several
functions to allow asynchronous callbacks.
No functional changes.
Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
---
tools/libxl/libxl_disk.c | 58 ++--
1 file changed, 32 insertions(+),
sdss->pvqemu wasn't initialiased and disposed of properly.
Also, move the initialisation of sdss->xswait with the rest of the
initialisation of sdss.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_dm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/lib
Hi,
This series contains cleanup patches, ahead of a series that's going to make
more changes to libxl.
Anthony PERARD (15):
libxl: Rename struct libxl_device_type to libxl__device_type
libxl: Remove unused variable in libxl__device_pci_add_xenstore
libxl_pci: Make libxl__create_pci_backend
- dom_path isn't used anymore in that function, remove it.
- Use `r' to store return value of external calls.
- Use `CTX', no need for a local `ctx'.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_domain.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git
There are two differents set of callbacks here, one for
libxl__domain_common_switch_qemu_logdirty,
and one for libxl__domain_suspend_common_switch_qemu_logdirty.
The first set calls the second.
Pure code motion.
Signed-off-by: Anthony PERARD
---
Notes:
The check for PVH seems to be in the
libxl__create_pci_backend isn't called from outside of libxl_pci
anymore, and it's only useful as part of the pci_add process, so
remove the prototype from libxl_internal.h.
No functional changes.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_internal.h | 2 --
tools/libxl/libxl_pci.c
*device isn't used.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_pci.c | 4
1 file changed, 4 deletions(-)
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 4ec6872798..67677d7b55 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -115,7 +115,6
libxl__device_type is internal to libxl, rename it to the internal
only prefix. And eliminate redundant 'struct' keyword, in accord with
the coding style.
No functional changes.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_create.c | 4 +--
tools/libxl/libxl_device.c | 10
libxl__device_pci_add_xenstore doesn't modify `pcidev', so it can be
constified. Also, we don't need pcidev_saved anymore, so remove the
saved copy. (device_add_domain_config is going to make it's own copy
anyway.)
To achieve this, constify pcidev in all functions that
libxl__device_pci_add_xensto
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_internal.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 846227c3cd..0046b30549 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3920,6 +39
The argument `starting' is used as a boolean, change its type to
reflex that throughout libxl_pci.c.
No functional changes.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_internal.h | 3 ++-
tools/libxl/libxl_pci.c | 14 --
2 files changed, 10 insertions(+), 7 deletions(-
`usbctrl' is modified in this function which doesn't seems to be
intended, and usbctrlinfo.backend_id was never modified.
Take this opportunity to consify the argument `usbctrl' in libxl API
to avoid similar mistake.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl.h | 2 +-
tools/libxl/
Two functions in generate `libxl_device_usbctrl' can be replaced by
generic macro:
- libxl_device_usbctrl_list -> LIBXL_DEFINE_DEVICE_LIST
- libxl_devid_to_device_usbctrl -> LIBXL_DEFINE_DEVID_TO_DEVICE
This patch only needs to define `libxl__usbctrl_devtype.from_xenstore'
to makes use of them.
S
The libxl_device_TYPE parameter of all the libxl_device_TYPE_getinfo
function seems to be only used as input to find more information to bi
stored in the libxl_TYPEinfo parameter.
Make sure this is always true and constify the input parameter to avoid
further mistake.
Signed-off-by: Anthony PERAR
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_usb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_usb.c b/tools/libxl/libxl_usb.c
index 3d389c0198..694870a3c3 100644
--- a/tools/libxl/libxl_usb.c
+++ b/tools/libxl/libxl_usb.c
@@ -148,7 +148,7 @@ s
The functions that calls usbctrl_getinfo() only needs information that
can be found in a `libxl_device_usbctrl'. So avoid calling
libxl_device_usbctrl_getinfo and call libxl_devid_to_device_usbctrl
instead. (libxl_device_usbctrl_getinfo needs a `libxl_device_usbctrl'
anyway.)
Signed-off-by: Anthon
ao->domid isn't a reliable way of getting a domid, it might not be set
(this isn't the case here). The right domid value can be found in the
libxl__device (which is the device we want to remove) attached to
libxl__ao_device.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_usb.c | 2 +-
1 fil
1: x86/ACPI: re-park previously parked CPUs upon resume from S3
2: x86/ACPI: restore VESA mode upon resume from S3
3: x86: a little bit of 16-bit video mode setting code cleanup
Patch 2 is meant to address an issue I've observed while testing
patch 1, and patch 3 is simply a collection a misc chan
Aiui when resuming from S3, CPUs come back out of RESET/INIT. Therefore
they need to undergo the same procedure as was added elsewhere by
commits d8f974f1a6 ("x86: command line option to avoid use of secondary
hyper-threads") and 8797d20a6e ("x86: possibly bring up all CPUs even
if not all are supp
In order for "acpi_sleep=s3_mode" to have any effect, we should record
the video mode we switched to during boot. Since right now there's mode
setting code for VESA modes only in the resume case, record the mode
just in that one case.
Signed-off-by: Jan Beulich
---
RFC: On the box that I've been
To "compensate" for the code size growth by an earlier change:
- drop "trampoline" labels (in almost all cases the target label is
reachable with an 8-bit-displacement branch anyway, and a single 16-
bit-displacement branch is still better than a pair of two branches)
- drop an entirely dead in
>>> On 05.04.19 at 15:55, wrote:
> 1: correct certain Fam17 checks
> 2: limit C1E disable family range
>
> v2: Follow Andrew's suggestion for NB_CFG in patch 1. New patch 2.
>
> Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://l
On 11.06.19 09:16, Ankur Arora wrote:
On 2019-06-07 8:04 a.m., Juergen Gross wrote:
On 09.05.19 19:25, Ankur Arora wrote:
Add xenhost_t which will serve as an abstraction over Xen interfaces.
It co-exists with the PV/HVM/PVH abstractions (x86_init, hypervisor_x86,
pv_ops etc) and is meant to ca
On 09.05.19 19:25, Ankur Arora wrote:
Abstract out xen_vcpu_id probing via (*probe_vcpu_id)(). Once that is
availab,e the vcpu_info registration happens via the VCPUOP hypercall.
Note that for the nested case, there are two vcpu_ids, and two vcpu_info
areas, one each for the default xenhost and
On 09.05.19 19:25, Ankur Arora wrote:
For configurations with multiple xenhosts, we need to handle events
generated from multiple xenhosts.
Having more than one upcall handler might be quite hairy, and it would
be simpler if the callback from L0-Xen could be bounced via L1-Xen.
This will also me
On 09.05.19 19:25, Ankur Arora wrote:
Largely mechanical patch that adds a new param, xenhost_t * to the
evtchn interfaces. The evtchn port instead of being domain unique, is
now scoped to xenhost_t.
As part of upcall handling we now look at all the xenhosts and, for
evtchn_2l, the xenhost's sha
Am Wed, 5 Jun 2019 11:53:38 +0100
schrieb Anthony PERARD :
> Olaf, did you apply this patch and run some guest? Do they still boot?
> It doesn't matter if you can't trigger the race with or without this
> patch, I just want to know if there are any regression.
> So, may have I your "Tested-by" ? A
flight 137674 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137674/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 129313
build-armhf-pvops
Hello Julien,
On 13.06.19 17:41, Julien Grall wrote:
Sorry I may have missed it. We can't really restrict the usage of the current
hypercall (it is pretty lax). So I think any lockless solution would require to
allow the hypercall
to be used together (which I want to avoid).
I'd better say h
On 14/06/2019 15:36, Andrii Anisov wrote:
Hello Julien,
Hi,
On 13.06.19 17:41, Julien Grall wrote:
Sorry I may have missed it. We can't really restrict the usage of the current
hypercall (it is pretty lax). So I think any lockless solution would require
to allow the hypercall
to be used to
On 14.06.19 17:39, Julien Grall wrote:
Why? What are the benefits for a guest to use the two interface together?
I do not say the guest has to use both interfaces simultaneously. It is
logically odd, doing so will only reflect in increasing of hypervisor overhead.
But such an implementation
As build system now have *_defconfig targets defined,
lets describe available defconfig files for the Arm architecture.
Signed-off-by: Volodymyr Babchuk
---
docs/misc/arm/defconfigs.txt | 23 +++
1 file changed, 23 insertions(+)
create mode 100644 docs/misc/arm/defconfigs.tx
Hi Andrii,
On 14/06/2019 16:11, Andrii Anisov wrote:
On 14.06.19 17:39, Julien Grall wrote:
Why? What are the benefits for a guest to use the two interface together?
I do not say the guest has to use both interfaces simultaneously. It is
logically odd, doing so will only reflect in increas
After patch 1, which really is the one I was after here, I did realize
that the number of uses of __get_cpu_var() had shrunk enough
that it seemed worthwhile to take the time and convert the
remaining uses, such that the construct could finally be dropped.
1: x86/mcheck: allow varying bank counts
Up to now we've been assuming that all CPUs would have the same number
of reporting banks. However, on upcoming AMD CPUs this isn't the case,
and one can observe
(XEN) mce.c:666: Different bank number on cpu
indicating that Machine Check support would not be enabled on the
affected CPUs. Convert
this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/acpi/cpuidle_menu.c
+++ b/xen/arch/x86/acpi/cpuidle_menu.c
@@ -146,7 +146,7 @@ static inline int which_bucket(unsigned
static inline s_time_t
this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -473,7 +473,8 @@ void mcheck_cmn_handler(const struct cpu
static atomic_t found_err
this_cpu{,_ptr}() are shorter, and have previously been marked as
preferred in Xen anyway.
Signed-off-by: Jan Beulich
--- a/xen/common/rcupdate.c
+++ b/xen/common/rcupdate.c
@@ -225,7 +225,7 @@ void call_rcu(struct rcu_head *head,
head->func = func;
head->next = NULL;
local_irq_sa
>>> On 14.06.19 at 17:11, wrote:
> On 14.06.19 17:39, Julien Grall wrote:
>> After all they have exactly the same data...
>
> Yes, but normal guests should use only one interface.
I thought it had been clarified already that normal guests can very
well use both interfaces, just not both at the s
flight 137684 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137684/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf fc7d997c35372126823c3b0acf7b67c45cbeea36
baseline version:
ovmf 562688707145df9d695f3
>>> On 07.03.19 at 11:32, wrote:
> generic.c: In function ‘print_mtrr_state’:
> generic.c:210:11: error: ‘%0*lx’ directive output between 1 and 1073741823
> bytes may cause result to exceed ‘INT_MAX’ [-Werror=format-overflow=]
> 210 |printk("%s %u base %0*"PRIx64"000 mask %0*"PRIx64"000 %s
On 14.06.19 18:24, Julien Grall wrote:
I hope you are aware that speaking about speed here is quite irrelevant. The
difference would be clear lost in the noise of the rest of the context switch.
Mmm... I have that understanding. Yet I'd rather try to not increase the noise,
if not reduce.
On 14/06/2019 17:11, Andrii Anisov wrote:
On 14.06.19 18:24, Julien Grall wrote:
But, if you allow something, then most likely someone will use it. However,
you have to differentiate implementation vs documentation.
In this case, I don't think the implementation should dictate what is going
flight 137726 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137726/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Hello Jan,
On 14.06.19 18:42, Jan Beulich wrote:
On 14.06.19 at 17:11, wrote:
On 14.06.19 17:39, Julien Grall wrote:
After all they have exactly the same data...
Yes, but normal guests should use only one interface.
I thought it had been clarified already that normal guests can very
well
On 14.06.19 19:20, Julien Grall wrote:
Well, that a stable ABI... Even if I would love to remove it, you can't get rid
of old guests that easily...
In 5 years, as XEN did for LK 3.18?
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-de
Hi Jan,
The title and commit message are a bit odd to read because you are modifying
common code but everything is geared towards x86.
On 14/06/2019 12:37, Jan Beulich wrote:
Aiui when resuming from S3, CPUs come back out of RESET/INIT. Therefore
they need to undergo the same procedure as was
{set, clear}_fixmap() are currently open-coding update to the Xen
page-tables. This can be avoided by using the generic helpers
map_pages_to_xen() and destroy_xen_mappings().
Both function are not meant to fail for fixmap, hence the BUG_ON()
checking the return.
Signed-off-by: Julien Grall
Revie
With the newly introduced flags, it is now possible to know how the page
will be updated through the flags.
All the use of xenmap_operation are now replaced with the flags. At the
same time, validity check are now removed as they are gathered in
xen_pt_check_entry().
Signed-off-by: Julien Grall
The code handling Xen PT update has quite a few restrictions on what it
can do. This is not a bad thing as it keeps the code simple.
There are already a few checks scattered in current page table handling.
However they are not sufficient as they could still allow to
modify/remove entry with contig
The current value of HSCTLR_BASE for Arm64 is pretty wrong. It would
actually turn on SCTLR_EL2.nAA (bit 6) on hardware implementing
ARMv8.4-LSE.
Furthermore, the documentation of what is cleared/set in SCTLR_EL2 is
also not correct and looks like to be a verbatim copy from Arm32.
HSCTLR_BASE is
At the moment, the flags are not enough to describe what kind of update
will done on the VA range. They need to be used in conjunction with the
enum xenmap_operation.
It would be more convenient to have all the information for the update
in a single place.
Two new flags are added to remove the re
Hi all,
This is the third part of the boot/memory rework for Xen on Arm. At the
moment, the update to Xen PT is scattered all around mm.c. This makes
difficult to rework Xen memory layout or even ensuring we are following the
Arm Arm properly (and we are not so far!).
This part contains code to p
Currently, xen_pt_update_entry() is only able to update the region covered
by xen_second (i.e 0 to 0x7fff).
Because of the restriction we end to have multiple functions in mm.c
modifying the page-tables differently.
Furthermore, we never walked the page-tables fully. This means that any
chang
set_pte_flags_on_range() is yet another function that will open-code
update to a specific range in the Xen page-tables. It can be completely
dropped by using either modify_xen_mappings() or destroy_xen_mappings().
Note that modify_xen_mappings() will keep the field 'pxn' cleared for
the all the ca
Currently, the virtual address of the 3rd level page-tables is obtained
using mfn_to_virt().
On Arm32, mfn_to_virt can only work on xenheap page. While in theory
all the page-tables updated will reside in xenheap, in practice the
page-tables covering Xen memory (e.g xen_mapping) is part of Xen bin
The enum xenmap_operation is not used anymore. So remove it.
Signed-off-by: Julien Grall
Reviewed-by: Andrii Anisov
Acked-by: Stefano Stabellini
---
Changes in v3:
- Add Stefano's acked-by
Changes in v2:
- Add Andrii's reviewed-by
---
xen/arch/arm/mm.c | 24 --
On 12/06/2019 19:59, Julien Grall wrote:
Hi Stefano,
On 5/2/19 12:30 AM, Stefano Stabellini wrote:
Improve Dom0-less documentation: include a complete configuration
example.
Signed-off-by: Stefano Stabellini
diff --git a/docs/features/dom0less.pandoc b/docs/features/dom0less.pandoc
index 4
flight 137677 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137677/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a
test-armhf-armhf-xl-cubietruck 1 build-che
On Fri, 14 Jun 2019, Julien Grall wrote:
> On 12/06/2019 19:59, Julien Grall wrote:
> > Hi Stefano,
> >
> > On 5/2/19 12:30 AM, Stefano Stabellini wrote:
> > > Improve Dom0-less documentation: include a complete configuration
> > > example.
> > >
> > > Signed-off-by: Stefano Stabellini
> > >
>
flight 137697 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137697/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 137600
build-arm64-xsm
flight 137696 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137696/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-qcow2 10 debian-di-install fail REGR. vs. 137604
Tests which did not suc
flight 137732 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137732/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
They're the default.
Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.
Signed-off-by: Daniel Vetter
Cc: Oleksandr Andrushchenko
Cc: xen-devel@lists.xenproject.org
---
drivers/gpu/drm/xen/xen_drm_front.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/g
Split out to make the functional changes stick out more.
v2: amdgpu gained DRIVER_SYNCOBJ_TIMELINE.
v3: amdgpu lost DRIVER_SYNCOBJ_TIMELINE.
Signed-off-by: Daniel Vetter
Cc: amd-...@lists.freedesktop.org
Cc: etna...@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Cc: intel-...@lists.f
On Wed, 12 Jun 2019, Julien Grall wrote:
> (Moving from xen-users to xen-devel).
>
> On 11/06/2019 23:18, Stefano Stabellini wrote:
> > I managed to reproduced the issue, and I know how to get past it. Try
> > using the raw kernel Image (arch/arm64/boot/Image) instead of Image.gz
> > for dom0 and
On Fri, 14 Jun 2019, Julien Grall wrote:
> set_pte_flags_on_range() is yet another function that will open-code
> update to a specific range in the Xen page-tables. It can be completely
> dropped by using either modify_xen_mappings() or destroy_xen_mappings().
>
> Note that modify_xen_mappings() w
On Fri, 14 Jun 2019, Julien Grall wrote:
> Currently, the virtual address of the 3rd level page-tables is obtained
> using mfn_to_virt().
>
> On Arm32, mfn_to_virt can only work on xenheap page. While in theory
> all the page-tables updated will reside in xenheap, in practice the
> page-tables cov
On Fri, 14 Jun 2019, Julien Grall wrote:
> The code handling Xen PT update has quite a few restrictions on what it
> can do. This is not a bad thing as it keeps the code simple.
>
> There are already a few checks scattered in current page table handling.
> However they are not sufficient as they c
On Fri, 14 Jun 2019, Julien Grall wrote:
> At the moment, the flags are not enough to describe what kind of update
> will done on the VA range. They need to be used in conjunction with the
> enum xenmap_operation.
>
> It would be more convenient to have all the information for the update
> in a si
On Fri, 14 Jun 2019, Julien Grall wrote:
> The current value of HSCTLR_BASE for Arm64 is pretty wrong. It would
> actually turn on SCTLR_EL2.nAA (bit 6) on hardware implementing
> ARMv8.4-LSE.
>
> Furthermore, the documentation of what is cleared/set in SCTLR_EL2 is
> also not correct and looks li
Hi Daniel.
Minor nitpick..
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 65d599065709..4fd09a9ad67a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -3193,7 +3193,7 @@ static struct drm_driver driver = {
>
flight 137686 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137686/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 133580
test-amd64-amd64-xl
flight 137705 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137705/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-pvshim12 guest-start fail never pass
test-amd64-i386-libvirt 13 migrat
flight 137717 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137717/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 16
guest-start/debianhvm.repeat fail in 137641 pass in 137717
t
94 matches
Mail list logo
