branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict
testid debian-hvm-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
On Wed, Oct 09, 2019 at 03:31:49PM +0200, Jan Beulich wrote:
> On 09.10.2019 14:27, Marek Marczykowski-Górecki wrote:
> > But then, Linux won't have EFI system table pointer either, no? I don't
> > see Xen passing it over in any way.
>
> Making the system table pointer available e.g. to kexec
flight 142470 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142470/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 142430 REGR.
vs. 139698
Tests
On 09.10.19 20:21, Andrew Cooper wrote:
c/s c0902a9a143a refactored hvm_enable() a little, but dropped the logic which
cleared hap_supported in the case that the user had asked for it off.
This results in Xen booting up, claiming:
(XEN) HVM: Hardware Assisted Paging (HAP) detected but
Hi,
Questions and comments below...
Thanks.
On 10/9/19 3:53 AM, Daniel Kiper wrote:
> Suggested-by: H. Peter Anvin
> Signed-off-by: Daniel Kiper
> Reviewed-by: Konrad Rzeszutek Wilk
> Reviewed-by: Ross Philipson
> ---
> ---
> Documentation/x86/boot.rst | 121
>
flight 142495 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142495/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 142423
flight 142485 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142485/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs.
133580
On Wed, 9 Oct 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 09/10/2019 00:12, Stefano Stabellini wrote:
> > 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
make_cpus_node() is using a static buffer to generate the FDT node name.
While mpdir_aff is a 64-bit integer, we only ever use the bits [23:0] as
only AFF{0, 1, 2} are supported for now.
To avoid any potential issues in the future, check that mpdir_aff has
only bits [23:0] set.
Take the
On 04.10.2019 19:28, Andrew Cooper wrote:
> On 04/10/2019 14:30, Jan Beulich wrote:
>> On 04.10.2019 15:18, Andrew Cooper wrote:
>>> On 26/09/2019 15:28, Jan Beulich wrote:
@@ -1068,8 +1067,29 @@ static void * __init allocate_ppr_log(st
On Wed, 9 Oct 2019, Steven Haigh wrote:
> For now, the only big issue that remains is that the current pygrub will
> always boot the second image in the list due to pygrub incorrectly parsing the
> failover sections of the Fedora grub.cfg where the failover will set
> 'default=1' causing this
On Wed, 9 Oct 2019 at 09:49, Jan Beulich wrote:
>
> On 08.10.2019 18:38, Andrew Cooper wrote:
> > 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
flight 142431 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142431/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 133580
On 08.10.2019 20:30, Andrew Cooper wrote:
> 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
On 09.10.2019 11:05, Roger Pau Monne wrote:
> @@ -411,6 +411,7 @@ int pt_irq_create_bind(
>
> pirq_dpci->gmsi.gvec = pt_irq_bind->u.msi.gvec;
> pirq_dpci->gmsi.gflags = gflags;
> +prev_vcpu_id = pirq_dpci->gmsi.dest_vcpu_id;
If this and ...
>
On 10/9/19 11:16 AM, Jan Beulich wrote:
> On 08.10.2019 18:38, Andrew Cooper wrote:
>> 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
On Wed, Oct 09, 2019 at 10:56:56AM +0200, Jan Beulich wrote:
> On 08.10.2019 18:29, 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()
On 09.10.2019 12:31, Marek Marczykowski-Górecki wrote:
> On Wed, Oct 09, 2019 at 10:56:56AM +0200, Jan Beulich wrote:
>> On 08.10.2019 18:29, 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
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 going to be cleared until a
call to PHYSDEVOP_prepare_msix is performed. Such call however
shouldn't be part of the
When using posted interrupts and the guest migrates MSI from vCPUs Xen
needs to flush any pending PIRR vectors on the previous vCPU, or else
those vectors could get wrongly injected at a later point when the MSI
fields are already updated.
Rename sync_pir_to_irr to vlapic_sync_pir_to_irr and
On 09.10.19 12:21, George Dunlap wrote:
On 10/9/19 11:16 AM, Jan Beulich wrote:
On 08.10.2019 18:38, Andrew Cooper wrote:
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
On 09.10.2019 12:11, Roger Pau Monné wrote:
> And it does print the following when setting up the iommu:
>
> (XEN) ioapic 0 pin 0 not masked
> (XEN) vec=00 delivery=ExINT dest=P status=0 polarity=0 irr=0 trig=E mask=0
> dest_id:0001
>
> I wonder, shouldn't all pins of all the io-apics be
> On 7 Oct 2019, at 11:01, Ian Jackson wrote:
>
> Hi. Thanks for the message.
>
> Just one thing I wanted to reply to in your mail:
>
> YOUNG, MICHAEL A. writes ("Re: [Xen-devel] [PATCH] read grubenv and set
> default from saved_entry or next_entry [and 1 more messages]"):
>> On Wed, 11
On 08.10.2019 21:27, Andrew Cooper wrote:
> 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
Acked-by: Jan Beulich
___
Xen-devel mailing list
On 10/8/19 5:10 PM, 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
On 08.10.2019 18:38, Andrew Cooper wrote:
> 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
Lars Kurth writes ("Re: [Xen-devel] [PATCH] read grubenv and set default from
saved_entry or next_entry [and 1 more messages]"):
> I am assuming there is no chance that this will make 4.13 with the freeze
> having passed.
Assuming we can get good quality patches, I would probably support a
flight 142436 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142436/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 142323
test-amd64-i386-xl-pvshim12
Thanks Michael,
In the meantime, we're looking at just disabling BLS by default in the
grub packages within Fedora when its run on a Xen guest. This means we
should at least be at a point where Fedora guests will work reliably
again as Xen guests.
It seems to be agreed that this will stay
flight 142486 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142486/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 98d1dac88f82c2b79d528faabe5e3fda8133e8bb
baseline version:
xen
On Wed, Oct 09, 2019 at 12:08:50PM +0200, Jan Beulich wrote:
> On 09.10.2019 11:05, Roger Pau Monne wrote:
> > @@ -411,6 +411,7 @@ int pt_irq_create_bind(
> >
> > pirq_dpci->gmsi.gvec = pt_irq_bind->u.msi.gvec;
> > pirq_dpci->gmsi.gflags = gflags;
> > +
On Wed, Oct 09, 2019 at 12:50:09PM +0200, Jan Beulich wrote:
> On 09.10.2019 12:31, Marek Marczykowski-Górecki wrote:
> > On Wed, Oct 09, 2019 at 10:56:56AM +0200, Jan Beulich wrote:
> >> On 08.10.2019 18:29, Marek Marczykowski-Górecki wrote:
> >>> On Tue, Oct 08, 2019 at 04:19:13PM +0200, Jan
On Wed, 9 Oct 2019, Steven Haigh wrote:
> 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
On 08.10.2019 18:38, Andrew Cooper wrote:
> 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
On 08.10.2019 18:29, 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 services code/data, to make
On 09.10.2019 10:33, 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 going to be cleared until a
> call to PHYSDEVOP_prepare_msix is
On 09.10.19 11:35, Jan Beulich wrote:
On 08.10.2019 21:27, Andrew Cooper wrote:
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
Acked-by: Jan Beulich
Release-acked-by: Juergen Gross
On Wed, Oct 09, 2019 at 11:31:59AM +0200, Jan Beulich wrote:
> On 08.10.2019 20:30, Andrew Cooper wrote:
> > 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
On 09.10.2019 12:20, Roger Pau Monné wrote:
> On Wed, Oct 09, 2019 at 12:08:50PM +0200, Jan Beulich wrote:
>> Considering that hvm_girq_dest_2_vcpu_id() isn't really inexpensive,
>> subsequent cleanup may then involve avoiding to call this function
>> if we'd overwrite .dest_vcpu_id as per above
The relationships between the headers are analogous to the various data
sections:
setup_header = .data
boot_params/setup_data = .bss
What is missing from the above list? That's right:
kernel_info = .rodata
We have been (ab)using .data for things that could go into .rodata or .bss for
a
The setup_data is a bit awkward to use for extremely large data objects,
both because the setup_data header has to be adjacent to the data object
and because it has a 32-bit length field. However, it is important that
intermediate stages of the boot process have a way to identify which
chunks of
This field contains maximal allowed type for setup_data.
Now bump the setup_header version in arch/x86/boot/header.S.
Suggested-by: H. Peter Anvin
Signed-off-by: Daniel Kiper
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Ross Philipson
---
Documentation/x86/boot.rst | 9
Hi,
Due to very limited space in the setup_header this patch series introduces new
kernel_info struct which will be used to convey information from the kernel to
the bootloader. This way the boot protocol can be extended regardless of the
setup_header limitations. Additionally, the patch series
On Wed, Oct 09, 2019 at 12:41:05PM +0200, Jan Beulich wrote:
> On 09.10.2019 12:11, Roger Pau Monné wrote:
> > And it does print the following when setting up the iommu:
> >
> > (XEN) ioapic 0 pin 0 not masked
> > (XEN) vec=00 delivery=ExINT dest=P status=0 polarity=0 irr=0 trig=E mask=0
> >
On 10/8/19 10:41 PM, Rob Herring wrote:
> 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
On 09.10.2019 13:52, Marek Marczykowski-Górecki wrote:
> On Wed, Oct 09, 2019 at 01:48:38PM +0200, Jan Beulich wrote:
>> On 09.10.2019 13:00, Marek Marczykowski-Górecki wrote:
>>> On Wed, Oct 09, 2019 at 12:50:09PM +0200, Jan Beulich wrote:
On 09.10.2019 12:31, Marek Marczykowski-Górecki
flight 142443 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142443/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 142318
test-amd64-i386-xl-qemut-win7-amd64 17
On 09.10.2019 14:21, Marek Marczykowski-Górecki wrote:
> On Wed, Oct 09, 2019 at 02:07:05PM +0200, Jan Beulich wrote:
>> On 09.10.2019 13:52, Marek Marczykowski-Górecki wrote:
>>> I'm talking about Xen->Xen transition here. How system table pointer is
>>> passed from old Xen to new Xen instance?
On Wed, Oct 09, 2019 at 01:48:38PM +0200, Jan Beulich wrote:
> On 09.10.2019 13:00, Marek Marczykowski-Górecki wrote:
> > On Wed, Oct 09, 2019 at 12:50:09PM +0200, Jan Beulich wrote:
> >> On 09.10.2019 12:31, Marek Marczykowski-Górecki wrote:
> >>> BTW How runtime services work after kexec? I
On Wed, Oct 09, 2019 at 02:07:05PM +0200, Jan Beulich wrote:
> On 09.10.2019 13:52, Marek Marczykowski-Górecki wrote:
> > On Wed, Oct 09, 2019 at 01:48:38PM +0200, Jan Beulich wrote:
> >> On 09.10.2019 13:00, Marek Marczykowski-Górecki wrote:
> >>> On Wed, Oct 09, 2019 at 12:50:09PM +0200, Jan
On Tue, Sep 17, 2019 at 03:14:03PM +0900, Masami Hiramatsu wrote:
> Hi Peter,
>
> Could you review this version?
These look good to me; shall I merge them or what was the plan?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On 09.10.2019 14:27, Marek Marczykowski-Górecki wrote:
> On Wed, Oct 09, 2019 at 02:24:31PM +0200, Jan Beulich wrote:
>> On 09.10.2019 14:21, Marek Marczykowski-Górecki wrote:
>>> On Wed, Oct 09, 2019 at 02:07:05PM +0200, Jan Beulich wrote:
On 09.10.2019 13:52, Marek Marczykowski-Górecki
On Wed, Oct 09, 2019 at 02:03:12PM +0200, Jan Beulich wrote:
> On 09.10.2019 13:29, Roger Pau Monné wrote:
> > On Wed, Oct 09, 2019 at 12:41:05PM +0200, Jan Beulich wrote:
> >> On 09.10.2019 12:11, Roger Pau Monné wrote:
> >>> And it does print the following when setting up the iommu:
> >>>
>
On 10/9/19 11:23 AM, Jürgen Groß wrote:
>> Regardless of the merits of the change Andy wants to see, it's not a one
>> that should be made during a feature freeze.
>
> Indeed. So either we take this patch or we have to revert the patch(es)
> introducing the regression.
Actually, just chatting
On Wed, Oct 09, 2019 at 10:33:21AM +0200, 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 going to be cleared until a
>call to
On 09.10.2019 13:00, Marek Marczykowski-Górecki wrote:
> On Wed, Oct 09, 2019 at 12:50:09PM +0200, Jan Beulich wrote:
>> On 09.10.2019 12:31, Marek Marczykowski-Górecki wrote:
>>> BTW How runtime services work after kexec? I don't see EFI handles
>>> handed over kexec, are they somehow
Hi Julien
On Fri, 2019-10-04 at 17:42 +0100, Julien Grall wrote:
> flask_assign_{, dt}device() may be used to check whether you can test
> if
> a device is assigned. In this case, the domain will be NULL.
>
> However, flask_iommu_resource_use_perm() will be called and may end
> up
> to deference
On 09.10.2019 13:29, Roger Pau Monné wrote:
> On Wed, Oct 09, 2019 at 12:41:05PM +0200, Jan Beulich wrote:
>> On 09.10.2019 12:11, Roger Pau Monné wrote:
>>> And it does print the following when setting up the iommu:
>>>
>>> (XEN) ioapic 0 pin 0 not masked
>>> (XEN) vec=00 delivery=ExINT dest=P
On 09.10.2019 14:52, Roger Pau Monne wrote:
> When using posted interrupts and the guest migrates MSI from vCPUs Xen
> needs to flush any pending PIRR vectors on the previous vCPU, or else
> those vectors could get wrongly injected at a later point when the MSI
> fields are already updated.
>
>
flight 142455 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142455/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 142423
On Wed, Oct 09, 2019 at 02:24:31PM +0200, Jan Beulich wrote:
> On 09.10.2019 14:21, Marek Marczykowski-Górecki wrote:
> > On Wed, Oct 09, 2019 at 02:07:05PM +0200, Jan Beulich wrote:
> >> On 09.10.2019 13:52, Marek Marczykowski-Górecki wrote:
> >>> I'm talking about Xen->Xen transition here. How
When using posted interrupts and the guest migrates MSI from vCPUs Xen
needs to flush any pending PIRR vectors on the previous vCPU, or else
those vectors could get wrongly injected at a later point when the MSI
fields are already updated.
Rename sync_pir_to_irr to vlapic_sync_pir_to_irr and
On 09.10.2019 16:14, George Dunlap wrote:
> On 10/9/19 11:23 AM, Jürgen Groß wrote:
>>> Regardless of the merits of the change Andy wants to see, it's not a one
>>> that should be made during a feature freeze.
>>
>> Indeed. So either we take this patch or we have to revert the patch(es)
>>
On 10/9/19 3:28 PM, Jan Beulich wrote:
> On 09.10.2019 16:14, George Dunlap wrote:
>> On 10/9/19 11:23 AM, Jürgen Groß wrote:
Regardless of the merits of the change Andy wants to see, it's not a one
that should be made during a feature freeze.
>>>
>>> Indeed. So either we take this patch
Hi Artem,
On 09/10/2019 15:20, Artem Mygaiev wrote:
cnt is unsigned, so always >=0
Coverity-ID: 1381848
Signed-off-by: Artem Mygaiev
Acked-by: Julien Grall
---
xen/drivers/char/scif-uart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/drivers/char/scif-uart.c
On 09.10.2019 15:56, Roger Pau Monné wrote:
> On Wed, Oct 09, 2019 at 02:03:12PM +0200, Jan Beulich wrote:
>> On 09.10.2019 13:29, Roger Pau Monné wrote:
>>> Right, then I guess we either mask all the io-apic pins or we setup
>>> proper remapping entries for non-masked pins? (in order to avoid
On 08/10/2019 18:21, Oleksandr wrote:
Hi, all
Hi,
Gentle reminder...
Sorry this fell through the cracks. I have now committed it.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
flight 142450 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142450/
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
Hi Stewart,
Sorry for the delay in answer.
On 04/10/2019 01:47, Stewart Hildebrand wrote:
Both upstream [1] and downstream [2] Linux kernels use "brcm,bcm2711"
as the compatible string for Raspberry Pi 4. Add this string to our
platform compatible list.
Did the RPI foundation released any
Also do not set mark device as SMMU protected when there are no more
SMMU resources left
Coverity-ID: 1381862
Signed-off-by: Artem Mygaiev
---
xen/drivers/passthrough/arm/smmu.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/xen/drivers/passthrough/arm/smmu.c
... for both lock and unlock
Coverity-ID: 1381840
Signed-off-by: Artem Mygaiev
---
xen/xsm/flask/avc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/xsm/flask/avc.c b/xen/xsm/flask/avc.c
index 87ea38b7a0..3a9507f62a 100644
--- a/xen/xsm/flask/avc.c
+++
cnt is unsigned, so always >=0
Coverity-ID: 1381848
Signed-off-by: Artem Mygaiev
---
xen/drivers/char/scif-uart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/drivers/char/scif-uart.c b/xen/drivers/char/scif-uart.c
index fa0b8274ca..9d3f66b55b 100644
---
From: Artem Mygaiev
There is a big amount of insignificant or false positives reported by
Coverity, fixing some of them can at least make code more consistent or
at least bit more readable.
Artem Mygaiev (3):
Consistent use for lock variables
Remove useless ASSERT condition
Free
Hi Stefano,
On 09/10/2019 00:12, Stefano Stabellini wrote:
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.
Hi Artem,
On 09/10/2019 15:20, Artem Mygaiev wrote:
Also do not set mark device as SMMU protected when there are no more
SMMU resources left
This is a sanity check on the content of the node, not a lack of resource in
this case.
TBH, the current placement is probably not correct. But I am
On Tue, Oct 08, 2019 at 10:39:11AM +0200, Roger Pau Monné wrote:
> On Sat, Oct 05, 2019 at 10:35:11AM +, tosher 1 wrote:
> > 3. How xenbus directories are created? What is the hierarchy of the
> > directories?
>
> They are created by the toolstack during domain creation: xl/libxl.
> There
flight 142488 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142488/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 141501
Tests which did
On Wednesday, October 9, 2019 11:30 AM, Julien Grall
wrote:
>On 04/10/2019 01:47, Stewart Hildebrand wrote:
>> Both upstream [1] and downstream [2] Linux kernels use "brcm,bcm2711"
>> as the compatible string for Raspberry Pi 4. Add this string to our
>> platform compatible list.
>
>Did the RPI
It's possible for a misconfigured device tree to cause Xen to crash when
there are overlapping addresses in the memory modules. Add a warning
when printing the addresses to let the user know there's a possible
issue when DEBUG is enabled.
Signed-off-by: Brian Woods
---
sample output:
...
(XEN)
flight 142476 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142476/
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. 142252
Tests which did not
c/s c0902a9a143a refactored hvm_enable() a little, but dropped the logic which
cleared hap_supported in the case that the user had asked for it off.
This results in Xen booting up, claiming:
(XEN) HVM: Hardware Assisted Paging (HAP) detected but disabled
but with HAP advertised via sysctl,
flight 142503 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142503/
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
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-win10-i386
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
On Wed, 9 Oct 2019 at 19:21, Andrew Cooper wrote:
>
> c/s c0902a9a143a refactored hvm_enable() a little, but dropped the logic which
> cleared hap_supported in the case that the user had asked for it off.
>
> This results in Xen booting up, claiming:
>
> (XEN) HVM: Hardware Assisted Paging
On Wed, 9 Oct 2019 at 19:21, Andrew Cooper wrote:
>
> c/s c0902a9a143a refactored hvm_enable() a little, but dropped the logic which
> cleared hap_supported in the case that the user had asked for it off.
>
> This results in Xen booting up, claiming:
>
> (XEN) HVM: Hardware Assisted Paging
Signed-off-by: Igor Druzhinin
---
xen/common/efi/boot.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 9a89414..6cef429 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1116,7 +1116,7 @@ static int __init
In some graphics modes firmware is allowed to return 0 in pixel reserved
bitmask which doesn't go against UEFI Spec 2.8 (12.9 Graphics Output Protocol).
Without this change non-TrueColor modes won't work which will cause
GOP init to fail - observed while trying to boot EFI Xen with Cirrus VGA.
If a bootloader is using native driver instead of EFI GOP it might
reset graphics mode to be different from what has been originally set
by firmware. While booting through MB2 Xen either need to parse video
setting passed by MB2 and use them instead of what GOP reports or
reset the mode to
Igor Druzhinin (3):
efi/boot: add missing pointer dereference in set_color
x86/efi: properly handle 0 in pixel reserved bitmask
efi/boot: make sure graphics mode is set while booting through MB2
xen/arch/x86/efi/efi-boot.h | 12 +---
xen/common/efi/boot.c | 10 +++---
2
flight 142462 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142462/
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
90 matches
Mail list logo
