Commit 5a11d0f7 mistakenly converted a log message into an error
condition when irq map is failed for the pci device being
passed through. Revert that part of the commit.
Signed-off-by: Zhao Yan
---
hw/xen/xen_pt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
flight 128832 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128832/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf aa52648c1e6f26b6b8734119ab8f6ba2890a1dad
baseline version:
ovmf
flight 128724 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128724/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 128603
test-armhf-armhf-libvirt-raw 13
On 15/10/2018 08:25, Julien Grall wrote:
> Hi,
>
> On 10/10/2018 11:35 PM, Stefano Stabellini wrote:
> > On Tue, 28 Aug 2018, Julien Grall wrote:
> > > On 11/08/18 01:01, Stefano Stabellini wrote:
> > > > #include
> > > > #include
> > > > #include
> > > > @@ -23,6 +91,721 @@
> > > >
On Mon, 15 Oct 2018, Julien Grall wrote:
> Hi,
>
> Please use scripts/get_maintainers.pl to CC relevant maintainers.
>
> On 15/10/2018 10:56, Stefano Stabellini wrote:
> > Introduce a macro, __symbol, which is a simple wrapper around RELOC_HIDE
> > to be used everywhere symbols such as _stext
On Mon, 15 Oct 2018, Tamas K Lengyel wrote:
> On Mon, Oct 15, 2018 at 3:57 AM Stefano Stabellini
> wrote:
> >
> > Initialize variable *access before returning it back to the caller.
> >
> > Signed-off-by: Stefano Stabellini
> > ---
> > xen/arch/arm/mem_access.c | 1 +
> > 1 file changed, 1
On 10/15/2018 04:32 PM, Ian Jackson wrote:
> Make the bufdev and non-bufdev messages distinct, and always print the
> non-constant argument (ie, the size).
Ok, so I was doing live migration of a domU with 8GiB ram, with Xen 4.11
and Linux 4.18 in the dom0, and it consistently failed with:
This run is configured for baseline tests only.
flight 75425 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75425/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
flight 128702 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128702/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvhv2-intel 15 guest-saverestore fail REGR. vs. 128656
Tests which
flight 128827 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128827/
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
flight 128698 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128698/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt 13 migrate-support-checkfail never pass
test-amd64-i386-xl-pvshim12
This run is configured for baseline tests only.
flight 75423 qemu-mainline real [real]
http://osstest.xensource.com/osstest/logs/75423/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
On Mon, Oct 15, 2018 at 06:15:50PM +0100, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH] tools/libfsimage: Set soname to 4.12 not
> 0.4.12"):
> > The prevailing style is:
> >
> > MAJOR = 4.12
> > MINOR = 0
> >
> > which is used by all other libraries.
>
> Err, sorry.
>
> From
On 15/10/18 18:15, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH] tools/libfsimage: Set soname to 4.12 not
> 0.4.12"):
>> The prevailing style is:
>>
>> MAJOR = 4.12
>> MINOR = 0
>>
>> which is used by all other libraries.
> Err, sorry.
>
> From 3d5d43fa8a23b63ecd5abaf0ffcbddcec8306af2
Andrew Cooper writes ("Re: [PATCH] tools/libfsimage: Set soname to 4.12 not
0.4.12"):
> The prevailing style is:
>
> MAJOR = 4.12
> MINOR = 0
>
> which is used by all other libraries.
Err, sorry.
From 3d5d43fa8a23b63ecd5abaf0ffcbddcec8306af2 Mon Sep 17 00:00:00 2001
From: Ian Jackson
To:
As discussed, I squwashed several of these patches together and I'm
now doing my code review on the result. I've gone through it in some
detail.
Again, I asked for more internal documentation about the legal states
etc. I will have to read it in detail again I'm afraid after that is
done.
The
Hi Stefano,
On 05/10/2018 19:47, Stefano Stabellini wrote:
It will be #included by a file in a xen/arch/arm subdirectory.
Signed-off-by: Stefano Stabellini
---
xen/arch/arm/domain_build.c | 2 +-
xen/arch/arm/kernel.c| 3 +-
xen/arch/arm/kernel.h| 86
Hi,
On 05/10/2018 19:47, Stefano Stabellini wrote:
To avoid mixing the output of different domains on the console, buffer
the output chars and print line by line. Unless the domain has input
from the serial, in which case we want to print char by char for a
smooth user experience.
The size of
flight 128825 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128825/
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 05/10/2018 19:47, Stefano Stabellini wrote:
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
Hi Stefano,
On 05/10/2018 19:47, Stefano Stabellini wrote:
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
Cheers,
flight 128821 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128821/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 272ecccd793c8fb12f4f356ada18a870c2426603
baseline version:
ovmf
Hi,
On 05/10/2018 19:47, Stefano Stabellini wrote:
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
On 15/10/18 16:23, Ian Jackson wrote:
> This was set to 0.4.12 by accident in
> c69a6aca8522c7f676953e56191584381adf2c06
> tools/libfsimage: Bump soname to 4.12
>
> The extra 0. is harmless but ugly. We should be somewhat consistent.
>
> Reported-by: Andrew Cooper
> Signed-off-by: Ian
Hi Stefano,
On 05/10/2018 19:47, Stefano Stabellini wrote:
also rename it to set_interrupt.
Signed-off-by: Stefano Stabellini
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
Hi Stefano,
On 05/10/2018 19:47, Stefano Stabellini wrote:
+static int __init make_gic_domU_node(const struct domain *d, void *fdt)
+{
+switch ( gic_hw_version() )
While I understand that today domains will use the same GIC version as
the host, it would be best if we don't rely on this
This was set to 0.4.12 by accident in
c69a6aca8522c7f676953e56191584381adf2c06
tools/libfsimage: Bump soname to 4.12
The extra 0. is harmless but ugly. We should be somewhat consistent.
Reported-by: Andrew Cooper
Signed-off-by: Ian Jackson
---
tools/libfsimage/common/Makefile | 4 ++--
1
On Fri, Oct 12, 2018 at 09:55:10AM -0600, Jan Beulich wrote:
> >>> On 09.10.18 at 11:42, wrote:
> > --- a/docs/misc/xen-command-line.markdown
> > +++ b/docs/misc/xen-command-line.markdown
> > @@ -681,6 +681,17 @@ Flag that makes a dom0 boot in PVHv2 mode.
> > Flag that makes a dom0 use shadow
Hi,
On 05/10/2018 19:47, Stefano Stabellini wrote:
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.
Add const to kernel_probe dt_device_node parameter.
This
On Mon, Oct 15, 2018 at 3:57 AM Stefano Stabellini
wrote:
>
> Initialize variable *access before returning it back to the caller.
>
> Signed-off-by: Stefano Stabellini
> ---
> xen/arch/arm/mem_access.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/xen/arch/arm/mem_access.c
Hi,
On 05/10/2018 19:47, Stefano Stabellini wrote:
Call a new function, "create_domUs", from setup_xen to start DomU VMs.
Introduce support for the "xen,domU" compatible node on device tree.
s/xen,domU/xen,domain/
Create new DomU VMs based on the information found on device tree under
This patch adds a couple of regs to the vm_event that are used by
the introspection. The base, limit and ar
bits are compressed into a uint64_t union so as not to enlarge the
vm_event.
Signed-off-by: Alexandru Isaila
---
xen/arch/x86/vm_event.c | 35 ---
Hi,
On 05/10/2018 19:47, Stefano Stabellini wrote:
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
---
Changes in v4:
- newline
Hi,
On 05/10/2018 19:47, Stefano Stabellini wrote:
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.
Please add something along the line: "This is under #if 0
Make the bufdev and non-bufdev messages distinct, and always print the
non-constant argument (ie, the size).
This assists diagnosis.
CC: Andrew Cooper
CC: Hans van Kranenburg
---
v2: Print sizes.
---
tools/libs/call/linux.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff
Hi Stefano,
On 05/10/2018 19:47, Stefano Stabellini wrote:
allocate_memory only deals with directly mapped memory. Rename it to
allocate_memory_11.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
Cheers,
---
Changes in v3:
- add patch
---
xen/arch/arm/domain_build.c | 5
Hi Stefano,
On 05/10/2018 19:47, Stefano Stabellini wrote:
No functional changes.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
Cheers,
---
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
Hi Stefano,
On 05/10/2018 19:47, Stefano Stabellini wrote:
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
This assists diagnosis.
CC: Andrew Cooper
CC: Hans van Kranenburg
---
tools/libs/call/linux.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/libs/call/linux.c b/tools/libs/call/linux.c
index d8a6306e04..bb56ff236e 100644
--- a/tools/libs/call/linux.c
+++
On Mon, Oct 15, 2018 at 11:36:20AM +0100, Andrew Cooper wrote:
> Reusing debugreg[5] for the PV emulated IO breakpoint information is confusing
> to read. Instead, introduce a dr7_emul field in pv_vcpu for the pupose.
>
> With the PV emulation out of the way, debugreg[4,5] are entirely unused
On Mon, Oct 15, 2018 at 03:07:21PM +0100, Andrew Cooper wrote:
> On 15/10/18 14:56, Roger Pau Monné wrote:
> > On Mon, Oct 15, 2018 at 11:36:20AM +0100, Andrew Cooper wrote:
> >> diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
> >> +
> >> /* data breakpoint extension MSRs */
> >>
On 15/10/18 14:56, Roger Pau Monné wrote:
> On Mon, Oct 15, 2018 at 11:36:20AM +0100, Andrew Cooper wrote:
>> diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
>> index 115ddf6..cc85395 100644
>> --- a/xen/arch/x86/domctl.c
>> +++ b/xen/arch/x86/domctl.c
>> @@ -1576,8 +1576,11 @@ void
Anthony PERARD writes ("Re: [PATCH v5 03/15] libxl_qmp: Implement fd callback
and read data"):
> On Wed, Oct 10, 2018 at 04:47:08PM +0100, Ian Jackson wrote:
> > Lines too long again. (I will stop complaining about this now but can
> > you pleae fix it throughout?)
>
> But the comment is less
flight 75422 distros-debian-sid real [real]
http://osstest.xensource.com/osstest/logs/75422/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
On Mon, Oct 15, 2018 at 03:25:08PM +0200, Vasilis Liaskovitis wrote:
> If a block device is hot-added when we are out of grants,
> gnttab_grant_foreign_access fails with -ENOSPC (log message "28
> granting access to ring page") in this code path:
>
> talk_to_blkback ->
> setup_blkring ->
Signed-off-by: Ian Jackson
CC: Anthony PERARD
---
tools/libxl/libxl_internal.h | 8
1 file changed, 8 insertions(+)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 43947b1b07..153566acd0 100644
--- a/tools/libxl/libxl_internal.h
+++
On Mon, Oct 15, 2018 at 11:36:20AM +0100, Andrew Cooper wrote:
> diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
> index 115ddf6..cc85395 100644
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -1576,8 +1576,11 @@ void arch_get_info_guest(struct vcpu *v,
>
On Mon, Oct 15, 2018 at 02:53:27PM +0100, Ian Jackson wrote:
> And give a reason.
>
> The previous `limit' of 75-80 was ambiguous.
>
> Signed-off-by: Ian Jackson
> CC: Anthony PERARD
Acked-by: Wei Liu
___
Xen-devel mailing list
And give a reason.
The previous `limit' of 75-80 was ambiguous.
Signed-off-by: Ian Jackson
CC: Anthony PERARD
---
tools/libxl/CODING_STYLE | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/CODING_STYLE b/tools/libxl/CODING_STYLE
index 32170efb9e..3d572f6925
On 10/15/18 9:32 AM, Andrew Cooper wrote:
> On 15/10/18 14:28, Boris Ostrovsky wrote:
>> On 10/15/18 6:36 AM, Andrew Cooper wrote:
>>>
>>> @@ -567,7 +573,10 @@ struct arch_vcpu
>>> void *fpu_ctxt;
>>> unsigned long vgc_flags;
>>> struct cpu_user_regs user_regs;
Hans van Kranenburg writes ("Re: [Xen-devel] [PATCH 07/12] tools/xenstore:
Re-introduce (fake) xs_restrict call to preserve ABI"):
> On 10/12/2018 05:12 PM, Ian Jackson wrote:
> > From: Hans van Kranenburg
>
> No, this was in the changes that I copied back from Ubuntu, it was
> written by
On 15/10/18 14:28, Boris Ostrovsky wrote:
> On 10/15/18 6:36 AM, Andrew Cooper wrote:
>>
>> @@ -567,7 +573,10 @@ struct arch_vcpu
>> void *fpu_ctxt;
>> unsigned long vgc_flags;
>> struct cpu_user_regs user_regs;
>> -unsigned long debugreg[8];
>> +
>> +
On 10/15/18 6:36 AM, Andrew Cooper wrote:
>
> @@ -567,7 +573,10 @@ struct arch_vcpu
> void *fpu_ctxt;
> unsigned long vgc_flags;
> struct cpu_user_regs user_regs;
> -unsigned long debugreg[8];
> +
> +/* Debug registers. */
> +unsigned long dr[4],
If a block device is hot-added when we are out of grants,
gnttab_grant_foreign_access fails with -ENOSPC (log message "28
granting access to ring page") in this code path:
talk_to_blkback ->
setup_blkring ->
xenbus_grant_ring ->
Hi,
Please use scripts/get_maintainers.pl to CC relevant maintainers.
On 15/10/2018 10:56, Stefano Stabellini wrote:
Introduce a macro, __symbol, which is a simple wrapper around RELOC_HIDE
to be used everywhere symbols such as _stext and _etext are used in the
code.
RELOC_HIDE is needed when
Hi,
Please use scripts/get_maintainers.pl to CC relevant maintainers. In
this case you need to add Ravzan and Tamas.
On 15/10/2018 10:56, Stefano Stabellini wrote:
Initialize variable *access before returning it back to the caller.
Same as the previous patch, why do you need this?
Hi,
On 15/10/2018 10:56, Stefano Stabellini wrote:
Initialize variable target before passing it as a parameter.
As such the current code is not wrong. So please explain why you need this.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
On 15/10/2018 14:01, Milan Boberic wrote:
On 15/10/2018 09:14, Julien Grall wrote:
Which link?
I made hyperlink on "link" word, looks like somehow it got lost, here
is the link:
https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf
HTML should be avoided
> On 15/10/2018 09:14, Julien Grall wrote:
> Which link?
I made hyperlink on "link" word, looks like somehow it got lost, here
is the link:
https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf
> The board should be fully supported upstreamed. If Xilinx has
(Resending the e-mail using a different smtp)
On 15/10/2018 08:25, Julien Grall wrote:
Hi,
On 10/10/2018 11:35 PM, Stefano Stabellini wrote:
On Tue, 28 Aug 2018, Julien Grall wrote:
On 11/08/18 01:01, Stefano Stabellini wrote:
#include
#include
#include
@@ -23,6 +91,721 @@
(Resending the e-mail using a different smtp)
On 15/10/2018 08:32, Julien Grall wrote:
Hi,
On 10/10/2018 11:49 PM, Stefano Stabellini wrote:
On Tue, 28 Aug 2018, Julien Grall wrote:
Hi Stefano,
On 11/08/18 01:01, Stefano Stabellini wrote:
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
On 09/10/18 10:42, Roger Pau Monne wrote:
> Add an option to allow trapping accesses to IO port 0xe9 for a PVH
> Dom0, so it can print to the HVM debug console. Note this is not
> enabled by default in order to prevent clashes with hardware on the
> system using 0xe9.
>
> Signed-off-by: Roger Pau
(Resending with a different address)
On 15/10/2018 09:14, Julien Grall wrote:
On 10/13/2018 05:01 PM, Milan Boberic wrote:
Hi,
Hi,
Don't interrupt _come_ from hardware and go/are routed to
hypervisor/os/app?
Yes they do, sorry, I reversed the order because I'm a newbie :) .
Would
On 15/10/18 10:56, Stefano Stabellini wrote:
> Introduce a macro, __symbol, which is a simple wrapper around RELOC_HIDE
> to be used everywhere symbols such as _stext and _etext are used in the
> code.
>
> RELOC_HIDE is needed when accessing symbols such as _stext and _etext
> because the C
On 15/10/2018 14:11, Andrew Cooper wrote:
> On 15/10/18 12:44, Juergen Gross wrote:
>> On 15/10/2018 13:28, Roger Pau Monné wrote:
>>> On Mon, Oct 15, 2018 at 11:36:16AM +0100, Andrew Cooper wrote:
In particular, initialising %dr6 with the value 0 is buggy, because on
hardware supporting
On 15/10/18 12:44, Juergen Gross wrote:
> On 15/10/2018 13:28, Roger Pau Monné wrote:
>> On Mon, Oct 15, 2018 at 11:36:16AM +0100, Andrew Cooper wrote:
>>> In particular, initialising %dr6 with the value 0 is buggy, because on
>>> hardware supporting Transnational Memory, it will cause the sticky
On 15/10/18 11:30, Roger Pau Monné wrote:
> Hello,
>
> Wei recently discovered an issue when running a Linux PVH Dom0 on a
> box with a Intel Family 6 (0x6), Model 158 (0x9e), Stepping 9 (raw
> 000906e9) CPU, we are not sure whether the issue is limited to a PVH
> Dom0, or it just happens to be
flight 128816 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128816/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd broken
build-amd64-freebsd 6
flight 128696 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128696/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 16 guest-localmigrate/x10
fail REGR. vs. 128646
On 10/05/2018 12:29 PM, Jan Beulich wrote:
> This is not used (and probably was never meant to be) by the tool stack.
> Limiting it to the current domain in particular allows to eliminate a
> bogus use of vCPU 0 in pagetable_dying().
>
> Remove the now unnecessary domain/vCPU parameters from the
flight 128808 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128808/
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. 128799
On 15/10/2018 13:28, Roger Pau Monné wrote:
> On Mon, Oct 15, 2018 at 11:36:16AM +0100, Andrew Cooper wrote:
>> In particular, initialising %dr6 with the value 0 is buggy, because on
>> hardware supporting Transnational Memory, it will cause the sticky RTM bit to
>> be asserted, even though a
On Mon, Oct 15, 2018 at 11:36:18AM +0100, Andrew Cooper wrote:
> In particular, initialising %dr6 with the value 0 is buggy, because on
> hardware supporting Transnational Memory, it will cause the sticky RTM bit to
> be asserted, even though a debug exception from a transaction hasn't actually
>
On Mon, Oct 15, 2018 at 11:36:17AM +0100, Andrew Cooper wrote:
> In particular, initialising %dr6 with the value 0 is buggy, because on
> hardware supporting Transnational Memory, it will cause the sticky RTM bit to
> be asserted, even though a debug exception from a transaction hasn't actually
>
On Mon, Oct 15, 2018 at 11:36:16AM +0100, Andrew Cooper wrote:
> In particular, initialising %dr6 with the value 0 is buggy, because on
> hardware supporting Transnational Memory, it will cause the sticky RTM bit to
> be asserted, even though a debug exception from a transaction hasn't actually
>
Ian Jackson writes ("Re: [Pkg-xen-devel] Ill-advised use of xs_open flag 1UL<<2
by Debian"):
> But that was all a long time ago. There is no longer any need to make
> upgrades from squeeze or whatever work correctly.
For the reasons I have explained, I have reverted this patch in my
latest
On Fri, Oct 12, 2018 at 08:14:36AM -0600, Jan Beulich wrote:
> >>> On 04.10.18 at 17:43, wrote:
> > It is used by PV code only.
>
> And wrongly so - the same is needed for a PVH Dom0 afaict.
Yes, looking at the models affected by this issue according to
init_amd it seems to cover the full AMD
This run is configured for baseline tests only.
flight 75421 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75421/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
On 15/10/18 11:50, Razvan Cojocaru wrote:
> On 10/15/18 1:36 PM, Andrew Cooper wrote:
>> Reusing debugreg[5] for the PV emulated IO breakpoint information is
>> confusing
>> to read. Instead, introduce a dr7_emul field in pv_vcpu for the pupose.
>>
>> With the PV emulation out of the way,
On 10/15/18 1:36 PM, Andrew Cooper wrote:
> Reusing debugreg[5] for the PV emulated IO breakpoint information is confusing
> to read. Instead, introduce a dr7_emul field in pv_vcpu for the pupose.
>
> With the PV emulation out of the way, debugreg[4,5] are entirely unused and
> don't need to be
On Fri, Oct 12, 2018 at 08:56:22AM -0600, Jan Beulich wrote:
> >>> On 04.10.18 at 17:43, wrote:
> > Instead of trying to split up entry.S and compat/entry.S, simply
> > provide some stubs for them.
>
> I'm not convinced; I'd much rather see the call sites recognizably
> compiled out with !PV.
Reusing debugreg[5] for the PV emulated IO breakpoint information is confusing
to read. Instead, introduce a dr7_emul field in pv_vcpu for the pupose.
With the PV emulation out of the way, debugreg[4,5] are entirely unused and
don't need to be stored.
Rename debugreg[0..3] to dr[0..3] to reduce
To allow a subsequent patch to map DFNs specified by hypercall, there
needs to be iommu_op wrapper function that does not contain an implicit
domain_crash. This patch introduces that function.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
v7:
- New in v7.
---
...to mean 'the page (being) mapped is reference counted'.
An important pre-requisite for PV-IOMMU mapping is being able to tell the
difference between IOMMU entries added at start-of-day by Xen and those
that have been added by a PV-IOMMU map operation. The reason for this is
that the pages for
In particular, initialising %dr6 with the value 0 is buggy, because on
hardware supporting Transnational Memory, it will cause the sticky RTM bit to
be asserted, even though a debug exception from a transaction hasn't actually
been observed.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
This contains the remaining patches from my original PV-IOMMU series (that
were not included in the recent pre-requisites series), and some new
patches to support the revised implementation.
The new patches are:
- To add a 'no crash' variant of the internal IOMMU map method.
- To add a new
This patch allows a domain to add or remove foreign frames from its
IOMMU mappings by grant reference as well as GFN. This is necessary,
for example, to support a PV network backend that needs to construct a
packet buffer that can be directly accessed by a NIC.
Signed-off-by: Paul Durrant
---
No functional change (as curr->arch.debugreg[5] is zero when DE is clear), but
this change simplifies the following patch.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
Reviewed-by: Roger Pau Monné
---
CC: Wei Liu
---
xen/arch/x86/x86_emulate.c | 24 +++-
1 file
Ranges that should be considered reserved in the IOMMU are not necessarily
limited to RMRRs. Any frame number that is not RAM but is present in the
initial domain map should be considered as reserved in the IOMMU.
This patch adds a rangeset to the domain_iommu structure that is then used
to track
This patch introduces the boilerplate for a new hypercall to allow a
domain to control IOMMU mappings for its own pages.
Whilst there is duplication of code between the native and compat entry
points which appears ripe for some form of combination, I think it is
better to maintain the separation
In particular, initialising %dr6 with the value 0 is buggy, because on
hardware supporting Transnational Memory, it will cause the sticky RTM bit to
be asserted, even though a debug exception from a transaction hasn't actually
been observed.
Introduce arch_vcpu_regs_init() to set various
This patch adds iommu_ops to add (map) or remove (unmap) frames in the
domain's IOMMU mappings.
Currently the flags value for each op must include the
XEN_IOMMUOP_map/unmap_all flag as the implementation does not yet support
per-device mappings. The sbdf field of each hypercall is accordingly
This patch adds a xen_iommu_op to allow the virtual machine's reserved
IOMMU ranges to be queried by the guest.
NOTE: The number of reserved ranges is determined by system firmware, in
conjunction with Xen command line options, and is expected to be
small. Thus, to avoid
This is the first part of the RFC series. It covers initialising the vcpu
registers correctly, and some code cleanup.
The remainder of the RFC series is still in progress - specifically trying to
avoid breaking introspection.
Andrew Cooper (5):
x86/boot: Initialise the debug registers
In particular, initialising %dr6 with the value 0 is buggy, because on
hardware supporting Transnational Memory, it will cause the sticky RTM bit to
be asserted, even though a debug exception from a transaction hasn't actually
been observed.
Move X86_DR6_DEFAULT into x86-defns.h along with the
Hello,
Wei recently discovered an issue when running a Linux PVH Dom0 on a
box with a Intel Family 6 (0x6), Model 158 (0x9e), Stepping 9 (raw
000906e9) CPU, we are not sure whether the issue is limited to a PVH
Dom0, or it just happens to be easier to trigger in this scenario.
The issue is
Introduce a macro, __symbol, which is a simple wrapper around RELOC_HIDE
to be used everywhere symbols such as _stext and _etext are used in the
code.
RELOC_HIDE is needed when accessing symbols such as _stext and _etext
because the C standard forbids comparisons between pointers pointing to
Initialize variable target before passing it as a parameter.
Signed-off-by: Stefano Stabellini
---
xen/arch/arm/vgic-v2.c | 2 +-
xen/arch/arm/vgic-v3.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index f6c11f1..0099fcf
Initialize variable *access before returning it back to the caller.
Signed-off-by: Stefano Stabellini
---
xen/arch/arm/mem_access.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/arm/mem_access.c b/xen/arch/arm/mem_access.c
index ba4ec78..10ab308 100644
---
Hi all,
This short patch series fixes a few issues discovered by the safety
certifications code scanner. The first two patches address simple
variable initializations concerns. The third patch introduces a new
macro that is used throughout the code in patch #4 to access _stext,
_etext pointers
1 - 100 of 105 matches
Mail list logo
