>>> On 08.12.16 at 20:35, wrote:
>
> On 12/7/2016 8:51 AM, Jan Beulich wrote:
> On 07.12.16 at 16:57, wrote:
>>> I did the the following:
>>>
>>> wget https://downloads.xenproject.org/release/xen/4.8.0/xen-4.8.0.tar.gz
>>> tar -xvzf xen-4.8.0.tar.gz
>>> cd /usr/local/src/xen-4.8.0
>>> ./co
>>> On 08.12.16 at 18:25, wrote:
> 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
On Thu, 2016-12-08 at 17:59 +, Wei Liu wrote:
> On Thu, Dec 08, 2016 at 05:56:12PM +0100, Cédric Bosdonnat wrote:
> > 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
>>> On 08.12.16 at 18:57, wrote:
> 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
On Thu, 2016-12-08 at 17:59 +, Andrew Cooper wrote:
> On 08/12/16 16:56, Cédric Bosdonnat wrote:
> > 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
>
>>> On 08.12.16 at 22:54, wrote:
> On Thu, 2016-12-08 at 03:14 -0700, Jan Beulich wrote:
>> > > > On 07.12.16 at 19:29, wrote:
>> > The list of classes is kept ordered from the more powerful to the
>> > less
>> > powerful.
>> > **TODO:** this has been [proposed by
>> > George](https://lists.xenp
>>> On 09.12.16 at 00:08, wrote:
> On Wed, Dec 07, 2016 at 06:27:58PM +0100, Daniel Kiper wrote:
>> On Wed, Dec 07, 2016 at 06:43:40AM -0700, Jan Beulich wrote:
>> > >>> On 05.12.16 at 23:25, wrote:
>> > > Current early command line parser implementation in assembler
>> > > is very difficult to c
Hi all,
I run the Ubuntu 16.04 server (2 vcpu/2G, Linux 4.4.0) on the Xen-4.1.2,
and installed gcc through the CDROM used by 16.04 iso file, when I
installed gcc that depends deb packages to decompress failed. But
uploaded the ISO files into the VM are mounted by loop or used as CDROM
for oth
On Fri, 2016-12-09 at 01:13 -0700, Jan Beulich wrote:
> > > > On 08.12.16 at 22:54, wrote:
> > Yeah, that was what was puzzling me too. Keeping them ordered has
> > the
> > nice property that if a user says the following in a config file:
> >
> > vcpuclass=["0-3:class0", "4-7:class1"]
> >
> > (
On 12/09/2016 12:57 AM, Tamas K Lengyel wrote:
> This patch relocates mem_access components that are currently mixed with p2m
> code into separate files. This better aligns the code with similar subsystems,
> such as mem_sharing and mem_paging, which are already in separate files. There
> are no co
>>> On 08.12.16 at 18:28, wrote:
> Part of the motivation for a01b6d4 was the anomaly which is the
> difference between the implementations of elf_phdr_size and
> elf_shdr_size.
>
> This was introduced in 39bf7b9d0ae5 "libelf: check loops for running
> away". That was part of the XSA-55 patchset
flight 103058 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103058/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-qcow2 6 xen-boot fail REGR. vs. 102521
test-xtf-amd64-
>>> On 08.12.16 at 18:33, wrote:
> On 08/12/16 16:01, Jan Beulich wrote:
>> That commit ("VT-d: use msi_compose_msg()) together with 15aa6c6748
>
> Which commit?
Oops - initially I had intended the title to include the hash: 83cd2038fe.
I've adjusted the text.
>> ("amd iommu: use base platform
>>> On 08.12.16 at 18:51, wrote:
> On 08/12/16 16:02, Jan Beulich wrote:
>> variable. With an IRQ happening at the deepest point of the stack, and
>> with send_guest_pirq() being called from there (leading to vcpu_kick()
>> -> ... -> csched_vcpu_wake() -> __runq_tickle() ->
>> cpumask_raise_softir
>>> On 09.12.16 at 09:29, wrote:
> On Fri, 2016-12-09 at 01:13 -0700, Jan Beulich wrote:
>> > > > On 08.12.16 at 22:54, wrote:
>> > Yeah, that was what was puzzling me too. Keeping them ordered has
>> > the
>> > nice property that if a user says the following in a config file:
>> >
>> > vcpucla
Hi,
Hypervisor will init paging when it starts. After paging is inited
(paging_init() in setup.c), I copied whole pagetable (except for PML4[258]
which is used as Linear page table, I create similar one in new PT) and
want to switch cr3 to my new PT.
If I do this after acpi_boot_init(), everythin
>>> On 08.12.16 at 23:57, wrote:
> --- a/xen/arch/x86/mm/Makefile
> +++ b/xen/arch/x86/mm/Makefile
> @@ -9,6 +9,7 @@ obj-y += guest_walk_3.o
> obj-y += guest_walk_4.o
> obj-y += mem_paging.o
> obj-y += mem_sharing.o
> +obj-y += mem_access.o
Please honor prior (mostly?) alphabetical ordering.
>>> On 09.12.16 at 04:17, wrote:
> IA32_PERF_GLOBAL_STATUS.OvfUncore (MSR 38EH, bit[61]) is always 0 and
> writing 1 to IA32_PERF_GLOBAL_OVF_CTRL.ClrOvfUncore (MSR 390H, bit[61])
> signals #GP.
> Reference "Intel Xeon Phi Procssor x200 Product Family", document
> number 334646-008.
I can see this
>>> On 09.12.16 at 00:40, wrote:
> I've been working (on and off) with SGI to get one of their 32TB boxes
> to boot and I don't think that works. We've fixed a couple of bugs but I
> don't think Xen can boot with that much memory. We successfully booted
> with just under 8TB but couldn't do it
>>> On 08.12.16 at 18:22, wrote:
> 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
On 09/12/16 10:59, Jan Beulich wrote:
On 08.12.16 at 18:22, wrote:
>> 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/lk
Hi Tamas,
On 08/12/16 22:57, Tamas K Lengyel wrote:
This patch relocates mem_access components that are currently mixed with p2m
code into separate files. This better aligns the code with similar subsystems,
such as mem_sharing and mem_paging, which are already in separate files. There
are no co
On 05/12/16 18:49, Alex Thorlton wrote:
> On systems with sufficiently large e820 tables, and several IOAPICs, it
> is possible for the XENMEM_machine_memory_map callback (and its
> counterpart, XENMEM_memory_map) to attempt to return an e820 table with
> more than 128 entries. This callback adds
On 02/12/16 07:15, 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.
>
> Sugge
On 05/12/16 18:49, Alex Thorlton wrote:
> It's really not necessary to limit E820_X_MAX to 128 in the non-EFI
> case. This commit drops E820_X_MAX's dependency on CONFIG_EFI, so that
> E820_X_MAX is always at least slightly larger than E820MAX.
>
> The real motivation behind this is actually to p
On Wed, 2016-12-07 at 12:21 -0800, Stefano Stabellini wrote:
> On Tue, 6 Dec 2016, Dario Faggioli wrote:
> > E.g., if I have pCPU 0 loaded at 75% and pCPU 1 loaded at 25%, vCPU
> > A
> > has a lot of routed interrupts, and moving it gives me perfect load
> > balancing (i.e., load will become 50% on
Hi Stefano,
On 08/12/16 22:00, Stefano Stabellini wrote:
On Thu, 8 Dec 2016, Julien Grall wrote:
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 pro
On Fri, Dec 09, 2016 at 01:09:45AM -0700, Jan Beulich wrote:
> >>> On 08.12.16 at 18:57, wrote:
> > 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
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm
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
On Thu, Dec 08, 2016 at 09:00:23AM -0700, 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: Wei Liu
___
>>> On 08.12.16 at 17:24, wrote:
> On 08/12/16 11:52, Jan Beulich wrote:
>> @@ -1401,14 +1401,11 @@ protmode_load_seg(
>> return rc;
>> }
>>
>> -if ( !is_x86_user_segment(seg) )
>> -{
>> -/* System segments must have S flag == 0. */
>> -if ( desc.b & (1u <<
On 09/12/16 06:48, Kinney, Michael D wrote:
> Hi Anthony,
>
> Can you provide more details on why you want to expose internal APIs
> in the library class?
>
> What is the specific issue? Is the Local APIC in your environment
> not behaving the same as real HW?
Xen's LAPIC emulation should match
Hi Julien,
On 6 December 2016 at 21:14, Julien Grall wrote:
+
+/*
+ * if any cpu does not support 16-bit VMID then restrict the
+ * max VMIDs which can be allocated to 256
+ */
+for_each_online_cpu ( cpu )
+{
+const struct cp
On Fri, Dec 09, 2016 at 01:05:19AM -0700, Jan Beulich wrote:
> >>> On 08.12.16 at 18:25, wrote:
> > 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_emu
>>> On 09.12.16 at 11:07, wrote:
> On 09/12/16 10:59, Jan Beulich wrote:
>> Right; a first question though would be whether 5-level support
>> would be a build time selection (just like 32-bit PAE was long ago),
>> or runtime determined.
>
> Guessing you mean Linux kernel here: the intention is t
Hi, Cedric et al. I like the idea of tidying this up. Thanks for the
patch, which (with some small changes) will be a good idea.
Cedric Bosdonnat writes ("Re: [Xen-devel] [PATCH] docs: turn links to docs/*
into absolute path"):
> On Thu, 2016-12-08 at 17:59 +, Andrew Cooper wrote:
> > Howev
1: x86emul: derive vcpu_must_have() from vcpu_has()
2: x86: drop cpu_has_sse{,2}
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
... to avoid introducing further redundancy when adding further feature
flag checks, and to bring its use better in line with its host_and_*()
sibling.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1260,39 +1260,39 @@ sta
Commit dc88221c97 ("x86: rename XMM* features to SSE*") pointlessly
added them - these features are always available on 64-bit CPUs. (Let's
not assume this for MMX though in at least the insn emulator.)
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x8
Jan Beulich writes ("Re: [PATCH] libelf: Fix div0 issues in
elf_{shdr,phdr}_count()"):
> On 08.12.16 at 18:28, wrote:
> > Looking at the commit message I was concerned that the phdr and shdr
> > counts might be excessive, and that libelf might get stuck in a loop
> > with an unreasonably high ite
On Thu, 2016-12-08 at 07:33 -0700, Jan Beulich wrote:
> Dario,
>
Hi,
> While it's
> already
> in use in credit1's __runq_tickle(), I then got puzzled by the
> different
> ways credit1 and credit2 use the variable: The former always uses
> scratch_cpumask_cpu() with the subject CPU as argument, wh
On Fri, 2016-12-09 at 11:25 +, Ian Jackson wrote:
> Hi, Cedric et al. I like the idea of tidying this up. Thanks for the
> patch, which (with some small changes) will be a good idea.
>
> Cedric Bosdonnat writes ("Re: [Xen-devel] [PATCH] docs: turn links to docs/*
> into absolute path"):
> >
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
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 | 39 +++
1 file changed, 39 insertions(+)
create mode 1006
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
Signed-off-by: Wei Liu
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Ian Jackson
Cc: Wei Liu
---
tools/tests/x86_emulator/test_x86_emulator.c | 28
1 file changed, 28 deletions(-)
diff --git a/tools/tests/x86_emulator/test_x86_emulator.c
b/tools/tests/x86_emulator/t
Source code and Makefile to fuzz libelf in Google's oss-fuzz
infrastructure.
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
C
Signed-off-by: Wei Liu
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Ian Jackson
Cc: Wei Liu
---
tools/tests/x86_emulator/test_x86_emulator.c | 59 +---
tools/tests/x86_emulator/x86_emulate.c | 39 ++
tools/tests/x86_emulator/x86_emulate.h | 19
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
It will be used by emulator fuzzing target.
Signed-off-by: Wei Liu
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Ian Jackson
Cc: Wei Liu
---
tools/tests/x86_emulator/test_x86_emulator.c | 12 ++--
tools/tests/x86_emulator/x86_emulate.c | 22 ++
tools/tests/x86_e
flight 103086 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103086/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8537bd7ef64f2ccf3b0db515f30813d5c3311a5c
baseline version:
ovmf 854c6b80dc3f1d4a15132
Let's try to limit #ifdef-ery, or else more of these would need to
appear later.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -404,6 +404,12 @@ typedef union {
(void *)((long)(__##var + __alignof(type) - __aligno
As said in the code comment being added, only adjustments affecting
further processing prior to the x86_decode_*() calls really belong into
x86_decode() itself.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1875,6 +1875,2
Make the code use EFLG_* constants instead.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -429,6 +429,7 @@ typedef union {
#define CR4_OSXSAVE(1<<18)
/* EFLAGS bit definitions. */
+#define EFLG_ID (1<<21)
#defin
On 09/12/16 11:53, Jan Beulich wrote:
> ... to avoid introducing further redundancy when adding further feature
> flag checks, and to bring its use better in line with its host_and_*()
> sibling.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
_
Hi, all!
On 12/09/2016 12:18 PM, Julien Grall wrote:
Hi Stefano,
On 08/12/16 22:00, Stefano Stabellini wrote:
On Thu, 8 Dec 2016, Julien Grall wrote:
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 goin
On Tue, Dec 06, 2016 at 11:52:48PM +0100, Daniel Kiper wrote:
> Hi,
>
> This updated patch series adds description of the Multiboot2 protocol new
> features and fixes some issues found here and there.
>
> It applies to multiboot2 branch in GRUB2 git tree.
>
> Here is short list of changes since v2:
On 09/12/16 11:54, Jan Beulich wrote:
> Commit dc88221c97 ("x86: rename XMM* features to SSE*") pointlessly
> added them - these features are always available on 64-bit CPUs. (Let's
> not assume this for MMX though in at least the insn emulator.)
>
> Signed-off-by: Jan Beulich
This isn't necessar
>>> On 09.12.16 at 12:54, wrote:
> Jan Beulich writes ("Re: [PATCH] libelf: Fix div0 issues in
> elf_{shdr,phdr}_count()"):
>> On 08.12.16 at 18:28, wrote:
>> > Looking at the commit message I was concerned that the phdr and shdr
>> > counts might be excessive, and that libelf might get stuck in
On 09/12/16 12:39, Jan Beulich wrote:
> Let's try to limit #ifdef-ery, or else more of these would need to
> appear later.
>
> Signed-off-by: Jan Beulich
Ooh - that's much nicer than the previous macros.
Reviewed-by: Andrew Cooper
Is this the kind of construct we would want to extend to the wh
flight 68180 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68180/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-armhf-jessie-netboot-pygrub 11 migrate-support-check fail
never pass
test-armhf-armhf-
On Thu, 2016-12-08 at 01:11 +0530, Praveen Kumar wrote:
> Hi,
>
Hey,
> I am new in Xen environment and trying to get VMs running with the
> build xen code base.
>
> But, am facing issue bringing up the libvirt deamon. I have installed
> latest unstable xen ( 4.9 ).
> There seems to be a conflict
>>> On 09.12.16 at 13:23, wrote:
> 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.
>
On Fri, Dec 09, 2016 at 06:07:11AM -0700, Jan Beulich wrote:
> >>> On 09.12.16 at 13:23, wrote:
> > 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
>>> On 09.12.16 at 13:23, wrote:
> @@ -18,4 +20,24 @@
> #define get_stub(stb) ((void *)((stb).addr = (uintptr_t)(stb).buf))
> #define put_stub(stb)
>
> +bool emul_test_make_stack_executable(void)
> +{
> +unsigned long sp;
> +bool stack_exec;
I'd prefer for this local variable to be re
Hi all,
I am a newbie in xen. I wish to know which all intel platforms support xen
hypervisor?.
Thanks and Regards,
George
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 09/12/16 12:39, Jan Beulich wrote:
> As said in the code comment being added, only adjustments affecting
> further processing prior to the x86_decode_*() calls really belong into
> x86_decode() itself.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
On 09/12/16 12:40, Jan Beulich wrote:
> Make the code use EFLG_* constants instead.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 09.12.16 at 13:23, wrote:
> --- a/tools/tests/x86_emulator/test_x86_emulator.c
> +++ b/tools/tests/x86_emulator/test_x86_emulator.c
> @@ -92,51 +92,33 @@ static int cmpxchg(
> return X86EMUL_OKAY;
> }
>
> -static int cpuid(
> -unsigned int *eax,
> -unsigned int *ebx,
> -
>>> On 09.12.16 at 13:23, wrote:
> --- a/tools/tests/x86_emulator/test_x86_emulator.c
> +++ b/tools/tests/x86_emulator/test_x86_emulator.c
> @@ -23,15 +23,6 @@ static const struct {
> #endif
> };
>
> -/* EFLAGS bit definitions. */
> -#define EFLG_OF (1<<11)
> -#define EFLG_DF (1<<10)
> -#defin
flight 103137 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103137/
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
On Thu, Dec 08, 2016 at 01:11:24AM +0530, Praveen Kumar wrote:
> Hi,
>
> I am new in Xen environment and trying to get VMs running with the build
> xen code base.
>
> But, am facing issue bringing up the libvirt deamon. I have installed
> latest unstable xen ( 4.9 ).
> There seems to be a conflic
>>> On 09.12.16 at 13:23, wrote:
> +static int fuzz_cpuid(
> +unsigned int *eax,
> +unsigned int *ebx,
> +unsigned int *ecx,
> +unsigned int *edx,
> +struct x86_emulate_ctxt *ctxt)
> +{
> +return emul_test_cpuid(eax, ebx, ecx, edx, ctxt);
> +}
Please use emul_test_cpuid di
>>> On 09.12.16 at 14:09, wrote:
> On Fri, Dec 09, 2016 at 06:07:11AM -0700, Jan Beulich wrote:
>> >>> On 09.12.16 at 13:23, wrote:
>> > 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
>
>>> On 09.12.16 at 14:00, wrote:
> On 09/12/16 11:54, Jan Beulich wrote:
>> Commit dc88221c97 ("x86: rename XMM* features to SSE*") pointlessly
>> added them - these features are always available on 64-bit CPUs. (Let's
>> not assume this for MMX though in at least the insn emulator.)
>>
>> Signed-
>>> On 09.12.16 at 14:06, wrote:
> On 09/12/16 12:39, Jan Beulich wrote:
>> Let's try to limit #ifdef-ery, or else more of these would need to
>> appear later.
>>
>> Signed-off-by: Jan Beulich
>
> Ooh - that's much nicer than the previous macros.
>
> Reviewed-by: Andrew Cooper
>
> Is this the
On Fri, Dec 09, 2016 at 01:19:24AM -0700, Jan Beulich wrote:
> >>> On 09.12.16 at 00:08, wrote:
[...]
> > I have checked it. It requires at least some changes made by patch #1 which
> > has "Reviewed-by: Jan Beulich ". Of course I can change
> > this but then I think that I should drop your Revi
On Fri, Dec 09, 2016 at 06:13:24AM -0700, Jan Beulich wrote:
[...]
> > --- a/tools/tests/x86_emulator/x86_emulate.h
> > +++ b/tools/tests/x86_emulator/x86_emulate.h
> > @@ -37,3 +37,22 @@
> > bool emul_test_make_stack_executable(void);
> >
> > #include "x86_emulate/x86_emulate.h"
> > +
> > +#de
On Fri, Dec 09, 2016 at 06:15:04AM -0700, Jan Beulich wrote:
> >>> On 09.12.16 at 13:23, wrote:
> > --- a/tools/tests/x86_emulator/test_x86_emulator.c
> > +++ b/tools/tests/x86_emulator/test_x86_emulator.c
> > @@ -23,15 +23,6 @@ static const struct {
> > #endif
> > };
> >
> > -/* EFLAGS bit de
Hi Stefano,
On 09/12/16 00:59, Stefano Stabellini wrote:
Add missing vgic_unlock_rank on the error path in
gic_remove_irq_from_guest.
CID: 1381843
s/CID/Coverity-ID/ to stay inline with the other coverity patch.
Signed-off-by: Stefano Stabellini
Reviewed-by: Julien Grall
This was intr
On 07/12/16 15:15, Jan Beulich wrote:
> Rename _get_rep_prefix() to make it more visibly fit other use cases
> and introduce a companion "put". Use them for repeated string insn
> handling as well as LOOP/J?CXZ instead of open coding the same logic a
> couple of times.
>
> Signed-off-by: Jan Beulic
On Fri, Dec 09, 2016 at 02:57:04PM +0200, Oleksandr Andrushchenko wrote:
> >>
> >>Should we have a section on new PV drivers? If so, I suggest to add:
> >>- Xen transport for 9pfs
> >>- PV Calls
> >
> >Good idea. We could also include DRM and PV Sound (CC Oleksandr).
> >
> This is a great idea. Let
On 12/09/2016 03:57 PM, Pasi Kärkkäinen wrote:
On Fri, Dec 09, 2016 at 02:57:04PM +0200, Oleksandr Andrushchenko wrote:
Should we have a section on new PV drivers? If so, I suggest to add:
- Xen transport for 9pfs
- PV Calls
Good idea. We could also include DRM and PV Sound (CC Oleksandr).
Th
Hi Stefano
On 09.12.16 02:59, Stefano Stabellini wrote:
> Add missing vgic_unlock_rank on the error path in
> gic_remove_irq_from_guest.
>
> CID: 1381843
>
> Signed-off-by: Stefano Stabellini
>
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 63c744a..a5348f2 100644
> --- a/xen/arch
On Tue, Dec 06, 2016 at 11:02:20AM -0800, Stefano Stabellini wrote:
> On Tue, 6 Dec 2016, Julien Grall wrote:
> > Hi all,
> >
> > Apologies for the late sending. You will find at the end of the mail a
> > summary
> > of the discussion. Feel free to reply if I missed some parts.
> >
> > At the en
On Wed 30 Nov 2016 08:44:20 PM CET, Eric Blake wrote:
> Quite a few users of qdict_put() were manually wrapping a
> non-QObject. We can make such call-sites shorter, by providing
> common macros to do the tedious work. Also shorten nearby
> qdict_put_obj(,,QOBJECT()) sequences.
>
> Signed-off-by:
On 09/12/16 13:28, Jan Beulich wrote:
On 09.12.16 at 14:00, wrote:
>> On 09/12/16 11:54, Jan Beulich wrote:
>>> Commit dc88221c97 ("x86: rename XMM* features to SSE*") pointlessly
>>> added them - these features are always available on 64-bit CPUs. (Let's
>>> not assume this for MMX though in
TSC_DEADLINE in particular depends on both; take the opportunity to add
a few more.
Signed-off-by: Jan Beulich
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -181,9 +181,11 @@ def crunch_numbers(state):
# bit is only representable in the 64bit PTE format offered by PAE.
Hi Stefano,
On 09/12/16 01:17, Stefano Stabellini wrote:
mode == ARRAY_SIZE(mode_strings) causes an out of bound access to
the mode_strings array.
Coverity-ID: 1381859
Signed-off-by: Stefano Stabellini
Reviewed-by: Julien Grall
On a side note, technically this will never happen because th
On 12/9/2016 12:03 AM, Jan Beulich wrote:
On 08.12.16 at 20:35, wrote:
On 12/7/2016 8:51 AM, Jan Beulich wrote:
On 07.12.16 at 16:57, wrote:
I did the the following:
wget https://downloads.xenproject.org/release/xen/4.8.0/xen-4.8.0.tar.gz
tar -xvzf xen-4.8.0.tar.gz
cd /usr/local/src/xen-4
Hi Stefano,
CC Jan as he is the maintainer of this code.
Cheers,
On 09/12/16 01:30, Stefano Stabellini wrote:
HorizontalResolution and VerticalResolution are 32bit, while size is
64bit. As it stands the multiplication is evaluated with 32bit
arithmetic, which could overflow. Cast HorizontalRes
On 09/12/16 14:17, Jan Beulich wrote:
> TSC_DEADLINE in particular depends on both; take the opportunity to add
> a few more.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xe
On 12/08/2016 11:33 PM, Ingo Molnar wrote:
> * Boris Ostrovsky wrote:
>
>> 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 n
>>> On 09.12.16 at 15:15, wrote:
> On 09/12/16 13:28, Jan Beulich wrote:
> On 09.12.16 at 14:00, wrote:
>>> On 09/12/16 11:54, Jan Beulich wrote:
Commit dc88221c97 ("x86: rename XMM* features to SSE*") pointlessly
added them - these features are always available on 64-bit CPUs. (Let
/proc/xen/xenbus does not work correctly. A read blocked waiting for
a xenstore message holds the mutex needed for atomic file position
updates. This blocks any writes on the same file handle, which can
deadlock if the write is needed to unblock the read.
Clear FMODE_ATOMIC_POS when opening this
On 12/08/2016 10:17 PM, Luwei Kang wrote:
> IA32_PERF_GLOBAL_STATUS.OvfUncore (MSR 38EH, bit[61]) is always 0 and
> writing 1 to IA32_PERF_GLOBAL_OVF_CTRL.ClrOvfUncore (MSR 390H, bit[61])
> signals #GP.
> Reference "Intel Xeon Phi Procssor x200 Product Family", document
> number 334646-008.
>
> Sig
>>> On 09.12.16 at 02:30, wrote:
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -687,7 +687,7 @@ static UINTN __init
> efi_find_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
> mode_info->HorizontalResolution *
> mode_info->VerticalResolution > size )
>
This run is configured for baseline tests only.
flight 68181 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68181/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8537bd7ef64f2ccf3b0db515f30813d5c3311a5c
baseline v
On 09/12/16 15:41, David Vrabel wrote:
> /proc/xen/xenbus does not work correctly. A read blocked waiting for
> a xenstore message holds the mutex needed for atomic file position
> updates. This blocks any writes on the same file handle, which can
> deadlock if the write is needed to unblock the
On 09/12/16 14:33, Jan Beulich wrote:
On 09.12.16 at 15:15, wrote:
>> On 09/12/16 13:28, Jan Beulich wrote:
>> On 09.12.16 at 14:00, wrote:
On 09/12/16 11:54, Jan Beulich wrote:
> Commit dc88221c97 ("x86: rename XMM* features to SSE*") pointlessly
> added them - these featur
1 - 100 of 207 matches
Mail list logo
