flight 138886 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138886/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 5c4a9b0e32c1f9c47d5b687d6036bb03c3cc071c
baseline version:
freebsd 14e63f898b1
flight 138880 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138880/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 6 xen-buildfail REGR. vs. 138376
build-i386-pre
flight 138878 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138878/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvhv2-intel 7 xen-boot fail REGR. vs. 133580
test-amd64-i386-exa
Denis,
Not sure if you gone through this - the interrupt routing is described in the
TRM chapter on interrupt controllers. In my edition (large file, don't want to
redownload unless needed.), this is chapter 17. Table 17-2 (in my edition)
should address a lot of what you are asking. It shows t
On 10.07.2019 18:17, Paul Durrant wrote:
> @@ -418,13 +417,7 @@ static void hvm_free_ioreq_mfn(struct hvm_ioreq_server
> *s, bool buf)
> unmap_domain_page_global(iorp->va);
> iorp->va = NULL;
>
> -/*
> - * Check whether we need to clear the allocation reference before
> -
flight 138894 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138894/
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 138875 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138875/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 6 xen-build fail in 138772 REGR. vs. 132889
build-i386-prev
Hi,
On 7/10/19 10:17 PM, Stefano Stabellini wrote:
> On Wed, 10 Jul 2019, Denis Obrezkov wrote:
>> Hi,
>>
>> On 7/10/19 9:49 PM, Stefano Stabellini wrote:
>>
>>>
>>> phandle = <0x0002>;
>>>
>>> I think that means that interrupts go to the GIC via Crossbar; i.e. the
>>> parent interrupt contr
flight 138877 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138877/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f527942e6bdd9f198db90f2de99a0482e9be5b1b
baseline version:
ovmf 8a842b31b93323ee3dc76
flight 138876 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138876/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 138850
test-armhf-armhf-libvirt-raw 13 saveresto
On Wed, 10 Jul 2019, Denis Obrezkov wrote:
> Hi,
>
> On 7/10/19 9:49 PM, Stefano Stabellini wrote:
>
> >
> > phandle = <0x0002>;
> >
> > I think that means that interrupts go to the GIC via Crossbar; i.e. the
> > parent interrupt controller of Crossbar is the GIC.
> >
> But the crossbar'
Hi,
On 7/10/19 9:49 PM, Stefano Stabellini wrote:
>
> phandle = <0x0002>;
>
> I think that means that interrupts go to the GIC via Crossbar; i.e. the
> parent interrupt controller of Crossbar is the GIC.
>
But the crossbar's interrupt-parent node is 0x0008 and phandle value
0x000
On Wed, 10 Jul 2019, Denis Obrezkov wrote:
> Hello,
>
> so, I think I understood why uart doesn't work, that's because all the
> irqs are routed to the crossbar not to GIC, so, xen can't deal with them.
>
> One thing I am concerned of is the:
> interrupt-controller@48281000 {
>
Hi,
@Stefano, I am going through the series and noticed you didn't give any
update. Could you confirm if my reply makes sense?
Cheers,
On 6/27/19 8:30 PM, Julien Grall wrote:
Hi Stefano,
On 6/27/19 7:55 PM, Stefano Stabellini wrote:
On Mon, 10 Jun 2019, Julien Grall wrote:
+1:
+ /*
Hi Andrew,
On 7/3/19 8:39 PM, Andrew Cooper wrote:
On 03/07/2019 14:06, Varad Gautam wrote:
When allocating the guest memory for an HVM domain, libxc keeps the P2M
mapping for the entirety of the guest memory around for the time of the
launch as xc_dom_image->p2m_host. For guests that have a la
Hi Stefano,
On 6/19/19 12:20 AM, Stefano Stabellini wrote:
Add a new memory policy option for the iomem parameter.
Possible values are:
- arm_dev_nGnRE, Device-nGnRE, the default on ARM
s/ARM/Arm/
- arm_mem_WB, WB cachable memory
- x86_UC_minus: uncachable memory, the default on x86
Store t
Hello,
so, I think I understood why uart doesn't work, that's because all the
irqs are routed to the crossbar not to GIC, so, xen can't deal with them.
One thing I am concerned of is the:
interrupt-controller@48281000 {
compatible = "ti,omap5-wugen-mpu", "ti,omap4-wugen-mp
Roger Pau Monne writes ("Re: [Xen-devel] [PATCH] libxl: fix pci device
re-assigning after domain reboot"):
> On Wed, Jun 26, 2019 at 03:37:26PM +0200, Juergen Gross wrote:
> > Signed-off-by: Juergen Gross
> > Tested-by: Chao Gao
>
> Reviewed-by: Roger Pau Monné
Committed, thanks.
Ian.
_
flight 138891 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138891/
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 138868 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138868/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 138826
test-amd64-amd64-xl-qemuu-win7-amd64
Hi,
On 6/19/19 12:20 AM, Stefano Stabellini wrote:
Reuse the existing padding field to pass memory policy information. On
Arm, the caller can specify whether the memory should be mapped as
Device-nGnRE (Device Memory on Armv7) at stage-2, which is the default
and the only possibility today, or c
Hi Stefano,
The Arm code looks good to me. One comment below.
On 6/19/19 12:20 AM, Stefano Stabellini wrote:
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index e28ea1c85a..d88df11e09 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1310,31 +1310,18 @@ static inline int p2m_r
Hi Stefano,
On 6/22/19 12:56 AM, Stefano Stabellini wrote:
Reserved memory regions are automatically remapped to dom0. Their device
tree nodes are also added to dom0 device tree. However, the dom0 memory
node is not currently extended to cover the reserved memory regions
ranges as required by th
Hi Stefano,
On 6/22/19 12:56 AM, Stefano Stabellini wrote:
Don't allow reserved-memory regions to be remapped into any guests,
until reserved-memory regions are properly supported in Xen. For now,
do not call iomem_permit_access for them.
Signed-off-by: Stefano Stabellini
---
Changes in v4:
-
The _PGC_allocated flag is set on a page when it is assigned to a domain
along with an initial reference count of 1. To clear this initial
reference count it is necessary to test-and-clear _PGC_allocated and then
only drop the reference if the test-and-clear succeeds. This is open-
coded in many pl
Hi Stefano,
On 6/22/19 12:56 AM, Stefano Stabellini wrote:
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 215746a5c3..d9cfb1aa2f 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -206,6 +206,28 @@ void __init dt_unreserved_regions(paddr_t s, paddr_t e,
}
Hi,
On 7/8/19 8:02 PM, Oleksandr wrote:
On 22.06.19 02:56, Stefano Stabellini wrote:
I have tested this series and got the same behavior as with V2 [1].
The "non-reserved-memory" node in my device-tree
(sram@47FFF000->scp_shmem@0) is still interpreted as a "reserved-memory".
I think, this take
Hi,
On 6/22/19 12:56 AM, Stefano Stabellini wrote:
As we parse the device tree in Xen, keep track of the reserved-memory
regions as they need special treatment (follow-up patches will make use
of the stored information.)
Reuse process_memory_node to add reserved-memory regions to the
bootinfo.r
Hi Stefano,
On 6/22/19 12:56 AM, Stefano Stabellini wrote:
Add two new parameters to device_tree_for_each_node: node and depth.
Node is the parent node to start the search from and depth is the min
depth of the search (the depth of the parent node). Passing 0, 0
triggers the old behavior.
We ne
Could we look at updating the wording of XSA-300 to make things a bit
more clear. I don't have exact wording suggestions but roughly some of
the questions I've fielded are:
1. Impact should make it clear there are two issues here. So its really
"and/or". Or a bulleted list.
2. Vulnerable Sy
On 07/04/19 16:41, Anthony PERARD wrote:
> Patch series available in this git branch:
> https://xenbits.xen.org/git-http/people/aperard/ovmf.git
> br.platform-xen-pvh-v3
>
> Hi,
>
> I've started to create a Xen specific platform, in OvmfPkg/XenOvmf.dsc
> with the goal to make it work on both Xen
On 07/04/19 16:42, Anthony PERARD wrote:
> XenIoPvhDxe use XenIoMmioLib to reserve some space to be use by the
> Grant Tables.
>
> The call is only done if it is necessary, we simply detect if the
> guest is PVH, as in this case there is currently no PCI bus, and no
> PCI Xen platform device which
On 7/9/19 10:07 PM, Zhenzhong Duan wrote:
> On 2019/7/9 22:54, Boris Ostrovsky wrote:
>> On 7/9/19 12:20 AM, Zhenzhong Duan wrote:
>>> -const __initconst struct hypervisor_x86 x86_hyper_xen_hvm = {
>>> +static uint32_t __init xen_platform_hvm(void)
>>> +{
>>> + uint32_t xen_domain = xen_cpuid
clang points out that the computation of LOWMEM_PAGES causes
a signed integer overflow on 32-bit x86:
arch/x86/kernel/head32.c:83:20: error: signed shift result (0x1)
requires 34 bits to represent, but 'int' only has 32 bits
[-Werror,-Wshift-overflow]
(PAGE_TABLE_SIZE(LOW
Guests can issue grant table operations and provide guest controlled
data to them. This data is used as index for memory loads after bound
checks have been done. Depending on the grant table version, the
size of elements in containers differ. As the base data structure is
a page, the number of elem
Guests can issue grant table operations and provide guest controlled
data to them. This data is used as index for memory loads after bound
checks have been done. To avoid speculative out-of-bound accesses, we
use the array_index_nospec macro where applicable, or the macro
block_speculation. Note, t
Dear all,
This patch series attempts to mitigate the issue that have been raised in the
XSA-289 (https://xenbits.xen.org/xsa/advisory-289.html). To block speculative
execution on Intel hardware, an lfence instruction is required to make sure
that selected checks are not bypassed. Speculative out-o
flight 138857 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138857/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail
REGR. vs. 138799
Test
On 09.07.19 17:28, Andrew Cooper wrote:
This is a vestigial remnent of the pre xenstored stub domain days.
Foreign mapping via MFN is a privileged operation which is not
necessary, because grant details are unconditionally set up during
domain construction. In practice, this means xenstored nev
On 09.07.19 17:28, Andrew Cooper wrote:
xenstored currently requires an libxc and evtchn interface, but leaves
the gnttab interface as optional.
gnttab is ubiquitous these days, and in practice mandatory in all cases
where xenstored isn't running as root in dom0 (due to the inability to
foreign
On 10.07.2019 08:10, osstest service owner wrote:
> flight 138852 xen-4.10-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/138852/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-amd64-prev
On 10.07.2019 10:54, Norbert Manthey wrote:
> On 7/10/19 05:04, Jan Beulich wrote:
>> On 08.07.2019 14:58, Norbert Manthey wrote:
>>> On 5/24/19 13:10, Jan Beulich wrote:
>>> On 24.05.19 at 11:54, wrote:
> On 5/23/19 16:17, Jan Beulich wrote:
> On 21.05.19 at 09:45, wrote:
>>>
On 7/10/19 05:12, Jan Beulich wrote:
> On 08.07.2019 15:53, Norbert Manthey wrote:
>> On 5/23/19 17:01, Jan Beulich wrote:
>> On 21.05.19 at 09:45, wrote:
* gnttab_set_version: all accessible data is allocated for both versions
>>> This is not enough for my taste: The very first loop is
On 07/04/19 16:42, Anthony PERARD wrote:
> On a Xen PVH guest, none of the existing serial or console interface
> works, so we add a new one, based on XenConsoleSerialPortLib, and
> implemented via SerialDxe.
>
> That is a simple console implementation that can works on both PVH
> guest and HVM gu
flight 138884 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138884/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 8706d38479218dcf549a94516918c3e3b30a7bb0
baseline version:
xen 843c
flight 138856 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138856/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
Tests which are fail
On 07/04/19 16:42, Anthony PERARD wrote:
> "PcAtChipsetPkg/8254TimerDxe" is replaced with a Xen-specific
> EFI_TIMER_ARCH_PROTOCOL implementation. Also remove
> 8259InterruptControllerDxe as it is not used anymore.
>
> This Timer uses the local APIC timer as time source as it can work on
> both a
On 07/04/19 16:42, Anthony PERARD wrote:
> When running in a Xen PVH guest, there's nothing to do in
> PciAcpiInitialization() because there isn't any PCI bus. When the Host
> Bridge DID isn't recognised, simply continue. (The value of
> PcdOvmfHostBridgePciDevId would be 0 because it isn't set.)
>
On 07/04/19 16:42, Anthony PERARD wrote:
> Replace the XenDetected() implementation by the one from
> XenPlatformLib.
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
> Signed-off-by: Anthony PERARD
> ---
>
> Notes:
> v3:
> - new patch
>
> .../PlatformBootManagerLib.inf
On 07/08/19 16:38, Laszlo Ersek wrote:
> On 07/04/19 16:42, Anthony PERARD wrote:
>> This patch replace the XenDetected() function by the one in
>> XenPlatformLib.
>>
>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
>> Signed-off-by: Anthony PERARD
>> ---
>>
>> Notes:
>> v3:
>>
On 07/04/19 16:42, Anthony PERARD wrote:
> We are going to replace XenDetected() implementation in
> PlatformBootManagerLib by the one in XenPlatformLib.
> PlatformBootManagerLib's implementation does cache the result of
> GetFirstGuidHob(), so we do something similar in XenPlatformLib.
>
> Ref: h
On 7/10/19 05:04, Jan Beulich wrote:
> On 08.07.2019 14:58, Norbert Manthey wrote:
>> On 5/24/19 13:10, Jan Beulich wrote:
>> On 24.05.19 at 11:54, wrote:
On 5/23/19 16:17, Jan Beulich wrote:
On 21.05.19 at 09:45, wrote:
>> --- a/xen/common/grant_table.c
>> +++ b/xen/com
52 matches
Mail list logo
