Hi all,
I'm working on fixing up the grub packages for Fedora in deducing the
new BLS logic in Fedora and disabling it in non-compatible environments.
BZ Report:
https://bugzilla.redhat.com/show_bug.cgi?id=1703700
Currently, it seems that we can deduce the following two scenarios:
in /sys/hy
flight 142459 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142459/
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
flight 142430 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142430/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR.
vs. 139698
test-amd64-a
Some UEFI implementations are not happy about running in 1:1 addressing,
but really virtual address space. Specifically, some access
EfiBootServices{Code,Data}, or even totally unmapped areas. Example
crash of GetVariable() call on Thinkpad W540:
Xen call trace:
[<0080>] 000
Workaround buggy UEFI accessing boot services memory after ExitBootServices().
Patches discussed here:
https://lists.xenproject.org/archives/html/xen-devel/2019-08/msg00701.html
Cc: Juergen Gross
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad
Remove unused (#ifdef-ed out) code. Reviving it in its current shape
won't fly because:
- SetVirtualAddressMap() needs to be mapped with 1:1 mapping, which
isn't the case at this time
- it uses directmap, which is going away soon
- it uses directmap, which is mapped with NX, breaking EfiRunti
On Tue, Oct 08, 2019 at 06:29:27PM +0200, Marek Marczykowski-Górecki wrote:
> On Tue, Oct 08, 2019 at 04:19:13PM +0200, Jan Beulich wrote:
> > On 08.10.2019 15:52, Marek Marczykowski-Górecki wrote:
> > > Regardless of SetVirtualAddressMap() discussion, I propose to
> > > automatically map boot ser
The size of buf is calculated wrongly: the number is printed as a
hexadecimal number, so we need 8 bytes for 32bit, not 10 bytes.
As a result, it should be sizeof("cpu@") + 8 bytes for a 32-bit number +
1 byte for \0. Total = 13.
mpidr_aff is 64-bit, however, only bits [0-23] are used. Add a chec
flight 142417 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142417/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR.
vs. 141822
test-amd6
On Tue, 8 Oct 2019, Julien Grall wrote:
> On 10/8/19 1:18 AM, Stefano Stabellini wrote:
> > On Mon, 7 Oct 2019, Julien Grall wrote:
> > > Hi,
> > >
> > > On 03/10/2019 02:02, Stefano Stabellini wrote:
> > > > On Fri, 20 Sep 2019, Julien Grall wrote:
> > > > > That's not correct. alloc_boot_pages()
Hi Stefano,
On 08/10/2019 22:18, Stefano Stabellini wrote:
> On Tue, 8 Oct 2019, Julien Grall wrote:
>> On 10/8/19 2:14 AM, Stefano Stabellini wrote:
>>> The size of buf is calculated wrongly: the number is 64bit, not 32bit.
>>
>> While the variable mpdir_aff is 64-bit, we only write the first 32-
On Tue, 8 Oct 2019, Julien Grall wrote:
> On 10/8/19 2:14 AM, Stefano Stabellini wrote:
> > The size of buf is calculated wrongly: the number is 64bit, not 32bit.
>
> While the variable mpdir_aff is 64-bit, we only write the first 32-bit in the
> property reg (#address-cells == 1 and fdt_property_
flight 142427 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142427/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-qcow2 16 guest-start.2 fail REGR. vs. 142252
Tests which did not suc
As the removed comments say, these aren't DT based devices.
of_dma_configure() is going to stop allowing a NULL DT node and calling
it will no longer work.
The comment is also now out of date as of commit 9ab91e7c5c51 ("arm64:
default to the direct mapping in get_arch_dma_ops"). Direct mapping
is
This has actually been present since c/s bd7c09c0 in 2008, and survived
through all of the recent microcode refactoring.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Chao Gao
CC: Juergen Gross
This is a cosmetic nice-to-have which has no risk for 4.13
flight 142423 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142423/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 410c4d00d9f7e369d1ce183e9e8de98cb59c4d20
baseline version:
ovmf d19040804afb2bdd60f18
Hello,
I have no idea if this is a regression or not. I suspect it might not
be, and has always been broken.
Either way, I'm seeing occasional single interrupt remapping errors when
booting a range of Intel systems
(XEN) x2APIC mode is already enabled by BIOS.
(XEN) Using APIC driver x2apic_clu
Hi, all
Gentle reminder...
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
flight 142415 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142415/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
140282
test-amd64-i38
On 08/10/2019 17:10, Jan Beulich wrote:
> From: Paul Durrant
>
> Now that xl.cfg has an option to explicitly enable IOMMU mappings for a
> domain, migration may be needlessly vetoed due to the check of
> is_iommu_enabled() in paging_log_dirty_enable().
> There is actually no need to prevent logdir
On Tue, Oct 08, 2019 at 04:19:13PM +0200, Jan Beulich wrote:
> On 08.10.2019 15:52, Marek Marczykowski-Górecki wrote:
> > On Tue, Oct 08, 2019 at 03:08:29PM +0200, Jan Beulich wrote:
> >> On 08.10.2019 13:50, Marek Marczykowski-Górecki wrote:
> >>> I explored it a bit more and talked with a few p
On 08.10.2019 13:31, Jan Beulich wrote:
> On 08.10.2019 13:15, Roger Pau Monné wrote:
>> On Tue, Oct 08, 2019 at 12:42:25PM +0200, Jürgen Groß wrote:
>>> On 07.10.19 22:56, osstest service owner wrote:
flight 142383 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/log
From: Paul Durrant
Now that xl.cfg has an option to explicitly enable IOMMU mappings for a
domain, migration may be needlessly vetoed due to the check of
is_iommu_enabled() in paging_log_dirty_enable().
There is actually no need to prevent logdirty from being enabled unless
devices are assigned t
On 08.10.19 00:02, Julien Grall wrote:
Hi,
Hi Julien
But, this is clearly what happen in current Xen setup if the driver is
not enabled. What I want to avoid is exposing an half complete
bindings to the guest (you don't know how it will behave).
So we either remove all the properties and n
From: Oleksandr Tyshchenko
We don't passthrough IOMMU device to hwdom even if it is not used by Xen.
Therefore exposing the properties that describe relationship between
master devices and IOMMUs does not make any sense.
According to the:
1. Documentation/devicetree/bindings/iommu/iommu.txt
2. D
On 08.10.2019 16:16, Roger Pau Monné wrote:
> On Tue, Oct 08, 2019 at 03:32:25PM +0200, Jan Beulich wrote:
>> On 08.10.2019 15:14, Roger Pau Monné wrote:
>>> On Tue, Oct 08, 2019 at 01:28:49PM +0200, Jan Beulich wrote:
On 08.10.2019 13:09, Roger Pau Monné wrote:
> Given that as you corr
On 08.10.2019 15:52, Marek Marczykowski-Górecki wrote:
> On Tue, Oct 08, 2019 at 03:08:29PM +0200, Jan Beulich wrote:
>> On 08.10.2019 13:50, Marek Marczykowski-Górecki wrote:
>>> On Thu, Aug 08, 2019 at 08:03:49AM +0200, Jan Beulich wrote:
On 08.08.2019 04:53, Marek Marczykowski-Górecki wr
On Tue, Oct 08, 2019 at 03:32:25PM +0200, Jan Beulich wrote:
> On 08.10.2019 15:14, Roger Pau Monné wrote:
> > On Tue, Oct 08, 2019 at 01:28:49PM +0200, Jan Beulich wrote:
> >> On 08.10.2019 13:09, Roger Pau Monné wrote:
> >>> Given that as you correctly point out maskall is unset after device
>
From: Oleksandr Grytsov
Currently backend path is remove for specific devices: VBD, VIF, QDISK.
This commit adds removing backend path for: VDISPL, VSND, VINPUT.
Signed-off-by: Oleksandr Grytsov
---
tools/libxl/libxl_device.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
From: Oleksandr Grytsov
There are two kind of VKBD devices: with QEMU backend and user space
backend. In current implementation they can't be distinguished as both use
VKBD backend type. As result, user space KBD backend is started and
stopped as QEMU backend. This commit adds new device kind VIN
From: Oleksandr Grytsov
We have added VKBD device with user space PV backend. But libxl can't
differentiate domain kind for this device. As result, it performs QEMU procedure
for adding and removing VKB device with user space backend. To fix this issue,
new device kind VINPUT is introduced. It is
flight 142412 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142412/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 7 xen-boot fail REGR. vs. 142318
test-armhf-armhf-libv
(+ Juergen)
Hi Stefano,
On 10/8/19 1:18 AM, Stefano Stabellini wrote:
On Mon, 7 Oct 2019, Julien Grall wrote:
Hi,
On 03/10/2019 02:02, Stefano Stabellini wrote:
On Fri, 20 Sep 2019, Julien Grall wrote:
That's not correct. alloc_boot_pages() is actually here to allow dynamic
allocation befor
On Tue, Oct 08, 2019 at 03:08:29PM +0200, Jan Beulich wrote:
> On 08.10.2019 13:50, Marek Marczykowski-Górecki wrote:
> > On Thu, Aug 08, 2019 at 08:03:49AM +0200, Jan Beulich wrote:
> >> On 08.08.2019 04:53, Marek Marczykowski-Górecki wrote:
> >>> On Wed, Aug 07, 2019 at 09:26:00PM +0200, Marek
On 08.10.2019 15:14, Roger Pau Monné wrote:
> On Tue, Oct 08, 2019 at 01:28:49PM +0200, Jan Beulich wrote:
>> On 08.10.2019 13:09, Roger Pau Monné wrote:
>>> Given that as you correctly point out maskall is unset after device
>>> reset, I feel that option 4 is the best one since it matches the st
On 08.10.2019 15:06, osstest service owner wrote:
> branch xen-unstable
> xenbranch xen-unstable
> job test-amd64-i386-qemuu-rhel6hvm-amd
> testid xen-boot
>
> Tree: linux
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/li
On Tue, Oct 08, 2019 at 01:28:49PM +0200, Jan Beulich wrote:
> On 08.10.2019 13:09, Roger Pau Monné wrote:
> > Given that as you correctly point out maskall is unset after device
> > reset, I feel that option 4 is the best one since it matches the state
> > of the hardware after reset.
>
> Right,
On 03/10/2019, 21:56, "Andrew Cooper" wrote:
Creative Commons is a more common license than GPL for documentation
purposes.
Switch to using CC-BY-4.0 to explicitly permit re-purposing and remixing of
the content.
Signed-off-by: Andrew Cooper
Reviewed-by: Lars Kurth
Al
On 08.10.2019 13:50, Marek Marczykowski-Górecki wrote:
> On Thu, Aug 08, 2019 at 08:03:49AM +0200, Jan Beulich wrote:
>> On 08.08.2019 04:53, Marek Marczykowski-Górecki wrote:
>>> On Wed, Aug 07, 2019 at 09:26:00PM +0200, Marek Marczykowski-Górecki wrote:
Ok, regardless of adding proper opti
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-qemuu-rhel6hvm-amd
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Hi,
On 10/8/19 2:15 AM, Stefano Stabellini wrote:
When reserved-memory regions are present in the host device tree, dom0
is started with multiple memory nodes. Each memory node should have a
unique name, but today they are all called "memory" leading to Linux
printing the following warning at bo
On 10/8/19 2:15 AM, Stefano Stabellini wrote:
Call make_memory_node for reserved_memory only if we actually have any
reserved_memory regions to handle.
Add a check in make_memory_node to return an error if it has been called
with no memory banks as argument.
Fixes: 248faa637d2 (xen/arm: add r
flight 142410 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142410/
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
On 03/10/2019, 21:59, "Andrew Cooper" wrote:
Put together an introduction page for the Sphinx/RST docs, along with a
glossary which will accumulate over time.
Signed-off-by: Andrew Cooper
Reviewed-by: Lars Kurth
There were a few minor improvements which could be made, I am
On 03/10/2019, 21:56, "Andrew Cooper" wrote:
Sphinx, its linters, and RST modes in common editors, expect 3 spaces of
indentation. Some bits already conform to this expectation. Update the
rest to match.
Signed-off-by: Andrew Cooper
Reviewed-by: Lars Kurth
_
On Thu, Aug 08, 2019 at 08:03:49AM +0200, Jan Beulich wrote:
> On 08.08.2019 04:53, Marek Marczykowski-Górecki wrote:
> > On Wed, Aug 07, 2019 at 09:26:00PM +0200, Marek Marczykowski-Górecki wrote:
> > > Ok, regardless of adding proper option for that, I've hardcoded map_bs=1
> > > and it still cr
On 08.10.2019 13:15, Roger Pau Monné wrote:
> On Tue, Oct 08, 2019 at 12:42:25PM +0200, Jürgen Groß wrote:
>> On 07.10.19 22:56, osstest service owner wrote:
>>> flight 142383 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/142383/
>>>
>>> Regressions :-(
>>>
>>> Test
On 08.10.2019 13:09, Roger Pau Monné wrote:
> On Tue, Oct 08, 2019 at 11:42:23AM +0200, Jan Beulich wrote:
>> On 08.10.2019 11:23, Roger Pau Monné wrote:
>>> On Wed, Oct 02, 2019 at 03:33:43PM +0200, Jan Beulich wrote:
On 02.10.2019 12:49, Roger Pau Monne wrote:
> The current implementat
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemuu-win7-amd64
testid windows-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbi
Hi Stefano,
On 10/8/19 2:14 AM, Stefano Stabellini wrote:
The size of buf is calculated wrongly: the number is 64bit, not 32bit.
While the variable mpdir_aff is 64-bit, we only write the first 32-bit
in the property reg (#address-cells == 1 and fdt_property_cell()). So
what needs to be modif
On Tue, Oct 08, 2019 at 12:42:25PM +0200, Jürgen Groß wrote:
> On 07.10.19 22:56, osstest service owner wrote:
> > flight 142383 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/142383/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> >
On Tue, Oct 08, 2019 at 11:42:23AM +0200, Jan Beulich wrote:
> On 08.10.2019 11:23, Roger Pau Monné wrote:
> > On Wed, Oct 02, 2019 at 03:33:43PM +0200, Jan Beulich wrote:
> >> On 02.10.2019 12:49, Roger Pau Monne wrote:
> >>> The current implementation of host_maskall makes it sticky across
> >>>
On 07.10.19 22:56, osstest service owner wrote:
flight 142383 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142383/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair 22 guest-migrate/
On Tue, 8 Oct 2019 at 09:25, Jan Beulich wrote:
>
> On 01.10.2019 17:11, Paul Durrant wrote:
> > --- a/xen/arch/x86/mm/paging.c
> > +++ b/xen/arch/x86/mm/paging.c
> > @@ -209,15 +209,15 @@ static int paging_free_log_dirty_bitmap(struct domain
> > *d, int rc)
> > return rc;
> > }
> >
> > -in
On 08.10.2019 11:23, Roger Pau Monné wrote:
> On Wed, Oct 02, 2019 at 03:33:43PM +0200, Jan Beulich wrote:
>> On 02.10.2019 12:49, Roger Pau Monne wrote:
>>> The current implementation of host_maskall makes it sticky across
>>> assign and deassign calls, which means that once a guest forces Xen to
On 25.09.2019 17:27, Jan Beulich wrote:
> There's nothing to restore here if there's no FPU in the first place.
>
> Signed-off-by: Jan Beulich
> ---
> To be considered for 4.13 since RSTR_FP_ERR_PTRS support was introduced
> just recently.
And already release-acked by Jürgen.
Jan
> --- a/xen/t
On Wed, Oct 02, 2019 at 03:33:43PM +0200, Jan Beulich wrote:
> On 02.10.2019 12:49, Roger Pau Monne wrote:
> > The current implementation of host_maskall makes it sticky across
> > assign and deassign calls, which means that once a guest forces Xen to
> > set host_maskall the maskall bit is not goi
Hi all,
I won't be able to kick off the call on Thursday, but should be able to join
the last 30 minutes of the call. Juergen has volunteered to kick off and
moderate the call, but to do this we have to change the dial-in details. Please
use the following details
https://www.gotomeet.me/Juergen
flight 142407 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142407/
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. 142323
test-amd64-i386-qemu
On Sat, Oct 05, 2019 at 10:35:11AM +, tosher 1 wrote:
> I was trying to understand the following things regarding the PV driver.
>
> 1. Who create frontend and backend instances?
That depends on where the frontend and backends run. For example
Linux blkback is implemented as a module of the L
On 08.10.2019 02:38, Marek Marczykowski-Górecki wrote:
> To be honest, I think unions are very scary from security point of view.
> It's quite easy to use a field that in given context have very different
> meaning and easily results in security issue. In the most cases,
> compiler can't help you
On 01.10.2019 17:11, Paul Durrant wrote:
> --- a/xen/arch/x86/mm/paging.c
> +++ b/xen/arch/x86/mm/paging.c
> @@ -209,15 +209,15 @@ static int paging_free_log_dirty_bitmap(struct domain
> *d, int rc)
> return rc;
> }
>
> -int paging_log_dirty_enable(struct domain *d, bool_t log_global)
> +i
On 07.10.2019 18:13, George Dunlap wrote:
> On 9/27/19 10:14 AM, Jan Beulich wrote:
>> On 26.09.2019 21:39, Lars Kurth wrote:
>>> +### Verbose vs. terse
>>> +Due to the time it takes to review and compose code reviewer, reviewers
>>> often adopt a
>>> +terse style. It is not unusual to see review
On 08/10/2019 06:54, Roman Shaposhnik wrote:
> Sorry -- was traveling last week, but I'm still very curious to get to
> the bottom of this:
>
> On Tue, Oct 1, 2019 at 1:25 AM Jan Beulich wrote:
>> On 01.10.2019 00:38, Roman Shaposhnik wrote:
>>> Btw, forgot to attach the patch with maxcpus=2 -- in
64 matches
Mail list logo
