On 09/15/16 20:08, Razvan Cojocaru wrote:
> On 09/15/16 19:36, Tamas K Lengyel wrote:
>> On Wed, Sep 14, 2016 at 1:58 AM, Razvan Cojocaru
>> wrote:
>>> On 09/13/2016 09:12 PM, Tamas K Lengyel wrote:
When emulating instructions the emulator maintains a small i-cache fetched
from the guest
On 09/15/16 21:24, Tamas K Lengyel wrote:
> The ARM SMC instructions are already configured to trap to Xen by default. In
> this patch we allow a user-space process in a privileged domain to receive
> notification of when such event happens through the vm_event subsystem by
> introducing the PRIVIL
On Wed, Sep 14, Stefano Stabellini wrote:
> Written like this, the code will unplug any Xen SCSI disks together with
> Xen IDE disks when the guest writes "1" to ioport `0x10`. I am sorry to
> be pedantic, but the recent changes introduced to
> docs/misc/hvm-emulated-unplug.markdown do not cover a
On Wed, Sep 14, Stefano Stabellini wrote:
> The doc says:
>
> "If VMDP was configured to control just NIC devices it would write the
> value 0x1 to offset 0x8. If VMDP was configured to control just storage
> devices it would write the value 0x2 to offset 0x8."
>
> So 0x1 to 0x8 to unplug NICs,
On Thu, 15 Sep 2016, Kyle Huey wrote:
First of all, please add a cover letter [PATCH 0/N] to your patch series
and send it with something which provides proper mail threading.
See: git-send-email, quilt
> arch_prctl is currently 64-bit only. Wire it up for 32-bits, as a no-op for
> now. Rename
flight 100975 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100975/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 100966
Regressions which
flight 100980 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100980/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-buildfail REGR. vs. 100962
Tests which did not suc
On 09/15/2016 05:38 PM, Wei Liu wrote:
On Thu, Sep 08, 2016 at 09:20:25AM +0200, Juergen Gross wrote:
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
On 16/09/16 07:32, Jan Beulich wrote:
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) writes of zero. If ever there will be bits we
can safely expos
>>> On 16.09.16 at 11:46, wrote:
> On 16/09/16 07:32, Jan Beulich wrote:
>> 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) writes of zero
On Thu, 15 Sep 2016, Kyle Huey wrote:
Please use proper prefixes for your patch:
git-log arch/x86/kernel/cpu/scattered.c will give you the hint:
x86/cpufeature: Move some of the scattered feature bits to x86_capability
x86/cpufeature: Correct spelling of the HWP_NOTIFY flag
and make the subject
> > +/*
> > + * MEMF_no_tlbflush can be set only during vm creation phase when
> > + * is_ever_unpaused is still false before this domain gets unpaused for
> > + * the first time.
> > + */
> > +if ( unlikely(!d->is_ever_unpaused) )
> > +a->memflags |= MEMF_no_tlbflus
On Fri, Sep 16, 2016 at 03:47:23AM -0700, Dongli Zhang wrote:
> > > +/*
> > > + * MEMF_no_tlbflush can be set only during vm creation phase when
> > > + * is_ever_unpaused is still false before this domain gets unpaused
> > > for
> > > + * the first time.
> > > + */
> > > +
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 Fri, Sep 16, 2016 at 10:51:18AM +0200, Juergen Groß wrote:
> On 09/15/2016 05:38 PM, Wei Liu wrote:
> >On Thu, Sep 08, 2016 at 09:20:25AM +0200, Juergen Gross wrote:
> >>Add HVM usb passthrough support to libxl by using qemu's capability
> >>to emulate standard USB controllers.
> >>
> >>A USB co
On Thu, Sep 15, 2016 at 05:10:46PM +0200, Filipe Manco wrote:
> In case of error during netback_probe() (e.g. an entry missing on the
> xenstore) netback_remove() is called on the new device, which will set
> the device backend state to XenbusStateClosed by calling
> set_backend_state(). However, t
> What is the scenario that you would want toolstack to set such flag?
>
> Shouldn't hypervisor always set the flag when the guest is never
> unpaused and always clear / ignore that flag if the guest is ever
> unpaused? If that's all is needed, why does toolstack need to get
> involved?
You are r
>>> On 14.09.16 at 10:23, wrote:
> Starting from the beginning it looks that there are "soft" limits enforced
> in BIOS early boot code looking for usable low memory region. Hight limit
> is set at 640 KiB and low at 256 KiB. This means that if a value from a given
> source which describes low mem
Hello Peng,
On 12/09/2016 11:43, Peng Fan wrote:
According to Linux Kernel, Documentation/arm64/booting.txt
"
When image_size is zero, a bootloader should attempt to keep as much
memory as possible free for use by the kernel immediately after the
end of the kernel image. The amount of space requ
On 09/16/2016 02:45 AM, Jan Beulich wrote:
>
>>> And then there's the question of whether excluding things from the
>>> build, but having them present in the sources actually helps.
>> The main reason for this whole relicensing debacle is to prevent non-GPL
>> binaries from linking against GPL obje
flight 100982 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100982/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-rtds 11 guest-start fail in 100973 pass in 100982
test-armhf-armhf-xl-vhd 9
Hi Konrad,
On 11/09/2016 22:35, 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.
Signed-off-by: Konrad Rzeszutek Wilk
FWIW:
Hi all,
the first batch of Xen Project Developer Summit Videos are available. There are
a few videos missing, which have some issues that still need to be fixed, but
that shouldn't take too long. You can see what is uploaded and available t
https://www.youtube.com/playlist?list=PLYyw7IQjL-zEcw-
Hi Konrad,
On 11/09/2016 22:35, Konrad Rzeszutek Wilk wrote:
The implementation on x86 always returns zero, but
other platforms may return error values.
Reviewed-by: Andrew Cooper
Suggested-by: Julien Grall
Signed-off-by: Konrad Rzeszutek Wilk
For the ARM bits:
Reviewed-by: Julien Grall
flight 67722 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67722/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-amd64-jessie-netboot-pvgrub 10 guest-startfail like 67680
Tests which did
Hi Konrad,
On 11/09/2016 22:35, 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
Whilst I agre
Hi Konrad,
On 11/09/2016 22:35, Konrad Rzeszutek Wilk wrote:
v2: [http://www.gossamer-threads.com/lists/xen/devel/61?page=last]
- Addressed the two outstanding concerns: CPU bit feature to test alternative
test-case, and errata #843419 on some Cortex-A53
I am a bit confused. I haven't
On Fri, Sep 16, 2016 at 03:35:21PM +0200, Julien Grall wrote:
> Hi Konrad,
>
> On 11/09/2016 22:35, Konrad Rzeszutek Wilk wrote:
> > v2: [http://www.gossamer-threads.com/lists/xen/devel/61?page=last]
> > - Addressed the two outstanding concerns: CPU bit feature to test
> > alternative
> >
On 16/09/2016 15:41, Konrad Rzeszutek Wilk wrote:
On Fri, Sep 16, 2016 at 03:35:21PM +0200, Julien Grall wrote:
Hi Konrad,
On 11/09/2016 22:35, Konrad Rzeszutek Wilk wrote:
v2: [http://www.gossamer-threads.com/lists/xen/devel/61?page=last]
- Addressed the two outstanding concerns: CPU b
Hi Tamas,
On 15/09/2016 20:24, Tamas K Lengyel wrote:
The ARM SMC instructions are already configured to trap to Xen by default. In
this patch we allow a user-space process in a privileged domain to receive
notification of when such event happens through the vm_event subsystem by
introducing the
flight 100984 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100984/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 5 xen-buildfail REGR. vs. 100966
test-armhf-armhf-
Hi Edgar,
On 07/09/2016 08:56, Edgar E. Iglesias wrote:
From: "Edgar E. Iglesias"
Add support for describing normal non-cacheable memory.
Signed-off-by: Edgar E. Iglesias
---
xen/arch/arm/p2m.c | 18 ++
xen/include/asm-arm/p2m.h | 1 +
xen/include/asm-arm/page.h |
Hi Edgar,
On 07/09/2016 08:56, Edgar E. Iglesias wrote:
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/do
Hi Edgar,
On 07/09/2016 08:56, Edgar E. Iglesias wrote:
From: "Edgar E. Iglesias"
Make dt_match_node match for existing properties.
We only search for the existence of the properties, not
for specific values.
Signed-off-by: Edgar E. Iglesias
---
xen/common/device_tree.c | 5 -
xen/
Hi Edgar,
On 07/09/2016 08:56, Edgar E. Iglesias wrote:
From: "Edgar E. Iglesias"
Add plumbing for passing around mapping attributes. This
is in preparation to allow us to differentiate the attributes
for specific device nodes.
We still use the same DEVICE mappings for all nodes so this
patch
Hi Edgar,
On 07/09/2016 08:56, Edgar E. Iglesias wrote:
From: "Edgar E. Iglesias"
Add support for describing normal non-cacheable memory.
I am a bit confused, you introduced this new p2m type but I don't see
any usage of it in this series. Is it expected?
Regards,
Signed-off-by: Edgar
On Fri, Sep 16, 2016 at 03:45:12PM +0200, Julien Grall wrote:
>
>
> On 16/09/2016 15:41, Konrad Rzeszutek Wilk wrote:
> > On Fri, Sep 16, 2016 at 03:35:21PM +0200, Julien Grall wrote:
> > > Hi Konrad,
> > >
> > > On 11/09/2016 22:35, Konrad Rzeszutek Wilk wrote:
> > > > v2: [http://www.gossamer-
On 16/09/2016 16:35, Konrad Rzeszutek Wilk wrote:
On Fri, Sep 16, 2016 at 03:45:12PM +0200, Julien Grall wrote:
On 16/09/2016 15:41, Konrad Rzeszutek Wilk wrote:
On Fri, Sep 16, 2016 at 03:35:21PM +0200, Julien Grall wrote:
Hi Konrad,
On 11/09/2016 22:35, Konrad Rzeszutek Wilk wrote:
v2:
On Mon, Sep 05, 2016 at 06:13:59AM -0400, Kyle Temkin wrote:
> From: "Kyle J. Temkin"
>
> Tegra devices have a legacy interrupt controller (lic, or ictlr) that
> must be programmed in parallel with their primary GIC. For all intents
> and purposes, we treat this devices attached to this controlle
On Mon, Sep 05, 2016 at 06:14:00AM -0400, Kyle Temkin wrote:
> From: "Kyle J. Temkin"
>
> The addition of new IRQ-related platform hooks now allow platforms to
> perform platform-specific interrupt logic; allowing e.g. virtualization
> of platform-specific interrupt controller hardware.
>
> This
On Fri, Sep 16, 2016 at 04:21:12PM +0200, Julien Grall wrote:
> Hi Edgar,
Hi Julien,
Thanks for the review!
> On 07/09/2016 08:56, Edgar E. Iglesias wrote:
> >From: "Edgar E. Iglesias"
> >
> >Add support for describing normal non-cacheable memory.
> >
> >Signed-off-by: Edgar E. Iglesias
> >---
On 16/09/2016 13:41, "Boris Ostrovsky" wrote:
>On 09/16/2016 02:45 AM, Jan Beulich wrote:
>>
And then there's the question of whether excluding things from the
build, but having them present in the sources actually helps.
>>> The main reason for this whole relicensing debacle is to pr
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 are assumed
to always contain zero value but n
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
---
Cc: Andrew Cooper
Cc: Jan Beulich
v3: First submission (as part of the ARM 32 and 64 support of Livepatc
As currently during the injection of the build-id it ends up
being marked as AW. We want it to be read-only.
Signed-off-by: Konrad Rzeszutek Wilk
---
Cc: Andrew Cooper
Cc: Jan Beulich
v6: New submission.
---
xen/arch/x86/test/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Hey!
Since v5:[https://lists.xen.org/archives/html/xen-devel/2016-09/msg01114.html]
- Acted on the review comments.
- Replaced "livepatch/docs: Document .bss not being cleared, and .data
potentially
having changed values" with "livepatch: Disallow applying after an revert"
- Added two mino
From: Ross Lagerwall
Add hook functions which run during patch apply and patch revert.
Hook functions are used by livepatch payloads to manipulate data
structures during patching, etc.
One use case is the XSA91. As Martin mentions it:
"If we have shadow variables, we also need an unload hook to
The initial patch: 11ff40fa7bb5fdcc69a58d0fec49c904ffca4793
"xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op" caps the
size of the binary at 2MB. We follow that in capping the size
of the .BSSes to be at maximum 2MB.
Reviewed-by: Ross Lagerwall
Signed-off-by: Konrad Rzeszutek Wilk
---
C
The NOP functionality will NOP any of the code at
the 'old_addr' or at 'name' if the 'new_addr' is zero.
The purpose of this is to NOP out calls, such as:
e8 <4-bytes-offset>
(5 byte insn), or on ARM a 4 byte insn for branching.
We need the EIP of where we need to the NOP, and that can
be provi
On Fri, Sep 16, 2016 at 04:24:17PM +0200, Julien Grall wrote:
> Hi Edgar,
>
> On 07/09/2016 08:56, Edgar E. Iglesias wrote:
> >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 argumen
flight 100987 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100987/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100898
test-amd64-amd64-xl-qemuu-win7-a
On Fri, Sep 16, 2016 at 1:21 AM, Razvan Cojocaru
wrote:
> On 09/15/16 20:08, Razvan Cojocaru wrote:
>> On 09/15/16 19:36, Tamas K Lengyel wrote:
>>> On Wed, Sep 14, 2016 at 1:58 AM, Razvan Cojocaru
>>> wrote:
On 09/13/2016 09:12 PM, Tamas K Lengyel wrote:
> When emulating instructions th
On Fri, Sep 16, 2016 at 04:28:20PM +0200, Julien Grall wrote:
> Hi Edgar,
>
> On 07/09/2016 08:56, Edgar E. Iglesias wrote:
> >From: "Edgar E. Iglesias"
> >
> >Make dt_match_node match for existing properties.
> >We only search for the existence of the properties, not
> >for specific values.
> >
On Fri, Sep 16, 2016 at 7:54 AM, Julien Grall wrote:
> Hi Tamas,
>
> On 15/09/2016 20:24, Tamas K Lengyel wrote:
>>
>> The ARM SMC instructions are already configured to trap to Xen by default.
>> In
>> this patch we allow a user-space process in a privileged domain to receive
>> notification of w
On Thu, Sep 15, 2016 at 11:32 PM, Jan Beulich wrote:
> 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) writes of zero. If ever there will be b
On Fri, Sep 16, 2016 at 04:34:36PM +0200, Julien Grall wrote:
> Hi Edgar,
>
> On 07/09/2016 08:56, Edgar E. Iglesias wrote:
> >From: "Edgar E. Iglesias"
> >
> >Add support for describing normal non-cacheable memory.
>
> I am a bit confused, you introduced this new p2m type but I don't see any
>
On Fri, Sep 16, 2016 at 12:50 AM, Thomas Gleixner wrote:
> On Thu, 15 Sep 2016, Kyle Huey wrote:
>
> First of all, please add a cover letter [PATCH 0/N] to your patch series
> and send it with something which provides proper mail threading.
> See: git-send-email, quilt
I did ... seems like using
On Fri, Sep 16, 2016 at 04:31:20PM +0200, Julien Grall wrote:
> Hi Edgar,
>
> On 07/09/2016 08:56, Edgar E. Iglesias wrote:
> >From: "Edgar E. Iglesias"
> >
> >Add plumbing for passing around mapping attributes. This
> >is in preparation to allow us to differentiate the attributes
> >for specific
On Fri, 2016-09-16 at 10:49 +0800, Wei Yang wrote:
> On Wed, Sep 14, 2016 at 06:18:48PM +0200, Dario Faggioli wrote:
> > On Wed, 2016-09-14 at 18:44 +0800, Wei Yang wrote:
> > If the system is not overbooked, it's a bit strange that the
> > scheduler
> > is the bottleneck.
> I looked at the origina
On 09/16/16 18:37, Tamas K Lengyel wrote:
> Since this breaks compilation of existing clients, I think we should
> increment some macro to alow for compile-time switching (maybe
> VM_EVENT_INTERFACE_VERSION?).
>>>
>>> I'm not sure I follow - this is a Xen internal-on
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:
> >From: "Edgar E. Iglesias"
> >
> >Add support for describing normal non-cacheable memory.
> >
> >Signed-off-by: Edgar E. Iglesias
> >---
> > xen/arch/arm/p2m.c |
On 09/16/2016 11:22 AM, Lars Kurth wrote:
>
> On 16/09/2016 13:41, "Boris Ostrovsky" wrote:
>
>> On 09/16/2016 02:45 AM, Jan Beulich wrote:
> And then there's the question of whether excluding things from the
> build, but having them present in the sources actually helps.
The main rea
Hey!
Since v3: [https://lists.xen.org/archives/html/xen-devel/2016-09/msg01127.html]
- Addressed Jan's comment (most are renaming)
- Addressed Julien's and Jan's idea of HAS_ALTERNATIVE
- Addressed Julien's review comments of "arm: poison initmem when it is freed."
v2: [http://www.gossamer-thr
The patch piggybacks on: livepatch: Initial ARM64 support, which
brings up all of the neccessary livepatch infrastructure pieces in.
This patch adds three major pieces:
1) ELF relocations. ARM32 uses SHT_REL instead of SHT_RELA which
means the adddendum had to be extracted from within the
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 Rzeszutek Wilk
---
Cc: Stefano Stabellini
Cc: Julien Grall
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 crash if one executes that code:
(XEN) CPU1: Unexpected Trap: S
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 Grall
Cc: Stefano Stabellini
Cc: Jan Beulich
Cc: Andrew Cooper
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.
Suggested-by: Julien Grall
Signed-off-by: Konr
It is exactly the same in both platforms.
No functional change.
Signed-off-by: Konrad Rzeszutek Wilk
---
Cc: Julien Grall
Cc: Stefano Stabellini
v3: New submission.
v4: s/arch_livepatch_insn_len/livepatch_insn_len/
s/PATCH_INSN_SIZE/ARCH_PATCH_INSN_SIZE/
---
xen/arch/arm/arm32/livepatch.
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' can show the example livepatches.
Acked-by: Jan Beulich
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 is word-size (4)
otherwise if one tries to us
As compared to x86 the va of the hypervisor .text
is locked down - we cannot modify the running pagetables
to have the .ro flag unset. We borrow the same idea that
alternative patching has - which is to vmap the entire
.text region and use the alternative virtual address
for patching.
Since we are
We need to two things:
1) Wrap the platform-specific objcopy parameters in defines
The input and output parameters for $(OBJCOPY) are different
based on the platforms. As such provide them in the
OBJCOPY_MAGIC define and use that.
2) The alternative is a bit different and there are no
The test-case is quite simple - we NOP the 'xen_minor_version'.
The amount of NOPs depends on the architecture.
On x86 the function is 11 bytes long:
55 push %rbp <- NOP
48 89 e5mov%rsp,%rbp <- NOP
b8 04 00 00 00 mov$0x4,%eax <
As they are not needed for the livepatch to work.
Also this allows us to properly test:
"livepatch: Disallow applying after an revert" as the livepatch
will now only have the minimalistic sections:
Section Headers:
[Nr] Name Type Address Offset
Size
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 ignore these symbols.
Reviewed-by: Andrew Cooper [x86 bits
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 unconditional
branch/jump varies. ARM32 is +/- 32MB, ARM64 is +/- 128MB while
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 (such as
add an veneer). But more importantly - we do not
On Fri, Sep 16, 2016 at 12:38:20PM -0400, 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
>> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
>> index 39a05fd..cf58fd5 100644
>> --- a/xen/arch/arm/traps.c
>> +++ b/xen/arch/arm/traps.c
>> @@ -41,6 +41,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "decode.h"
>> #include "vtimer.h"
>> @@ -2527,6 +252
flight 100991 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100991/
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
The ARM SMC instructions are already configured to trap to Xen by default. In
this patch we allow a user-space process in a privileged domain to receive
notification of when such event happens through the vm_event subsystem by
introducing the PRIVILEGED_CALL type.
The intended use-case for this fe
This run is configured for baseline tests only.
flight 67721 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67721/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm 15 guest-start/deb
flight 100989 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100989/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-xsm 3 host-install(3)broken REGR. vs. 1009
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 way. So, it looks
Weird. The -n says:
I have spent some time investigating a case where qemu is failing to
register xenstore watches for a PV guest once I enable vfb (and
thereby triggering the creation of a qemu instance).
The qemu logs show something along the lines of:
xen be core: xen be core: xen be: watching backend path
(backen
This run is configured for baseline tests only.
flight 67723 seabios real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67723/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop
Hi, all,
I have been following the instructions at
https://wiki.linaro.org/LEG/Engineering/Virtualization/Xen_on_ARMv8_Foundation
to build xen for arm64.
When I tried to use the latest kernel instead of v3.13 as suggested, I
failed when building boot-wrapped image. See below.
==
flight 100992 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100992/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 100982
test-armhf-armhf-xl-vhd
On Thu, 15 Sep 2016, Julien Grall wrote:
> The back pointer will be usefult later to get the domain when we only
> have the p2m in hand.
>
> Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
> ---
> Changes in v2:
> - Patch added
> ---
> xen/arch/arm/p2m.c| 1 +
>
On Thu, 15 Sep 2016, Julien Grall wrote:
> Currently, a stage-2 fault translation will likely access an emulated
> region. All the checks are pre-sanitity check for MMIO emulation.
>
> A follow-up patch will handle a new case that could lead to a stage-2
> translation. To improve the clarity of th
On Thu, 15 Sep 2016, Julien Grall wrote:
> A data/instruction abort may have occurred if another CPU was playing
> with the stage-2 page table when following the break-before-make
> sequence (see D4.7.1 in ARM DDI 0487A.j). Rather than injecting directly
> the fault to the guest, we need to check w
On Thu, 15 Sep 2016, Julien Grall wrote:
> The level shift can be encoded with 8-bit. So it is not necessary to
> use paddr_t (i.e 64-bit).
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> Changes in v2:
> - Use uint8_t rather than unsigned int
> - R
On Thu, 15 Sep 2016, Julien Grall wrote:
> Mapping the root table is always done the same way. To avoid duplicating
> the code in a later patch, move the code in a separate helper.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> Changes in v2:
> - Use level
On Thu, 15 Sep 2016, Julien Grall wrote:
> Currently, for a given GFN, the function __p2m_lookup will only return
> the associated MFN and the p2m type of the mapping.
>
> In some case we need the order of the mapping and the memaccess
> permission. Rather than providing a separate function for th
On Thu, 15 Sep 2016, Julien Grall wrote:
> The function p2m_cache_flush can be re-implemented using the generic
> function p2m_get_entry by iterating over the range and using the mapping
> order given by the callee.
>
> As the current implementation, no preemption is implemented, although
> the co
flight 100993 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100993/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100966
test-amd64-amd64-xl-rtds
Hi,
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Hi,
Sorry for the blank email previously.
I am trying to modify netback.c in the Linux Kernel and Observe the
changes. I've cloned the latest Linux Kernel with Git, checked out version
4.7.0 and compiled it with the config options listed here:
https://wiki.xenproject.org/wiki/Mainlin
99 matches
Mail list logo
