flight 44396 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44396/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-armhf-pvops 3 host-install(3) broken like 44379
build-armhf
On 08/05/2016 23:51, Kevin Moraga wrote:
> Hi,
> I don't know if this is the exact same issue... but is the most related
> one that I found.
>
> I'm try to compile kernel 4.4.8 (using fedora 23) to run with Xen 4.6.0
> and Intel Skylake processor (Intel Core i7-6600U)
>
> This kernel is crashing al
>
> You should put in some extra gdprintk's into the altp2m path of Xen to see
> how far it gets when you try to enable VE. That would enable us to pinpoint
> where it gets stuck exactly.
>
> Tamas
>
I've added gdprintk into HVMOP_altp2m_vcpu_enable_notify section of
do_altp2m_op function, but no o
flight 93877 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93877/
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. 65543
test-amd64-amd64-xl-qemuu-ov
On May 06, 2016 10:24 PM, Jan Beulich wrote:
> On x86, iommu_get_ops() BUG()s when running on non-Intel, non-AMD
> hardware. While, with our current code, that's a correct prerequisite
> assumption for IOMMU presence, this is wrong on systems without IOMMU.
> Hence iommu_enabled (and alike) checks
On 08/05/16 05:12, Meng Xu wrote:
> On Sat, May 7, 2016 at 5:19 PM, Meng Xu wrote:
>> On Tue, May 3, 2016 at 5:46 PM, Dario Faggioli
>> wrote:
>>>
>>> The scheduling hooks API is now used properly, and no
>>> initialization or de-initialization happen in
>>> alloc/free_pdata any longer.
>>>
>>> I
On Wed, 2016-04-27 at 15:29 +0100, Wei Liu wrote:
> On Wed, Apr 20, 2016 at 10:04:03AM +0200, Paulina Szubarczyk wrote:
> > libxl_set_memory_target seems to have the following return values:
> >
> > * 1 on failure, if the failure happens because of a xenstore error *or*
> > * invalid target
> >
>
>>> On 09.05.16 at 09:55, wrote:
> On May 06, 2016 10:24 PM, Jan Beulich wrote:
>> On x86, iommu_get_ops() BUG()s when running on non-Intel, non-AMD
>> hardware. While, with our current code, that's a correct prerequisite
>> assumption for IOMMU presence, this is wrong on systems without IOMMU.
>
On May 09, 2016 4:24 PM, Jan Beulich wrote:
> >>> On 09.05.16 at 09:55, wrote:
> > On May 06, 2016 10:24 PM, Jan Beulich wrote:
> >> On x86, iommu_get_ops() BUG()s when running on non-Intel, non-AMD
> >> hardware. While, with our current code, that's a correct prerequisite
> >> assumption for IO
Domain-0 is always member of Pool-0 (or, to be precise: of the cpuppol
with cpupool-id 0). Document this in the xl man page.
Signed-off-by: Juergen Gross
---
docs/man/xl.pod.1 | 1 +
1 file changed, 1 insertion(+)
diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index e2bd32d..9887f1b 100644
Hello,
I'm trying to build simple bare metal application on ARM Cortex A7.
I reached the phase in which I successfully created domain. Now,
I would like to check if application is really running (it runs according
xl list). But i need some simple interaction or at least console output.
So far thi
On 09/05/2016 09:29, Juergen Gross wrote:
> Domain-0 is always member of Pool-0 (or, to be precise: of the cpuppol
> with cpupool-id 0). Document this in the xl man page.
>
> Signed-off-by: Juergen Gross
Out of interest, why?
Is this a limitation of the current implementation, or something which
On 09/05/16 10:36, Andrew Cooper wrote:
> On 09/05/2016 09:29, Juergen Gross wrote:
>> Domain-0 is always member of Pool-0 (or, to be precise: of the cpuppol
>> with cpupool-id 0). Document this in the xl man page.
>>
>> Signed-off-by: Juergen Gross
>
> Out of interest, why?
>
> Is this a limita
flight 93873 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93873/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 4 host-build-prep fail REGR. vs. 93813
Regressions which ar
> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: 07 May 2016 20:09
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; net...@vger.kernel.org; Wei Liu
> Subject: Re: [PATCH net-next 2/4] xen-netback: add control protocol
> implementation
>
> From: Paul Du
flight 93880 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93880/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-xsm 14 guest-saverestore fail REGR. vs. 91479
test-amd64-i386-libvirt
On Mon, May 09, 2016 at 03:37:25PM +0800, Big Strong wrote:
> >
> > You should put in some extra gdprintk's into the altp2m path of Xen to see
> > how far it gets when you try to enable VE. That would enable us to pinpoint
> > where it gets stuck exactly.
> >
> > Tamas
> >
> I've added gdprintk int
On 09/05/2016 09:34, Ivan Pavić2 wrote:
Hello,
Hello Ivan,
I'm trying to build simple bare metal application on ARM Cortex A7.
I reached the phase in which I successfully created domain. Now,
I would like to check if application is really running (it runs according
xl list). But i need some
>>> On 06.05.16 at 16:26, wrote:
> On Fri, Apr 29, 2016 at 03:35:51AM -0600, Jan Beulich wrote:
>> As discussed on the hackathon, avoid us having to issue security
>> advisories for issues affecting only heavily disaggregated tool stack
>> setups, which no-one appears to use (or else they should s
On Thu, 5 May 2016, Julien Grall wrote:
> The header asm-arm/page.h makes use of the macro dsb defined in the header
> asm-arm/system.h. Currently, the includer has to specify both of them.
>
> This can be avoided by including asm-arm/system.h in asm-arm/page.h.
>
> Signed-off-by: Julien Grall
On Thu, 5 May 2016, Julien Grall wrote:
> Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
> xen/arch/arm/Makefile | 38 --
> xen/arch/arm/arm32/Makefile | 9 -
> xen/arch/arm/arm64/Makefile | 12 +---
> xen/arch/a
On Thu, 5 May 2016, Julien Grall wrote:
> Add new macros to easily get different parts of the register and to
> check if a given MIDR match a CPU model range. The latter will be really
> useful to handle errata later.
>
> The macros have been imported from the header arch64/include/asm/cputype.h
On 05/05/2016 17:34, Julien Grall wrote:
Flushing the icache will required when the support Xen patching will be
added.
Also import the macro icache_line_size which is used by
flush_icache_range.
Signed-off-by: Julien Grall
Hmmm, I forgot to drop this patch from the series. Please ignore i
On Mon, May 9, 2016 at 9:21 AM, Paulina Szubarczyk
wrote:
> On Wed, 2016-04-27 at 15:29 +0100, Wei Liu wrote:
>> On Wed, Apr 20, 2016 at 10:04:03AM +0200, Paulina Szubarczyk wrote:
>> > libxl_set_memory_target seems to have the following return values:
>> >
>> > * 1 on failure, if the failure happ
On 08/05/2016 12:59, Peng Fan wrote:
Hi Julien,
Hello Peng,
On Thu, Apr 28, 2016 at 10:50:33AM +0100, Julien Grall wrote:
Hello,
On 27/04/16 23:53, Suriyan Ramasami wrote:
How can I check which core is currently active?
Judging by this link on big.LITTLE architecture:
On Thu, 5 May 2016, Julien Grall wrote:
> Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
> xen/include/asm-arm/arm64/page.h | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/xen/include/asm-arm/arm64/page.h
> b/xen/include/asm-arm/arm64/page.h
> index 29a32cf..fbdc8fb
On Thu, 5 May 2016, Julien Grall wrote:
> This will be used to know if a feature, which Xen cares, is available accross
> all the CPUs.
>
> This code is a light version of arch/arm64/kernel/cpufeature.c from
> Linux v4.6-rc3.
>
> Signed-off-by: Julien Grall
> ---
> xen/arch/arm/Makefile
On Thu, 5 May 2016, Julien Grall wrote:
> New immediates will be defined in the future. To keep track of the
> immediates allocated, gather all of them in a separate header.
>
> Also rename BRK_BUG_FRAME to BKR_BUG_FRAME_IMM.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
>
Right now there's only tool stack related documentation there.
Signed-off-by: Jan Beulich
--- unstable.orig/MAINTAINERS
+++ unstable/MAINTAINERS
@@ -353,6 +353,7 @@ F: install.sh
F: m4/
F: configure
F: docs/Makefile
+F: docs/man/
F: stubdom/Makefile
F: *.ac
F:
On Thu, 5 May 2016, Julien Grall wrote:
> It may not possible to return a proper error when encoding an
> instruction. Instead, a handcrafted instruction will be returned.
>
> Also, provide the encoding for the faulting instruction.
>
> Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
On Mon, May 9, 2016 at 10:57 AM, Jan Beulich wrote:
> Right now there's only tool stack related documentation there.
>
> Signed-off-by: Jan Beulich
Acked-by: George Dunlap
But I guess it really wants a tools maintainer's Ack.
-George
___
Xen-devel
Hi Stefano,
On 09/05/2016 10:53, Stefano Stabellini wrote:
On Thu, 5 May 2016, Julien Grall wrote:
diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
index 7b519cd..2bebad1 100644
--- a/xen/include/asm-arm/cpufeature.h
+++ b/xen/include/asm-arm/cpufeature.h
@@ -35,
>>> On 09.05.16 at 09:23, wrote:
> On 08/05/2016 23:51, Kevin Moraga wrote:
>> Hi,
>> I don't know if this is the exact same issue... but is the most related
>> one that I found.
>>
>> I'm try to compile kernel 4.4.8 (using fedora 23) to run with Xen 4.6.0
>> and Intel Skylake processor (Intel Cor
On Thu, 5 May 2016, Julien Grall wrote:
> We may need to update branch instruction when patching Xen.
>
> The code has been imported from the files arch/arm64/kernel/insn.c
> and arch/arm64/include/asm/insn.h in Linux v4.6-rc3.
>
> Note that only the necessary helpers have been imported.
>
> Sig
>>> On 09.05.16 at 00:51, wrote:
> I'm try to compile kernel 4.4.8 (using fedora 23) to run with Xen 4.6.0
> and Intel Skylake processor (Intel Core i7-6600U)
>
> This kernel is crashing almost in the same way as explained in this
> thread... But my problem is mainly with Skylake. Because the sam
>>> On 02.05.16 at 17:11, wrote:
> Don't use more or report more to guests than we are capable of
> handling.
>
> At once simplify the code in hvm_cpuid() and mtrr_top_of_ram().
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -46,6 +46,
flight 93893 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93893/
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. 65543
test-amd64-amd64-xl-qemuu-ov
Julien Grail wrote:
> You can dump the registers of a vCPU with xenctx.
> $PREFIX/lib/xen/bin/xenctx domid
> $PREFIX is the path where xen tools have been installed (i.e --prefix on
> the configure). The default path is /usr/local/
Thanks for advice. I discovered that the PC has value 0x0C and
On 07/05/16 09:17, Heinrich Schuchardt wrote:
> Commit a4cdb556cae0 ("xen/gntdev: add ioctl for grant copy")
> leads to a warning
> xen/gntdev.c: In function ‘gntdev_ioctl_grant_copy’:
> xen/gntdev.c:949:1: warning: the frame size of 1248 bytes
> is larger than 1024 bytes [-Wframe-larger-than=]
>
On Mon, May 09, 2016 at 03:57:33AM -0600, Jan Beulich wrote:
> Right now there's only tool stack related documentation there.
>
> Signed-off-by: Jan Beulich
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen
On Mon, May 09, 2016 at 03:31:52AM -0600, Jan Beulich wrote:
> >>> On 06.05.16 at 16:26, wrote:
> > On Fri, Apr 29, 2016 at 03:35:51AM -0600, Jan Beulich wrote:
> >> As discussed on the hackathon, avoid us having to issue security
> >> advisories for issues affecting only heavily disaggregated too
On Mon, May 09, 2016 at 10:53:30AM +0200, Juergen Gross wrote:
> On 09/05/16 10:36, Andrew Cooper wrote:
> > On 09/05/2016 09:29, Juergen Gross wrote:
> >> Domain-0 is always member of Pool-0 (or, to be precise: of the cpuppol
> >> with cpupool-id 0). Document this in the xl man page.
> >>
> >> Sig
On Mon, May 09, 2016 at 10:21:09AM +0200, Paulina Szubarczyk wrote:
> On Wed, 2016-04-27 at 15:29 +0100, Wei Liu wrote:
> > On Wed, Apr 20, 2016 at 10:04:03AM +0200, Paulina Szubarczyk wrote:
> > > libxl_set_memory_target seems to have the following return values:
> > >
> > > * 1 on failure, if th
>>> On 09.05.16 at 12:56, wrote:
> On Mon, May 09, 2016 at 03:31:52AM -0600, Jan Beulich wrote:
>> But note that by not having it on the list for now, things don't
>> change: As per the original XSA-77, the operation was deemed
>> disaggregation unsafe (and hence by implication its use in stub
>>
On Mon, May 09, 2016 at 05:18:33AM -0600, Jan Beulich wrote:
> >>> On 09.05.16 at 12:56, wrote:
> > On Mon, May 09, 2016 at 03:31:52AM -0600, Jan Beulich wrote:
> >> But note that by not having it on the list for now, things don't
> >> change: As per the original XSA-77, the operation was deemed
>
Various coding style compliance cleanups, such as, arranging for
using only one path out of the function, whitespaces in loops ad if-s
and r instead of rc for storing non-libxl error codes.
Signed-off-by: Paulina Szubarczyk
---
Changes since v3:
- When the opendir() returns NULL stored in 'dir'
*libxl__device_from_pcidev(), pcidev_struct_fill() initialize
the values of libxl_device and libxl_device_pci structs
and can be void.
*libxl__create_pci_backend(), libxl__device_pci_destroy_all()
should propagate the success/error, rather than always returning 0.
Signed-off-by: Paulina Szubar
Returning error codes makes it easier for shell scripts to tell if a
command has failed or succeeded.
Signed-off-by: George Dunlap
Signed-off-by: Paulina Szubarczyk
Acked-by: Wei Liu
---
tools/libxl/xl_cmdimpl.c | 68 ++--
1 file changed, 49 insertio
Functions libxl_tmem_freeze(), libxl_tmem_thaw(), libxl_tmem_set() and
libxl_tmem_shared_auth() located in libxl.c file return
ERROR_FAIL/ERROR_INVAL or internal error codes from libxc library
improve main_tmem_* return codes by returning EXIT_{SUCCESS/FAILURE}
accordingly to return codes of those
This is my bite-sized outreachy project [1][2].
The patch aims to improve coding_style and return failure for more xl commands:
- pci-*
-- tmem-*
After rebase to staging it seems that the patch {09} cleaning
libxl_set_memory_target()
to return useful error codes from [0] is not applied I resen
- Use EXIT_{SUCCESS,FAILURE} for main_cd*() function
- Use 0/1 as return values of cd_insert function
Signed-off-by: Paulina Szubarczyk
Reviewed-by: Olaf Hering
Acked-by: Roger Pau Monné
---
tools/libxl/xl_cmdimpl.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
dif
From: George Dunlap
libxl_set_memory_target seems to have the following return values:
'1' : on failure, if the failure happens because of a xenstore error
*or* invalid target
'-1': on error, the setmaxmem and set_pod_target hypercalls
return -1 and set errno appropriately.
'0'
In accordance with CODING_SYTLE:
- Use 'r' for return values to functions whose return values are a
different error space (like xc_tmem_control, xc_tmem_auth)
libxc functions are supposed to, on failure, set errno and always
return -1 which is the value stored in 'r', therfore use LOGE()
inst
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2016-3710,CVE-2016-3712 / XSA-179
version 4
QEMU: Banked access to VGA memory (VBE) uses inconsistent bounds checks
UPDATES IN VERSION 4
Public release. Also includ
On 02/05/16 16:11, Jan Beulich wrote:
> --- a/xen/arch/x86/e820.c
> +++ b/xen/arch/x86/e820.c
> @@ -451,11 +451,11 @@ static uint64_t __init mtrr_top_of_ram(v
> return 0;
>
> /* Find the physical address size for this CPU. */
> -cpuid(0x8000, &eax, &ebx, &ecx, &edx);
> -
>>> On 09.05.16 at 14:35, wrote:
> On 02/05/16 16:11, Jan Beulich wrote:
>> --- a/xen/arch/x86/e820.c
>> +++ b/xen/arch/x86/e820.c
>> @@ -451,11 +451,11 @@ static uint64_t __init mtrr_top_of_ram(v
>> return 0;
>>
>> /* Find the physical address size for this CPU. */
>> -cpuid(
On Fri, May 06, 2016 at 04:48:01PM +0100, Ross Lagerwall wrote:
> Here is a set of changes to make building xSplice patches easier.
> Tested to boot on x86.
> Compile-tested on arm.
>
> This is probably too late to make it into 4.7, but hey, if someone wants
> to put it in I've CC'd Wei.
>
Unfor
On 28/04/2016 13:25, Paul Durrant wrote:
>> Maybe you are lucky, qemu is registered before your own demu
>> emulator.
>
> I guess I was lucky.
Yeah, QEMU has been doing that since 2013 (commit 3bb28b7, "memory:
Provide separate handling of unassigned io ports accesses", 2013-09-05).
>> I used
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: 09 May 2016 13:56
> To: Paul Durrant; Martin Cerveny
> Cc: George Dunlap; xen-de...@lists.xensource.com
> Subject: Re: [Xen-devel] Overlaped PIO with multiple ioreq_server
> (Xen4.6.1)
>
>
>
> On 28/04/2016 1
On Mon, May 09, 2016 at 01:30:54PM +0200, Paulina Szubarczyk wrote:
> - Use EXIT_{SUCCESS,FAILURE} for main_cd*() function
> - Use 0/1 as return values of cd_insert function
>
> Signed-off-by: Paulina Szubarczyk
> Reviewed-by: Olaf Hering
> Acked-by: Roger Pau Monné
Acked-by: Wei Liu
_
On Mon, May 09, 2016 at 01:30:56PM +0200, Paulina Szubarczyk wrote:
> *libxl__device_from_pcidev(), pcidev_struct_fill() initialize
> the values of libxl_device and libxl_device_pci structs
> and can be void.
>
> *libxl__create_pci_backend(), libxl__device_pci_destroy_all()
> should propagate t
On Mon, May 09, 2016 at 01:30:55PM +0200, Paulina Szubarczyk wrote:
> From: George Dunlap
>
> libxl_set_memory_target seems to have the following return values:
>
> '1' : on failure, if the failure happens because of a xenstore error
>*or* invalid target
> '-1': on error, the setmaxmem
On Mon, May 09, 2016 at 01:30:58PM +0200, Paulina Szubarczyk wrote:
> In accordance with CODING_SYTLE:
> - Use 'r' for return values to functions whose return values are a
>different error space (like xc_tmem_control, xc_tmem_auth)
>
> libxc functions are supposed to, on failure, set errno an
On Mon, May 09, 2016 at 01:30:57PM +0200, Paulina Szubarczyk wrote:
> Various coding style compliance cleanups, such as, arranging for
> using only one path out of the function, whitespaces in loops ad if-s
> and r instead of rc for storing non-libxl error codes.
>
> Signed-off-by: Paulina Szubarc
Hi Stefano,
On 09/05/16 11:05, Stefano Stabellini wrote:
On Thu, 5 May 2016, Julien Grall wrote:
+u32 aarch64_insn_encode_immediate(enum aarch64_insn_imm_type type,
+ u32 insn, u64 imm)
+{
+ u32 immlo, immhi, mask;
+ int shift;
Here Linux checks for
Hi Paulina
I believe this series is now all acked.
We're however in code freeze at the moment -- only critical bug fixes
and patches very of very low risk can be committed. I will apply this
series when the tree reopens.
I have a small suggestion for you. You seemed to have shuffled the order
of
flight 93908 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93908/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-build fail REGR. vs. 93623
Tests which di
Turns out there are a lot of broken corner cases.
Andrew Cooper (4):
x86/hvm: Always return the linear address from
hvm_virtual_to_linear_addr()
x86/hvm: Raise #SS faults for %ss-based segmentation violations
x86/hvm: Correct the emulated interaction of invlpg with segments
x86/hvm: Fi
hap_invlpg() is reachable from the instruction emulator, which means
introspection and tests using hvm_fep can end up here. As such, crashing the
domain is not an appropriate action to take.
Fixing this involves rearranging the callgraph.
paging_invlpg() is now the central entry point. It first
Some callers need the linear address (with appropriate segment base), whether
or not the limit or canonical check succeeds.
While modifying the function, change the return type to bool_t to match its
semantics.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
---
xen/arch/x86/hvm/
Raising #GP under such circumstances is architecturally wrong.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
CC: Paul Durrant
CC: Wei Liu
---
xen/arch/x86/hvm/emulate.c | 3 ++-
xen/arch/x86/mm/shadow/common.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
The `invlpg` instruction is documented to take a memory address, and is not
documented to suffer faults from segmentation violations.
Experimentally, and subsequently confirmed by both Intel and AMD, the
instruction does take into account segment bases, but will happily invalidate
a TLB entry for
Don't use more or report more to guests than we are capable of
handling.
At once
- correct the involved extended CPUID level checks,
- simplify the code in hvm_cpuid() and mtrr_top_of_ram().
Signed-off-by: Jan Beulich
---
v2: Also correct extended CPUID level range checks.
--- a/xen/arch/x86/cp
We should consistently check the upper 16 bits to be equal 0x8000 and
only then the full value to be >= the desired level.
Signed-off-by: Jan Beulich
---
As to inclusion in 4.7 - I think this would be desirable, but it's not
a must: I'm unaware of real world environments where
CPUID[0x8000].E
On 09/05/16 14:15, Jan Beulich wrote:
> Don't use more or report more to guests than we are capable of
> handling.
>
> At once
> - correct the involved extended CPUID level checks,
> - simplify the code in hvm_cpuid() and mtrr_top_of_ram().
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Coope
On Sat, 2016-05-07 at 23:19 +0200, Meng Xu wrote:
> On Tue, May 3, 2016 at 5:46 PM, Dario Faggioli
> wrote:
> >
> >
> > The scheduling hooks API is now used properly, and no
> > initialization or de-initialization happen in
> > alloc/free_pdata any longer.
> >
> > In fact, just like it is for C
On 09/05/16 14:19, Jan Beulich wrote:
> We should consistently check the upper 16 bits to be equal 0x8000 and
> only then the full value to be >= the desired level.
>
> Signed-off-by: Jan Beulich
> ---
> As to inclusion in 4.7 - I think this would be desirable, but it's not
> a must: I'm unaware o
On Mon, 2016-05-09 at 14:06 +0100, Wei Liu wrote:
> Hi Paulina
>
> I believe this series is now all acked.
>
> We're however in code freeze at the moment -- only critical bug fixes
> and patches very of very low risk can be committed. I will apply this
> series when the tree reopens.
Hi Wei,
T
>>> On 09.05.16 at 15:21, wrote:
> On 09/05/16 14:15, Jan Beulich wrote:
>> Don't use more or report more to guests than we are capable of
>> handling.
>>
>> At once
>> - correct the involved extended CPUID level checks,
>> - simplify the code in hvm_cpuid() and mtrr_top_of_ram().
>>
>> Signed-off
On 09/05/16 14:26, Jan Beulich wrote:
On 09.05.16 at 15:21, wrote:
>> On 09/05/16 14:15, Jan Beulich wrote:
>>> Don't use more or report more to guests than we are capable of
>>> handling.
>>>
>>> At once
>>> - correct the involved extended CPUID level checks,
>>> - simplify the code in hvm_c
Fix a declared-but-not-defined warning when building with
XEN_BALLOON_MEMORY_HOTPLUG=n. This fixes a regression introduced by
commit dfd74a1edfab
("xen/balloon: Fix crash when ballooning on x86 32 bit PAE").
Signed-off-by: Ross Lagerwall
---
drivers/xen/balloon.c | 4 ++--
1 file changed, 2 inse
On Mon, May 09, 2016 at 03:25:18PM +0200, Paulina Szubarczyk wrote:
> On Mon, 2016-05-09 at 14:06 +0100, Wei Liu wrote:
> > Hi Paulina
> >
> > I believe this series is now all acked.
> >
> > We're however in code freeze at the moment -- only critical bug fixes
> > and patches very of very low ris
On Mon, May 09, 2016 at 07:15:47AM -0600, Jan Beulich wrote:
> Don't use more or report more to guests than we are capable of
> handling.
>
> At once
> - correct the involved extended CPUID level checks,
> - simplify the code in hvm_cpuid() and mtrr_top_of_ram().
>
> Signed-off-by: Jan Beulich
On Mon, May 09, 2016 at 07:19:56AM -0600, Jan Beulich wrote:
> We should consistently check the upper 16 bits to be equal 0x8000 and
> only then the full value to be >= the desired level.
>
> Signed-off-by: Jan Beulich
> ---
> As to inclusion in 4.7 - I think this would be desirable, but it's not
>>> On 09.05.16 at 15:15, wrote:
> Some callers need the linear address (with appropriate segment base), whether
> or not the limit or canonical check succeeds.
>
> While modifying the function, change the return type to bool_t to match its
> semantics.
>
> Signed-off-by: Andrew Cooper
Reviewe
On 09/05/16 15:29, Ross Lagerwall wrote:
> Fix a declared-but-not-defined warning when building with
> XEN_BALLOON_MEMORY_HOTPLUG=n. This fixes a regression introduced by
> commit dfd74a1edfab
> ("xen/balloon: Fix crash when ballooning on x86 32 bit PAE").
>
> Signed-off-by: Ross Lagerwall
> ---
>>> On 09.05.16 at 15:15, wrote:
> Raising #GP under such circumstances is architecturally wrong.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
CC George as well
On Mon, May 09, 2016 at 02:15:40PM +0100, Andrew Cooper wrote:
> Raising #GP under such circumstances is architecturally wrong.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Tim Deegan
> CC: Paul Durrant
> CC: Wei Liu
> ---
> xen/arch/x86/hvm/emulate.c
On 09/05/16 14:15, Andrew Cooper wrote:
> Raising #GP under such circumstances is architecturally wrong.
You should include a reference to the relevant Intel and AMD manuals here.
David
> ---
> CC: Jan Beulich
> CC: Tim Deegan
> CC: Paul Durrant
> CC: Wei Liu
> ---
> xen/arch/x86/hvm/emulat
>>> On 09.05.16 at 15:15, wrote:
> The `invlpg` instruction is documented to take a memory address, and is not
> documented to suffer faults from segmentation violations.
>
> Experimentally, and subsequently confirmed by both Intel and AMD, the
> instruction does take into account segment bases,
On 09/05/16 14:42, Jan Beulich wrote:
On 09.05.16 at 15:15, wrote:
>> The `invlpg` instruction is documented to take a memory address, and is not
>> documented to suffer faults from segmentation violations.
>>
>> Experimentally, and subsequently confirmed by both Intel and AMD, the
>> instruc
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 09 May 2016 14:16
> To: Xen-devel
> Cc: Andrew Cooper; Jan Beulich; Paul Durrant; Wei Liu
> Subject: [PATCH for-4.7 3/4] x86/hvm: Correct the emulated interaction of
> invlpg with segments
>
> The `invlpg
>>> On 09.05.16 at 15:15, wrote:
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -,10 +,13 @@ static void svm_invlpga_intercept(
>
> static void svm_invlpg_intercept(unsigned long vaddr)
> {
> -struct vcpu *curr = current;
> HVMTRACE_LONG_2D(INVLPG,
On Thu, Apr 28, 2016 at 03:20:46PM -0600, Jim Fehlig wrote:
> qemu commit 91a097e7 forbids specifying cache mode for empty
> drives. Attempting to create a domain with an empty qdisk cdrom
> drive results in
>
> qemu-system-x86_64: -drive if=ide,index=1,readonly=on,media=cdrom,
>cache=writebac
On 09/05/16 14:57, Jan Beulich wrote:
On 09.05.16 at 15:15, wrote:
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -,10 +,13 @@ static void svm_invlpga_intercept(
>>
>> static void svm_invlpg_intercept(unsigned long vaddr)
>> {
>> -struct vcpu *cu
>
>
>
> > I do have a minor comment about the patch, although it is not
> > important at all and it is not really about this patch...
> >
> > >
> > > @@ -614,7 +612,8 @@ rt_deinit(struct scheduler *ops)
> > > {
> > > struct rt_private *prv = rt_priv(ops);
> > >
> > > -kill_timer(prv->repl
On 29/04/16 10:35, Jan Beulich wrote:
> As discussed on the hackathon, avoid us having to issue security
> advisories for issues affecting only heavily disaggregated tool stack
> setups, which no-one appears to use (or else they should step up to get
> things into shape).
>
> Signed-off-by: Jan Beu
On Fri, May 6, 2016 at 2:21 PM, Dario Faggioli
wrote:
> On Wed, 2016-05-04 at 18:34 +0100, George Dunlap wrote:
>> On 04/05/16 18:21, Dario Faggioli wrote:
>> >
>> > After all, I'm fine with an ASSERT() too, but then I think we
>> > should
>> > add one to the same effect to csched_switch_sched() t
On 21/04/16 15:27, Pali Rohár wrote:
> On Thursday 21 April 2016 15:12:52 Juergen Gross wrote:
>> On 21/04/16 12:57, Pali Rohár wrote:
>>> On Tuesday 05 April 2016 21:31:52 Pali Rohár wrote:
On Tuesday 05 April 2016 16:54:14 Guenter Roeck wrote:
> On Tue, Apr 05, 2016 at 07:10:07AM +0200,
On Sat, May 7, 2016 at 10:19 PM, Meng Xu wrote:
> On Tue, May 3, 2016 at 5:46 PM, Dario Faggioli
> wrote:
>>
>> The scheduling hooks API is now used properly, and no
>> initialization or de-initialization happen in
>> alloc/free_pdata any longer.
>>
>> In fact, just like it is for Credit2, there
1 - 100 of 188 matches
Mail list logo
