> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, December 08, 2016 12:07 AM
>
> On 07/12/16 15:39, Jan Beulich wrote:
> On 07.12.16 at 16:31, wrote:
> >> On 12/07/2016 10:14 AM, Jan Beulich wrote:
> >> On 07.12.16 at 16:10, wrote:
> On 12/07/2016 06:29 AM,
flight 103008 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103008/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs.
101675
test-amd64-i38
>>> On 07.12.16 at 18:09, wrote:
> On 07/12/16 11:43, Jan Beulich wrote:
> On 07.12.16 at 02:07, wrote:
>>> On 07/12/2016 01:00, Jiandi An wrote:
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -762,6 +762,8 @@ static int xenmem_add_to_physmap_batch(struct domain
*
On Wed, Dec 07, 2016 at 02:04:27PM +0100, Cedric Bosdonnat wrote:
> On Wed, 2016-12-07 at 11:25 +, Wei Liu wrote:
> > On Mon, Nov 14, 2016 at 03:57:00PM +0100, Cédric Bosdonnat wrote:
> > > Qdisk supports qcow and qcow2, extend it to also support qed disk
> > > format.
> > >
> > > Signed-off-b
On 08/12/16 10:28, Wei Liu wrote:
> On Wed, Dec 07, 2016 at 02:04:27PM +0100, Cedric Bosdonnat wrote:
>> On Wed, 2016-12-07 at 11:25 +, Wei Liu wrote:
>>> On Mon, Nov 14, 2016 at 03:57:00PM +0100, Cédric Bosdonnat wrote:
Qdisk supports qcow and qcow2, extend it to also support qed disk
>>>
At 20:37 + on 07 Dec (1481143049), Andrew Cooper wrote:
> Given that it hasn't booted on the past two releases of Xen, and doesn't
> appear to have ever worked in one common case, does anyone have any
> objection if I remove all vestigial pieces and permanently lay the
> feature to rest in SCM
>>> On 07.12.16 at 19:29, wrote:
> ### x86
>
> There is no HMP platform of relevance, for now, in x86 world. Therefore,
> only one class will exist, and all the CPUs will be set to belong to it.
> **TODO X86:** is this correct?
What about the original Xeon Phi (on a PCIe card)?
> ## Hypervisor
On Thu, 2016-12-08 at 03:14 -0700, Jan Beulich wrote:
> > > > On 07.12.16 at 19:29, wrote:
> > ### x86
> >
> > There is no HMP platform of relevance, for now, in x86 world.
> > Therefore,
> > only one class will exist, and all the CPUs will be set to belong
> > to it.
> > **TODO X86:** is this co
On Thu, 2016-12-08 at 07:12 +0100, Juergen Gross wrote:
> On 07/12/16 19:29, Dario Faggioli wrote:
> >
> > Setting and getting the CPU class of a vCPU will happen via two new
> > hypercalls:
> >
> > * `XEN_DOMCTL_setvcpuclass`
> > * `XEN_DOMCTL_setvcpuclass`
>
> XEN_DOMCTL_getvcpuclass
>
Oops,
On 08/12/16 11:27, Dario Faggioli wrote:
> On Thu, 2016-12-08 at 07:12 +0100, Juergen Gross wrote:
>> On 07/12/16 19:29, Dario Faggioli wrote:
>>> ### Phase 2
>>>
>>> Inside Xen, the various schedulers will be modified to deal
>>> internally with
>>> the fact that vCPUs can only run on pCPUs from t
>>> On 08.12.16 at 11:23, wrote:
> On Thu, 2016-12-08 at 03:14 -0700, Jan Beulich wrote:
>> > > > On 07.12.16 at 19:29, wrote:
>> > ### x86
>> >
>> > There is no HMP platform of relevance, for now, in x86 world.
>> > Therefore,
>> > only one class will exist, and all the CPUs will be set to belo
Hi Stefano,
On 07/12/16 22:51, Stefano Stabellini wrote:
On Wed, 7 Dec 2016, Julien Grall wrote:
Hi all,
Currently, it is only possible to start AArch32 guest with GICv2. This means
that if the host interrupt controller is not compatible with GICv2, it will
not be possible to boot AArch32 gues
1: extend / amend supported FPU opcodes
2: simplify FPU source operand handling
3: simplify FPU destination operand handling
4: reduce FPU handling code size
5: avoid undefined behavior when dealing with 10-byte FPU operands
6: simplify FPU handling asm() constraints
Signed-off-by: Jan Beulich
--
First of all there are a number of secondary encodings both Intel and
AMD support, but which aren't formally documented. See e.g.
www.sandpile.org/x86/opc_fpu.htm for inofficial documentation.
Next there are a few more no-ops - instructions which served a purpose
only on 8087 or 287.
Further swit
Consistently use ea instead of src for passing the memory address to
->read(). This eliminates the need to copy ea to src, resulting in a
couple of hundred bytes smaller binary size.
In addition for opcode DE we can leverage SrcMem16 to eliminate a call
of the ->read() hook. At the same time drop
Pulling out the {get,put}_fpu() invocations from individual emulation
paths leads to a couple of kb code size reduction in my builds. Note
that this is fine exception-wise:
- #UD and #NM have implementation defined order relative to one
another,
- data read #GP/#SS/#PF now properly are delivered
Accessing an 8-byte (or perhaps just 4-byte in the test harness when
built as 32-bit app) field to read/write 10 bytes (leveraging the
successive field) is a latent bug, as the compiler could copy things
around. Use the 32 bytes large SSE/AVX slot instead.
Signed-off-by: Jan Beulich
Reviewed-by:
The memory clobber is rather harsh here. However, fic.exn_raised may be
modified as a side effect, so we need to let the compiler know that all
of "fic" may be changed (preventing it from moving around accesses to
the exn_raised field).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x
Consolidate the copying of ea to dst: There's no need to set the type
to OP_MEM, and instead the load cases setting it to OP_NONE allows the
copying to be done just once per major opcode.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
---
v2: Re-base over changes to patch 1.
--- a/xen/ar
Now that segment registers are numbered naturally this can be easily
done to achieve some code size reduction.
Also consistently use X86EMUL_OKAY in the code being touched.
Signed-off-by: Jan Beulich
---
v2: Set retire.mov_ss for "pop %ss" instead of "pop %es".
--- a/xen/arch/x86/x86_emulate/x8
On 08/12/16 11:35, Jan Beulich wrote:
> First of all there are a number of secondary encodings both Intel and
> AMD support, but which aren't formally documented. See e.g.
> www.sandpile.org/x86/opc_fpu.htm for inofficial documentation.
>
> Next there are a few more no-ops - instructions which serv
1: support 64-bit segment descriptor types
2: support LAR/LSL/VERR/VERW
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
By putting it after all instruction fetching has been done, we can both
simplify the existing handling of immediate operands and take care of
any future instructions allowing rIP-relative operands and getting
additional bytes fetched in x86_decode_*() (the current cases of extra
bytes getting fetch
flight 103009 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103009/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken
On 08/12/16 11:40, Jan Beulich wrote:
> Now that segment registers are numbered naturally this can be easily
> done to achieve some code size reduction.
>
> Also consistently use X86EMUL_OKAY in the code being touched.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
_
On 08/12/16 11:40, Jan Beulich wrote:
> By putting it after all instruction fetching has been done, we can both
> simplify the existing handling of immediate operands and take care of
> any future instructions allowing rIP-relative operands and getting
> additional bytes fetched in x86_decode_*() (
This is a prereq particularly to eventually supporting UMIP emulation,
but also for LAR/LSL/VERR/VERW.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1355,7 +1355,7 @@ protmode_load_seg(
const struct x86_emulate_ops *
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -46,7 +46,47 @@ static int read(
if ( verbose )
printf("** %s(%u, %p,, %u,)\n", __func__, seg, (void *)offset, bytes);
-bytes_read += bytes;
+
On 08/12/16 11:51, Jan Beulich wrote:
> This is a prereq particularly to eventually supporting UMIP emulation,
> but also for LAR/LSL/VERR/VERW.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.o
Since I stumbled across this while looking for further constification
opportunities, also correct the insn_fetch() related comment.
Signed-off-by: Jan Beulich
---
I would have wanted to also constify the pointers passed to .write(),
.cmpxchg(), and .rep_stos(), but that doesn't work (not only) be
Unconditionally reporting a skipped test in 64-bit builds is not very
useful, especially when quite a few more tests are about to be added.
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -613,8 +613,8 @@ int mai
They're useless and at best confusing.
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -342,7 +342,7 @@ int main(int argc, char **argv)
if ( !stack_exec )
printf("Warning: Stack could not be made ex
>>> On 06.12.16 at 15:47, wrote:
> As for UMIP itself, there are a number of issues which we should
> consider here.
>
> First, this adds quite a lot of emulation and extra handling in security
> sensitive areas. That isn't a problem per say, but given concerns with
> emulation in general (and i
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 08 December 2016 11:53
> To: xen-devel
> Cc: Andrew Cooper ; Paul Durrant
>
> Subject: [PATCH] x86emul: constify write_segment() register pointer
>
> Since I stumbled across this while looking for further constif
flight 103013 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103013/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 854c6b80dc3f1d4a151322b21c5fb6952b159ca9
baseline version:
ovmf 2c1cc12931b6c5a854712
flight 103082 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103082/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
Signed-off-by: Wei Liu
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
tools/fuzz/README | 7 +++
1 file changed, 7 insertions(+)
create mode 100644 tools/fuzz/README
diff --git a
Introduce FUZZ_NO_LIBXC in libelf-private.h. That macro will be set when
compiling libelf fuzzer target because libxc is not required in libelf
fuzzing.
Signed-off-by: Wei Liu
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabel
Hi all
This series adds two fuzzing targets to run in Google's oss-fuzz
infrastructure.
There will be some other patches on the oss-fuzz side. Their recommendation is
to have all the fuzzing targets committed in our tree so that they can be
kept up to date.
The fuzzing targets aren't very sophis
This will make all fuzzing targets get build every time tools directory
is built. This serves as basic regression test.
Signed-off-by: Wei Liu
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
Instruction emulator fuzzing code is from code previous written by
Andrew and George. Adapted to llvm fuzzer and hook up the build system.
Signed-off-by: Andrew Cooper
Signed-off-by: George Dunlap
Signed-off-by: Wei Liu
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Qdisk supports qcow and qcow2, extend it to also support qed disk
format.
Signed-off-by: Cédric Bosdonnat
---
v2:
* Add qed to the list for possible format values in xl-disk-configuration.txt
* Add LIBXL_HAVE_QED
---
docs/misc/xl-disk-configuration.txt |4 +-
tools/libxl/libxl.h
A simple program and Makefile to fuzz libelf in Google's oss-fuzz
infrastructure.
Signed-off-by: Wei Liu
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
tools/fuzz/libelf/Makefile
On 08/12/16 11:53, Jan Beulich wrote:
> Since I stumbled across this while looking for further constification
> opportunities, also correct the insn_fetch() related comment.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper , although a
suggestion about the wording.
> ---
> I would have
On 08/12/16 11:53, Jan Beulich wrote:
> Unconditionally reporting a skipped test in 64-bit builds is not very
> useful, especially when quite a few more tests are about to be added.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-dev
On 08/12/16 11:54, Jan Beulich wrote:
> They're useless and at best confusing.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
elf_uval() can return zero either because the field itself is zero, or because
the access is out of bounds.
c/s a01b6d4 "libelf: treat phdr and shdr similarly" introduced two div0 issues
as e_{ph,sh}entsize are not checked for sanity before being used to divide
elf->size.
Spotted by Coverity.
Si
flight 103011 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103011/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-winxpsp3 6 xen-boot fail REGR. vs. 101737
test-amd64-amd64-xl
flight 68176 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68176/
Perfect :-)
All tests in this flight passed as required
baseline version:
flight 68133
jobs:
build-amd64 pass
build-armh
Dario,
analyzing a stack overflow I've run into the other day I came across
credit1's __runq_tickle() not only itself having two cpumask_t
variables on the stack, but then also calling cpumask_raise_softirq()
(which uses yet one more). I then recalled you have a scratch mask
in the scheduler, and
>>> On 08.12.16 at 15:18, wrote:
> elf_uval() can return zero either because the field itself is zero, or because
> the access is out of bounds.
>
> c/s a01b6d4 "libelf: treat phdr and shdr similarly" introduced two div0 issues
> as e_{ph,sh}entsize are not checked for sanity before being used to
>>> On 08.12.16 at 14:54, wrote:
> --- a/xen/common/libelf/libelf-private.h
> +++ b/xen/common/libelf/libelf-private.h
> @@ -72,8 +72,10 @@
> #include
> #include
>
> +#ifndef FUZZ_NO_LIBXC
> #include "xenctrl.h"
> #include "xc_private.h"
> +#endif
If put in together with patch 2 (which I
>>> On 08.12.16 at 14:54, wrote:
> A simple program and Makefile to fuzz libelf in Google's oss-fuzz
> infrastructure.
Mind adding some description here on how this is expected to work /
be used? The new Makefile produce an object file and an archive,
but no binary, so it's not clear to me what u
On 08/12/16 14:41, Jan Beulich wrote:
On 08.12.16 at 15:18, wrote:
>> elf_uval() can return zero either because the field itself is zero, or
>> because
>> the access is out of bounds.
>>
>> c/s a01b6d4 "libelf: treat phdr and shdr similarly" introduced two div0
>> issues
>> as e_{ph,sh}ents
Jan Beulich writes ("Re: [PATCH] libelf: Fix div0 issues in
elf_{shdr,phdr}_count()"):
> On 08.12.16 at 15:18, wrote:
> > Spotted by Coverity.
>
> And wrongly so, imo.
...
> > @@ -148,11 +154,17 @@ unsigned elf_shdr_count(struct elf_binary *elf)
> > unsigned elf_phdr_count(struct elf_binary *el
On Thu, Dec 08, 2016 at 07:47:22AM -0700, Jan Beulich wrote:
> >>> On 08.12.16 at 14:54, wrote:
> > A simple program and Makefile to fuzz libelf in Google's oss-fuzz
> > infrastructure.
>
> Mind adding some description here on how this is expected to work /
> be used? The new Makefile produce an
On 12/02/2016 01:15 AM, Juergen Gross wrote:
Instead of requesting a new slot on the ring to the backend early, do
so only after all has been setup for the request to be sent. This
makes error handling easier as we don't need to undo the request id
allocation and ring slot allocation.
Suggeste
>>> On 08.12.16 at 14:54, wrote:
> Instruction emulator fuzzing code is from code previous written by
> Andrew and George. Adapted to llvm fuzzer and hook up the build system.
With this, how much of the new code could be shared between
Google's fuzzer and AFL, for which George had put this togeth
This email only tracks big items for xen.git tree. Please reply for items you
woulk like to see in 4.9 so that people have an idea what is going on and
prioritise accordingly.
You're welcome to provide description and use cases of the feature you're
working on.
= Timeline =
We now adopt a fixed
I'm just wondering if anybody had a chance to look at the patch...
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 08.12.16 at 15:46, wrote:
> On 08/12/16 14:41, Jan Beulich wrote:
> On 08.12.16 at 15:18, wrote:
>>> elf_uval() can return zero either because the field itself is zero, or
> because
>>> the access is out of bounds.
>>>
>>> c/s a01b6d4 "libelf: treat phdr and shdr similarly" introduced
>>> On 08.12.16 at 16:12, wrote:
> = Projects =
>
> == Hypervisor ==
>
> * Boot Xen on EFI platforms using GRUB2 (multiboot2 protocol)
> - Daniel Kiper
>
> * Per-cpu tasklet
> - Konrad Rzeszutek Wilk
>
> === x86 ===
>
> * Allow ioreq server interface to support XenGT
> - Yu Zhan
On 08/12/16 15:17, Jan Beulich wrote:
On 08.12.16 at 15:46, wrote:
>> On 08/12/16 14:41, Jan Beulich wrote:
>> On 08.12.16 at 15:18, wrote:
elf_uval() can return zero either because the field itself is zero, or
>> because
the access is out of bounds.
c/s a01b6d4 "lib
On Thu, Dec 08, 2016 at 08:03:04AM -0700, Jan Beulich wrote:
> >>> On 08.12.16 at 14:54, wrote:
> > Instruction emulator fuzzing code is from code previous written by
> > Andrew and George. Adapted to llvm fuzzer and hook up the build system.
>
> With this, how much of the new code could be share
- learn about memory size from the E820
- ignore error if host bridge devid is 0x, PVH does not have PCI and
reading from unexisting device return -1.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD
---
OvmfPkg/XenPlatformPei/MemDetect.c | 71 +
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD
---
OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
b/OvmfPkg/Library/PlatformBootManagerLib/BdsPl
Copy of OvmfPkg/ResetVector, with one changes:
- default_cr0: enable cache
Xen copy the OVMF code to RAM, there is no need for cache. Also, it
makes OVMF slow to start on AMD.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD
---
OvmfPkg/XenOvmf.dsc
This one enter directly in 32bits
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD
---
OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm | 79 +
OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm | 23 +++
OvmfPkg/XenResetVector/XenRese
This is a debug IO port that will output directly to the Xen Hypervisor
console.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD
---
OvmfPkg/XenOvmf.dsc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index e4
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD
---
OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf | 1 +
1 file changed, 1 insertion(+)
diff --git a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf
b/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf
in
This is a copy of OvmfX64, removing VirtIO and some SMM.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD
---
OvmfPkg/XenOvmf.dsc | 793
OvmfPkg/XenOvmf.fdf | 504 +
2 files
A copy of OvmfPkg/PlatformPei without some of QEMU specific
initialization, Xen does not support QemuFwCfg.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD
---
OvmfPkg/XenOvmf.dsc | 2 +-
OvmfPkg/XenOvmf.fdf |
A copy of OvmfPkg/Library/PciHostBridgeLib
Removing support for pci bus enumeration, I think, and only use scan of
already enumerated pci bus.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD
---
.../Library/XenPciHostBridgeLib/XenPciHostBridge.h | 75
Hi,
I've started to create a Xen specifig plaform, in OvmfPkg/XenOvmf.dsc
with the goal to make it work on both Xen HVM and Xen PVHv2
The first few patches only create the platform and duplicate some code from
OvmfPkg and the later patches (from OvmfPkg/XenPlatformPei: Add xen PVH
specific code)
and add OvmfPkg/XenConsoleIo/XenConsoleIo to XenOvmf platform.
It actually look for gEfiSerialIoProtocolGuid.
---
.../Library/PlatformBootManagerLib/BdsPlatform.c | 33 ++
.../PlatformBootManagerLib.inf | 2 ++
OvmfPkg/XenOvmf.dsc
Andrew Cooper writes ("Re: [PATCH] libelf: Fix div0 issues in
elf_{shdr,phdr}_count()"):
> On 08/12/16 15:17, Jan Beulich wrote:
> > Oh, I see - elf_phdr_count() itself relies on the check that's
> > about to be done. But I think the correct thing then would be to
> > not use elf_phdr_count() here
On Thu, Dec 08, 2016 at 03:12:12PM +, Julien Grall wrote:
[...]
> == Toolstack ==
>
> * Logging solution for Xen system
> - Wei Liu
>
Not enough interest, please drop this for now.
> * Remove blktap2
> - Wei Liu
>
Under discussion with user.
> == Mini-OS ==
>
> == GRUB ==
>
---
OvmfPkg/XenOvmf.dsc | 5 -
OvmfPkg/XenOvmf.fdf | 2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index a7a884e..345157b 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -567,7 +567,10 @@
}
MdeModulePkg/Univer
This "device" use XenIoMmioLib to reserve some space to be use by grant
tables. It's use 0xfc00, which might not be a good choice...
There is probably a better way that using a device for this.
---
OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c | 263
OvmfPkg/XenIoPv
declare more exported function, ReadLocalApicReg and WriteLocalApicReg.
On my system (running OVMF inside a Xen PVH guest), writing the
interrupt information (to XAPIC_LVT_TIMER_OFFSET) would also reset the
init-count register, thus disabling the timer.
---
UefiCpuPkg/Include/Library/LocalApicLib
And replacing the ACPI Timer by this one based on the local APIC.
ACPI Timer does not work in a PVH guest, but local APIC works on both
PVH and HVM.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD
---
OvmfPkg/XenOvmf.dsc | 18 +-
1: make tlbflush_filter()'s first parameter a pointer
2: VT-d: correct dma_msi_set_affinity()
3: x86: introduce and use scratch CPU mask
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 08.12.16 at 16:36, wrote:
> On Thu, Dec 08, 2016 at 03:12:12PM +, Julien Grall wrote:
> [...]
>> == Toolstack ==
>>
>> * Logging solution for Xen system
>> - Wei Liu
>>
>
> Not enough interest, please drop this for now.
Possibly slightly related: What's the situation with the r
This brings it in line with most other functions dealing with CPU
masks. Convert both implementations to inline functions at once.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2514,7 +2514,7 @@ static int __get_page_type(struct page_i
cpumask_co
That commit ("VT-d: use msi_compose_msg()) together with 15aa6c6748
("amd iommu: use base platform MSI implementation") introducing the use
of a per-CPU scratch CPU mask went too far: dma_msi_set_affinity() may,
at least in theory, be called in interrupt context, and hence the use
of that scratch v
On Thu, Dec 08, 2016 at 08:57:21AM -0700, Jan Beulich wrote:
> >>> On 08.12.16 at 16:36, wrote:
> > On Thu, Dec 08, 2016 at 03:12:12PM +, Julien Grall wrote:
> > [...]
> >> == Toolstack ==
> >>
> >> * Logging solution for Xen system
> >> - Wei Liu
> >>
> >
> > Not enough interest, plea
__get_page_type(), so far using an on-stack CPU mask variable, is
involved in the recursion when e.g. pinning page tables. This means
there may be up two five instances of the function active at a time,
implying five instances of the (up to 512 bytes large) CPU mask
variable. With an IRQ happening
>>> On 08.12.16 at 16:47, wrote:
> Andrew Cooper writes ("Re: [PATCH] libelf: Fix div0 issues in
> elf_{shdr,phdr}_count()"):
>> On 08/12/16 15:17, Jan Beulich wrote:
>> > Oh, I see - elf_phdr_count() itself relies on the check that's
>> > about to be done. But I think the correct thing then woul
>>> On 30.11.16 at 17:49, wrote:
> --- a/docs/misc/hvmlite.markdown
> +++ b/docs/misc/hvmlite.markdown
> @@ -75,3 +75,23 @@ info structure that's passed at boot time (field
> rsdp_paddr).
>
> Description of paravirtualized devices will come from XenStore, just as it's
> done for HVM guests.
>
>>> On 30.11.16 at 17:49, wrote:
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -834,6 +834,7 @@ static inline unsigned int p2m_get_iommu_flags(p2m_type_t
> p2mt)
> case p2m_grant_map_rw:
> case p2m_ram_logdirty:
> case p2m_map_foreign:
> +case p2m_mmi
>>> On 30.11.16 at 17:49, wrote:
> Allow the use of both the emulated local APIC and IO APIC for the hardware
> domain.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
albeit I'm not 100% convinced of ...
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -509,6 +509
On 08/12/16 11:52, Jan Beulich wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -182,7 +182,7 @@ static const opcode_desc_t opcode_table[
>
> static const opcode_desc_t twobyte_table[256] = {
> /* 0x00 - 0x07 */
> -ModRM, Implicit
On 08/12/16 16:00, Jan Beulich wrote:
> This brings it in line with most other functions dealing with CPU
> masks. Convert both implementations to inline functions at once.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailin
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl
testid xen-boot
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree:
The first round of (very preliminary) patches for supporting the new
5-level paging of future Intel x86 processors [1] has been posted to
lkml:
https://lkml.org/lkml/2016/12/8/378
An explicit note has been added: "CONFIG_XEN is broken." and
"I would appreciate help with the code."
I think we sho
The new Xen PVH entry point requires page tables to be setup by the
kernel since it is entered with paging disabled.
Pull the common code out of head_32.S so that mk_early_pgtbl_32 can be
invoked from both the new Xen entry point and the existing startup_32
code.
Convert resulting common code to
From a user point of view, when reading things like "See
docs/misc/txt" in a man page, it is not obvious to find the
location of that file. Use $docdir to turn these into absolute
paths.
Signed-off-by: Cédric Bosdonnat
---
docs/man/xl.cfg.pod.5.in | 16
docs/man/xl.pod.1.in
On 08/12/16 16:46, Juergen Gross wrote:
> The first round of (very preliminary) patches for supporting the new
> 5-level paging of future Intel x86 processors [1] has been posted to
> lkml:
>
> https://lkml.org/lkml/2016/12/8/378
>
> An explicit note has been added: "CONFIG_XEN is broken." and
> "I
On Thu, Dec 08, 2016 at 08:03:04AM -0700, Jan Beulich wrote:
[...]
>
> > +static int emul_read_cr(
> > +unsigned int reg,
> > +unsigned long *val,
> > +struct x86_emulate_ctxt *ctxt)
> > +{
> > +/* Fake just enough state for the emulator's _get_fpu() to be happy. */
> > +switch
Ian Jackson writes ("Re: [PATCH] libelf: Fix div0 issues in
elf_{shdr,phdr}_count()"):
> Admittedly the rule about iteration count is not so easy to remember,
> and I had failed to anticipate that someone would introduce division.
> But both of those kind of bugs are denial of service, rather than
1 - 100 of 142 matches
Mail list logo
