If LMCE is supported by host and ' mca_caps = [ "lmce" ] ' is present
in xl config, the LMCE capability will be exposed in guest MSR_IA32_MCG_CAP.
By default, LMCE is not exposed to guest so as to keep the backwards migration
compatibility.
Signed-off-by: Haozhong Zhang
---
Cc: Ian Jackson
Cc: W
v2 can be found at
https://lists.xen.org/archives/html/xen-devel/2017-03/msg02154.html.
This patch series is organized as below:
* Patch 1 - 9 correspond to v2 patch 4 - 12.
* Patch 2 has got R-b from Jan Beulich after addressing his comments in v2.
* Patch 9 has got A-b from Wei Liu.
* Other
If MCG_LMCE_P is present in guest MSR_IA32_MCG_CAP, then allow guest
to read/write MSR_IA32_MCG_EXT_CTL.
Signed-off-by: Haozhong Zhang
---
Cc: Jan Beulich
Cc: Andrew Cooper
Changes in v3:
* Replace lmce_enabled in struct hvm_vmce_vcpu and struct vmce by
mcg_ext_ctl.
* Drop the change to X
Enable LMCE if it's supported by the host CPU. If Xen boot parameter
"mce_fb = 1" is present, LMCE will be disabled forcibly.
Signed-off-by: Haozhong Zhang
Reviewed-by: Jan Beulich
---
Cc: Jan Beulich
Cc: Andrew Cooper
Changes in v3:
* Make lmce_support static.
---
xen/arch/x86/cpu/mcheck/m
LMCE is sent to only one CPU thread, so MCE handler, barriers and
softirq handler should go without waiting for other CPUs, when
handling LMCE. Note LMCE is still broadcast to all vcpus as regular
MCE on Intel CPU right now.
Signed-off-by: Haozhong Zhang
---
Cc: Jan Beulich
Cc: Andrew Cooper
C
Though XEN_MC_inject_v2 allows injecting MC# to specified CPUs, the
current xc_mca_op() does not use this feature and not provide an
interface to callers. This commit add a new xc_mca_op_inject_v2() that
receives a cpumap providing the set of target CPUs.
Signed-off-by: Haozhong Zhang
---
Cc: Ian
If MCG_LMCE_P is present in guest MSR_IA32_MCG_CAP, then set LMCE and
LOCK bits in guest MSR_IA32_FEATURE_CONTROL. Intel SDM requires those
bits are set before SW can enable LMCE.
Signed-off-by: Haozhong Zhang
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Jun Nakajima
Cc: Kevin Tian
Changes in v
Inject LMCE to guest if the host MCE is LMCE and the affected vcpu is
known. Otherwise, broadcast MCE to all vcpus on Intel host.
Signed-off-by: Haozhong Zhang
---
Cc: Jan Beulich
Cc: Andrew Cooper
Changes in v3:
* Adjust a check in mc_memerr_dhandler() and add code comment for it.
---
xen/a
Signed-off-by: Haozhong Zhang
---
Cc: Jan Beulich
Cc: Andrew Cooper
Changes in v3:
* Add a check to avoid XEN_MC_INJECT_CPU_BROADCAST being used
with XEN_MC_INJECT_TYPE_LMCE.
---
xen/arch/x86/cpu/mcheck/mce.c | 25 -
xen/include/public/arch-x86/xen-mca.h |
If option '-l' or '--lmce' is specified and the host supports LMCE,
xen-mceinj will inject LMCE to CPU specified by '-c' (or CPU0 if '-c'
is not present).
Signed-off-by: Haozhong Zhang
Acked-by: Wei Liu
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/tests/mce-test/tools/xen-mceinj.c | 50 +
flight 106986 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106986/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106637
test-amd64-amd64-xl-qemuu-win7-a
On Wed, Mar 29, 2017 at 10:08:02PM +0100, Andrew Cooper wrote:
> On 27/03/17 10:06, Joshua Otto wrote:
> > In the context of the live migration algorithm, the precopy iteration
> > count refers to the number of page-copying iterations performed prior to
> > the suspension of the guest and transmiss
flight 106985 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106985/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail REGR. vs. 106844
test-armhf-armh
On Wed, Mar 29, 2017 at 07:54:15PM +0100, Jennifer Herbert wrote:
> I would like to encourage this patch - as I have use for it outside
> of your postcopy work.
Glad to hear that!
> Some things people will comment on:
> You've used 'unsigned' without the int keyword, which people don't like.
> Al
On Wed, Mar 29, 2017 at 09:18:10PM +0100, Andrew Cooper wrote:
> On 27/03/17 10:06, Joshua Otto wrote:
> > The precopy phase of the xc_domain_save() live migration algorithm has
> > historically been implemented to run until either a) (almost) no pages
> > are dirty or b) some fixed, hard-coded max
On 29/03/17 20:53, Felix Schmoll wrote:
> Hi,
>
> while looking at this some more I came to the following
> questions/assumptions, so I'd be grateful if you could shortly address them:
>
> -While implementing our own kernel last semester me and my team-mate
> came to believe that pusha/popa were
flight 106979 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106979/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail REGR. vs. 106959
Regressions which
On Tue, Mar 28, 2017 at 08:52:26PM +0100, Andrew Cooper wrote:
> On 27/03/17 10:06, Joshua Otto wrote:
> > diff --git a/tools/libxc/xc_sr_stream_format.h
> > b/tools/libxc/xc_sr_stream_format.h
> > index 3291b25..32400b2 100644
> > --- a/tools/libxc/xc_sr_stream_format.h
> > +++ b/tools/libxc/xc_s
On Tue, Mar 28, 2017 at 08:27:48PM +0100, Andrew Cooper wrote:
> On 27/03/17 10:06, Joshua Otto wrote:
> > diff --git a/tools/libxc/xc_sr_restore.c b/tools/libxc/xc_sr_restore.c
> > index 481a904..8574ee8 100644
> > --- a/tools/libxc/xc_sr_restore.c
> > +++ b/tools/libxc/xc_sr_restore.c
> > @@ -194
On Tue, Mar 28, 2017 at 08:03:26PM +0100, Andrew Cooper wrote:
> On 27/03/17 10:06, Joshua Otto wrote:
> > Writing the libxc save stream requires writing a few 'trivial' records,
> > consisting only of a header with a particular type. As a readability
> > aid, it's nice to have obviously-named fun
On Sun, Mar 19, 2017 at 5:09 PM, Haozhong Zhang
wrote:
> This is v2 RFC patch series to add vNVDIMM support to HVM domains.
> v1 can be found at
> https://lists.xenproject.org/archives/html/xen-devel/2016-10/msg00424.html.
>
> No label and no _DSM except function 0 "query implemented functions"
>
On Tue, Mar 28, 2017 at 03:41:02PM +0100, Wei Liu wrote:
> Hi Harley, Chester and Joshua
>
> This is really nice work. I took a brief look at all the patches, they
> look really high quality.
Thank you!
>
> We're currently approaching freeze for a Xen release. We've got a lot on
> our plate. I
On Sun, Mar 19, 2017 at 5:09 PM, Haozhong Zhang
wrote:
> xen-ndctl is a tool for users in Dom0 to setup the host pmem with Xen
> hypervisor. It's used to specify the storage, which is either the
> regular RAM or a pmem range, to manage the specified pmem.
>
> Signed-off-by: Haozhong Zhang
> ---
>
Hi Stefano,
What do you say if we extend this project into "sharing multiple
ranges of memory area among VMs from the config file".
Cheers.
Zhongze Liu
2017-03-30 9:07 GMT+08:00 Zhongze Liu :
> Hi Stefano,
>
> Thanks for reminding me of the deadline and providing me with more information
> on t
flight 106977 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106977/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 106965
test-armhf-armhf-libvirt-x
Hi Julien,
On 2017/3/29 22:07, Julien Grall wrote:
>
>
> On 29/03/17 10:28, Wei Chen wrote:
>> Hi Julien,
>>
>> On 2017/3/29 16:40, Julien Grall wrote:
>>> Hi Wei,
>>>
>>> On 28/03/2017 08:23, Wei Chen wrote:
diff --git a/xen/include/asm-arm/arm32/insn.h
b/xen/include/asm-arm/arm32/insn
flight 106976 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106976/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 11 guest-start fail REGR. vs. 59254
test-armhf-armhf-xl
On 17-03-30 09:37:33, Yi Sun wrote:
> On 17-03-29 03:57:52, Jan Beulich wrote:
> > >>> On 29.03.17 at 03:36, wrote:
> > > On 17-03-29 09:20:21, Yi Sun wrote:
> > >> On 17-03-28 06:20:48, Jan Beulich wrote:
> > >> > >>> On 28.03.17 at 13:59, wrote:
> > >> > > I think we at least need a 'get_val()'
On 17-03-29 03:57:52, Jan Beulich wrote:
> >>> On 29.03.17 at 03:36, wrote:
> > On 17-03-29 09:20:21, Yi Sun wrote:
> >> On 17-03-28 06:20:48, Jan Beulich wrote:
> >> > >>> On 28.03.17 at 13:59, wrote:
> >> > > I think we at least need a 'get_val()' hook.
> >> >
> >> > Of course.
> >> >
> >> >
Hi Stefano,
Thanks for reminding me of the deadline and providing me with more information
on this project.
I did setup the arm model and doing well with it. But after that, I
encountered some
private issues that I have to handle first, so I failed to get back to
you immediately.
Sorry for that.
This run is configured for baseline tests only.
flight 71120 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71120/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 6e7ec25aaaf0dfc2b4c84ffd4c7ee7cd442aecb6
baseline v
On Fri, 3 Mar 2017, Julien Grall wrote:
> Hi Stefano,
>
> On 01/03/17 22:15, Stefano Stabellini wrote:
> > Move the atomic write of rank->vcpu, which sets the new vcpu target, to
> > vgic_migrate_irq, at the beginning of the lock protected area (protected
> > by the vgic lock).
> >
> > This code
On Fri, 3 Mar 2017, Julien Grall wrote:
> Hi Stefano,
>
> On 01/03/17 22:15, Stefano Stabellini wrote:
> > A potential race condition occurs when vgic_migrate_irq is called a
> > second time, while GIC_IRQ_GUEST_MIGRATING is already set. In that case,
> > vgic_migrate_irq takes a different vgic lo
On 27/03/2017 10:06, Joshua Otto wrote:
> Hi,
>
> We're a team of three fourth-year undergraduate software engineering students
> at
> the University of Waterloo in Canada. In late 2015 we posted on the list [1]
> to
> ask for a project to undertake for our program's capstone design project, and
Hi,
On 29/03/2017 23:36, Stefano Stabellini wrote:
On Wed, 29 Mar 2017, Oleksandr Andrushchenko wrote:
If you can come up with a patch that only affects
xen_swiotlb_get_sgtable, and translates successfully void *cpu_addr into
a physical address using "at", I think I would take that patch. I woul
On Wed, 29 Mar 2017, Oleksandr Andrushchenko wrote:
> Hi, Stefano!
>
> Ok, probably I need to put more details into the use-case
> so it is clear. What I am doing is a DRM driver which
> utilizes PRIME buffer sharing [1] to implement zero-copy
> of display buffers between DomU and Dom0. PRIME is b
Define the ring according to the protocol specification, using the new
DEFINE_XEN_FLEX_RING_AND_INTF macro.
Add the header to the C99 check.
Signed-off-by: Stefano Stabellini
CC: jbeul...@suse.com
CC: konrad.w...@oracle.com
---
xen/include/Makefile | 5 -
xen/include/public/io/9pfs
Define the ring and request and response structs according to the
specification. Use the new DEFINE_XEN_FLEX_RING macro.
Add the header to the C99 check.
Signed-off-by: Stefano Stabellini
CC: jbeul...@suse.com
CC: konrad.w...@oracle.com
---
xen/include/Makefile| 4 +-
xen/include/
Hi all,
this patch series introduces a set of new ring macros to support rings
in the formats specified by the Xen 9pfs transport and PV Calls
protocol. It also introduces the Xen 9pfs and PV Calls protocols
headers.
Changes in v6:
- remove stray semicolons
- code style fix for return statements
Introduce a C99 headers check, for non-ANSI compliant headers: 9pfs.h
and pvcalls.h.
In addition to the usual -include stdint.h, also add -include string.h
to the C99 check to get the declaration of memcpy and size_t.
For the same reason, also add -include cstring to the C++ check when
necessary.
This patch introduces macros, structs and functions to handle rings in
the format described by docs/misc/pvcalls.markdown and
docs/misc/9pfs.markdown. The index page (struct __name##_data_intf)
contains the indexes and the grant refs to setup two rings.
Indexes page
+
On Wed, 29 Mar 2017, Xen.org security team wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory XSA-206
version 9
xenstore denial of service via repeated update
I am seeing a build failure from these patches whe
On Wed, 29 Mar 2017, Jan Beulich wrote:
> >>> On 29.03.17 at 00:08, wrote:
> > Introduce a C99 headers check, for non-ANSI compliant headers: 9pfs.h
> > and pvcalls.h.
> >
> > In addition to the usual -include stdint.h, also add -include string.h
> > to the C99 check to get the declaration of mem
On Wed, 29 Mar 2017, Jan Beulich wrote:
> >>> On 28.03.17 at 23:04, wrote:
> > On Tue, 28 Mar 2017, Jan Beulich wrote:
> >> >>> Stefano Stabellini 03/27/17 10:54 PM >>>
> >> >On Mon, 27 Mar 2017, Jan Beulich wrote:
> >> >> >>> On 24.03.17 at 19:31, wrote:
> >> >> > +/*
> >> >> > + * See docs/mis
On Wed, 29 Mar 2017, Julien Grall wrote:
> Hi,
>
> On 28/03/2017 16:23, Julien Grall wrote:
> > Hi all,
> >
> > Apologies for the late sending, you will find at the end of the e-mail a
> > summary of the discussion from the previous call. Feel free to reply if I
> > missed some parts.
> >
> > I
Hi,
On 28/03/2017 16:23, Julien Grall wrote:
Hi all,
Apologies for the late sending, you will find at the end of the e-mail a
summary of the discussion from the previous call. Feel free to reply if I
missed some parts.
I suggest to have the next call on the 5th April at 5PM UTC. Any opinions?
flight 106978 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106978/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 6e7ec25aaaf0dfc2b4c84ffd4c7ee7cd442aecb6
baseline version:
ovmf 89ad870fbff03a511102c
On 27/03/17 10:06, Joshua Otto wrote:
> In the context of the live migration algorithm, the precopy iteration
> count refers to the number of page-copying iterations performed prior to
> the suspension of the guest and transmission of the final set of dirty
> pages. Similarly, the precopy dirty th
flight 106984 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106984/
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
test-amd64-amd64-libvirt 12 mig
On Wed, 29 Mar 2017, Jan Beulich wrote:
> >>> On 29.03.17 at 00:08, wrote:
> > +#define DEFINE_XEN_FLEX_RING(name)
> >\
> > +static inline RING_IDX name##_mask(RING_IDX idx, RING_IDX ring_size)
> >\
> > +{
On 27/03/17 10:06, Joshua Otto wrote:
> The precopy phase of the xc_domain_save() live migration algorithm has
> historically been implemented to run until either a) (almost) no pages
> are dirty or b) some fixed, hard-coded maximum number of precopy
> iterations has been exceeded. This policy and
On Wed, 29 Mar 2017, Jan Beulich wrote:
> >>> On 29.03.17 at 00:08, wrote:
> > --- a/xen/include/public/io/ring.h
> > +++ b/xen/include/public/io/ring.h
> > @@ -27,6 +27,21 @@
> > #ifndef __XEN_PUBLIC_IO_RING_H__
> > #define __XEN_PUBLIC_IO_RING_H__
> >
> > +/*
> > + * When #include'ing this h
Hello,
Felix Schmoll, on mer. 29 mars 2017 20:53:14 +0200, wrote:
> -While implementing our own kernel last semester me and my team-mate
> came to believe that pusha/popa were faster that pushing/popping the
> individual registers, since it is just a single command. The Mini-OS
> kernel however do
Hi,
while looking at this some more I came to the following
questions/assumptions, so I'd be grateful if you could shortly address them:
-While implementing our own kernel last semester me and my team-mate came
to believe that pusha/popa were faster that pushing/popping the individual
registers,
Hi,
I would like to encourage this patch - as I have use for it outside
of your postcopy work.
Some things people will comment on:
You've used 'unsigned' without the int keyword, which people don't like.
Also on line 324, your missing space between 'if (' and
'ctx->save.policy_decision'.
Also
On Wed, 29 Mar 2017, Paolo Bonzini wrote:
> On 29/03/2017 01:54, Stefano Stabellini wrote:
> >>> I understand your point of view, and honestly it wouldn't be a problem
> >>> doing it the way you suggested either. However, I think that going
> >>> forward it will be less of a maintenance pain to kee
For all other people who happen to see this patch: this isn't meant to
be applied.
Cc Juergen as well.
On Wed, Mar 29, 2017 at 08:07:39PM +0200, Felix Schmoll wrote:
> Minimal implementation of a new hypercall that returns the domain
> id of the invoking domain with adjustments in libxc.
>
I th
flight 106982 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106982/
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
test-amd64-amd64-libvirt 12 mig
On Wed, Mar 29, 2017 at 08:16:02PM +0200, Felix Schmoll wrote:
> Make minimal adjustments in order to enable the compilation of the
> xen source-code with gcc-6's -fsanitize-coverage=trace-pc option.
>
> Due to a bug in Xen's build-system the flag for the compiler has
> to be handed in via the com
2017-03-29 17:54 GMT+02:00 Wei Liu :
> On Wed, Mar 29, 2017 at 04:24:15PM +0200, Felix Schmoll wrote:
> > Hi,
> >
> > here the final patch for the domain_id:
>
> Please have a look at
>
> https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches
>
> And follow the instructions to submit patc
Make minimal adjustments in order to enable the compilation of the
xen source-code with gcc-6's -fsanitize-coverage=trace-pc option.
Due to a bug in Xen's build-system the flag for the compiler has
to be handed in via the command line, i.e. for compiling one would
use:
make CC=
This is a
Minimal implementation of a new hypercall that returns the domain
id of the invoking domain with adjustments in libxc.
Signed-off-by: Felix Schmoll
---
tools/libxc/include/xenctrl.h | 1 +
tools/libxc/xc_private.c | 6 ++
xen/arch/arm/traps.c | 1 +
xen/arch/x86/hvm/hypercall.c
On Tue, Mar 28, 2017 at 08:59:09PM +0100, Andrew Cooper wrote:
> On 27/03/17 10:06, Joshua Otto wrote:
> > colo_merge_secondary_dirty_bitmap() unconditionally free()s the .data
> > member of its local xc_sr_record structure rec on its exit path.
> > However, if the initial call to read_record() fai
branch xen-unstable
xenbranch xen-unstable
job build-i386-libvirt
testid libvirt-build
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen
On 29/03/17 17:45, Wei Liu wrote:
> On Wed, Mar 29, 2017 at 12:35:25PM -0400, Boris Ostrovsky wrote:
>> On 03/29/2017 12:25 PM, Wei Liu wrote:
>>> On Fri, Mar 24, 2017 at 01:05:04PM -0400, Boris Ostrovsky wrote:
+static void check_one_page(struct page_info *pg)
+{
+mfn_t mfn = _m
From: Jennifer Herbert
This new lib devicemodel call allows multiple extents of pages to be
marked as modified in a single call. This is something needed for a
usecase I'm working on.
The xen side of the modified_memory call has been modified to accept
an array of extents. The devicemodle libr
On Wed, Mar 29, 2017 at 12:35:25PM -0400, Boris Ostrovsky wrote:
> On 03/29/2017 12:25 PM, Wei Liu wrote:
> > On Fri, Mar 24, 2017 at 01:05:04PM -0400, Boris Ostrovsky wrote:
> >> +static void check_one_page(struct page_info *pg)
> >> +{
> >> +mfn_t mfn = _mfn(page_to_mfn(pg));
> >> +uint64
On 03/29/2017 12:25 PM, Wei Liu wrote:
> On Fri, Mar 24, 2017 at 01:05:04PM -0400, Boris Ostrovsky wrote:
>> +static void check_one_page(struct page_info *pg)
>> +{
>> +mfn_t mfn = _mfn(page_to_mfn(pg));
>> +uint64_t *ptr;
>> +
>> +ptr = map_domain_page(mfn);
>> +ASSERT(*ptr != PAG
On Fri, Mar 24, 2017 at 01:05:04PM -0400, Boris Ostrovsky wrote:
> +static void check_one_page(struct page_info *pg)
> +{
> +mfn_t mfn = _mfn(page_to_mfn(pg));
> +uint64_t *ptr;
> +
> +ptr = map_domain_page(mfn);
> +ASSERT(*ptr != PAGE_POISON);
Should be ASSERT(*ptr == 0) here.
_
On Wed, Mar 29, 2017 at 04:38:43PM +0100, Andrew Cooper wrote:
> MEM_LOG() is just a thin wrapper around gdprintk(), obscuring some of the
> common information. Inline it, and take the opportunity to correct some of
> the printked information.
>
> Some corrections, each where appropriate:
> * Co
On Wed, Mar 29, 2017 at 04:24:15PM +0200, Felix Schmoll wrote:
> Hi,
>
> here the final patch for the domain_id:
Please have a look at
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches
And follow the instructions to submit patches.
___
On 03/29/2017 06:04 PM, Razvan Cojocaru wrote:
> On 03/29/2017 05:00 PM, Razvan Cojocaru wrote:
>> On 03/29/2017 04:55 PM, Jan Beulich wrote:
>> On 28.03.17 at 12:50, wrote:
On 03/28/2017 01:47 PM, Jan Beulich wrote:
On 28.03.17 at 12:27, wrote:
>> On 03/28/2017 01:03 PM, Ja
Hi,
On 29/10/16 01:39, Stefano Stabellini wrote:
> On Wed, 28 Sep 2016, Andre Przywara wrote:
>> Allow a guest to provide the address and size for the memory regions
>> it has reserved for the GICv3 pending and property tables.
>> We sanitise the various fields of the respective redistributor
>> r
On 29/03/17 15:54, Jan Beulich wrote:
On 28.03.17 at 15:18, wrote:
@@ -441,13 +481,8 @@ static int dm_op(domid_t domid,
struct xen_dm_op_modified_memory *data =
&op.u.modified_memory;
-const_op = false;
-
-rc = -EINVAL;
-if ( data->pad )
-
MEM_LOG() is just a thin wrapper around gdprintk(), obscuring some of the
common information. Inline it, and take the opportunity to correct some of
the printked information.
Some corrections, each where appropriate:
* Correction of pfn/mfn terms and consistent use of PRI_pfn/mfn
* s!I/O!MMIO!
On 03/29/2017 05:00 PM, Razvan Cojocaru wrote:
> On 03/29/2017 04:55 PM, Jan Beulich wrote:
> On 28.03.17 at 12:50, wrote:
>>> On 03/28/2017 01:47 PM, Jan Beulich wrote:
>>> On 28.03.17 at 12:27, wrote:
> On 03/28/2017 01:03 PM, Jan Beulich wrote:
> On 28.03.17 at 11:14, wrot
>>> On 29.03.17 at 16:35, wrote:
> On 29/03/17 11:38, Jan Beulich wrote:
> On 28.03.17 at 15:18, wrote:
>>> @@ -441,13 +481,8 @@ static int dm_op(domid_t domid,
>>> struct xen_dm_op_modified_memory *data =
>>> &op.u.modified_memory;
>>>
>>> -const_op = false
A number of changes have been made to how we determine whether TSC
is emulated (e.g. commit 4fc380ac0077 ("x86/time: don't use virtual TSC
if host and guest frequencies are equal")).
Update the man page to reflect those changes
Signed-off-by: Boris Ostrovsky
Suggested-by: Olaf Hering
---
docs/
Rename it to NR_HVM_DOMU_IRQS, and get it's value from the size of the DomU vIO
APIC redirection table.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
Changes since v2:
- New in this version.
NB: this patch makes it easier to get rid of VIOAPIC_NUM_PINS in later patc
Rearrange the fields of hvm_irq so that gsi_assert_count can be converted into
a variable size array and add a new field to account the number of GSIs.
Due to this changes the irq member in the hvm_domain struct also needs to
become a pointer set at runtime.
Signed-off-by: Roger Pau Monné
---
Cc
Although it's still always set to VIOAPIC_NUM_PINS (48).
Add a new field to the hvm_ioapic struct to contain the number of pins (number
of IO redirection table entries) and turn the redirection table into a variable
sized array.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Coop
So that the function can be called from other files without adding prototypes
to each of them.
Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
Changes since v1:
- Add io_ prefix to avoid confusion.
- Make the parameter unsigned.
---
xen/arch/x8
Add support for multiple vIO APICs on the same domain, thus turning
d->arch.hvm_domain.vioapic into an array of vIO APIC control structures.
Note that this functionality is not exposed to unprivileged guests, and will
only be used by PVHv2 Dom0.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
The base address, id and number of pins of the vIO APICs exposed to PVHv2 Dom0
is the same as the values found on bare metal.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/dom0_build.c | 33 -
Introduce a macro to get a pointer to the hvm_irq for a HVM domain. No
functional change.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Kevin Tian
---
Changes since v2:
- Switch d->arch.hvm_domain.irq.dpci accesses to use the macro also.
---
NB: this is a pre-patch
This is required in order to have a variable number of vIO APIC pins, instead
of the current fixed value (48). Note that this patch only expands the fields
of the hvm_vioapic struct, without actually introducing any new fields or
functionality.
The reason to expand the hvm_vioapic structure instea
Hello,
This patch series introduce support for having a variable number of entries in
vIO APICs, and also having a variable number of vIO APICs per domain. This
functionality is not used by unprivileged guests, that are still limited to a
single IO APIC with 48 entries.
The functionality introduc
On 29/03/17 11:38, Jan Beulich wrote:
On 28.03.17 at 15:18, wrote:
Perhaps drop "already"? Personally I also wouldn't mind you dropping
the variable altogether and using header->opaque directly, but I
guess that's too "opaque" for your taste?
It would make the code too opaque for my taste
Hi,
here the final patch for the domain_id:
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 2d97d36c38..1e152c8a07 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1569,6 +1569,7 @@ int xc_domctl(xc_interface *xch, struct xen_domc
Hi Wei,
On 27/03/17 09:40, Wei Chen wrote:
Signed-off-by: Wei Chen
Thank you for updating the commit message :). With the small change below:
Reviewed-by: Julien Grall
---
Notes:
This bug will affect the staging, staging-4.8 and stable-4.8 source trees.
---
v2->v3
1. Fix typos.
2. Explai
On 03/29/2017 04:55 PM, Jan Beulich wrote:
On 28.03.17 at 12:50, wrote:
>> On 03/28/2017 01:47 PM, Jan Beulich wrote:
>> On 28.03.17 at 12:27, wrote:
On 03/28/2017 01:03 PM, Jan Beulich wrote:
On 28.03.17 at 11:14, wrote:
>> I'm not sure that the RETRY model is what th
Cc-ing Julien, as this series is meant for 4.9.
Juergen
On 28/03/17 18:26, Juergen Gross wrote:
> Rework the transaction handling of xenstored to no longer raise
> conflicts so often.
>
> This series has been sent for pre-review to some reviewers before as the
> series is related to XSA 206 whic
On 29/03/17 15:01, Jan Beulich wrote:
On 29.03.17 at 15:50, wrote:
>> On 29/03/17 14:06, Jan Beulich wrote:
>> On 29.03.17 at 14:29, wrote:
@@ -1068,10 +1073,10 @@ get_page_from_l1e(
return 0;
could_not_pin:
-MEM_LOG("Error getting mfn %lx (pfn %lx)
On 29/03/17 10:28, Wei Chen wrote:
Hi Julien,
On 2017/3/29 16:40, Julien Grall wrote:
Hi Wei,
On 28/03/2017 08:23, Wei Chen wrote:
diff --git a/xen/include/asm-arm/arm32/insn.h b/xen/include/asm-arm/arm32/insn.h
new file mode 100644
index 000..4cda69e
--- /dev/null
+++ b/xen/include/asm
On 03/29/2017 09:47 AM, Boris Ostrovsky wrote:
> On 03/29/2017 06:28 AM, Wei Liu wrote:
>> On Fri, Mar 24, 2017 at 01:05:01PM -0400, Boris Ostrovsky wrote:
>>> While waiting for a lock we may want to periodically run some
>>> code. We could use spin_trylock() but since it doesn't take lock
>>> tick
>>> On 29.03.17 at 15:50, wrote:
> On 29/03/17 14:06, Jan Beulich wrote:
> On 29.03.17 at 14:29, wrote:
>>> @@ -1068,10 +1073,10 @@ get_page_from_l1e(
>>> return 0;
>>>
>>> could_not_pin:
>>> -MEM_LOG("Error getting mfn %lx (pfn %lx) from L1 entry %" PRIpte
>>> -" for
On 03/29/2017 04:55 PM, Jan Beulich wrote:
On 28.03.17 at 12:50, wrote:
>> On 03/28/2017 01:47 PM, Jan Beulich wrote:
>> On 28.03.17 at 12:27, wrote:
On 03/28/2017 01:03 PM, Jan Beulich wrote:
On 28.03.17 at 11:14, wrote:
>> I'm not sure that the RETRY model is what th
Hi,
On 22/03/17 16:33, Julien Grall wrote:
[ ... ]
gicv3_dist_init();
+res = gicv3_its_init();
+if ( res )
+printk(XENLOG_WARNING "GICv3: ITS: initialization failed:
%d\n", res);
>>>
>>> I would have expect a panic here because the ITS subsystem could
>>> On 28.03.17 at 12:50, wrote:
> On 03/28/2017 01:47 PM, Jan Beulich wrote:
> On 28.03.17 at 12:27, wrote:
>>> On 03/28/2017 01:03 PM, Jan Beulich wrote:
>>> On 28.03.17 at 11:14, wrote:
> I'm not sure that the RETRY model is what the guest OS expects. AFAIK, a
> failed CMPXCHG
On 03/29/2017 06:28 AM, Wei Liu wrote:
> On Fri, Mar 24, 2017 at 01:05:01PM -0400, Boris Ostrovsky wrote:
>> While waiting for a lock we may want to periodically run some
>> code. We could use spin_trylock() but since it doesn't take lock
>> ticket it may take a long time until the lock is taken.
>
1 - 100 of 165 matches
Mail list logo
