>>> On 07.03.17 at 18:48, wrote:
> Here some concrete examples. The major bootloaders on ARM today are:
> * UEFI
> * U-boot
> * GRUB
>
> I will leave UEFI aside as people will usually chainload to GRUB and
> then boot whatever they want.
>
> In both GRUB and U-boot a user will
>>> On 08.03.17 at 02:58, wrote:
> Those assertions as well as mce_[u|d]handlers[], mce_[u|d]handler_num
> and mce_action() were intel only and lifted to the common code by c/s
> 3a91769d6e1. However, MCE handling on AMD does not use mce_[u|d]handlers[]
> before and after that commit, so assertion
>>> On 08.03.17 at 00:32, wrote:
> v{,u}comis{s,d} have two operands, so require vex.reg set to ~0.
>
> Spotted by AFL
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
I'm sorry for the oversight.
Jan
___
Xen-devel mailing list
Xen-devel@l
>>> On 08.03.17 at 08:16, wrote:
> 4. As for the different behavior between arm and x86 on handling the
> dom0 options after " -- " in the
> command line, I will left this difference as untouched, coz
> whether to add this feature to arm or to remove
> this feature from x86 is beyond the s
flight 106534 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106534/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 106513
test-amd64-i386-xl-qemuu-wi
Other Amazon folks indicate he's not available as a maintainer anymore
at this point in time. Maintenance of the MCE sub-component will fall
back to the x86 maintainers.
Signed-off-by: Jan Beulich
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -269,11 +269,6 @@ F: xen/include/asm-*/livepatch.h
F: xen
For the default EPT view we have xc_set_mem_access_multi(), which
is able to set an array of pages to an array of access rights with
a single hypercall. However, this functionality was lacking for the
altp2m subsystem, which could only set page restrictions for one
page at a time. This patch addres
flight 106535 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106535/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-rumprun-i386 16 rumprun-demo-xenstorels/xenstorels.repeat fail
REGR. vs. 106095
test-a
flight 68643 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68643/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-amd64-squeeze-netboot-pygrub 9 debian-di-install fail like
68599
test-amd64-
> On Mon, Mar 06, 2017 at 04:20:57PM +0200, Elena Reshetova wrote:
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter overflows that might lead to use-after-free
> > si
> -Original Message-
> From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> Sent: 07 March 2017 19:14
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; qemu-de...@nongnu.org; Stefano
> Stabellini
> Subject: Re: [PATCH v4 5/5] xen: use libxendevicemodel when available
>
> O
> On Mon, Mar 06, 2017 at 04:20:55PM +0200, Elena Reshetova wrote:
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter overflows that might lead to use-after-free
> > si
On Wed, Mar 08, 2017 at 09:42:09AM +, Reshetova, Elena wrote:
> > On Mon, Mar 06, 2017 at 04:20:55PM +0200, Elena Reshetova wrote:
> > > refcount_t type and corresponding API should be
> > > used instead of atomic_t when the variable is used as
> > > a reference counter. This allows to avoid ac
On 08/03/17 08:45, Jan Beulich wrote:
> Other Amazon folks indicate he's not available as a maintainer anymore
> at this point in time. Maintenance of the MCE sub-component will fall
> back to the x86 maintainers.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
For now, I am happy for th
On 08/03/17 10:35, Andrew Cooper wrote:
> On 08/03/17 08:45, Jan Beulich wrote:
>> Other Amazon folks indicate he's not available as a maintainer anymore
>> at this point in time. Maintenance of the MCE sub-component will fall
>> back to the x86 maintainers.
>>
>> Signed-off-by: Jan Beulich
>
> A
On 08.03.17 09:45, Jan Beulich wrote:
> Other Amazon folks indicate he's not available as a maintainer anymore
> at this point in time. Maintenance of the MCE sub-component will fall
> back to the x86 maintainers.
>
> Signed-off-by: Jan Beulich
Acked-by: Christoph Egger
>
> --- a/MAINTAINERS
flight 106549 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106549/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 4361e80d228655b100bae5d19b489b39d20aa68d
baseline version:
xen 6d55
Hi Stefano,
On 08/03/17 00:12, Stefano Stabellini wrote:
On Tue, 7 Mar 2017, Julien Grall wrote:
Hi Stefano,
On 03/06/2017 08:01 PM, Stefano Stabellini wrote:
Sync the ring.h file with upstream Xen, to introduce the new ring macros.
They will be used by the Xen transport for 9pfs.
Signed-off
v{,u}comis{s,d}, and vcvt{,t}s{s,d}2si are two-operand instructions, while
vzero{all,upper} take no operands, so require vex.reg set to ~0 to avoid #UD.
Spotted while fuzzing with AFL
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/x86_emulate/x86_emulate.c | 4 +++-
1 file ch
Hi Jan,
On 08/03/17 08:03, Jan Beulich wrote:
On 07.03.17 at 18:48, wrote:
Here some concrete examples. The major bootloaders on ARM today are:
* UEFI
* U-boot
* GRUB
I will leave UEFI aside as people will usually chainload to GRUB and
then boot whatever they want.
In
Hi Stefano,
On 08/03/17 00:49, Stefano Stabellini wrote:
On Tue, 7 Mar 2017, Julien Grall wrote:
On 03/06/2017 08:01 PM, Stefano Stabellini wrote:
+ if (ring->bytes == NULL)
+ goto error;
+ for (i = 0; i < (1 << XEN_9PFS_RING_ORDER); i++)
+ ring->intf->r
All,
I am pleased to announce the release of Xen 4.7.2. This is
available immediately from its git repository
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.7
(tag RELEASE-4.7.2) or from the XenProject download page
http://www.xenproject.org/downloads/xen-archives/xen-4
All,
I am pleased to announce the release of Xen 4.6.5. This is
available immediately from its git repository
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.6
(tag RELEASE-4.6.5) or from the XenProject download page
http://www.xenproject.org/downloads/xen-archives/xen-4
>>> On 08.03.17 at 13:10, wrote:
> v{,u}comis{s,d}, and vcvt{,t}s{s,d}2si are two-operand instructions, while
> vzero{all,upper} take no operands, so require vex.reg set to ~0 to avoid
> #UD.
>
> Spotted while fuzzing with AFL
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
On 08/03/17 13:02, Jan Beulich wrote:
On 08.03.17 at 13:10, wrote:
>> v{,u}comis{s,d}, and vcvt{,t}s{s,d}2si are two-operand instructions, while
>> vzero{all,upper} take no operands, so require vex.reg set to ~0 to avoid
>> #UD.
>>
>> Spotted while fuzzing with AFL
>> Signed-off-by: Andrew C
>>> On 08.03.17 at 14:24, wrote:
> One observation however. It would probably be safer to poison the stub
> with 0xcc each time (especially if we have a path which omits the ret),
> instead of leaving partial instructions in place.
I too have been considering this.
Jan
___
>
>>> + ring->bytes = (void*)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
>>> XEN_9PFS_RING_ORDER);
>>> + if (ring->bytes == NULL)
>>> + goto error;
>>> + for (i = 0; i < (1 << XEN_9PFS_RING_ORDER); i++)
>>> + ring->intf->ref[i] =
>>> gnttab_grant_foreign_access(dev->oth
> On 03/06/2017 03:21 PM, Elena Reshetova wrote:
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter overflows that might lead to use-after-free
> > situations.
>
> The
> On 03/06/2017 09:21 AM, Elena Reshetova wrote:
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter overflows that might lead to use-after-free
> > situations.
> >
> >
In ept_handle_violation(), write violations are also treated as
read violations. And when a VM is accessing a write-protected
address with read-modify-write instructions, the read emulation
process is triggered first.
For p2m_ioreq_server pages, current ioreq server only forwards
the write operati
XenGT leverages ioreq server to track and forward the accesses to GPU
I/O resources, e.g. the PPGTT(per-process graphic translation tables).
Currently, ioreq server uses rangeset to track the BDF/ PIO/MMIO ranges
to be emulated. To select an ioreq server, the rangeset is searched to
see if the I/O
Routine hvmemul_do_io() may need to peek the p2m type of a gfn to
select the ioreq server. For example, operations on gfns with
p2m_ioreq_server type will be delivered to a corresponding ioreq
server, and this requires that the p2m type not be switched back
to p2m_ram_rw during the emulation proces
A new DMOP - XEN_DMOP_map_mem_type_to_ioreq_server, is added to
let one ioreq server claim/disclaim its responsibility for the
handling of guest pages with p2m type p2m_ioreq_server. Users
of this DMOP can specify which kind of operation is supposed
to be emulated in a parameter named flags. Curren
After an ioreq server has unmapped, the remaining p2m_ioreq_server
entries need to be reset back to p2m_ram_rw. This patch does this
synchronously by iterating the p2m table.
The synchronous resetting is necessary because we need to guarantee
the p2m table is clean before another ioreq server is m
flight 106540 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106540/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 9 debian-install fail blocked in 106251
test-armhf-armhf-libvirt
After an ioreq server has unmapped, the remaining p2m_ioreq_server
entries need to be reset back to p2m_ram_rw. This patch does this
asynchronously with the current p2m_change_entry_type_global()
interface.
This patch also disallows live migration, when there's still any
outstanding p2m_ioreq_serv
Hi George,
On 06/03/17 14:48, George Dunlap wrote:
On 06/03/17 13:21, Julien Grall wrote:
Hi Jan,
On 06/03/17 12:41, Jan Beulich wrote:
On 06.03.17 at 12:42, wrote:
I thought a bit more about those params. I think the name should be
generic and not tie to pl011 because we may want to emulat
The registers only accessible in 64-bit mode need to be left alone in
this case.
Reported-by: Andrew Cooper
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -2910,6 +2910,45 @@ int main(int argc, char **argv)
>>> +}
>>> +
>>> +static int p9_xen_write_todo(struct xen_9pfs_dataring *ring, RING_IDX size)
>>> +{
>>> + RING_IDX cons, prod;
>>> +
>>> + cons = ring->intf->out_cons;
>>> + prod = ring->intf->out_prod;
>>> + mb();
>>> +
>>> + if (XEN_9PFS_RING_SIZE - xen_9pfs_queued(prod, cons,
>>> XE
On 08/03/17 13:56, Jan Beulich wrote:
> The registers only accessible in 64-bit mode need to be left alone in
> this case.
>
> Reported-by: Andrew Cooper
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lis
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Yu
> Zhang
> Sent: 08 March 2017 13:32
> To: xen-devel@lists.xen.org
> Cc: zhiyuan...@intel.com
> Subject: [Xen-devel] [PATCH v7 1/5] x86/ioreq server: Release the p2m lock
> after mmio is handled.
On 03/08/2017 02:48 PM, Reshetova, Elena wrote:
On 03/06/2017 03:21 PM, Elena Reshetova wrote:
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-af
flight 106537 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106537/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-intel 11 guest-start fail REGR. vs. 59254
test-armhf-armhf-xl
On Tue, Mar 07, 2017 at 10:44:15PM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 07, 2017 at 12:39:04AM +0100, Daniel Kiper wrote:
> > On Wed, Feb 22, 2017 at 09:04:17AM -0800, Doug Goldstein wrote:
> >
> > [...]
> >
> > > I'm currently at ELC and then on vacation so I don't have access to any
>
>>> +
>>> + if (xen_9pfs_queued(prod, cons, XEN_9PFS_RING_SIZE) <
>>> sizeof(h)) {
>>> + notify_remote_via_irq(ring->irq);
>>> + return;
>>> + }
>>> +
>>> + masked_prod = xen_9pfs_mask(prod, XEN_9PFS_RING_SIZE);
>>> + m
flight 106538 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106538/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 105963
test-amd64-amd64-xl-qemuu-
Hi Jan,
On 06/03/17 13:48, Jan Beulich wrote:
On 06.03.17 at 14:21, wrote:
On 06/03/17 12:41, Jan Beulich wrote:
Furthermore - how does this scale? I.e. what if other devices pop
up wanting to be emulated? Or multiple UARTs?
I think you can appreciate that using QEMU for emulating an UART i
Instead of generating the *.pc.in files at configure time use the new
pkg-config scheme for those files. Add the dependencies to other Xen
libraries as needed.
Signed-off-by: Juergen Gross
---
.gitignore| 1 -
tools/configure | 4 +---
tools/configure.ac
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xentoollog.pc file.
Signed-off-by: Juergen Gross
---
.gitignore | 1 +
tools/libs/toollog/Makefile | 20 +++-
tools/libs/toollog/xentoollog.pc.in | 9 ++
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xenstore.pc file.
Signed-off-by: Juergen Gross
---
.gitignore| 1 +
tools/xenstore/Makefile | 21 +
tools/xenstore/xenstore.pc.in | 10 ++
3 files chang
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xengnttab.pc and a xengntshr.pc file.
Signed-off-by: Juergen Gross
---
.gitignore| 2 ++
tools/libs/gnttab/Makefile| 22 +-
tools/libs/gnttab/xengntshr.pc
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xencall.pc file.
Signed-off-by: Juergen Gross
---
.gitignore| 1 +
tools/libs/call/Makefile | 21 -
tools/libs/call/xencall.pc.in | 10 ++
to
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xenvchan.pc file.
Signed-off-by: Juergen Gross
---
.gitignore| 1 +
tools/libvchan/Makefile | 21 -
tools/libvchan/xenvchan.pc.in | 10 ++
3 files chang
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xenguest.pc file.
Update the xencontrol.pc file to reflect the dependencies of libxenctrl.
Signed-off-by: Juergen Gross
---
tools/libxc/Makefile | 6 --
tools/libxc/xencontrol.pc.in | 3 ++-
t
Some libraries require different compiler-flags when being used in a
local build compared to a build using installed libraries.
Reflect that by supporting local cflags variables in generated
pkg-config files. The local variants will be empty in the installed
pkg-config files.
The flags for the li
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xendevicemodel.pc file.
Signed-off-by: Juergen Gross
---
.gitignore | 1 +
tools/libs/devicemodel/Makefile | 21 -
tools/libs/devicemodel/xen
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xenevtchn.pc file.
Signed-off-by: Juergen Gross
---
.gitignore| 1 +
tools/libs/evtchn/Makefile| 21 -
tools/libs/evtchn/xenevtchn.pc.in | 10 ++
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xenstat.pc file.
Signed-off-by: Juergen Gross
---
.gitignore | 1 +
tools/xenstat/libxenstat/Makefile | 20 +++-
tools/xenstat/libxenstat/xenstat.pc.in | 10
Instead of setting the PKG_CONFIG_DIR make variable in each library
Makefile do it in tools/Makefile and stubdom/Makefile globally.
Signed-off-by: Juergen Gross
---
stubdom/Makefile | 1 +
tools/Makefile | 3 +++
tools/libxc/Makefile | 1 -
3 files changed, 4 insertions(+), 1 deletion(
To help consumers of the Xen libraries (e.g. qemu) to use correct
flags when building provide pkg-config files for all libraries of
Xen.
The first 2 patches correct some flags used by the Xen internal build
system. The build process wasn't producing wrong results, but this was
just pure luck as no
LDLIBS_* and SHLIB_* settings in tools/Rules.mk are sometimes missing
some SHDEPS_* added to them.
Add the missing flags, even if sometimes being empty.
Signed-off-by: Juergen Gross
---
tools/Rules.mk | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --gi
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xenforeignmemory.pc file.
Signed-off-by: Juergen Gross
---
.gitignore | 1 +
tools/libs/foreignmemory/Makefile | 21 -
tools/libs/forei
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xenblktapctl.pc file.
Signed-off-by: Juergen Gross
---
.gitignore | 1 +
tools/blktap2/control/Makefile | 23 +--
tools/blktap2/control/xenblktapc
Commit 78fb69ad9 ("tools/Rules.mk: Properly handle libraries with
recursive dependencies.") introduced a copy and paste error in
tools/Rules.mk:
LDLIBS_libxenstore and SHLIB_libxenstore don't use SHDEPS_libxenstore
but SHDEPS_libxenguest. This will add a superfluous dependency of
libxenstore on li
On 02/03/17 18:53, Vitaly Kuznetsov wrote:
> As a preparation to splitting the code we need to untangle it:
>
> x86_hyper_xen -> x86_hyper_xen_hvm and x86_hyper_xen_pv
> xen_platform() -> xen_platform_hvm() and xen_platform_pv()
> xen_cpu_up_prepare() -> xen_cpu_up_prepare_pv() and xen_cpu_up_prep
On 02/03/17 18:53, Vitaly Kuznetsov wrote:
> have_vcpu_info_placement applies to both PV and HVM and as we're going
> to split the code we need to make it global.
>
> Rename to xen_have_vcpu_info_placement.
>
> Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Juergen Gross
Juergen
_
>>> On 15.02.17 at 09:49, wrote:
> This patch implements the CPU init and free flow including L3 CAT
> initialization and feature list free.
I think from the final-effect-of-the-patch point of view the L3 CAT
aspect is more relevant, so that's what should appear in the title.
> @@ -136,11 +140,8
>>> On 15.02.17 at 09:49, wrote:
> @@ -362,11 +370,33 @@ void psr_free_rmid(struct domain *d)
> d->arch.psr_rmid = 0;
> }
>
> +static inline unsigned int get_max_cos_max(const struct psr_socket_info
> *info)
While I see that the immediately following function (in context) is
inline too,
On 02/03/17 18:53, Vitaly Kuznetsov wrote:
> Create enlighten_pvh.c by splitting off PVH related code from enlighten.c,
> put it under CONFIG_XEN_PVH.
>
> Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
>>> On 15.02.17 at 09:49, wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -84,6 +84,7 @@ enum psr_feat_type {
> PSR_SOCKET_L3_CAT = 0,
> PSR_SOCKET_L3_CDP,
> PSR_SOCKET_L2_CAT,
> +PSR_SOCKET_UNKNOWN = 0x,
Any reason to use this value, instead of just the n
On 02/03/17 18:53, Vitaly Kuznetsov wrote:
> Move PVHVM related code to enlighten_hvm.c. Three functions:
> xen_cpuhp_setup(), xen_reboot(), xen_emergency_restart() are shared, drop
> static qualifier from them. These functions will go to common code once
> it is split from enlighten.c.
>
> Signed
On 02/03/17 18:53, Vitaly Kuznetsov wrote:
> Basically, enlighten.c is renamed to enlighten_pv.c and some code moved
> out to common enlighten.c.
>
> Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-
On 02/03/17 18:53, Vitaly Kuznetsov wrote:
> All code to supprot Xen PV will get under this new option. For the
s/supprot/support/
> beginning, check for it in the common code.
>
> Signed-off-by: Vitaly Kuznetsov
> ---
> arch/x86/kernel/cpu/hypervisor.c | 4 +++-
> arch/x86/kernel/process_64.
>>> On 08.03.17 at 15:45, wrote:
> I was looking at the backend code and see it is using DOMCTL command. I
> guess it is considered that the console backend will be tied to a
> specific Xen version. Am I correct?
I don't think I'm qualified to talk about the console backend
implementation (and
On 07/03/17 18:08, Andre Przywara wrote:
Hi Julien,
Hi Andre,
On 06/02/17 19:16, Julien Grall wrote:
Hi Andre,
On 30/01/17 18:31, Andre Przywara wrote:
To be able to easily send commands to the ITS, create the respective
wrapper functions, which take care of the ring buffer.
The first t
On 3/8/2017 10:06 PM, Paul Durrant wrote:
-Original Message-
From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Yu
Zhang
Sent: 08 March 2017 13:32
To: xen-devel@lists.xen.org
Cc: zhiyuan...@intel.com
Subject: [Xen-devel] [PATCH v7 1/5] x86/ioreq server: Release the p2
>>> On 15.02.17 at 09:49, wrote:
> @@ -260,9 +263,22 @@ static bool l3_cat_get_feat_info(const struct feat_node
> *feat,
> return true;
> }
>
> +static bool l3_cat_get_val(const struct feat_node *feat, unsigned int cos,
> + enum cbm_type type, uint64_t *val)
> +{
flight 106543 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106543/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 106510
test-armhf-armhf-libvirt-xsm 13
...rather than leaving fragments of old instructions in place. This reduces
the chances of something going further-wrong (as the debug trap will be cause
and terminate the guest) in a cascade-failure where we end up executing the
instruction fragments.
Before:
(XEN) d2v0 exception 6 (ec=)
XenGT leverages ioreq server to track and forward the accesses to GPU
I/O resources, e.g. the PPGTT(per-process graphic translation tables).
Currently, ioreq server uses rangeset to track the BDF/ PIO/MMIO ranges
to be emulated. To select an ioreq server, the rangeset is searched to
see if the I/O
A new DMOP - XEN_DMOP_map_mem_type_to_ioreq_server, is added to
let one ioreq server claim/disclaim its responsibility for the
handling of guest pages with p2m type p2m_ioreq_server. Users
of this DMOP can specify which kind of operation is supposed
to be emulated in a parameter named flags. Curren
In ept_handle_violation(), write violations are also treated as
read violations. And when a VM is accessing a write-protected
address with read-modify-write instructions, the read emulation
process is triggered first.
For p2m_ioreq_server pages, current ioreq server only forwards
the write operati
After an ioreq server has unmapped, the remaining p2m_ioreq_server
entries need to be reset back to p2m_ram_rw. This patch does this
asynchronously with the current p2m_change_entry_type_global()
interface.
This patch also disallows live migration, when there's still any
outstanding p2m_ioreq_serv
After an ioreq server has unmapped, the remaining p2m_ioreq_server
entries need to be reset back to p2m_ram_rw. This patch does this
synchronously by iterating the p2m table.
The synchronous resetting is necessary because we need to guarantee
the p2m table is clean before another ioreq server is m
Routine hvmemul_do_io() may need to peek the p2m type of a gfn to
select the ioreq server. For example, operations on gfns with
p2m_ioreq_server type will be delivered to a corresponding ioreq
server, and this requires that the p2m type not be switched back
to p2m_ram_rw during the emulation proces
flight 106551 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106551/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64 5 xen
Hi,
Recently, OVMF start to read MSR 0x1a0, which cause a General Protection
fault on AMD, but not in Intel. OMVF does not handle it and crash.
OVMF use msr 0x1a0, which seems to be IA32_MISC_ENABLE, to find out if
the XD attribute can be use on page tables.
From a recent run (OVMF output):
http
>>> On 15.02.17 at 09:49, wrote:
> As set value flow is the most complicated one in psr, it will be
> divided to some patches to make things clearer. This patch
> implements the set value framework to show a whole picture firstly.
>
> It also changes domctl interface to make it more general.
>
>
Hi,
On 08/03/17 15:28, Julien Grall wrote:
>
>
> On 07/03/17 18:08, Andre Przywara wrote:
>> Hi Julien,
>
> Hi Andre,
>
>>
>> On 06/02/17 19:16, Julien Grall wrote:
>>> Hi Andre,
>>>
>>> On 30/01/17 18:31, Andre Przywara wrote:
To be able to easily send commands to the ITS, create the res
On 03/08/2017 10:59 AM, Anthony PERARD wrote:
> Hi,
>
> Recently, OVMF start to read MSR 0x1a0, which cause a General Protection
> fault on AMD, but not in Intel. OMVF does not handle it and crash.
I don't think this MSR exists on AMD processors so that would be OVMF bug.
-boris
>
> OVMF use msr
>>> On 08.03.17 at 16:39, wrote:
> ...rather than leaving fragments of old instructions in place. This reduces
> the chances of something going further-wrong (as the debug trap will be cause
> and terminate the guest) in a cascade-failure where we end up executing the
> instruction fragments.
Wh
>>> On 08.03.17 at 16:59, wrote:
> Is this a missing feature in Xen or a bug in OVMF?
The easiest way for you or them to find out is to try reading the MSR
on bare hardware on an AMD system. But see also Boris' reply.
Jan
___
Xen-devel mailing list
X
flight 106542 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106542/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 3 host-install(3) broken REGR. vs. 105991
test-armhf-armh
..snip..
> > Now in the process I discovered that my patch for grub-mkconfig to
> > detect multiboot2 payloads and use those instead of multiboot never
> > made it upstream, so I had to modify my grub.cfg by hand (see below).
>
> It will be nice if you post it after GRUB2 2.02 release.
OK, I will
>>> On 15.02.17 at 09:49, wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -119,6 +119,32 @@ struct feat_ops {
> /* get_val is used to get feature COS register value. */
> bool (*get_val)(const struct feat_node *feat, unsigned int cos,
> enum cbm_typ
>>> On 15.02.17 at 09:49, wrote:
> Continue with patch:
???
> 'x86: refactor psr: set value: assemble features value array'
Or did you perhaps mean "continue from"?
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -145,6 +145,19 @@ struct feat_ops {
> const st
flight 106555 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106555/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64 5 xen
On 03/08/2017 08:49 AM, Reshetova, Elena wrote:
>> On 03/06/2017 09:21 AM, Elena Reshetova wrote:
>>> refcount_t type and corresponding API should be
>>> used instead of atomic_t when the variable is used as
>>> a reference counter. This allows to avoid accidental
>>> refcounter overflows that migh
When using LivePatch, use of __LINE__ can generate spurious changes in
functions due to embedded line numbers. For release builds with
LivePatch enabled, remove the use of these line numbers and print the
current text address instead.
Signed-off-by: Ross Lagerwall
---
xen/arch/arm/traps.c | 20
Instead of using a locking order based on line numbers which interacts
poorly with trying to create a live patch, statically define the locking
order.
Signed-off-by: Ross Lagerwall
Reviewed-by: Dario Faggioli
---
Changes in v2:
* Rearranged defines.
* Make lock orders fit in a sign-extended 8-b
1 - 100 of 168 matches
Mail list logo
