On Thu, Sep 22, 2016 at 11:12:15AM +0200, Dario Faggioli wrote:
>On Sat, 2016-09-17 at 03:30 +, Wei Yang wrote:
>> Dario,
>>
>Hey, hi again, and sorry for the in getting back at this particular
>part of the conversation.
>
Sure, I was busy with other stuffs these days :-(
>> Just get chance
flight 101129 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101129/
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. 101123
Regressions which
On Fri, 23 Sep 2016, Dario Faggioli wrote:
> On Fri, 2016-09-23 at 11:15 +0100, Julien Grall wrote:
> > On 23/09/16 11:05, Peng Fan wrote:
> > > If cluster is not prefered, cpuclass maybe a choice, but I
> > > personally perfer
> > > "cluster" split for ARM.
> > >
> > > Thanks,
> > > Peng.
> > >
This run is configured for baseline tests only.
flight 67756 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67756/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-insta
On Thu, 22 Sep 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 22/09/2016 18:31, Stefano Stabellini wrote:
> > On Thu, 22 Sep 2016, Julien Grall wrote:
> > > Hello Peng,
> > >
> > > On 22/09/16 10:27, Peng Fan wrote:
> > > > On Thu, Sep 22, 2016 at 10:50:23AM +0200, Dario Faggioli wrote:
> > > > >
flight 101128 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101128/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail like 101102
test-amd64-i386-xl-qemut-wi
On September 24, 2016 7:34 AM, Tian Kevin < kevin.t...@intel.com > wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Friday, September 23, 2016 11:34 PM
>>
>> >>> On 20.09.16 at 15:30, wrote:
>> > --- a/xen/arch/x86/hvm/vlapic.c
>> > +++ b/xen/arch/x86/hvm/vlapic.c
>> > @@ -433,6 +43
Hi
I am experimenting Xen with my embedded system environment and got a
question in next_module() function.
*static paddr_t __init next_module(paddr_t s, paddr_t *end)*
*{*
*struct bootmodules *mi = &bootinfo.modules;*
*paddr_t lowest = ~(paddr_t)0;*
*int i;*
*for ( i = 0; i < mi
This run is configured for baseline tests only.
flight 67757 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67757/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ea317c0658b013659e064ba0323d1da8294acf4e
baseline v
Hi Daniel,
On 23/09/2016 22:47, Daniel Kiper wrote:
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 38eb888..2085f35 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -66,6
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, September 23, 2016 11:34 PM
>
> >>> On 20.09.16 at 15:30, wrote:
> > --- a/xen/arch/x86/hvm/vlapic.c
> > +++ b/xen/arch/x86/hvm/vlapic.c
> > @@ -433,6 +433,12 @@ void vlapic_EOI_set(struct vlapic *vlapic)
> > void vlapic_handle_EOI(s
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, September 20, 2016 9:04 PM
>
> While putting together another patch modifying the secondary exec
> controls I noticed that vmx_vcpu_update_vmfunc_ve() does a raw VMWRITE
> instead of going through the designated function. I assume tha
Build xen.gz with EFI code. We need this to support multiboot2
protocol on EFI platforms.
If we wish to load non-ELF file using multiboot (v1) or multiboot2 then
it must contain "linear" (or "flat") representation of code and data.
This is requirement of both boot protocols. Currently, PE file con
Every multiboot protocol (regardless of version) compatible image must
specify its load address (in ELF or multiboot header). Multiboot protocol
compatible loader have to load image at specified address. However, there
is no guarantee that the requested memory region (in case of Xen it starts
at 2
Current early command line parser implementation in assembler
is very difficult to change to relocatable stuff using segment
registers. This requires a lot of changes in very weird and
fragile code. So, reimplement this functionality in C. This
way code will be relocatable out of the box (without p
Hi,
I am sending seventh version of multiboot2 protocol support for
legacy BIOS and EFI platforms. This patch series release contains
fixes for all known issues.
The final goal is xen.efi binary file which could be loaded by EFI
loader, multiboot (v1) protocol (only on legacy BIOS platforms) and
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
---
v4
..calculating its value during runtime.
Signed-off-by: Daniel Kiper
Acked-by: Jan Beulich
---
xen/arch/x86/setup.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index f19af6e..ca1a97a 100644
--- a/xen/arch/x86/setup.c
+++ b
There is a problem with place_string() which is used as early memory
allocator. It gets memory chunks starting from start symbol and goes
down. Sadly this does not work when Xen is loaded using multiboot2
protocol because then the start lives on 1 MiB address and we should
not allocate a memory fro
Add multiboot2 protocol support. Alter min memory limit handling as we
now may not find it from either multiboot (v1) or multiboot2.
This way we are laying the foundation for EFI + GRUB2 + Xen development.
Signed-off-by: Daniel Kiper
---
v7 - suggestions/fixes:
- rename mbi_mbi/mbi2_mbi to mb
Currently xen ELF end of image address is calculated using first line from
"nm -nr xen/xen-syms" output. However, sometimes it may contain random
symbol address not related to the end of image in any way. It can happen
if a symbol is introduced with address larger than __end_of_image__ symbol
addre
Subsequent patches introducing relocatable early boot code play with
page tables using 2 MiB huge pages. If load address is not aligned at
2 MiB then code touching such page tables must have special cases for
start and end of Xen image memory region. So, let's make life easier
and move default load
It seems that from xen ELF image POV _end symbol properly determine
image end. However, taking into account that initial Xen image mapping
covers 16 MiB it looks that it is not sufficient. Currently bootloader
potentially may load xen ELF image at 1 MiB and let's say put Linux
kernel or initrd at 8
This way Xen can be loaded on EFI platforms using GRUB2 and
other boot loaders which support multiboot2 protocol.
Signed-off-by: Daniel Kiper
Acked-by: Jan Beulich
---
v7 - suggestions/fixes:
- do not allocate twice memory for trampoline if we were
loaded via multiboot2 protocol on EFI p
This way macro name better describes its function.
There is no functional change.
Suggested-by: Jan Beulich
Signed-off-by: Daniel Kiper
---
xen/arch/x86/boot/head.S | 40
xen/arch/x86/boot/trampoline.S |2 +-
xen/arch/x86/boot/wakeup.S |
..nor EFI platforms with runtime services enabled.
Suggested-by: Jan Beulich
Signed-off-by: Daniel Kiper
Acked-by: Jan Beulich
---
v6 - suggestions/fixes:
- move this commit behind "efi: create efi_enabled()" commit
(suggested by Jan Beulich).
v5 - suggestions/fixes:
- fix build err
First of all we need to differentiate between legacy BIOS
and EFI platforms during runtime, not during build, because
one image will have legacy and EFI code and can be executed
on both platforms. Additionally, we need more fine grained
knowledge about EFI environment and check for EFI platform
and
On Fri, Sep 23, 2016 at 11:00:42PM +0200, Samuel Thibault wrote:
> Marek Marczykowski-Górecki, on Fri 23 Sep 2016 20:56:43 +0200, wrote:
> > 1. How to do this? ;) I.e. what synchronization primitives are available
> > in mini-os? Just pthread_mutex_lock/unlock?
>
> pthread_mutex_lock are nops :o)
Marek Marczykowski-Górecki, on Fri 23 Sep 2016 20:56:43 +0200, wrote:
> 1. How to do this? ;) I.e. what synchronization primitives are available
> in mini-os? Just pthread_mutex_lock/unlock?
pthread_mutex_lock are nops :o) because we don't have pthread_create.
But for mini-os itself there are sync
On Fri, Sep 23, 2016 at 9:50 AM, Tamas K Lengyel
wrote:
> On Fri, Sep 23, 2016 at 9:39 AM, Jan Beulich wrote:
> On 23.09.16 at 17:26, wrote:
>>> On Fri, Sep 23, 2016 at 2:24 AM, Jan Beulich wrote:
>>> On 22.09.16 at 19:18, wrote:
> So I verified that when CPU-based load exiting is
This run is configured for baseline tests only.
flight 67752 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67752/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-h
Some code (specifically, introduced by commit 801d469ad ("[HVM] ACPI
support patch 3 of 4: ACPI _PRT table.")) has only been licensed under
GPLv2. We want to prevent this code from showing up in non-GPL
binaries which might become possible after we make ACPI builder code
available to users other th
flight 101127 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101127/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ea317c0658b013659e064ba0323d1da8294acf4e
baseline version:
ovmf 8b4ca351dded404f99250
flight 101123 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101123/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-credit2 15 guest-start/debian.repeatfail like 101110
test-amd64-i386-xl-qemuu-w
This run is configured for baseline tests only.
flight 67755 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67755/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8b4ca351dded404f992504c45e358572c4d236f9
baseline v
On Fri, Sep 23, 2016 at 04:51:33PM +0200, Samuel Thibault wrote:
> Marek Marczykowski-Górecki, on Fri 23 Sep 2016 16:25:41 +0200, wrote:
> > Toolstack during (stub)domain startup setup two things, mostly
> > asynchronously:
> > 1. pciback/pcifront (through standard xenstore entries)
> > 2. instruct
Contains items that at some point need to be addressed.
The items do not directly affect governance.pandoc
Signed-off-by: Lars Kurth
---
governance.todo | 23 +++
1 file changed, 23 insertions(+)
create mode 100644 governance.todo
diff --git a/governance.todo b/governance.t
I made some significant proposed changes to governance.html based on a number
of issues that were raised in a number of surveys last year, and via other
means, as well as in the recent discussions related to governance.html changes
(the issue of too many committers in XAPI and XAPI being able to
Added RTC Policy
Added +2 ... -2 scheme for votes
Clarified lazy consensus (tallying and lazy voting)
Added Informal Votes/Surveys
Added Project Team Leadership role and Decision making
Added Community Decisions with Funding and Legal Implications
Changed Project Wide Decision making: per project b
Main changes
Leadership team decisions: express quorum in terms of +1 votes
Security Team Members: election
Project Wide Decision Making: minor text changes
Signed-off-by: Lars Kurth
---
governance.pandoc | 45 ++---
1 file changed, 30 insertions(+), 15 de
Added TOC
Re-arranged sections compared to previous version of document
Added new anchors where needed
Split Roles section into two sections
The actual content was not changed (with the exception of minor
typos that I spotted)
Signed-off-by: Lars Kurth
---
governance.pandoc | 207 ++
From: "Edgar E. Iglesias"
This series adds support for mapping mmio-sram nodes into dom0
as normal uncached MEMORY with RW perms.
If the no-memory-wc prop is present in the DTB node, we create
DEVICE RW mappings instead.
Comments welcome!
Best regards,
Edgar
ChangeLog:
v3 -> v4:
* Rename p2m
From: "Edgar E. Iglesias"
Add support for describing normal non-cacheable memory.
Signed-off-by: Edgar E. Iglesias
---
xen/arch/arm/p2m.c | 19 +++
xen/include/asm-arm/p2m.h | 1 +
xen/include/asm-arm/page.h | 1 +
3 files changed, 21 insertions(+)
diff --git a/xen/
From: "Edgar E. Iglesias"
Rename p2m_mmio_direct_nc to p2m_mmio_direct_dev to better
express that we are mapping device memory. This will allow us
to use p2m_mmio_direct_nc for Normal Non-Cached mappings.
No functional change.
Signed-off-by: Edgar E. Iglesias
---
xen/arch/arm/p2m.c| 6
From: "Edgar E. Iglesias"
Make dt_match_node match for a single existing property.
We only search for the existence of the property, not
for specific values.
Acked-by: Julien Grall
Signed-off-by: Edgar E. Iglesias
---
xen/common/device_tree.c | 5 -
xen/include/xen/device_tree.h | 7
From: "Edgar E. Iglesias"
Rename and generalize un/map_regions_rw_cache into
un/map_regions_p2mt. The new functions take the mapping
attributes as an argument.
No functional change.
Signed-off-by: Edgar E. Iglesias
---
xen/arch/arm/domain_build.c | 18 ++
xen/arch/arm/p2m.c
From: "Edgar E. Iglesias"
Map mmio-sram nodes as un-cached memory. If the node
has set the no-memory-wc property, we map it as device.
The DTS bindings for mmio-sram nodes can be found in the
Linux tree under Documentation/devicetree/bindings/sram/sram.txt.
Signed-off-by: Edgar E. Iglesias
---
From: "Edgar E. Iglesias"
Add plumbing for passing around mapping attributes.
Nodes that don't specifically state their type will inherit
their type from their parent.
This is in preparation for allowing us to differentiate the attributes
for specific device nodes.
We still use the same DEVICE
From: "Edgar E. Iglesias"
Add __DT_MATCH macros without braces to allow the creation
of match descriptors with multiple combined match options.
Acked-by: Julien Grall
Signed-off-by: Edgar E. Iglesias
---
xen/include/xen/device_tree.h | 13 +
1 file changed, 9 insertions(+), 4 dele
On Fri, Sep 23, 2016 at 11:35:27AM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 23, 2016 at 04:25:41PM +0200, Marek Marczykowski-Górecki wrote:
> > On Fri, Sep 23, 2016 at 03:27:07PM +0200, Samuel Thibault wrote:
> > > Marek Marczykowski-Górecki, on Fri 23 Sep 2016 10:48:14 +0200, wrote:
> > >
flight 101126 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101126/
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
flight 101121 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101121/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101116
test-amd64-i386-xl-qemuu-wi
On Mon, Sep 19, 2016 at 05:22:27PM +0200, Julien Grall wrote:
> Hi Edgar,
Hi Julien,
Sorry for the late reply!
>
> On 16/09/2016 18:17, Edgar E. Iglesias wrote:
> >On Fri, Sep 16, 2016 at 04:21:12PM +0200, Julien Grall wrote:
> >>Hi Edgar,
> >>
> >>On 07/09/2016 08:56, Edgar E. Iglesias wrote:
On 14/09/16 17:21, Jan Beulich wrote:
On 14.09.16 at 18:11, wrote:
On 08/09/16 14:11, Jan Beulich wrote:
@@ -1580,6 +1586,9 @@ struct x86_emulate_state {
ext_0f = vex_0f,
ext_0f38 = vex_0f38,
ext_0f3a = vex_0f3a,
+ext_8f08 = 8,
+ext_8f09,
+
On 14/09/16 16:05, Jan Beulich wrote:
On 14.09.16 at 16:22, wrote:
On 08/09/16 14:10, Jan Beulich wrote:
This way we can at least size (and e.g. skip) them if needed, and we
also won't raise the wrong fault due to not having read all relevant
bytes.
What faults are you referring to? #UD vs #
On Fri, Sep 23, 2016 at 11:37:27AM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 23, 2016 at 03:36:27PM +0100, Ross Lagerwall wrote:
> > On 09/21/2016 06:32 PM, Konrad Rzeszutek Wilk wrote:
> > > If the distance is too big we are in trouble - as our relocation
> > > distance can surely be clipp
This run is configured for baseline tests only.
flight 67753 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67753/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-build
> Same as previously, can this not be done with a simple memcpy?
Done!
From caaf99c75f28486737c21f1fc5f584b67e088f35 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk
Date: Fri, 23 Sep 2016 11:25:12 -0400
Subject: [PATCH v6] livepatch, arm[32|64]: Share arch_livepatch_revert
It is exactly t
> > int arch_livepatch_perform_rel(struct livepatch_elf *elf,
> > const struct livepatch_elf_sec *base,
> > const struct livepatch_elf_sec *rela)
> > diff --git a/xen/common/livepatch_elf.c b/xen/common/livepatch_elf.c
> > index f4699
flight 101124 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101124/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8b4ca351dded404f992504c45e358572c4d236f9
baseline version:
ovmf fe882c01122e7e01e0e78
> > +bool arch_livepatch_symbol_ok(const struct livepatch_elf *elf,
> > + const struct livepatch_elf_sym *sym)
> > +{
> > +/*
> > + * - Mapping symbols - denote the "start of a sequence of bytes of the
> > + * appropriate type" to mark certain features - s
On Fri, Sep 23, 2016 at 9:39 AM, Jan Beulich wrote:
On 23.09.16 at 17:26, wrote:
>> On Fri, Sep 23, 2016 at 2:24 AM, Jan Beulich wrote:
>> On 22.09.16 at 19:18, wrote:
So I verified that when CPU-based load exiting is enabled, the TLB
flush here is critical. Without it the gu
On Fri, Sep 23, 2016 at 02:38:57PM +0100, Ross Lagerwall wrote:
> On 09/21/2016 06:32 PM, Konrad Rzeszutek Wilk wrote:
> snip
> > +
> > +void arch_livepatch_revert(const struct livepatch_func *func)
> > +{
> > +uint32_t *new_ptr;
> > +unsigned int i, len;
> > +
> > +new_ptr = func->old_
>>> On 23.09.16 at 17:26, wrote:
> On Fri, Sep 23, 2016 at 2:24 AM, Jan Beulich wrote:
> On 22.09.16 at 19:18, wrote:
>>> So I verified that when CPU-based load exiting is enabled, the TLB
>>> flush here is critical. Without it the guest kernel crashes at random
>>> points during boot. OTOH
On Fri, Sep 23, 2016 at 03:36:27PM +0100, Ross Lagerwall wrote:
> On 09/21/2016 06:32 PM, Konrad Rzeszutek Wilk wrote:
> > If the distance is too big we are in trouble - as our relocation
> > distance can surely be clipped, or still have a valid width - but
> > cause an overflow of distance.
> >
>
On Fri, Sep 23, 2016 at 04:25:41PM +0200, Marek Marczykowski-Górecki wrote:
> On Fri, Sep 23, 2016 at 03:27:07PM +0200, Samuel Thibault wrote:
> > Marek Marczykowski-Górecki, on Fri 23 Sep 2016 10:48:14 +0200, wrote:
> > > I'm still trying to get PCI passthrough working with stubdomain and
> > > wi
This run is configured for baseline tests only.
flight 67754 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67754/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf fe882c01122e7e01e0e78ca8da64630faf9a7b5a
baseline v
>>> On 20.09.16 at 15:30, wrote:
> --- a/xen/arch/x86/hvm/vlapic.c
> +++ b/xen/arch/x86/hvm/vlapic.c
> @@ -433,6 +433,12 @@ void vlapic_EOI_set(struct vlapic *vlapic)
> void vlapic_handle_EOI(struct vlapic *vlapic, u8 vector)
> {
> struct domain *d = vlapic_domain(vlapic);
> +struct vcp
On Fri, Sep 23, 2016 at 2:24 AM, Jan Beulich wrote:
On 22.09.16 at 19:18, wrote:
>> So I verified that when CPU-based load exiting is enabled, the TLB
>> flush here is critical. Without it the guest kernel crashes at random
>> points during boot. OTOH why does Xen trap every guest CR3 update
>>> On 23.09.16 at 16:48, wrote:
> On 14/09/16 10:55, Jan Beulich wrote:
> On 13.09.16 at 20:44, wrote:
>>> I would suggest leaving the generate_exception_if(mode_64bit(), EXC_UD,
>>> -1); after the ASSERT() so even if we do end up in a wonky state, we
>>> don't try to jump the guest to 0.
>>
>>> On 23.09.16 at 12:42, wrote:
> Extend the "tsc" boot parameter is to further relax TSC restrictions and
> allow it to be used on machines that guarantee reliable TSC across
> sockets. This is up to board manufacturers and there's no way for the OS
> to probe this property, therefore user needs
On 09/21/2016 06:32 PM, Konrad Rzeszutek Wilk wrote:
It is exactly the same in both platforms.
No functional change.
Acked-by: Julien Grall
Signed-off-by: Konrad Rzeszutek Wilk
---
Cc: Julien Grall
Cc: Stefano Stabellini
v3: New submission.
v4: s/arch_livepatch_insn_len/livepatch_insn_len/
>>> On 23.09.16 at 12:42, wrote:
> Recent x86/time changes improved a lot of the monotonicity in xen
> timekeeping, making it much harder to observe time going backwards.
> Although platform timer can't be expected to be perfectly in sync with
> TSC and so get_s_time won't be guaranteed to always
On 09/21/2016 06:32 PM, Konrad Rzeszutek Wilk wrote:
So they can be shared with ARM64 (but not yet, so they
are only built on x86).
No functional change.
We also need to tweak the MAINTAINERS and .gitignore file.
Also we need to update SUBDIRS to include the new 'test'
directory so 'cscope' ca
Marek Marczykowski-Górecki, on Fri 23 Sep 2016 16:25:41 +0200, wrote:
> On Fri, Sep 23, 2016 at 03:27:07PM +0200, Samuel Thibault wrote:
> > Marek Marczykowski-Górecki, on Fri 23 Sep 2016 10:48:14 +0200, wrote:
> > > I'm still trying to get PCI passthrough working with stubdomain and
> > > without
On 09/21/2016 06:32 PM, Konrad Rzeszutek Wilk wrote:
Certain platforms, such as ARM [32|64] add extra mapping symbols
such as $x (for ARM64 instructions), or more interesting to
this patch: $t (for Thumb instructions). These symbols are suppose
to help the final linker to make any adjustments (su
On 14/09/16 10:55, Jan Beulich wrote:
On 13.09.16 at 20:44, wrote:
On 08/09/16 14:07, Jan Beulich wrote:
@@ -1602,6 +1602,45 @@ struct x86_emulate_state {
#define _regs (state->regs)
static int
+x86_decode_base(
What do you mean by decode_base here?
The base instruction set (no 0f or
On 09/23/2016 10:38 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [PATCH v5 03/21] acpi: Prevent GPL-only code
> from seeping into non-GPL binaries"):
>> On 09/23/2016 10:24 AM, Ian Jackson wrote:
>>> But really, why not make this (or most of it) a here document (ie with
>>> <<) ?
>> Sor
On 09/21/2016 06:32 PM, Konrad Rzeszutek Wilk wrote:
Those symbols are used to help final linkers to replace insn.
The ARM ELF specification mandates that they are present
to denote the start of certain CPU features. There are two
variants of it - short and long format.
Either way - we can ignor
>>> On 23.09.16 at 16:23, wrote:
> On 09/23/2016 05:18 AM, Jan Beulich wrote:
>>
>>> @@ -36,18 +37,25 @@ ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl
>>> iasl
>>> mk_dsdt: mk_dsdt.c
>>> $(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c
>>>
>>> -dsdt_anycpu_qemu_xen.asl:
Boris Ostrovsky writes ("Re: [PATCH v5 03/21] acpi: Prevent GPL-only code from
seeping into non-GPL binaries"):
> On 09/23/2016 10:24 AM, Ian Jackson wrote:
> > But really, why not make this (or most of it) a here document (ie with
> > <<) ?
>
> Sorry, I don't follow this. What is a "here docum
On 09/21/2016 06:32 PM, Konrad Rzeszutek Wilk wrote:
If the distance is too big we are in trouble - as our relocation
distance can surely be clipped, or still have a valid width - but
cause an overflow of distance.
On various architectures the maximum displacement for a unconditional
branch/jump
On 09/23/2016 10:24 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [PATCH v5 03/21] acpi: Prevent GPL-only code
> from seeping into non-GPL binaries"):
+printf "\n/* Beginning of GPL-only code */\n\n"
+
+printf "/* _S3 and _S4 are in separate SSDTs */\n"
+printf
On Fri, Sep 23, 2016 at 03:21:35PM +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: [OSSTEST PATCH] TestSupport: use qemu-img to create
> vhd image"):
> > FAOD, I haven't dropped this. This patch LGTM.
> >
> > Acked-by: Ian Jackson
> >
> > I have queued it for a push at some point. Right
On Fri, Sep 23, 2016 at 03:27:07PM +0200, Samuel Thibault wrote:
> Marek Marczykowski-Górecki, on Fri 23 Sep 2016 10:48:14 +0200, wrote:
> > I'm still trying to get PCI passthrough working with stubdomain and
> > without qemu in dom0 (even for just vfb/vkbd backends). How is this
> > supposed to wo
Boris Ostrovsky writes ("Re: [PATCH v5 03/21] acpi: Prevent GPL-only code from
seeping into non-GPL binaries"):
> >> +printf "\n/* Beginning of GPL-only code */\n\n"
> >> +
> >> +printf "/* _S3 and _S4 are in separate SSDTs */\n"
> >> +printf "Name (\_S5, Package (0x04) {\n"
> >> +prin
Ian Jackson writes ("Re: [OSSTEST PATCH] TestSupport: use qemu-img to create
vhd image"):
> FAOD, I haven't dropped this. This patch LGTM.
>
> Acked-by: Ian Jackson
>
> I have queued it for a push at some point. Right now there's a d-i
> update in the pipeline ahead of it.
Well, it did this:
On 09/23/2016 05:18 AM, Jan Beulich wrote:
>
>> @@ -36,18 +37,25 @@ ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
>> mk_dsdt: mk_dsdt.c
>> $(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c
>>
>> -dsdt_anycpu_qemu_xen.asl: dsdt.asl dsdt_acpi_info.asl mk_dsdt
>> +ifeq (
>>> On 02.09.16 at 15:15, wrote:
> And that is another reason I use pause/unpause here, it can address
> all the races. And this is an one-time action (Only occurs at the first
> device gets assigned), do you think it is that unacceptable?
Btw. please see George's very nice description - much bet
>>> On 23.09.16 at 13:35, wrote:
> One early allocator for both platforms would be nice. And I have a feeling
> that this is the Jan's goal. However, I am not going to insist because you
> know ARM platforms better than I. So, I think that Jan should say what is
> his idea in this situation.
The
Hi Dario,
On 22/09/16 17:31, Dario Faggioli wrote:
On Thu, 2016-09-22 at 12:24 +0100, Julien Grall wrote:
On 22/09/16 09:43, Dario Faggioli wrote:
Local migration basically --from the vcpu perspective-- means
create a
new vcpu, stop the original vcpu, copy the state from original to
new,
destr
On Fri, 2016-09-23 at 18:05 +0800, Peng Fan wrote:
> We still can introduce cpupool-cluster-split or as Juergen suggested,
> use "cpupool-slit feature=xx" to split the cluster or cpuclasses
> into different cpupools. This is just a feature that better to have,
> I think.
>
> The reason to include
On 09/21/2016 06:32 PM, Konrad Rzeszutek Wilk wrote:
snip
+
+void arch_livepatch_revert(const struct livepatch_func *func)
+{
+uint32_t *new_ptr;
+unsigned int i, len;
+
+new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
+len = livepatch_insn_len(func) / sizeof(uint32_
On Fri, 2016-09-23 at 11:15 +0100, Julien Grall wrote:
> On 23/09/16 11:05, Peng Fan wrote:
> > If cluster is not prefered, cpuclass maybe a choice, but I
> > personally perfer
> > "cluster" split for ARM.
> >
> > Thanks,
> > Peng.
> >
> > [1] https://en.wikipedia.org/wiki/ARM_big.LITTLE
>
> Ple
flight 101122 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101122/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf fe882c01122e7e01e0e78ca8da64630faf9a7b5a
baseline version:
ovmf 85b88deb18857af261c65
Marek Marczykowski-Górecki, on Fri 23 Sep 2016 10:48:14 +0200, wrote:
> I'm still trying to get PCI passthrough working with stubdomain and
> without qemu in dom0 (even for just vfb/vkbd backends). How is this
> supposed to work?
Just as I recall from my memory:
> 1. Should xen-pcifront in the ta
On 09/21/2016 06:32 PM, Konrad Rzeszutek Wilk wrote:
If the payload had the sections mentioned but the hypervisor
did not support some of them (say on ARM the .ex_table) - instead
of ignoring them - it should forbid loading of such payload.
Reviewed-by: Julien Grall
Signed-off-by: Konrad Rzeszu
flight 101120 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101120/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-qcow2 9 debian-di-install fail REGR. vs. 101072
Tests which did not suc
On Fri, Sep 23, 2016 at 12:42:10PM +0100, Julien Grall wrote:
>
>
> On 23/09/16 12:35, Daniel Kiper wrote:
> >On Fri, Sep 23, 2016 at 12:07:14PM +0100, Julien Grall wrote:
> >>On 23/09/16 11:50, Daniel Kiper wrote:
> >>>Hi Julien,
> >>
> >>Hi Daniel,
> >>
> >>>
> >>>On Thu, Sep 22, 2016 at 06:07:26
Boris Ostrovsky writes ("[PATCH v5 04/21] acpi: Re-license ACPI builder files
from GPLv2 to LGPLv2.1"):
> ACPI builder is currently distributed under GPLv2 license.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists
1 - 100 of 135 matches
Mail list logo
