On Fri, Feb 10, 2017 at 02:54:23AM -0700, Jan Beulich wrote:
> >>> On 09.02.17 at 23:24, wrote:
> > On Thu, 9 Feb 2017, Jan Beulich wrote:
> >> the recent qemuu update results in the produced binary triggering the
> >> OOM killer on the first system I tried the updated
Hi,
On 01/26/2017 09:11 PM, Julien Grall wrote:
Hi,
On 26/01/2017 19:01, Boris Ostrovsky wrote:
On 01/26/2017 12:18 PM, Ian Jackson wrote:
Boris Ostrovsky writes ("Re: [Xen-devel] [linux-linus test] 104684:
regressions - FAIL"):
On 01/26/2017 08:23 AM, osstest service owner wrote:
flight
On 13/02/17 11:00, Andrew Cooper wrote:
> XSA-173 (c/s 8b1764833) introduces gfn_bits, and an upper limit which might be
> lower than the real maxphysaddr, to avoid overflowing the superpage shadow
> backpointer.
>
> However, plenty of hardware has a physical address width less that 44 bits,
>
..calculating its value during runtime.
Signed-off-by: Daniel Kiper
Acked-by: Jan Beulich
Reviewed-by: Doug Goldstein
---
xen/arch/x86/setup.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git
This way macro name better describes its function.
Currently it is used to calculate symbol offset in
relation to the beginning of Xen image mapping.
However, value returned by sym_offs() for a given
symbol is not always equal its physical address.
There is no functional change.
Suggested-by:
Add multiboot2 protocol support for relocatable images. Only GRUB2 with
"multiboot2: Add support for relocatable images" patch understands
that feature. Older multiboot protocol (regardless of version)
compatible loaders ignore it and everything works as usual.
Signed-off-by: Daniel Kiper
On Tue, Feb 14, 2017 at 02:57:42PM +, Julien Grall wrote:
> Hi,
>
> On 01/26/2017 09:11 PM, Julien Grall wrote:
> > Hi,
> >
> > On 26/01/2017 19:01, Boris Ostrovsky wrote:
> > > On 01/26/2017 12:18 PM, Ian Jackson wrote:
> > > > Boris Ostrovsky writes ("Re: [Xen-devel] [linux-linus test]
On 14/02/17 17:42, George Dunlap wrote:
> On 13/02/17 11:00, Andrew Cooper wrote:
>> XSA-173 (c/s 8b1764833) introduces gfn_bits, and an upper limit which might
>> be
>> lower than the real maxphysaddr, to avoid overflowing the superpage shadow
>> backpointer.
>>
>> However, plenty of hardware
On Tue, 14 Feb 2017, Boris Ostrovsky wrote:
> On 02/13/2017 12:03 PM, Paul Durrant wrote:
> > Recently a new dm_op[1] hypercall was added to Xen to provide a mechanism
> > for restricting device emulators (such as QEMU) to a limited set of
> > hypervisor operations, and being able to audit those
On Tue, Feb 14, Stefano Stabellini wrote:
> Also, I tried to do the same conversion with my copy of Libreoffice and
> the FODT files produced are significantly different from yours, which
> means, even if we use FODT docs, we are probably going to be unable to
> send changes as meaningful text
On Mon, Feb 13, 2017 at 11:47:26AM -0800, Stefano Stabellini wrote:
Reviewed-by: Konrad Rzeszutek Wilk
> Changes in v5:
> - add padding after out_prod
> - add "Why ring.h is not needed"
> - specify max-ring-page-order >= 1
___
Hi,
On 02/13/2017 10:14 PM, Stefano Stabellini wrote:
On Mon, 13 Feb 2017, Tamas K Lengyel wrote:
On Mon, Feb 13, 2017 at 2:54 PM, Stefano Stabellini
wrote:
On Mon, 13 Feb 2017, Tamas K Lengyel wrote:
On Mon, Feb 13, 2017 at 2:13 PM, Stefano Stabellini
flight 105790 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105790/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-buildfail REGR. vs. 105756
On 14/02/17 18:33, Daniel Kiper wrote:
> init.data section is clearly writable, so, add "w" flag to its
> definition in xen/arch/x86/boot/x86_64.S.
>
> Signed-off-by: Daniel Kiper
Reviewed-by: Andrew Cooper
On 14/02/17 17:49, George Dunlap wrote:
> On 14/02/17 17:45, Andrew Cooper wrote:
>> On 14/02/17 17:42, George Dunlap wrote:
>>> On 13/02/17 11:00, Andrew Cooper wrote:
XSA-173 (c/s 8b1764833) introduces gfn_bits, and an upper limit which
might be
lower than the real maxphysaddr,
On Tue, 14 Feb 2017, Julien Grall wrote:
> Hi Stefano,
>
> On 02/13/2017 07:59 PM, Stefano Stabellini wrote:
> > On Mon, 13 Feb 2017, Julien Grall wrote:
> >> Hi Stefano,
> >>
> >> On 10/02/17 01:01, Stefano Stabellini wrote:
> >>> On Fri, 3 Feb 2017, Edgar E. Iglesias wrote:
> A possible
On Tue, Feb 14, 2017 at 07:33:24PM +0100, Daniel Kiper wrote:
> This way Xen can be loaded on EFI platforms using GRUB2 and
> other boot loaders which support multiboot2 protocol.
>
> Signed-off-by: Daniel Kiper
I am posting diff between v14 and v15 for your convenience.
This patch makes the GDT remapped pages read-only to prevent corruption.
This change is done only on 64-bit.
The native_load_tr_desc function was adapted to correctly handle a
read-only GDT. The LTR instruction always writes to the GDT TSS entry.
This generates a page fault if the GDT is
flight 105797 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105797/
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
On 14/02/17 17:45, Andrew Cooper wrote:
> On 14/02/17 17:42, George Dunlap wrote:
>> On 13/02/17 11:00, Andrew Cooper wrote:
>>> XSA-173 (c/s 8b1764833) introduces gfn_bits, and an upper limit which might
>>> be
>>> lower than the real maxphysaddr, to avoid overflowing the superpage shadow
>>>
This patch aligns MODULES_END to the beginning of the Fixmap section.
It optimizes the space available for both sections. The address is
pre-computed based on the number of pages required by the Fixmap
section.
It will allow GDT remapping in the Fixmap section. The current
MODULES_END static
Each processor holds a GDT in its per-cpu structure. The sgdt
instruction gives the base address of the current GDT. This address can
be used to bypass KASLR memory randomization. With another bug, an
attacker could target other per-cpu structures or deduce the base of
the main memory section
The KVM segment_base function is confusing. This patch replaces integers
with appropriate flags, simplify constructs and add comments.
Signed-off-by: Thomas Garnier
---
Based on next-20170213
---
arch/x86/kvm/vmx.c | 26 ++
1 file changed, 18
Ping as I am also interested in modifying kbdfront...
On 02/09/2017 03:45 PM, Juergen Gross wrote:
On 30/01/17 16:10, Juergen Gross wrote:
Instead of using the default resolution of 800*600 for the pointing
device of xen-kbdfront try to read the resolution of the (virtual)
framebuffer device.
> From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On Behalf Of Andrew Cooper
> Sent: Tuesday, February 14, 2017 3:59 PM
>
> On 14/02/2017 02:52, Tian, Kevin wrote:
> >> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> >> Sent: Monday, February 13, 2017 10:32 PM
> >>
> >>
This run is configured for baseline tests only.
flight 68555 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68555/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5b97eb4c35316cbe8235ae526209263da818e1a4
baseline
On 14/02/2017 08:04, Tian, Kevin wrote:
>> From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On Behalf Of Andrew
>> Cooper
>> Sent: Tuesday, February 14, 2017 3:59 PM
>>
>> On 14/02/2017 02:52, Tian, Kevin wrote:
From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
Sent: Monday,
On Tue, Feb 14, 2017 at 08:46:56AM +, Roger Pau Monne wrote:
> Hello,
>
> These patches fix the remaining issues so that Wformat can be enabled for
> clang.
This has now been superseded by "[PATCH v4 0/4] clang: don't disable any
warnings". Please ignore this series.
Roger.
> On 14/02/17 02:19, Luwei Kang wrote:
> > vpmu_enable() can not use for check if vpmu is enabled in guest during
> > booting up. Because linux kernel get the status of if supported pmu is
> > earler than xen vpmu initialise. vpmu_enable() will return false even
> > if vpmu has been enabled in
On Tue, Feb 14, 2017 at 10:29 AM, Wei Liu wrote:
> On Thu, Feb 09, 2017 at 11:35:16AM +, George Dunlap wrote:
>> No. This is why I'm bothering to paint this bikeshed: In every context
>> *except* "cpupool create", 0 means cpupool0 -- the one that was created
>> at boot,
flight 105784 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105784/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR.
vs. 105756
Due to the large number of grants in use it seems more useful to print the
grant references and handlers in hex format rather than decimal.
Signed-off-by: Roger Pau Monné
Reviewed-by: Andrew Cooper
---
Cc: Andrew Cooper
And fix the following errors reported:
traps.c:2014:25: error: equality comparison with extraneous parentheses
[-Werror,-Wparentheses-equality]
else if ( (port == RTC_PORT(0)) )
~^~
traps.c:2014:25: note: remove extraneous parentheses around the
Hello,
The following series removes the disable of certain clang warnings, after this
all clang warnings are enabled. This supersedes "[PATCH v3 0/2] Enable Wformat
for clang".
It has been tested in FreeBSD with clang 3.8, and by travis, all OK:
https://travis-ci.org/royger/xen/builds/201482055
The following incorrect format specifiers and incorrect number of parameters
passed to printf like functions are reported by clang:
mce.c:601:18: error: data argument not used by format string
[-Werror,-Wformat-extra-args]
smp_processor_id());
^
xenpm.c:102:23:
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano
>>> On 14.02.17 at 03:19, wrote:
> vpmu_enable() can not use for check if vpmu is enabled in guest during
> booting up. Because linux kernel get the status of if supported pmu
> is earler than xen vpmu initialise. vpmu_enable() will return false
> even if vpmu has been
On Mon, Feb 13, 2017 at 06:53:49AM -0700, Jan Beulich wrote:
> >>> On 10.02.17 at 13:33, wrote:
> > ---
> > Changes since v5:
> > - Adjust the logic to set need_paging.
> > - Remove the usage of the _AC macro.
> > - Subtract memory from the end of regions instead of the
On Mon, Feb 13, 2017 at 04:05:19PM +, Roger Pau Monne wrote:
> On Mon, Feb 13, 2017 at 03:59:15PM +, Wei Liu wrote:
> > On Mon, Feb 13, 2017 at 03:49:14PM +, Roger Pau Monne wrote:
> > > Sorry, I've forgot to re-generate the patch after adding the
> > > maintainers...
> > >
> > > On
>>> On 14.02.17 at 11:19, wrote:
> On Tue, Feb 14, 2017 at 10:10:16AM +, Roger Pau Monne wrote:
>> On Mon, Feb 13, 2017 at 06:53:49AM -0700, Jan Beulich wrote:
>> > >>> On 10.02.17 at 13:33, wrote:
>> > > --- a/xen/include/asm-x86/page.h
>> > > +++
1: VMX: fix VMCS race on context-switch paths
2: x86: package up context switch hook pointers
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
They're all solely dependent on guest type, so we don't need to repeat
all the same four pointers in every vCPU control structure. Instead use
static const structures, and store pointers to them in the domain
control structure.
Since touching it anyway, take the opportunity and move
On Thu, Feb 09, 2017 at 11:35:16AM +, George Dunlap wrote:
> On 09/02/17 11:24, Wei Liu wrote:
> > On Thu, Feb 09, 2017 at 11:17:46AM +, George Dunlap wrote:
> >> On 09/02/17 10:35, Wei Liu wrote:
> >>> On Wed, Feb 08, 2017 at 04:17:58PM +, George Dunlap wrote:
> On 08/02/17
On 13/02/17 14:21, Sergey Dyasli wrote:
> Sergey Dyasli (3):
> x86/vmx: introduce VMX_INSN_SUCCEED
> x86/vvmx: correctly emulate VMWRITE
> x86/vvmx: correctly emulate VMREAD
Committed, thanks.
~Andrew
___
Xen-devel mailing list
When __context_switch() is being bypassed during original context
switch handling, the vCPU "owning" the VMCS partially loses control of
it: It will appear non-running to remote CPUs, and hence their attempt
to pause the owning vCPU will have no effect on it (as it already
looks to be paused). At
On 14/02/17 10:33, Jan Beulich wrote:
On 13.02.17 at 14:03, wrote:
>> --- /dev/null
>> +++ b/xen/arch/x86/hvm/hypercall.c
>> @@ -0,0 +1,332 @@
>> +/**
>> + * arch/hvm/hypercall.c
>> + *
>>
>>> On 14.02.17 at 11:37, wrote:
> 997382 introduced the following errors:
>
> intr.c:342:46: error: address of array 'vlapic->regs->data' will always
> evaluate to 'true'
> [-Werror,-Wpointer-bool-conversion]
> if ( vlapic && vlapic->regs->data )
>
On 13/02/17 16:20, Jan Beulich wrote:
On 13.02.17 at 14:58, wrote:
>> On 13/02/17 11:40, Jan Beulich wrote:
>> On 10.02.17 at 17:38, wrote:
On 01/02/17 11:12, Jan Beulich wrote:
> Before adding more use of stubs cloned from
> >>> On 14.02.17 at 03:19, wrote:
> > vpmu_enable() can not use for check if vpmu is enabled in guest during
> > booting up. Because linux kernel get the status of if supported pmu is
> > earler than xen vpmu initialise. vpmu_enable() will return false even
> > if vpmu has
flight 105785 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105785/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 105720
test-armhf-armhf-libvirt 13
>>> On 14.02.17 at 11:10, wrote:
> On Mon, Feb 13, 2017 at 06:53:49AM -0700, Jan Beulich wrote:
>> >>> On 10.02.17 at 13:33, wrote:
>> > +static int __init pvh_steal_ram(struct domain *d, unsigned long size,
>> > +
On 14/02/17 02:19, Luwei Kang wrote:
> vpmu_enable() can not use for check if vpmu is enabled in guest during
> booting up. Because linux kernel get the status of if supported pmu
> is earler than xen vpmu initialise. vpmu_enable() will return false
> even if vpmu has been enabled in guest.
Sorry
>>> On 13.02.17 at 14:03, wrote:
> --- /dev/null
> +++ b/xen/arch/x86/hvm/hypercall.c
> @@ -0,0 +1,332 @@
> +/**
> + * arch/hvm/hypercall.c
> + *
> + * HVM hypercall dispatching routines
> + *
>
997382 introduced the following errors:
intr.c:342:46: error: address of array 'vlapic->regs->data' will always
evaluate to 'true'
[-Werror,-Wpointer-bool-conversion]
if ( vlapic && vlapic->regs->data )
~~ ~~^~~~
intr.c:352:42: error:
>>> On 13.02.17 at 14:03, wrote:
> --- a/xen/arch/x86/hvm/hypercall.c
> +++ b/xen/arch/x86/hvm/hypercall.c
> @@ -73,10 +73,12 @@ static long hvm_grant_table_op(
>
> static long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
> {
> +struct vcpu *curr =
My previous reply got bounced because my tablet insisted on using HTML...
> -Original Message-
>
> These need to be static. (I can fix it when committing.)
Ok, thanks.
>
> And I am still not sure about using XEN_PAGE_SIZE. There is no
> dependency in the hypervisor on buffers being
>>> On 07.02.17 at 00:32, wrote:
> Commit c7bdecae42 ("x86/apicv: fix RTC periodic timer and apicv issue") has
> added a assertion that intack.vector is the highest priority vector. But
> according to the osstest, the assertion failed sometimes. More discussion can
> be found
> From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On Behalf Of Andrew Cooper
> Sent: Tuesday, February 14, 2017 4:19 PM
>
> On 14/02/2017 08:04, Tian, Kevin wrote:
> >> From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On Behalf Of Andrew
> Cooper
> >> Sent: Tuesday, February 14, 2017 3:59
On Tue, Feb 14, 2017 at 03:46:37AM -0700, Jan Beulich wrote:
> >>> On 14.02.17 at 11:37, wrote:
> > 997382 introduced the following errors:
> >
> > intr.c:342:46: error: address of array 'vlapic->regs->data' will always
> > evaluate to 'true'
> >
The following incorrect format specifiers and incorrect number of parameters
passed to printf like functions are reported by clang:
mce.c:601:18: error: data argument not used by format string
[-Werror,-Wformat-extra-args]
smp_processor_id());
^
xenpm.c:102:23:
Hello,
These patches fix the remaining issues so that Wformat can be enabled for
clang.
This patches have been tested on FreeBSD with clang 3.8, and travis:
https://travis-ci.org/royger/xen/builds/201165863
Thanks, Roger.
___
Xen-devel mailing list
>>> On 13.02.17 at 19:26, wrote:
> On 13/02/17 13:19, Jan Beulich wrote:
>> ---
>> TBD: Do we really want to re-init the TSS every time we are about to
>> use it? This can happen quite often during boot, especially while
>> grub is running.
>
> The only case
flight 105781 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105781/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 105279
>>> On 14.02.17 at 09:40, wrote:
>> From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On Behalf Of Andrew
>> Cooper
>> Sent: Tuesday, February 14, 2017 4:19 PM
>>
>> On 14/02/2017 08:04, Tian, Kevin wrote:
>> >> From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On
On Tue, Feb 14, 2017 at 10:10:16AM +, Roger Pau Monne wrote:
> On Mon, Feb 13, 2017 at 06:53:49AM -0700, Jan Beulich wrote:
> > >>> On 10.02.17 at 13:33, wrote:
> > > --- a/xen/include/asm-x86/page.h
> > > +++ b/xen/include/asm-x86/page.h
> > > @@ -374,6 +374,18 @@
>>> On 13.02.17 at 14:03, wrote:
> hvm_grant_table_op() and hvm_grant_table_op_compat32() are almost identical,
> but there is no need to have two functions instantiated at the end of
> different function pointers.
>
> Combine the two into a single hvm_grant_table_op()
>>> On 13.02.17 at 14:03, wrote:
> --- a/xen/arch/x86/hvm/hypercall.c
> +++ b/xen/arch/x86/hvm/hypercall.c
> @@ -23,6 +23,29 @@
>
> #include
>
> +static long hvm_memory_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
> +{
> +struct vcpu *curr = current;
const?
>>> On 14.02.17 at 11:33, wrote:
> On 14/02/17 10:33, Jan Beulich wrote:
> On 13.02.17 at 14:03, wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/x86/hvm/hypercall.c
>>> @@ -0,0 +1,332 @@
>>>
>
flight 68556 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68556/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-i386-daily-netboot-pygrub 10 guest-start fail REGR. vs. 68530
flight 105788 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105788/
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
On Tue, Feb 14, 2017 at 12:31:00PM +, osstest service owner wrote:
> flight 105784 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/105784/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>
>>> On 14.02.17 at 13:30, wrote:
> --- a/Config.mk
> +++ b/Config.mk
> @@ -212,9 +212,6 @@ CFLAGS += -std=gnu99
>
> CFLAGS += -Wall -Wstrict-prototypes
>
> -# Clang complains about macros that expand to 'if ( ( foo == bar ) ) ...'
> -CFLAGS-$(clang) += -Wno-parentheses
On 14/02/17 12:30, Roger Pau Monne wrote:
> And fix the following errors reported:
>
> traps.c:2014:25: error: equality comparison with extraneous parentheses
> [-Werror,-Wparentheses-equality]
> else if ( (port == RTC_PORT(0)) )
>~^~
>
>>> On 14.02.17 at 13:30, wrote:
> --- a/Config.mk
> +++ b/Config.mk
> @@ -213,8 +213,7 @@ CFLAGS += -std=gnu99
> CFLAGS += -Wall -Wstrict-prototypes
>
> # Clang complains about macros that expand to 'if ( ( foo == bar ) ) ...'
> -# and is a bit too fierce about unused
On Mon, Feb 13, 2017 at 08:58:42AM +, Paul Durrant wrote:
> > -Original Message-
> > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > Sent: 10 February 2017 21:52
> > To: Paul Durrant ; xen-de...@lists.xenproject.org
> > Subject: [PATCH v1] Make
flight 105786 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105786/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15
guest-localmigrate/x10 fail REGR. vs.
On Mon, Feb 13, 2017 at 02:32:13PM +0800, Yi Sun wrote:
> This patch creates CAT and CDP feature document in doc/features/. It describes
> key points to implement L3 CAT/CDP and L2 CAT which is described in details in
> Intel SDM "INTEL® RESOURCE DIRECTOR TECHNOLOGY (INTEL® RDT) ALLOCATION
>
On 14/02/17 10:29, Jan Beulich wrote:
> They're all solely dependent on guest type, so we don't need to repeat
> all the same four pointers in every vCPU control structure. Instead use
> static const structures, and store pointers to them in the domain
> control structure.
>
> Since touching it
> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: 14 February 2017 15:16
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org
> Subject: Re: [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)
>
> On Mon, Feb
Hi Andrew,
On 02/07/2017 06:57 PM, Andrew Cooper wrote:
The predicate is common between x86 and ARM, and is unlikley to be different/
NIT: s/unlikley/unlikely/
on other architectures. Drop the arch declarations and introduce a common
static inline in xen/mm.h instead.
Signed-off-by:
Hi,
Ping? As Ian mentioned earlier, without this series it is not possible
to build Xen tools for ARM64 in osstest.
Cheers,
On 02/08/2017 07:50 PM, Julien Grall wrote:
Hi,
On 24/01/17 22:19, David Scott wrote:
On 24 Jan 2017, at 11:35, Ian Jackson wrote:
Ian
On Tue, Feb 14, 2017 at 12:30:55PM +, Roger Pau Monne wrote:
> The following incorrect format specifiers and incorrect number of parameters
> passed to printf like functions are reported by clang:
>
> mce.c:601:18: error: data argument not used by format string
>
On 02/13/2017 12:03 PM, Paul Durrant wrote:
> Recently a new dm_op[1] hypercall was added to Xen to provide a mechanism
> for restricting device emulators (such as QEMU) to a limited set of
> hypervisor operations, and being able to audit those operations in the
> kernel of the domain in which
Hi Tamas,
On 13/02/17 16:20, Tamas K Lengyel wrote:
On Fri, Feb 10, 2017 at 5:14 PM, Volodymyr Babchuk
wrote:
Hello,
This e-mail is sort of follow-up to the two threads: [1] (my thread
about TEE interaction) and [2] (Edgar's thread regarding handling SMC
calls in
On Tue, Feb 14, 2017 at 09:46:17AM -0500, Waiman Long wrote:
> On 02/14/2017 04:39 AM, Peter Zijlstra wrote:
> > On Mon, Feb 13, 2017 at 05:34:01PM -0500, Waiman Long wrote:
> >> It is the address of _time that will exceed the 32-bit limit.
> > That seems extremely unlikely. That would mean we
Hi,
At 06:19 -0700 on 13 Feb (1486966797), Jan Beulich wrote:
> The present way of setting this up is flawed: Leaving the I/O bitmap
> pointer at zero means that the interrupt redirection bitmap lives
> outside (ahead of) the allocated space of the TSS. Similarly setting a
> TSS limit of 255 when
On Mon, Feb 13, 2017 at 08:46:29AM +, Paul Durrant wrote:
> > -Original Message-
> > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > Sent: 10 February 2017 21:52
> > To: Paul Durrant ; xen-de...@lists.xenproject.org
> > Cc: Konrad Rzeszutek Wilk
> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: 14 February 2017 15:32
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org
> Subject: Re: [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)
>
> On Tue, Feb
On Mon, Feb 13, 2017 at 02:32:16PM +0800, Yi Sun wrote:
> This patch implements the CPU init and free flow including L3 CAT
> initialization and feature list free.
>
> Signed-off-by: Yi Sun
> ---
> v7:
> - initialize 'l3_cat'.
> - fix typo.
> - correct
> -Original Message-
[snip]
> > Thank you. Keep in mind that it will likely break against
> > older Xen versions (Xen 4.4?) as there is no xenctrl_compat.h
>
> I'm not sure you actually need to include that directly. I was going to try
> just
> adding the 'want compat' defines and seeing
Fixes c33b5f013d ("Add XENV to docs/misc")
Signed-off-by: Olaf Hering
---
docs/misc/xen-env-table-spec.fodt | 852 ++
1 file changed, 852 insertions(+)
diff --git a/docs/misc/xen-env-table-spec.fodt
b/docs/misc/xen-env-table-spec.fodt
new
Fixes 140b31a8de ("Add STAO spec to docs/misc")
Signed-off-by: Olaf Hering
---
docs/misc/status-override-table-spec.fodt | 707 ++
1 file changed, 707 insertions(+)
diff --git a/docs/misc/status-override-table-spec.fodt
Signed-off-by: Olaf Hering
---
docs/misc/xen-env-table-spec.odt | Bin 19204 -> 0 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
diff --git a/docs/misc/xen-env-table-spec.odt b/docs/misc/xen-env-table-spec.odt
deleted file mode 100644
index
These two patches don't apply anymore. Please rebase.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Tue, Feb 14, 2017 at 03:26:34PM +, Paul Durrant wrote:
> > -Original Message-
> > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > Sent: 14 February 2017 15:16
> > To: Paul Durrant
> > Cc: xen-de...@lists.xenproject.org
> > Subject: Re:
On Tue, Feb 14, 2017 at 03:39:00PM +, Paul Durrant wrote:
> > -Original Message-
> > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > Sent: 14 February 2017 15:32
> > To: Paul Durrant
> > Cc: xen-de...@lists.xenproject.org
> > Subject: Re:
Signed-off-by: Olaf Hering
---
docs/misc/status-override-table-spec.odt | Bin 20206 -> 0 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
diff --git a/docs/misc/status-override-table-spec.odt
b/docs/misc/status-override-table-spec.odt
deleted file mode 100644
index
The odt files should have been saved as Flat XML via 'Save as ...'.
git send-email warns about lines longer than 998 chars. Hopefully all
involved mail services have no silly limits.
Olaf
Olaf Hering (4):
docs: convert STAO from odt to fodt
docs: convert XENV from odt to fodt
docs: remove
On 13/02/17 16:59, Tamas K Lengyel wrote:
On Mon, Feb 13, 2017 at 9:37 AM, Julien Grall wrote:
Hi Tamas,
On 13/02/17 16:20, Tamas K Lengyel wrote:
On Fri, Feb 10, 2017 at 5:14 PM, Volodymyr Babchuk
wrote:
Hello,
This e-mail is sort of
Hi Stefano,
On 02/13/2017 07:59 PM, Stefano Stabellini wrote:
> On Mon, 13 Feb 2017, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 10/02/17 01:01, Stefano Stabellini wrote:
>>> On Fri, 3 Feb 2017, Edgar E. Iglesias wrote:
A possible hack could be to allocate a chunk of DDR dedicated for PCI
1 - 100 of 170 matches
Mail list logo