flight 130026 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130026/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 129475
build-amd64-xsm
>>> On 14.11.18 at 01:20, wrote:
> On Mon, Nov 12, 2018 at 01:17:59AM -0700, Jan Beulich wrote:
>> >>> On 09.11.18 at 18:16, wrote:
>> > LWP doesn't exist any more, even on the hardware it used to exist on.
>> > It was never implemented on Fam17h, and was removed from Fam15/16h in a
>> >
>>> On 13.11.18 at 23:02, wrote:
> On Tue, 13 Nov 2018, Jan Beulich wrote:
>> >>> On 13.11.18 at 14:17, wrote:
>> > On 13/11/2018 12:56, Jan Beulich wrote:
>> > On 13.11.18 at 00:06, wrote:
>> >>> @@ -33,8 +33,8 @@ static int init_percpu_area(unsigned int cpu)
>> >>> if ( (p =
On 11/14/18 9:35 AM, Tian, Kevin wrote:
+#ifdef CONFIG_HVM
+/* There's already a memory_type_changed() in asm/mtrr.h. */
+static void _memory_type_changed(struct p2m_domain *p2m)
+{
+if ( p2m->memory_type_changed )
+p2m->memory_type_changed(p2m);
}
> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
> Sent: Wednesday, November 14, 2018 3:33 PM
>
> On 11/14/18 7:55 AM, Tian, Kevin wrote:
> >> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
> >> Sent: Sunday, November 11, 2018 10:07 PM
> >>
> >> When an new altp2m view is
On 11/14/18 7:55 AM, Tian, Kevin wrote:
>> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
>> Sent: Sunday, November 11, 2018 10:07 PM
>>
>> When an new altp2m view is created very early on guest boot, the
>> display will freeze (although the guest will run normally). This
>> may also
On 11/14/18 7:44 AM, Tian, Kevin wrote:
>> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
>> Sent: Sunday, November 11, 2018 10:07 PM
>>
>> This patch is a pre-requisite for fixing the logdirty VGA issue
>> (display freezes when switching to a new altp2m view early in a
>> domain's
flight 130021 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130021/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 129475
build-amd64-xsm
flight 129791 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129791/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 16 guest-localmigrate/x10 fail
REGR. vs.
flight 129789 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129789/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR.
vs. 125898
> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
> Sent: Sunday, November 11, 2018 10:07 PM
>
> When an new altp2m view is created very early on guest boot, the
> display will freeze (although the guest will run normally). This
> may also happen on resizing the display. The reason is
> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
> Sent: Sunday, November 11, 2018 10:07 PM
>
> This patch is a pre-requisite for fixing the logdirty VGA issue
> (display freezes when switching to a new altp2m view early in a
> domain's lifetime), but sent separately for easier review.
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Friday, November 9, 2018 10:42 PM
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Kevin Tian
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Tuesday, November 6, 2018 8:08 PM
>
> Currently Xen tries to map bitmaps during emulation of vmptrld and
> vmwrite. This is wrong: a guest can store arbitrary values in those
> fields.
>
> Make bitmaps mapping happen only during a
flight 130017 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130017/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 129475
build-amd64-xsm
flight 130014 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130014/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129475
build-amd64
flight 130006 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130006/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129475
build-amd64
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, November 9, 2018 12:16 AM
>
> There's no need to go through an extra level of indirection. In order to
> limit code churn, call sites using struct domain_iommu's platform_ops
> don't get touched here, however.
>
> Signed-off-by: Jan
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Tuesday, November 6, 2018 8:08 PM
>
> The size of Xen's virtual vmcs region is 4096 bytes (see comment about
> Virtual VMCS layout in include/asm-x86/hvm/vmx/vvmx.h). Correctly
> report
> it to the guest in case when VMCS shadowing
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Tuesday, November 6, 2018 8:08 PM
>
> 1. Add VMX_INSN_VMCLEAR_WITH_VMXON_PTR errno and add the
> appropriate
>check to the function.
>
> 2. Correct the return value for not-4KB-aligned case and for invalid
>physaddr (when
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Tuesday, November 6, 2018 8:08 PM
>
> Calling vmfail_valid() is correct only if vvmcx is valid. Modify
> functions to use vmfail() instead which performs the necessary check.
>
> While at it, add ASSERTs into vmfail_valid/invalid()
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Tuesday, November 6, 2018 8:08 PM
>
> And use it in nvmx_handle_invept() and nvmx_handle_invvpid().
>
> Signed-off-by: Sergey Dyasli
Acked-by: Kevin Tian
___
Xen-devel mailing list
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Tuesday, November 6, 2018 8:08 PM
>
> As a convenient helper function and refactor the code to use it.
>
> No functional change.
>
> Signed-off-by: Sergey Dyasli
Reviewed-by: Kevin Tian
flight 130003 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130003/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129475
build-amd64
flight 13 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/13/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129475
build-amd64
The pull request you sent on Sat, 10 Nov 2018 14:46:12 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-4.20a-rc2-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ab6e1f378f546b0caa616ac0fcc730725cc2d222
Thank you!
--
Deet-doot-dot,
On Mon, Nov 12, 2018 at 01:17:59AM -0700, Jan Beulich wrote:
> >>> On 09.11.18 at 18:16, wrote:
> > On 06/11/18 16:16, Jan Beulich wrote:
> > On 06.11.18 at 16:52, wrote:
> >>> On 06/11/18 15:38, Jan Beulich wrote:
> >>> On 05.11.18 at 12:21, wrote:
> > They are identical, so
On Mon, 12 Nov 2018, Mirela Simonovic wrote:
> PSCI system suspend function shall be invoked to finalize Xen suspend
> procedure. Resume entry point, which needs to be passed via 1st argument
> of PSCI system suspend call to the EL3, is hyp_resume. For now, hyp_resume
> is just a placeholder that
flight 129995 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129995/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129475
build-amd64
On Mon, 12 Nov 2018, Mirela Simonovic wrote:
> System suspend may lead to a state where GIC would be powered down.
> Therefore, Xen should save/restore the context of GIC on suspend/resume.
> Note that the context consists of states of registers which are
> controlled by the hypervisor. Other GIC
On Tue, Nov 13, 2018 at 06:27:02PM +, Andrew Cooper wrote:
> This was accidentially dropped in c/s 889b200cb52 "Change timestamps
> representation for keyhandlers".
>
> Signed-off-by: Andrew Cooper
Acked-by: Wei Liu
___
Xen-devel mailing list
flight 129773 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129773/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 6 xen-install fail REGR. vs. 129514
On Tue, 13 Nov 2018 at 02:01, Julien Grall wrote:
> On 11/11/18 1:15 AM, Matthew Daley wrote:
> > Hi Julien,
>
> Hi Matthew,
>
> > On Sat, 10 Nov 2018 at 00:22, Julien Grall wrote:
> >>> Firstly, Xen fails to bring up any other CPUs but the one it is booting
> >>> on:
> >>>
> >>> (XEN) Bringing
On Mon, 12 Nov 2018, Mirela Simonovic wrote:
> The rcu_barrier() has to be added to ensure that the per cpu area is
> freed before a non-boot CPU tries to initialize it (_free_percpu_area()
> has to be called before the init_percpu_area()). This scenario occurs
> when non-boot CPUs are
On Mon, 12 Nov 2018, Mirela Simonovic wrote:
> These functions will be reused by suspend/resume support for ARM.
>
> Signed-off-by: Mirela Simonovic
> Signed-off-by: Saeed Nowshadi
> ---
> xen/arch/x86/acpi/power.c | 28
> xen/common/domain.c | 29
On Mon, 12 Nov 2018, Mirela Simonovic wrote:
> Non-boot CPUs have to be disabled on suspend and enabled on resume
> (hotplug-based mechanism). Disabling non-boot CPUs will lead to PSCI
> CPU_OFF to be called by each non-boot CPU. Depending on the underlying
> platform capabilities, this may lead
flight 129992 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129992/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129475
build-amd64
Hi,
On 11/13/18 9:35 PM, Stefano Stabellini wrote:
On Tue, 13 Nov 2018, Julien Grall wrote:
On 13/11/2018 01:36, Stefano Stabellini wrote:
On Mon, 12 Nov 2018, Julien Grall wrote:
On 11/12/18 11:30 AM, Mirela Simonovic wrote:
We can turn this assembly code into a .macro, so that at least
flight 129982 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129982/
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
On Tue, 13 Nov 2018, Jan Beulich wrote:
> >>> On 13.11.18 at 14:17, wrote:
> > On 13/11/2018 12:56, Jan Beulich wrote:
> > On 13.11.18 at 00:06, wrote:
> >>> --- a/xen/arch/x86/alternative.c
> >>> +++ b/xen/arch/x86/alternative.c
> >>> @@ -194,7 +194,7 @@ void init_or_livepatch
On Tue, 13 Nov 2018, Julien Grall wrote:
> Hi,
>
> On 13/11/2018 01:36, Stefano Stabellini wrote:
> > On Mon, 12 Nov 2018, Julien Grall wrote:
> > > On 11/12/18 11:30 AM, Mirela Simonovic wrote:
> > We can turn this assembly code into a .macro, so that at least when we
> > get around to it, we
flight 129987 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129987/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129475
build-amd64
On Mon, 12 Nov 2018, Julien Grall wrote:
> (+ Andre)
>
> On 11/12/18 5:42 PM, Mirela Simonovic wrote:
> > Hi Julien,
> >
> > On Mon, Nov 12, 2018 at 6:00 PM Julien Grall wrote:
> > >
> > >
> > >
> > > On 11/12/18 4:52 PM, Mirela Simonovic wrote:
> > > > Hi Julien,
> > >
> > > Hi,
> > >
> >
On Tue, 13 Nov 2018, Julien Grall wrote:
> > > > > > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > > > > > index e594b48d81..7f8105465c 100644
> > > > > > --- a/xen/arch/arm/domain.c
> > > > > > +++ b/xen/arch/arm/domain.c
> > > > > > @@ -97,6 +97,11 @@ static void
On Mon, 12 Nov 2018, Julien Grall wrote:
> > > However, what is the issue with saving all the registers here?
> > >
> >
> > We need to save arguments that are provided by a guest with system
> > suspend PSCI call. These arguments are the entry point that needs to
> > be saved in program counter
On 25/09/2018 14:35, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 25/09/2018 14:35, Jan Beulich wrote:
> @@ -7979,6 +7991,42 @@ x86_emulate(
> dst.type = OP_NONE;
> break;
>
> +case X86EMUL_OPC_EVEX_66(0x0f38, 0x18): /* vbroadcastss
> xmm/m32,[xyz]mm{k} */
> +generate_exception_if(evex.w || evex.br, EXC_UD);
> +
On 25/09/2018 14:34, Jan Beulich wrote:
> Plus vpternlog{d,q} as being extensively used by the compiler, in order
> to facilitate test enabling in the harness as soon as possible. Also the
> twobyte_table[] entries for a few more insns get their .d8s field set
> right away, in order to not split
On 25/09/2018 14:33, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
flight 129979 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129979/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129475
build-amd64
On 25/09/2018 14:33, Jan Beulich wrote:
> Also correct an AVX counterpart's comment.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
What do you consider "normal" here?
On 25/09/2018 14:32, Jan Beulich wrote:
> Also correct the AVX counterpart's comment.
>
> Signed-off-by: Jan Beulich
The content itself Acked-by: Andrew Cooper ,
but preferably with a better description.
___
On 11/13/18 8:43 PM, Razvan Cojocaru wrote:
> On 11/13/18 7:57 PM, George Dunlap wrote:
>> On 11/11/18 2:07 PM, Razvan Cojocaru wrote:
>> At the moment we essentially have two "init" states:
>> * After domain creation; altp2m structures allocated, but no rangesets, & c
>> * After being enabled for
On 25/09/2018 14:32, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
flight 129972 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129972/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 5 host-ping-check-native fail REGR. vs. 129960
Tests which
On 11/13/18 7:57 PM, George Dunlap wrote:
> On 11/11/18 2:07 PM, Razvan Cojocaru wrote:
>> This patch is a pre-requisite for the one fixing VGA logdirty
>> freezes when using altp2m. It only concerns itself with the
>> ranges allocation / deallocation / initialization part. While
>> touching the
This was accidentially dropped in c/s 889b200cb52 "Change timestamps
representation for keyhandlers".
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
CC: George Dunlap
CC: Andrii Anisov
---
xen/common/keyhandler.c | 4 ++--
1 file
On 25/09/2018 14:31, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
flight 129973 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129973/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129475
build-amd64
On 25/09/2018 14:30, Jan Beulich wrote:
> The more generic AVX512 implementation allows quite a bit of insn-
> specific code to be dropped/shared.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
On Tue, 13 Nov 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 13/11/2018 02:22, Stefano Stabellini wrote:
> > On Mon, 12 Nov 2018, Julien Grall wrote:
> > > Hi Mirela,
> > >
> > > Thank you for posting the series. Could you provide a branch with the
> > > patch
> > > applied?
> > >
> > > On
On 11/11/18 2:07 PM, Razvan Cojocaru wrote:
> This patch is a pre-requisite for the one fixing VGA logdirty
> freezes when using altp2m. It only concerns itself with the
> ranges allocation / deallocation / initialization part. While
> touching the code, I've switched global_logdirty from bool_t
>
Find addresses, sizes on device tree from kernel_probe.
Find the cmdline from the bootcmdlines array.
Introduce a new boot_module_find_by_addr_and_kind function to match not
just on boot module kind, but also by address so that we can support
multiple domains.
Introduce a
Introduce a union in struct vpl011 to contain the console ring members.
A later patch will add another member of the union for the case where
the backend is in Xen.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v4:
- name union "backend"
Changes in v3:
- rename ring
Hi all,
This is first step toward "dom0less" as discussed in the various
certifications related threads and discussions.
The goal of this series is to enable Xen to boot multiple domains in
parallel, in addition to dom0, out of information found on device tree.
The device tree based boot
Add a new start address field to struct bootcmdline to easily match a
cmdline to the corresponding bootmodule. This is useful for debugging
(not actually needed for functionalities today, but could be.)
Instead of printing the index in the cmdline array, print the start
address of the
Introduce a new array to store the cmdline of each boot module. It is
separate from struct bootmodules. Remove the cmdline field from struct
boot_module. This way, kernels and initrds with the same address in
memory can share struct bootmodule (important because we want them to be
free'd only
Similar to construct_dom0, construct_domU creates a barebone DomU guest.
The device tree node passed as argument is compatible "xen,domain", see
docs/misc/arm/device-tree/booting.txt.
Remove #if 0 from allocate_memory as this patch will start using it.
Signed-off-by: Stefano Stabellini
Today Ctrl-AAA is used to switch between Xen and Dom0. Extend the
mechanism to allow for switching between Xen, Dom0, and any of the
initial DomU created from Xen alongside Dom0 out of information provided
via device tree.
Rename xen_rx to console_rx to match the new behavior.
Clarify existing
Extend the existing device tree based multiboot protocol to include
information regarding multiple domains to boot.
Signed-off-by: Stefano Stabellini
---
Changes in v4:
- memory is 64bit
Changes in v3:
- remove "xen,initial-domain" for now
- make vpl011 an empty property
- memory in KBs
Introduce an is_console option to allow certain classes of domUs to use
the Xen console. Specifically, it will be used to give console access to
all domUs started from Xen from information on device tree.
Signed-off-by: Stefano Stabellini
Acked-by: Daniel De Graaf
CC: andrew.coop...@citrix.com
Call a new function, "create_domUs", from setup_xen to start DomU VMs.
Introduce support for the "xen,domain" compatible node on device tree.
Create new DomU VMs based on the information found on device tree under
"xen,domain". Call construct_domU for each domain.
Introduce a simple global
Move generic initializations out of construct_dom0 so that they can be
reused.
Rename prepare_dtb to prepare_dtb_hwdom to avoid confusion.
No functional changes in this patch.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v5:
- rename __construct_domain to
domain_build.c is too large.
Move all the ACPI specific device tree generating functions from
domain_build.c to acpi/domain_build.c.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v7:
- build domain_build.init.o
- remove "static" from prepare_acpi implementation
allocate_memory only deals with directly mapped memory. Rename it to
allocate_memory_11.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v3:
- add patch
---
xen/arch/arm/domain_build.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
Add a new document to provide information on how to use dom0less related
features and their current limitations.
Signed-off-by: Stefano Stabellini
---
Changes in v5:
- convert to markdown
- move to docs/features
- add entry to docs/INDEX
Changes in v4:
- rename to .txt
- improve wording
Xen boot modules need to account not just for Dom0 but also for a few
potential DomUs, each of them coming with their own kernel and initrd.
Increase MAX_MODULES to 32 to allow for more DomUs.
Signed-off-by: Stefano Stabellini
Reviewed-by: Doug Goldstein
---
xen/include/asm-arm/setup.h | 2 +-
Make vpl011 being able to be used without a userspace component in Dom0.
In that case, output is printed to the Xen serial and input is received
from the Xen serial one character at a time.
Call domain_vpl011_init during construct_domU if vpl011 is enabled.
Introduce a new ring struct with only
Don't add duplicate boot modules (same kind and same start address),
they are freed later, we don't want to introduce double-free errors.
Introduce a domU flag in struct bootmodule and struct bootcmdline. Set
it for kernels and ramdisks of "xen,domain" nodes to avoid getting
confused in
Make sure to only look for multiboot compatible nodes only under
/chosen, not under any other paths (depth <= 3).
Signed-off-by: Stefano Stabellini
---
Changes in v7:
- set path size to 92, treat -FDT_ERR_NOSPACE as erro
Changes in v6:
- do not proceed if fdt_get_path returns error !=
also rename it to set_interrupt.
Signed-off-by: Stefano Stabellini
Reviewed-by: Julien Grall
---
xen/arch/arm/domain_build.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index
Introduce vpl011 support to guests started from Xen: it provides a
simple way to print output from a guest, as most guests come with a
pl011 driver. It is also able to provide a working console with
interrupt support.
The UART exposed to the guest is a SBSA compatible UART and not a PL011.
SBSA
Move unregister_init_virtual_region to init_done. Follow the same path
as x86. It is also useful to move it later so that create_domUs can be
called before that in following patches.
Signed-off-by: Stefano Stabellini
Reviewed-by: Julien Grall
---
xen/arch/arm/setup.c | 6 +++---
1 file
Introduce functions to generate a basic domU device tree, similar to the
existing functions in tools/libxl/libxl_arm.c.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v5:
- use d->arch.vgic.version
Changes in v4:
- code style
- two separate functions for gicv2 and
It will be #included by a file in a xen/arch/arm subdirectory.
Signed-off-by: Stefano Stabellini
Reviewed-by: Julien Grall
---
xen/arch/arm/domain_build.c | 2 +-
xen/arch/arm/kernel.c| 3 +-
xen/arch/arm/kernel.h| 86
No functional changes.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v3:
- no change in print messages
- do not remove BUG_ON
Changes in v2:
- new patch
---
xen/arch/arm/domain_build.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git
Move the code to calculate in_fifo_level and out_fifo_level out of
vpl011_data_avail, to the caller.
This change will make it possible to reuse vpl011_data_avail with
different ring structures in a later patch.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v3:
-
Introduce an allocate_memory function able to allocate memory for DomUs
and map it at the right guest addresses, according to the guest memory
map: GUEST_RAM0_BASE and GUEST_RAM1_BASE.
This is under #if 0 as not used for now.
Signed-off-by: Julien Grall
Signed-off-by: Stefano Stabellini
---
On 25/09/2018 14:28, Jan Beulich wrote:
> +#define avx512_vlen_check(lig) do { \
> +switch ( evex.lr ) \
> +{ \
> +default: \
> +generate_exception(EXC_UD); \
> +case 2: \
> +break; \
> +case 0: case 1: \
> +if (!(lig)) \
if ( !(lig) )
> +
>>> On 13.11.18 at 15:39, wrote:
> On 13/11/2018 14:36, Wei Liu wrote:
>> On Tue, Nov 13, 2018 at 07:14:24AM -0700, Jan Beulich wrote:
>> On 12.11.18 at 17:16, wrote:
Currently, a number of options passed for domain creation are ignored, or
have
implicit fallback behaviour.
flight 129969 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129969/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129475
build-amd64
>>> On 13.11.18 at 16:07, wrote:
> On 13/11/2018 14:14, Jan Beulich wrote:
> On 12.11.18 at 17:16, wrote:
>>> --- a/xen/arch/x86/domain.c
>>> +++ b/xen/arch/x86/domain.c
>>> @@ -420,6 +420,46 @@ void arch_vcpu_destroy(struct vcpu *v)
>>>
>>> int arch_sanitise_domain_config(struct
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-raw
testid xen-boot
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
flight 129960 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129960/
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
Anthony PERARD writes ("Re: [PATCH v6.1 05/11] libxl_qmp: Implementation of
libxl__ev_qmp_*"):
> On Tue, Nov 13, 2018 at 01:14:30PM +, Ian Jackson wrote:
> > This one is probably an asisstant for transitioning between states so
> > the pre- and post-conditions may not be pure. Whatever it is
On Mon, 5 Nov 2018 02:40:33 +0100
Samuel Ortiz wrote:
> This is going to be needed by the hardware reduced implementation, so
> let's export it.
> Once the ACPI builder methods and getters will be implemented, the
> acpi_get_pci_host() implementation will become hardware agnostic.
>
>
On 13/11/2018 11:42, Jan Beulich wrote:
On 12.11.18 at 18:50, wrote:
>> On 25/09/18 14:29, Jan Beulich wrote:
>>> In order to be able to verify the 32-bit variant builds and runs,
>>> introduce a respective target (and the necessary other adjustments).
>>>
>>> Signed-off-by: Jan Beulich
>>
On 13/11/2018 11:12, Jan Beulich wrote:
On 12.11.18 at 18:42, wrote:
>> On 25/09/18 14:29, Jan Beulich wrote:
>>> Besides the already existing tests (which are going to be extended once
>>> respective ISA extension support is complete), let's also ensure for
>>> every individual insn that
On Tue, Nov 13, 2018 at 01:14:30PM +, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH v6.1 05/11] libxl_qmp: Implementation of
> libxl__ev_qmp_*"):
> ...
>
> I think this was intended to satisfy my request for comments about
> legal states:
>
> > +/* helpers */
> > +
> > +static void
flight 129963 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129963/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129475
build-amd64
1 - 100 of 172 matches
Mail list logo
