According to
https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01797.html
this partially reverts commit 350bc1a9d4 ("x86: support newer Intel CPU
models") to account for the appearant earlier mis-documentation.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xe
Hello Peng,
On 19/09/2016 04:08, van.free...@gmail.com wrote:
From: Peng Fan
This patchset is to support XEN run on big.little SoC.
The idea of the patch is from
"https://lists.xenproject.org/archives/html/xen-devel/2016-05/msg00465.html";
There are some changes to cpupool and add x86 stub fu
>>> On 15.09.16 at 18:51, wrote:
> @@ -1793,7 +1793,17 @@ static int _hvm_emulate_one(struct hvm_emulate_ctxt
> *hvmemul_ctxt,
> pfec |= PFEC_user_mode;
>
> hvmemul_ctxt->insn_buf_eip = regs->eip;
> -if ( !vio->mmio_insn_bytes )
> +
> +if ( unlikely(hvmemul_ctxt->set_conte
>>> On 19.09.16 at 04:50, wrote:
> This patch cleaned up the code by replacing complicated tlbflush check and
> operation with inline functions. We should use those inline functions to
> avoid the complicated tlbflush check and tlbflush operations when
> implementing TODOs left in commit a902c12ee
>>> On 19.09.16 at 04:50, wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -1004,6 +1004,14 @@ int domain_unpause_by_systemcontroller(struct domain
> *d)
> {
> int old, new, prev = d->controller_pause_count;
>
> +/*
> + * We record this information here for popu
Hello Julien,
On Mon, Sep 19, 2016 at 10:09:06AM +0200, Julien Grall wrote:
>Hello Peng,
>
>On 19/09/2016 04:08, van.free...@gmail.com wrote:
>>From: Peng Fan
>>
>>This patchset is to support XEN run on big.little SoC.
>>The idea of the patch is from
>>"https://lists.xenproject.org/archives/html/
>>> On 16.09.16 at 17:29, wrote:
> On general this is unhealthy - as the payload's .bss (definitly)
> or .data (maybe) will be modified once the payload is running.
>
> Doing an revert and then re-applying the payload with a non-pristine
> .bss or .data can lead to unforseen consequences (.bss ar
>>> On 16.09.16 at 17:29, wrote:
> --- a/xen/common/livepatch_elf.c
> +++ b/xen/common/livepatch_elf.c
> @@ -86,6 +86,10 @@ static int elf_resolve_sections(struct livepatch_elf *elf,
> const void *data)
> delta < sizeof(Elf_Ehdr) ? "at ELF header" : "is past
> end");
>
Hello,
On 19/09/2016 10:36, Peng Fan wrote:
On Mon, Sep 19, 2016 at 10:09:06AM +0200, Julien Grall wrote:
Hello Peng,
On 19/09/2016 04:08, van.free...@gmail.com wrote:
From: Peng Fan
This patchset is to support XEN run on big.little SoC.
The idea of the patch is from
"https://lists.xenproje
flight 101008 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101008/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-xsm 6 xen-boot fail in 100998 pass in 101008
test-armhf-armhf-libvirt 4
>>> On 16.09.16 at 17:29, wrote:
> @@ -31,11 +30,11 @@ void arch_livepatch_revive(void)
>
> int arch_livepatch_verify_func(const struct livepatch_func *func)
> {
> -/* No NOP patching yet. */
> -if ( !func->new_size )
> +/* If NOPing only do up to maximum amount we can put in the -
>>> On 16.09.16 at 17:29, wrote:
> Right now the contents of 'name' are all located in
> the .data section. We want them in the .rodata section
> so change the type to have const on them.
>
> Signed-off-by: Konrad Rzeszutek Wilk
I've only now noticed that the tests get covered in the LIVEPATCH
>>> On 16.09.16 at 18:38, wrote:
> x86 implements all of them by default - and we just
> add two extra HAS_ variables to be declared in autoconf.h.
>
> ARM 64 only has alternative while ARM 32 has none of them.
>
> And while at it change the livepatch common code that
> would benefit from this.
>>> On 16.09.16 at 18:38, wrote:
> If the distance is too great we are in trouble - as our relocation
s/great/big/ (or large), as mentioned before?
> @@ -68,7 +69,7 @@ int arch_livepatch_secure(const void *va, unsigned int
> pages, enum va_type types
> void arch_livepatch_init(void);
>
> #i
>>> On 16.09.16 at 17:29, wrote:
> docs/misc/livepatch.markdown | 7 +--
> xen/arch/x86/alternative.c| 2 +-
> xen/arch/x86/livepatch.c | 40
> +--
> xen/common/livepatch.c| 3 ++-
> xen/include/asm-x86/alternative.h |
> From: Xuquan (Euler) [mailto:xuqu...@huawei.com]
> Sent: Monday, September 12, 2016 5:08 PM
>
> On September 12, 2016 3:58 PM, Tian, Kevin wrote:
> >> From: Xuquan (Euler) [mailto:xuqu...@huawei.com]
> >> Sent: Friday, September 09, 2016 11:02 AM
> >>
> >> On August 30, 2016 1:58 PM, Tian Kevin
Hi Konrad,
On 16/09/2016 18:38, Konrad Rzeszutek Wilk wrote:
x86 implements all of them by default - and we just
add two extra HAS_ variables to be declared in autoconf.h.
ARM 64 only has alternative while ARM 32 has none of them.
And while at it change the livepatch common code that
would ben
>>> On 16.09.16 at 18:38, wrote:
> --- a/xen/arch/arm/livepatch.c
> +++ b/xen/arch/arm/livepatch.c
> @@ -117,6 +117,20 @@ bool arch_livepatch_symbol_ok(const struct livepatch_elf
> *elf,
> return true;
> }
>
> +bool arch_livepatch_symbol_deny(const struct livepatch_elf *elf,
> +
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, September 16, 2016 2:32 PM
>
> We don't currently emulate it, so guests should not be misguided to
> believe they can (try to) use it.
>
> For now, simply return zero to guests for platform MSR reads, and only
> accept (by discarding)
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, September 19, 2016 3:52 PM
>
> According to
> https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01797.html
> this partially reverts commit 350bc1a9d4 ("x86: support newer Intel CPU
> models") to account for the appearant
Fix commit f6d4cf5 ("docs: document old SUSE/Novell unplug for HVM").
The values which VMDP used to control either NIC or disk are flipped.
What the code does is:
case 8:
if (val == 1 ) {
ide_unplug_harddisks();
} else if (val == 2) {
pci_unplug
>>> On 16.09.16 at 18:38, wrote:
> As they are not needed for the livepatch to work.
I think this patch can be dropped when skipping zero-size sections,
as suggested earlier.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.or
>>> On 16.09.16 at 18:38, wrote:
> Most of the WARN_ON or BUG_ON sections are properly aligned on
> x86. However on ARM and on x86 assembler the macros don't include
> any aligment information - hence they end up being the default
> byte granularity.
>
> On ARM32 it is paramount that the aligment
osstest service owner writes ("[xtf test] 100874: all pass - PUSHED"):
> flight 100874 xtf real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/100874/
>
> Perfect :-)
Hooray. I see this is running in xen-unstable now, as expected.
Just to check, are we expecting `xtf/test-pv64-xsa-16
Hi Konrad,
On 16/09/2016 18:38, Konrad Rzeszutek Wilk wrote:
The current byte sequence is '0xcc' which makes sense on x86,
but on ARM it is:
stclgt 12, cr12, [ip], {204} ; 0xcc
Picking something more ARM applicable such as:
efefefefsvc 0x00efefef
Creates a nice
On Mon, Sep 19, 2016 at 10:53:56AM +0200, Julien Grall wrote:
>Hello,
>
>On 19/09/2016 10:36, Peng Fan wrote:
>>On Mon, Sep 19, 2016 at 10:09:06AM +0200, Julien Grall wrote:
>>>Hello Peng,
>>>
>>>On 19/09/2016 04:08, van.free...@gmail.com wrote:
From: Peng Fan
This patchset is to supp
On Mon, Sep 19, 2016 at 9:53 AM, Julien Grall wrote:
>>> As mentioned in the mail you pointed above, this series is not enough to
>>> make
>>> big.LITTLE working on then. Xen is always using the boot CPU to detect
>>> the
>>> list of features. With big.LITTLE features may not be the same.
>>>
>>>
flight 67729 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67729/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 3 host-install(3) broken REGR.
On 19/09/2016 11:38, Peng Fan wrote:
On Mon, Sep 19, 2016 at 10:53:56AM +0200, Julien Grall wrote:
Hello,
On 19/09/2016 10:36, Peng Fan wrote:
On Mon, Sep 19, 2016 at 10:09:06AM +0200, Julien Grall wrote:
Hello Peng,
On 19/09/2016 04:08, van.free...@gmail.com wrote:
From: Peng Fan
This
Hi George,
On 19/09/2016 11:45, George Dunlap wrote:
On Mon, Sep 19, 2016 at 9:53 AM, Julien Grall wrote:
As mentioned in the mail you pointed above, this series is not enough to
make
big.LITTLE working on then. Xen is always using the boot CPU to detect
the
list of features. With big.LITTLE f
>>> On 14.09.16 at 19:37, wrote:
> This patch introduces support for using TSC as platform time source
> which is the highest resolution time and most performant to get.
> Though there are also several problems associated with its usage, and
> there isn't a complete (and architecturally defined) g
>>> On 14.09.16 at 19:37, wrote:
> To allow the caller to fetch the last read from the clocksource which
> was used to calculate system_time. This is a prerequisite for a
> subsequent patch that will use this last read.
>
> Signed-off-by: Joao Martins
Acked-by: Jan Beulich
with one further min
David Miller writes:
> From: Vitaly Kuznetsov
> Date: Fri, 16 Sep 2016 12:59:14 +0200
>
>> @@ -595,6 +596,19 @@ static int xennet_start_xmit(struct sk_buff *skb,
>> struct net_device *dev)
>> offset = offset_in_page(skb->data);
>> len = skb_headlen(skb);
>>
>> +/* The first req
>>> On 14.09.16 at 19:37, wrote:
> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -951,6 +951,14 @@ static void __update_vcpu_system_time(struct vcpu *v,
> int force)
> _u.tsc_timestamp = tsc_stamp;
> _u.system_time = t->stamp.local_stime;
>
> +/*
> + * It's expe
On 19/09/16 12:06, Julien Grall wrote:
> Hi George,
>
> On 19/09/2016 11:45, George Dunlap wrote:
>> On Mon, Sep 19, 2016 at 9:53 AM, Julien Grall
>> wrote:
> As mentioned in the mail you pointed above, this series is not
> enough to
> make
> big.LITTLE working on then. Xen is alw
Hello,
My name is Veronia Bahaa. I'm a student at Ain Shams university, Egypt. I
am interested in participating in Outreachy Round 13 in the Xen Hypervisor
Userspace Tools Project. Could you point me to some small tasks I could do
to get familiar with the project?
Thanks!
Veronia
Hi Konrad,
On 16/09/2016 18:38, Konrad Rzeszutek Wilk wrote:
diff --git a/xen/arch/arm/arm64/livepatch.c b/xen/arch/arm/arm64/livepatch.c
new file mode 100644
index 000..49eb69b
--- /dev/null
+++ b/xen/arch/arm/arm64/livepatch.c
[...]
+int arch_livepatch_perform_rela(struct livepatch_elf
>>> On 14.09.16 at 19:37, wrote:
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -270,7 +270,9 @@ If set, override Xen's default choice for the platform
> timer.
> Having TSC as platform timer requires being explicitly set. This is because
> TSC can
On 19/09/16 11:22, Vitaly Kuznetsov wrote:
> David Miller writes:
>
>> From: Vitaly Kuznetsov
>> Date: Fri, 16 Sep 2016 12:59:14 +0200
>>
>>> @@ -595,6 +596,19 @@ static int xennet_start_xmit(struct sk_buff *skb,
>>> struct net_device *dev)
>>> offset = offset_in_page(skb->data);
>>> le
On 19/09/16 11:06, Julien Grall wrote:
> Hi George,
>
> On 19/09/2016 11:45, George Dunlap wrote:
>> On Mon, Sep 19, 2016 at 9:53 AM, Julien Grall
>> wrote:
> As mentioned in the mail you pointed above, this series is not
> enough to
> make
> big.LITTLE working on then. Xen is alw
Small packet loss is reported on complex multi host network configurations
including tunnels, NAT, ... My investigation led me to the following check
in netback which drops packets:
if (unlikely(txreq.size < ETH_HLEN)) {
netdev_err(queue->vif->dev,
David Vrabel writes:
> On 19/09/16 11:22, Vitaly Kuznetsov wrote:
>> David Miller writes:
>>
>>> From: Vitaly Kuznetsov
>>> Date: Fri, 16 Sep 2016 12:59:14 +0200
>>>
@@ -595,6 +596,19 @@ static int xennet_start_xmit(struct sk_buff *skb,
struct net_device *dev)
offset = offse
On Mon, Sep 19, 2016 at 10:37:30AM +0100, Ian Jackson wrote:
> osstest service owner writes ("[xtf test] 100874: all pass - PUSHED"):
> > flight 100874 xtf real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/100874/
> >
> > Perfect :-)
>
> Hooray. I see this is running in xen-unstab
Hi all
In order to make things clearer: this seems to be a problem in upstream
EDK2. Xen Project only tracks upstream, no additional patch is added on
top.
So, I deleted the irrelevant bits below.
On Sun, Sep 18, 2016 at 03:38:19AM +, Chen, Farrah wrote:
> I also tried:
>
> git clone https
Small packet loss is reported on complex multi host network configurations
including tunnels, NAT, ... My investigation led me to the following check
in netback which drops packets:
if (unlikely(txreq.size < ETH_HLEN)) {
netdev_err(queue->vif->dev,
>>> On 19.09.16 at 12:42, wrote:
> On Mon, Sep 19, 2016 at 10:37:30AM +0100, Ian Jackson wrote:
>> The log says:
>>PV superpage support not detected
>>
>> I assume this is not a missing hardware feature, but rather a missing
>> build option or something ?
>>
>> https://wiki.xenproject.org/wi
On 09/18/16 05:38, Chen, Farrah wrote:
> Hi,
>
> When I compile xen with the latest commit in RHEL 6.7, it failed when make
> tools. Errors showed when running edk2 build for OvmfPkgX64.
> Bisected and this error occurred from commit
> 8c8b6fb02342f7aa78e611a5f0f63dcf8fbf48f2.
>
> commit 8c8b6f
On Mon, Sep 19, 2016 at 04:56:01AM -0600, Jan Beulich wrote:
> >>> On 19.09.16 at 12:42, wrote:
> > On Mon, Sep 19, 2016 at 10:37:30AM +0100, Ian Jackson wrote:
> >> The log says:
> >>PV superpage support not detected
> >>
> >> I assume this is not a missing hardware feature, but rather a mis
>>> On 16.09.16 at 22:43, wrote:
> On Mon, Sep 12, 2016 at 10:18:16PM +0200, Daniel Kiper wrote:
>> Currently ELF end of image address is calculated using first line from
>> "nm -nr xen/xen-syms" output. However, today usually it contains random
>> symbol address not related to end of image in any
On Mon, Sep 19, 2016 at 09:29:46AM +, Olaf Hering wrote:
> Fix commit f6d4cf5 ("docs: document old SUSE/Novell unplug for HVM").
> The values which VMDP used to control either NIC or disk are flipped.
> What the code does is:
>
> case 8:
> if (val == 1 ) {
> ide_un
On Fri, Sep 16, 2016 at 04:43:21PM -0400, Konrad Rzeszutek Wilk wrote:
> On Mon, Sep 12, 2016 at 10:18:16PM +0200, Daniel Kiper wrote:
> > Currently ELF end of image address is calculated using first line from
> > "nm -nr xen/xen-syms" output. However, today usually it contains random
> > symbol ad
>>> On 12.09.16 at 22:18, wrote:
> -multiboot_info_t __stdcall *reloc(multiboot_info_t *mbi_old, u32 trampoline)
> +multiboot_info_t __stdcall *reloc(u32 mbi_old, u32 trampoline)
> {
> multiboot_info_t *mbi;
> int i;
>
> alloc = trampoline;
>
> -mbi = reloc_mbi_struct(mbi_o
On Mon, Sep 19, 2016 at 12:16:06PM +0100, Wei Liu wrote:
> On Mon, Sep 19, 2016 at 09:29:46AM +, Olaf Hering wrote:
> > Fix commit f6d4cf5 ("docs: document old SUSE/Novell unplug for HVM").
> > The values which VMDP used to control either NIC or disk are flipped.
> > What the code does is:
> >
flight 101009 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101009/
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
Wei Liu writes ("[PATCH v2] libs/gnttab: introduce XENGNTTAB_BUILD_BUG_ON"):
> The implementation is taken from libxc.
...
> I could have put it in a header file accessible to all libraries under
> libs but this construct is only relevant to xengnttab library at the
> moment so it's put under gntta
>>> On 12.09.16 at 22:18, wrote:
> @@ -65,13 +82,11 @@ static u32 copy_string(u32 src)
> return copy_mem(src, p - src + 1);
> }
>
> -multiboot_info_t __stdcall *reloc(u32 mbi_in, u32 trampoline)
> +static multiboot_info_t *mbi_mbi(u32 mbi_in)
This is rather unhelpful a name - how about mb
>>> On 12.09.16 at 22:18, wrote:
> --- a/xen/arch/x86/domain_page.c
> +++ b/xen/arch/x86/domain_page.c
> @@ -36,7 +36,7 @@ static inline struct vcpu *mapcache_current_vcpu(void)
> * domain's page tables but current may point at another domain's VCPU.
> * Return NULL as though current i
>>> On 12.09.16 at 22:18, wrote:
> ..nor EFI platforms with runtime services enabled.
>
> Suggested-by: Jan Beulich
> Signed-off-by: Daniel Kiper
Acked-by: Jan Beulich
Albeit I think the title/description is now not really fitting the
single efi_enabled() check anymore.
Jan
>>> On 12.09.16 at 22:18, wrote:
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -520,6 +520,8 @@ static void noinline init_done(void)
>
> system_state = SYS_STATE_active;
>
> +free_ebmalloc_unused_mem();
Now that the allocator properly lives in common code, this appea
>>> On 12.09.16 at 22:18, wrote:
> --- a/xen/arch/x86/efi/stub.c
> +++ b/xen/arch/x86/efi/stub.c
> @@ -3,6 +3,43 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/*
> + * Here we are in EFI stub. EFI calls are not suppor
With the planned support of HVM USB passthrough via the USB emulation
capabilities of qemu libxl has to support guest devices which have no
back- and frontend. Information about those devices will live in the
libxl part of Xenstore only.
Add some basic support to libxl to be able to cope with this
In case of failure when trying to add a new USB controller to a domain
libxl might leak xenstore entries. Add a function to remove them and
call this function in case of failure.
Signed-off-by: Juergen Gross
---
This patch might be a backport candidate to 4.7 (will have to modify
tools/libxl/libx
Add the capability to pass USB devices to HVM domains by using the
emulation of USB controllers of qemu.
The user interface via xl is the same as for pvusb passthrough, only
the type of the usbctrl is different: instead of "qusb" (qemu-based
pvusb backend) or "vusb" (kernel-based pvusb backend) th
Add HVM usb passthrough support to libxl by using qemu's capability
to emulate standard USB controllers.
A USB controller is added via qmp command to the emulated hardware
when a usbctrl device of type DEVICEMODEL is requested. Depending on
the requested speed the appropriate hardware type is sele
Update the man page regarding passthrough of USB devices to HVM
domains via qemu USB emulation.
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
docs/man/xl.cfg.pod.5.in | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg
>>> On 12.09.16 at 22:18, wrote:
> --- a/xen/arch/x86/boot/Makefile
> +++ b/xen/arch/x86/boot/Makefile
> @@ -1,9 +1,16 @@
> obj-bin-y += head.o
>
> -RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h
> $(BASEDIR)/include/xen/multiboot.h \
> +DEFS_H_DEPS = $(BASEDIR)/include/xen/stdbool.h
> +
> +
On Mon, Sep 19, 2016 at 12:41:47PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH v2] libs/gnttab: introduce XENGNTTAB_BUILD_BUG_ON"):
> > The implementation is taken from libxc.
> ...
> > I could have put it in a header file accessible to all libraries under
> > libs but this construct is onl
>>> On 12.09.16 at 22:18, wrote:
> --- a/xen/arch/x86/Rules.mk
> +++ b/xen/arch/x86/Rules.mk
> @@ -1,6 +1,10 @@
>
> # x86-specific definitions
>
> +XEN_IMG_OFFSET = 0x20
Please prefer := for simple assignments like this one.
> +CFLAGS += -DXEN_IMG
>>> On 12.09.16 at 22:18, wrote:
> ..calculating its value during runtime.
>
> Signed-off-by: Daniel Kiper
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Hello Julien,
On Mon, Sep 19, 2016 at 10:53:56AM +0200, Julien Grall wrote:
>Hello,
>
>On 19/09/2016 10:36, Peng Fan wrote:
>>On Mon, Sep 19, 2016 at 10:09:06AM +0200, Julien Grall wrote:
>>>Hello Peng,
>>>
>>>On 19/09/2016 04:08, van.free...@gmail.com wrote:
From: Peng Fan
This patch
On Mon, Sep 19, 2016 at 12:52:39AM -0500, Suravee Suthikulpanit wrote:
> GITHUB
> ==
> Latest git tree can be found at:
> http://github.com/ssuthiku/xen.gitxen_avic_part1_v1
>
> OVERVIEW
>
> This patch set is the first of the two-part patch series to introduce
> the new AMD A
Hello Konrad,
On 16/09/2016 18:38, Konrad Rzeszutek Wilk wrote:
If the distance is too great 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 uncondition
On Mon, Sep 19, 2016 at 11:59:05AM +0200, Julien Grall wrote:
>
>
>On 19/09/2016 11:38, Peng Fan wrote:
>>On Mon, Sep 19, 2016 at 10:53:56AM +0200, Julien Grall wrote:
>>>Hello,
>>>
>>>On 19/09/2016 10:36, Peng Fan wrote:
On Mon, Sep 19, 2016 at 10:09:06AM +0200, Julien Grall wrote:
>Hello
On Mon, Sep 19, 2016 at 11:42:05AM +0100, Wei Liu wrote:
> On Mon, Sep 19, 2016 at 10:37:30AM +0100, Ian Jackson wrote:
> > osstest service owner writes ("[xtf test] 100874: all pass - PUSHED"):
> > > flight 100874 xtf real [real]
> > > http://logs.test-lab.xenproject.org/osstest/logs/100874/
> > >
On Mon, Sep 19, 2016 at 11:33:58AM +0100, George Dunlap wrote:
>On 19/09/16 11:06, Julien Grall wrote:
>> Hi George,
>>
>> On 19/09/2016 11:45, George Dunlap wrote:
>>> On Mon, Sep 19, 2016 at 9:53 AM, Julien Grall
>>> wrote:
>> As mentioned in the mail you pointed above, this series is not
>
Hi,
On 19/09/2016 11:27, Jan Beulich wrote:
On 16.09.16 at 18:38, wrote:
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -117,6 +117,20 @@ bool arch_livepatch_symbol_ok(const struct livepatch_elf
*elf,
return true;
}
+bool arch_livepatch_symbol_deny(const struct livepa
Hi Konrad,
On 16/09/2016 18:38, Konrad Rzeszutek Wilk wrote:
/* Our replacement function for xen_extra_version. */
const char *xen_hello_world(void)
{
+#ifdef CONFIG_X86
unsigned long tmp;
int rc;
@@ -24,7 +27,10 @@ const char *xen_hello_world(void)
*/
rc = __get_user(tm
Wei Liu writes ("Re: [Xen-devel] [xtf test] 100874: all pass - PUSHED"):
> On Mon, Sep 19, 2016 at 04:56:01AM -0600, Jan Beulich wrote:
> > I guess the respective command line option ("allowsuperpage") was
> > not given?
>
> Correct, that option is not given in osstest.
It should be, in the XTF t
Hi Konrad,
On 16/09/2016 18:38, Konrad Rzeszutek Wilk wrote:
To use as a common way of testing alternative patching for
livepatches. Both architectures have this FEATURE and the
test-cases can piggyback on that.
Suggested-by: Julien Grall
Signed-off-by: Konrad Rzeszutek Wilk
---
Cc: Julien G
Wei Liu writes ("Re: [PATCH v2] libs/gnttab: introduce XENGNTTAB_BUILD_BUG_ON"):
> AIUI BUILD_BUG_ON is a private thing to each library, hence the
> duplication. But I'm fine with having a central header for that, too.
>
> If we want to share that macro across all libraries, we can create a
> tool
On Mon, Sep 19, 2016 at 02:46:11PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [Xen-devel] [xtf test] 100874: all pass - PUSHED"):
> > On Mon, Sep 19, 2016 at 04:56:01AM -0600, Jan Beulich wrote:
> > > I guess the respective command line option ("allowsuperpage") was
> > > not given?
> >
> >
On Mon, Sep 19, 2016 at 02:49:05PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH v2] libs/gnttab: introduce
> XENGNTTAB_BUILD_BUG_ON"):
> > AIUI BUILD_BUG_ON is a private thing to each library, hence the
> > duplication. But I'm fine with having a central header for that, too.
> >
> > I
On 9/15/2016 10:32 PM, Jan Beulich wrote:
On 15.09.16 at 16:16, wrote:
On 9/13/2016 11:25 PM, Jan Beulich wrote:
Wait - what is do_invalid_op() doing on the stack? I don't think it
belongs there, and hence I wonder whether the keypress
happened after some already fatal event (in which case a
Lars Kurth writes ("Re: [PATCH v2 3/3] Significant changes to decision making;
some new roles and minor changes"):
> I could, but it isn't really that long. And it makes life hard for me, as
> there is only one file. Thus breaking it into bits and maintaining the
> changes is hard in git.
Are you
On Mon, Sep 19, 2016 at 05:14:07AM -0600, Jan Beulich wrote:
> >>> On 16.09.16 at 22:43, wrote:
> > On Mon, Sep 12, 2016 at 10:18:16PM +0200, Daniel Kiper wrote:
> >> Currently ELF end of image address is calculated using first line from
> >> "nm -nr xen/xen-syms" output. However, today usually it
On Mon, Sep 19, 2016 at 02:51:03PM +0100, Wei Liu wrote:
> On Mon, Sep 19, 2016 at 02:46:11PM +0100, Ian Jackson wrote:
> > Wei Liu writes ("Re: [Xen-devel] [xtf test] 100874: all pass - PUSHED"):
> > > On Mon, Sep 19, 2016 at 04:56:01AM -0600, Jan Beulich wrote:
> > > > I guess the respective comm
On Mon, Sep 19, 2016 at 11:26:19AM +0200, Julien Grall wrote:
> Hi Konrad,
>
> On 16/09/2016 18:38, Konrad Rzeszutek Wilk wrote:
> > x86 implements all of them by default - and we just
> > add two extra HAS_ variables to be declared in autoconf.h.
> >
> > ARM 64 only has alternative while ARM 32
Lai, Paul C writes ("trying to get started w/ osstest"):
> I?m looking to get started with osstest and running to some roadblocks.
Thanks for your interest. Sorry for the late response - I've been
away.
> The page https://blog.xenproject.org/2013/02/02/
> xen-automatic-test-system-osstest/ looks
Hi Konrad,
On 19/09/2016 16:04, Konrad Rzeszutek Wilk wrote:
On Mon, Sep 19, 2016 at 11:26:19AM +0200, Julien Grall wrote:
Hi Konrad,
On 16/09/2016 18:38, Konrad Rzeszutek Wilk wrote:
x86 implements all of them by default - and we just
add two extra HAS_ variables to be declared in autoconf.h
>>> On 19.09.16 at 15:33, wrote:
> Hi,
>
> On 19/09/2016 11:27, Jan Beulich wrote:
> On 16.09.16 at 18:38, wrote:
>>> --- a/xen/arch/arm/livepatch.c
>>> +++ b/xen/arch/arm/livepatch.c
>>> @@ -117,6 +117,20 @@ bool arch_livepatch_symbol_ok(const struct
>>> livepatch_elf
> *elf,
>>> ret
On 19/09/2016 16:11, Jan Beulich wrote:
On 19.09.16 at 15:33, wrote:
On 19/09/2016 11:27, Jan Beulich wrote:
On 16.09.16 at 18:38, wrote:
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -117,6 +117,20 @@ bool arch_livepatch_symbol_ok(const struct livepatch_elf
*elf,
Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [xtf test] 100874: all pass -
PUSHED"):
> On Mon, Sep 19, 2016 at 02:51:03PM +0100, Wei Liu wrote:
> > ... depends on the security support status of that particular
> > feature.
>
> To enable it you had to provide the 'allowsuperpage' parameter so by
On Mon, Sep 19, 2016 at 11:35:57AM +0200, Julien Grall wrote:
> Hi Konrad,
>
> On 16/09/2016 18:38, Konrad Rzeszutek Wilk wrote:
> > The current byte sequence is '0xcc' which makes sense on x86,
> > but on ARM it is:
> >
> > stclgt 12, cr12, [ip], {204} ; 0xcc
> >
> > Picking
On Mon, Sep 19, 2016 at 05:58:46AM -0600, Jan Beulich wrote:
> >>> On 12.09.16 at 22:18, wrote:
> > --- a/xen/arch/x86/domain_page.c
> > +++ b/xen/arch/x86/domain_page.c
> > @@ -36,7 +36,7 @@ static inline struct vcpu *mapcache_current_vcpu(void)
> > * domain's page tables but current may po
Wei Liu writes ("[PATCH 3/5] xen: replace TEST_COVERAGE with CONFIG_GCOV"):
> The sole purpose of TEST_COVERAGE macro is to guard the availability of
> gcov sysctl. Now we have a proper CONFIG_GCOV, use it.
FAOD my reading of xen/Kconfig.debug is that CONFIG_GCOV depends on
CONFIG_DEBUG which says
flight 101011 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101011/
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
>
> > void arch_livepatch_revive(void)
> > {
> > +/*
> > + * Nuke the instruction cache. Data cache has been cleaned before in
> > + * arch_livepatch_apply_jmp.
>
> I think you forgot to clean text region from the payload. Without that, you
> may receive a crash if you have a separa
On 19/09/2016 16:34, Julien Grall wrote:
Hi Konrad,
On 16/09/2016 18:38, Konrad Rzeszutek Wilk wrote:
Most of the WARN_ON or BUG_ON sections are properly aligned on
x86. However on ARM and on x86 assembler the macros don't include
any aligment information - hence they end up being the default
Hi Konrad,
On 16/09/2016 18:38, Konrad Rzeszutek Wilk wrote:
Most of the WARN_ON or BUG_ON sections are properly aligned on
x86. However on ARM and on x86 assembler the macros don't include
any aligment information - hence they end up being the default
s/aligment/alignment/
byte granularity.
Hello Konrad,
On 16/09/2016 18:38, Konrad Rzeszutek Wilk wrote:
The patch piggybacks on: livepatch: Initial ARM64 support, which
brings up all of the neccessary livepatch infrastructure pieces in.
s/neccessary/necessary/
This patch adds three major pieces:
1) ELF relocations. ARM32 uses S
1 - 100 of 218 matches
Mail list logo
