Hi All,
We are trying to do graphical virtualization in intel® Atom™ E3845(MinnowBoard
Turbot Quad-Core board) using xen.
Is it possible to do graphical virtualization in intel® Atom?
If yes,Could you please suggest what are versions of xen and linux recommended
to use and steps i need to foll
Hi All,
We are trying to do graphical virtualization in intel® Atom™ E3845(MinnowBoard
Turbot Quad-Core board) using xen.
Is it possible to do graphical virtualization in intel® Atom?
If yes,Could you please suggest what are versions of xen and linux recommended
to use and steps i need to foll
flight 112661 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112661/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-xtf-amd64-amd64-4 47 xtf/test-hvm64-lbr-tsx-vmentry fail in 112648 pass
in 112661
test-xtf-amd64-amd64
Hey,
As per Andrew [Cooper]'s suggestion, writing here instead of #xen on
Freenode.
I'm trying out Xen (4.9.0) with OVMF (r21243.3858b4a1ff-1) and having it
crash right on boot both with the 32b and 64b OVMF binaries. This is on
Arch Linux, AMD Ryzen on a X370 motherboard.
Given the follow
Hi all,
Today's linux-next merge of the xen-tip tree got a conflict in:
arch/x86/entry/entry_64.S
between commit:
UNWIND_HINT_IRET_REGS ("x86/entry/64: Add unwind hint annotations")
from the tip tree and commit:
ad5b8c4ba323 ("xen: get rid of paravirt op adjust_exception_frame")
from t
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Saturday, August 12, 2017 12:43 AM
>
> On certain Intel systems, as far as I can tell almost all pre-Haswell ones,
> trying to boot a PVH Dom0 will freeze the box completely, up to the point
> that
> not even the watchdog works. The fre
> From: Roger Pau Monne
> Sent: Saturday, August 12, 2017 12:43 AM
>
> This is emulated by Xen and must not be mapped into PVH Dom0 p2m.
same comment as previous one. please send it separately.
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
> ---
> xen/arch/x
> From: Roger Pau Monne
> Sent: Saturday, August 12, 2017 12:43 AM
>
> They are emulated by Xen, so they must not be mapped into Dom0 p2m.
> Introduce a helper function to add the MMCFG areas to the list of
> denied iomem regions for PVH Dom0.
>
> Signed-off-by: Roger Pau Monné
this patch is a
flight 112658 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112658/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 16 guest-start/debian.repeat fail REGR. vs. 112646
Tests which did n
> From: Roger Pau Monne
> Sent: Saturday, August 12, 2017 12:43 AM
>
> Hello,
>
> Currently iommu_inclusive_mapping is not working for PVH Dom0, this
not working for all platforms or only older boxes? The subject indicates
the former while the later description seems the latter...
> patch
> ser
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, August 11, 2017 9:20 PM
>
> None of the callers really needs the struct page_info pointer.
>
> Signed-off-by: Jan Beulich
> Acked-by: George Dunlap
Reviewed-by: Kevin Tian
___
Xen-devel
On 2017年08月16日 19:21, Paolo Bonzini wrote:
> On 16/08/2017 02:22, Lan Tianyu wrote:
>> Xen vIOMMU device model will be in Xen hypervisor. Skip vIOMMU
>> check for Xen here when vcpu number is more than 255.
>
> I think you still need to do a check for vIOMMU being enabled.
Yes, this will be done
flight 112657 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112657/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 3 capture-logs broken REGR. vs. 112102
Juergen Gross writes:
> Cleanup special cases of paravirt patching:
>
> - Xen doesn't need a custom patching function, it can use
> paravirt_patch_default()
>
> - Remove lguest completely from the tree. A LKML mail asking for any
> users 3 months ago did not reveal any need for keeping lguest
flight 112659 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112659/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a
build-arm64-libvirt 1 build-check(1)
flight 112655 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112655/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-rumprun-i386 17 rumprun-demo-xenstorels/xenstorels.repeat fail
REGR. vs. 112544
test-amd6
flight 112653 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112653/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 7 reboot fail REGR. vs. 110515
test-amd64-amd64-xl
On 08/16/2017 02:23 PM, Andrew Cooper wrote:
> They are only referenced by physical address (either the HSA MSR, or via
> VMSAVE/VMLOAD which take a physical operand). Allocating xenheap hages and
> storing their virtual address is wasteful.
>
> Allocate them with domheap pages instead, taking the
Hello Jan,
On Wed, Aug 09, 2017 at 05:58:19AM -0600, Jan Beulich wrote:
>
> > On 08/08/17 21:08, Volodymyr Babchuk wrote:
> >> +#ifndef __XEN_PUBLIC_ARCH_ARM_SMC_H__
> >> +#define __XEN_PUBLIC_ARCH_ARM_SMC_H__
> >> +
> >> +typedef struct {
> >> +uint32_t a[4];
> >> +} xen_arm_smccc_uid;
>
>
This run is configured for baseline tests only.
flight 71982 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71982/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf af0364f01e8cac95afad01437f13beef90f6640b
baseline v
flight 112670 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112670/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64-pvops 2 hos
On Wed, Aug 16, 2017 at 07:31:56PM +0200, Juergen Gross wrote:
> ENTRY(xen_irq_disable_direct)
> movb $1, PER_CPU_VAR(xen_vcpu_info) + XEN_vcpu_info_mask
> -ENDPATCH(xen_irq_disable_direct)
> ret
> ENDPROC(xen_irq_disable_direct)
> - RELOC(xen_irq_disable_direct, 0)
Might as
Hello all,
This is 4th version of patch series:
* Fixed spelling in comments
* Fixed coding style
Volodymyr Babchuk (3):
arm: processor: add new struct hsr_smc32 into hsr union
arm: traps: handle unknown exceptions in check_conditional_instr()
arm: traps: handle SMC32 in check_conditiona
flight 112656 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112656/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf af0364f01e8cac95afad01437f13beef90f6640b
baseline version:
ovmf a6b3d753f98118ee547ae
On ARMv8 architecture we need to ensure that conditional check was passed
for a trapped SMC instruction that originates from AArch32 state
(ARM DDI 0487B.a page D7-2271).
Thus, we should not skip it while checking HSR.EC value.
For this type of exception special coding of HSR.ISS is used. There is
According to ARM architecture reference manual (ARM DDI 0487B.a page D7-2259,
ARM DDI 0406C.c page B3-1426), exception with unknown reason (HSR.EC == 0)
has no valid bits in HSR (apart from HSR.EC), so we can't check if that was
caused by conditional instruction. We need to assume that it is uncond
On ARMv8, one of conditional exceptions (SMC that originates
from AArch32 state) has extra field in HSR.ISS encoding:
CCKNOWNPASS, bit [19]
Indicates whether the instruction might have failed its condition
code check.
0 - The instruction was unconditional, or was conditional and
passed its
On 07/21/2017 03:26 PM, Stefano Stabellini wrote:
> On Fri, 21 Jul 2017, Arnd Bergmann wrote:
>> __WARN() is an internal helper that is only available on
>> some architectures, but causes a build error e.g. on ARM64
>> in some configurations:
>>
>> drivers/xen/pvcalls-back.c: In function 'set_backe
Instead of scrubbing pages during guest destruction (from
free_heap_pages()) do this opportunistically, from the idle loop.
We might come to scrub_free_pages()from idle loop while another CPU
uses mapcache override, resulting in a fault while trying to do
__map_domain_page() in scrub_one_page(). T
Instead of scrubbing pages while holding heap lock we can mark
buddy's head as being scrubbed and drop the lock temporarily.
If someone (most likely alloc_heap_pages()) tries to access
this chunk it will signal the scrubber to abort scrub by setting
head's BUDDY_SCRUB_ABORT bit. The scrubber checks
This will make code a bit more readable, especially with changes that
will be introduced in subsequent patches.
Signed-off-by: Boris Ostrovsky
Acked-by: Jan Beulich
---
xen/common/page_alloc.c | 139 +++-
1 file changed, 77 insertions(+), 62 deletions
While waiting for a lock we may want to periodically run some
code. This code may, for example, allow the caller to release
resources held by it that are no longer needed in the critical
section protected by the lock.
Specifically, this feature will be needed by scrubbing code where
the scrubber,
.. so that it's easy to find pages that need to be scrubbed (those pages are
now marked with _PGC_need_scrub bit).
We keep track of the first unscrubbed page in a page buddy using first_dirty
field. For now it can have two values, 0 (whole buddy needs scrubbing) or
INVALID_DIRTY_IDX (the buddy doe
V8:
* Reverted x86's page_info.u.free to using integral types instead of bitfields
* Defined arch_lock_signal_wmb() to avoid having extra barrier in ARM
(see per-patch changes)
When a domain is destroyed the hypervisor must scrub domain's pages before
giving them to another guest in order to prev
Add a debug Kconfig option that will make page allocator verify
that pages that were supposed to be scrubbed are, in fact, clean.
Signed-off-by: Boris Ostrovsky
Reviewed-by: Jan Beulich
---
xen/Kconfig.debug | 7 ++
xen/common/page_alloc.c | 63 +++
When allocating pages in alloc_heap_pages() first look for clean pages. If none
is found then retry, take pages marked as unscrubbed and scrub them.
Note that we shouldn't find unscrubbed pages in alloc_heap_pages() yet. However,
this will become possible when we stop scrubbing from free_heap_page
Signed-off-by: Boris Ostrovsky
Reviewed-by: Wei Liu
---
xen/common/page_alloc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 48798ca..34c45be 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -2308,6 +2308,
They are only referenced by physical address (either the HSA MSR, or via
VMSAVE/VMLOAD which take a physical operand). Allocating xenheap hages and
storing their virtual address is wasteful.
Allocate them with domheap pages instead, taking the opportunity to suitably
NUMA-position them. This avo
Xen's paravirt patch function xen_patch() does some special casing for
irq_ops functions to apply relocations when those functions can be
patched inline instead of calls.
Unfortunately none of the special case function replacements is small
enough to be patched inline, so the special case never ap
Cleanup special cases of paravirt patching:
- Xen doesn't need a custom patching function, it can use
paravirt_patch_default()
- Remove lguest completely from the tree. A LKML mail asking for any
users 3 months ago did not reveal any need for keeping lguest [1].
In case the patches make it t
In this case, rmb() is being used for its compiler barrier property. Replace
it with an explicit barrer() and comment, to avoid it becoming an unnecessary
lfence instruction (when rmb() gets fixed) or looking like an SMP issue.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/drivers/p
On 16/08/17 17:47, Andrew Cooper wrote:
> On 16/08/17 16:23, Jan Beulich wrote:
> On 16.08.17 at 13:22, wrote:
>>> x86's current implementation of wmb() is a compiler barrier. As a result,
>>> the
>>> only change in this patch is to remove an mfence instruction from
>>> cpuidle_disable_deep_
On 16/08/17 17:48, Andre Przywara wrote:
Hi,
On 11/08/17 15:10, Julien Grall wrote:
Hi Andre,
On 21/07/17 20:59, Andre Przywara wrote:
Since the GICs MMIO access always covers a number of IRQs at once,
introduce wrapper functions which loop over those IRQs, take their
locks and read or upda
On Wed, Aug 16, 2017 at 8:12 AM, Ingo Molnar wrote:
>
>
> * Thomas Garnier wrote:
>
> > On Tue, Aug 15, 2017 at 12:56 AM, Ingo Molnar wrote:
> > >
> > > * Thomas Garnier wrote:
> > >
> > >> > Do these changes get us closer to being able to build the kernel as
> > >> > truly
> > >> > position i
Hi,
On 11/08/17 15:10, Julien Grall wrote:
> Hi Andre,
>
> On 21/07/17 20:59, Andre Przywara wrote:
>> Since the GICs MMIO access always covers a number of IRQs at once,
>> introduce wrapper functions which loop over those IRQs, take their
>> locks and read or update the priority values.
>> This
On 16/08/17 16:23, Jan Beulich wrote:
On 16.08.17 at 13:22, wrote:
>> x86's current implementation of wmb() is a compiler barrier. As a result,
>> the
>> only change in this patch is to remove an mfence instruction from
>> cpuidle_disable_deep_cstate().
>>
>> None of these barriers serve an
Idea is: the more CPUs are still active in a grace period,
the more we can wait to check whether it's time to invoke
the callbacks (on those CPUs that have already quiesced,
are idle, and have callbacks queued).
What we're trying to avoid is one of those idle CPUs to
wake up, only to discover that
Xen is a tickless (micro-)kernel, i.e., when a CPU becomes
idle there is no timer tick that will periodically wake the
CPU up.
OTOH, when we imported RCU from Linux, Linux was (on x86) a
ticking kernel, i.e., there was a periodic timer tick always
running, even on idle CPUs. This was bad for power
On the CPU where a callback is queued, cpu_is_haltable()
returns false (due to rcu_needs_cpu() being itself false).
That means the CPU would spin inside idle_loop(), continuously
calling do_softirq(), and, in there, continuously checking
rcu_pending(), in a tight loop.
Let's instead allow the CPU
In fact, right now, we read it at every iteration of the loop.
The reason it's done like this is how context switch was handled
on IA64 (see commit ae9bfcdc, "[XEN] Various softirq cleanups" [1]).
However:
1) we don't have IA64 any longer, and all the achitectures that
we do support, are ok wit
If a CPU has a callback queued, it must be ready to invoke
it, as soon as all the other CPUs involved in the grace period
has gone through a quiescent state.
But if we let such CPU go idle, we can't really tell when (if!)
it will realize that it is actually time to invoke the callback.
To solve th
Hello,
This is take 2 of this series, v1 of which can be found here:
https://lists.xen.org/archives/html/xen-devel/2017-07/msg02770.html
This new version is mostly about taking care of the various review comments
received. Something of the differences are worth a mention here, though:
- patch
Since commit 964fae8ac ("cpuidle: suspend/resume scheduler
tick timer during cpu idle state entry/exit"), if a scheduler
has a periodic tick timer, we stop it when going idle.
This, however, is only true for x86. Make it true for ARM as
well.
Signed-off-by: Dario Faggioli
Reviewed-by: Stefano St
On 16/08/17 17:27, Andre Przywara wrote:
Hi,
On 10/08/17 16:35, Julien Grall wrote:
Hi,
On 21/07/17 20:59, Andre Przywara wrote:
Currently we protect the pending_irq structure with the corresponding
VGIC VCPU lock. There are problems in certain corner cases (for
instance if an IRQ is migrat
On 16 August 2017 at 17:26, Daniel Micay wrote:
>> How are these assumptions hardcoded by GCC? Most of the instructions
>> should be
>> relocatable straight away, as most call/jump/branch instructions are
>> RIP-relative.
>>
>> I.e. is there no GCC code generation mode where code can be placed
>>
Hi,
On 10/08/17 16:35, Julien Grall wrote:
> Hi,
>
> On 21/07/17 20:59, Andre Przywara wrote:
>> Currently we protect the pending_irq structure with the corresponding
>> VGIC VCPU lock. There are problems in certain corner cases (for
>> instance if an IRQ is migrating), so let's introduce a per-I
> How are these assumptions hardcoded by GCC? Most of the instructions
> should be
> relocatable straight away, as most call/jump/branch instructions are
> RIP-relative.
>
> I.e. is there no GCC code generation mode where code can be placed
> anywhere in the
> canonical address space, yet call a
On 16/08/17 16:07, Jan Beulich wrote:
On 16.08.17 at 16:22, wrote:
>> On 16/08/17 15:14, Andrew Cooper wrote:
>>> On 16/08/17 15:11, Jan Beulich wrote:
>>> On 16.08.17 at 15:58, wrote:
> --- a/xen/include/asm-x86/x86_64/page.h
> +++ b/xen/include/asm-x86/x86_64/page.h
> @@ -5
On Wed, 16 Aug 2017, Ingo Molnar wrote:
> And we'd do this for _EVERY_ function call in the kernel. That kind of crap is
> totally unacceptable.
Ahh finally a limit is in sight as to how much security hardening etc can
reduce kernel performance.
___
X
On 08/15/2017 09:21 PM, Konrad Rzeszutek Wilk wrote:
> Hey Jens,
>
> Please git pull the following branch:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> stable/for-jens-4.13
>
> which has two fixes, both of them spotted by Amazon.
>
> 1) Fix in Xen-blkfront caused by the
flight 112652 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112652/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 6 xen-install fail REGR. vs. 110906
test-amd64-i386
On Wed, 2017-08-16 at 12:22 +0100, Andrew Cooper wrote:
> Barriers are a complicated topic, a source of confusion, and their
> incorrect
> use is a common cause of bugs. It *really* doesn't help when Xen's
> API is the
> same as Linux, but its ABI different.
>
> Bring the two back in line, so pro
On Wed, 2017-08-16 at 12:22 +0100, Andrew Cooper wrote:
> There is no functional change. Xen currently assignes smp_* meaning
> to
> the non-smp_* barriers.
>
> All of these uses are just to deal with shared memory between
> multiple
> processors, so use the smp_*() which are the correct barriers
>>> On 16.08.17 at 13:22, wrote:
> x86's current implementation of wmb() is a compiler barrier. As a result, the
> only change in this patch is to remove an mfence instruction from
> cpuidle_disable_deep_cstate().
>
> None of these barriers serve any purpose. Most aren't aren't synchronising
>
* Thomas Garnier wrote:
> On Tue, Aug 15, 2017 at 12:56 AM, Ingo Molnar wrote:
> >
> > * Thomas Garnier wrote:
> >
> >> > Do these changes get us closer to being able to build the kernel as truly
> >> > position independent, i.e. to place it anywhere in the valid x86-64
> >> > address
> >> >
On 08/11/2017 10:54 AM, Juergen Gross wrote:
> When running as Xen pv-guest the exception frame on the stack contains
> %r11 and %rcx additional to the other data pushed by the processor.
>
> Instead of having a paravirt op being called for each exception type
> prepend the Xen specific code to eac
>>> On 16.08.17 at 13:22, wrote:
> * Drop trailing whitespace.
> * Move amd_nonfatal_mcheck_init() into .init.text and drop a trailing
> return.
> * Drop unnecessary wmb()'s. Because of Xen's implementation, they are only
> compiler barriers anyway, and each wrmsr() is already fully se
On 08/04/2017 07:36 AM, Juergen Gross wrote:
> Remove stuff no longer needed.
>
> Juergen Gross (3):
> xen: remove tests for pvh mode in pure pv paths
> xen: remove unused function xen_set_domain_pte()
> xen: remove not used trace functions
>
> arch/x86/include/asm/xen/page.h | 5 -
> a
>>> On 16.08.17 at 16:22, wrote:
> On 16/08/17 15:14, Andrew Cooper wrote:
>> On 16/08/17 15:11, Jan Beulich wrote:
>> On 16.08.17 at 15:58, wrote:
--- a/xen/include/asm-x86/x86_64/page.h
+++ b/xen/include/asm-x86/x86_64/page.h
@@ -51,13 +51,15 @@ extern unsigned long xen_virt_
On 08/02/2017 06:36 PM, Boris Ostrovsky wrote:
> On 08/02/2017 01:46 PM, Arvind Yadav wrote:
>> pci_device_id are not supposed to change at runtime. All functions
>> working with pci_device_id provided by work with
>> const pci_device_id. So mark the non-const structs as const.
>>
>> Signed-off-by
flight 112666 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112666/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64-pvops 2 hos
On 07/27/2017 11:44 AM, Juergen Gross wrote:
> On 27/07/17 17:37, Boris Ostrovsky wrote:
>> On 07/27/2017 11:11 AM, Juergen Gross wrote:
>>> The macros for testing domain types are more complicated then they
>>> need to. Simplify them.
>>>
>>> Signed-off-by: Juergen Gross
>>> ---
>>> include/xen/
On Fri, Aug 11, 2017 at 05:25:34PM +0200, Felix Schmoll wrote:
> This commit makes the changes to the hypervisor, the build system as
> well as libxc necessary in order to facilitate tracing of program counters.
>
> A discussion of the design can be found in the mailing list:
> https://lists.xen.o
Hi Andre,
On 21/07/17 21:00, Andre Przywara wrote:
Instead of using an atomic access and hoping for the best, let's use
the new pending_irq lock now to make sure we read a sane version of
the target VCPU.
How this is going to bring a saner version?
You only read the vCPU and well nothing prev
Hi Andre,
On 21/07/17 21:00, Andre Przywara wrote:
The enabled bits for a group of IRQs are still stored in the irq_rank
structure, although we already have the same information in pending_irq,
in the GIC_IRQ_GUEST_ENABLED bit of the "status" field.
Remove the storage from the irq_rank and just
On 08/16/2017 08:20 AM, Jan Beulich wrote:
So far callers of the libxc interface passed in a domain ID which was
then ignored in the hypervisor. Instead, make the hypervisor honor it
(accepting DOMID_INVALID to obtain original behavior), allowing to
query whether a device can be assigned to a par
On 16/08/17 15:14, Andrew Cooper wrote:
> On 16/08/17 15:11, Jan Beulich wrote:
> On 16.08.17 at 15:58, wrote:
>>> --- a/xen/include/asm-x86/x86_64/page.h
>>> +++ b/xen/include/asm-x86/x86_64/page.h
>>> @@ -51,13 +51,15 @@ extern unsigned long xen_virt_end;
>>>
>>> static inline unsigned lo
>>> On 16.08.17 at 16:14, wrote:
> On 16/08/17 15:11, Jan Beulich wrote:
> On 16.08.17 at 15:58, wrote:
>>> --- a/xen/include/asm-x86/x86_64/page.h
>>> +++ b/xen/include/asm-x86/x86_64/page.h
>>> @@ -51,13 +51,15 @@ extern unsigned long xen_virt_end;
>>>
>>> static inline unsigned long __v
On 16/08/17 15:11, Jan Beulich wrote:
On 16.08.17 at 15:58, wrote:
>> --- a/xen/include/asm-x86/x86_64/page.h
>> +++ b/xen/include/asm-x86/x86_64/page.h
>> @@ -51,13 +51,15 @@ extern unsigned long xen_virt_end;
>>
>> static inline unsigned long __virt_to_maddr(unsigned long va)
>> {
>> -
>>> On 16.08.17 at 15:58, wrote:
> --- a/xen/include/asm-x86/x86_64/page.h
> +++ b/xen/include/asm-x86/x86_64/page.h
> @@ -51,13 +51,15 @@ extern unsigned long xen_virt_end;
>
> static inline unsigned long __virt_to_maddr(unsigned long va)
> {
> -ASSERT(va >= XEN_VIRT_START);
> ASSERT
>>> On 16.08.17 at 14:51, wrote:
> Modify the custom parameter parsing routines in:
>
> xen/arch/x86/genapic/probe.c
>
> to indicate whether the parameter value was parsed successfully.
>
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
_
__virt_to_maddr() is used very frequently, but has a large footprint due to
its assertions and comparasons.
Rearange its logic to drop one assertion entirely, encoding its check in a
second assertion (with no additional branch, and the comparason performed with
a 32bit immediate rather than requir
>>> On 16.08.17 at 14:51, wrote:
> Modify the custom parameter parsing routines in:
>
> xen/arch/x86/dom0_build.c
>
> to indicate whether the parameter value was parsed successfully.
>
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
>>> On 16.08.17 at 14:27, wrote:
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 16.08.17 at 14:49, wrote:
> It is a vestigial leftover of Xen having inherited Linux's memory management
> code in the early days.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
htt
Hi Andre,
On 21/07/17 21:00, Andre Przywara wrote:
The VCPU a shared virtual IRQ is targeting is currently stored in the
irq_rank structure.
For LPIs we already store the target VCPU in struct pending_irq, so
move SPIs over as well.
The ITS code, which was using this field already, was so far us
flight 112650 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112650/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-2 47 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 111516
Regressions whi
On Wed, Aug 16, 2017 at 6:43 AM, Razvan Cojocaru
wrote:
> On 16.08.2017 15:32, Tamas K Lengyel wrote:
>>
>> On Wed, Aug 16, 2017 at 12:07 AM, Razvan Cojocaru
>> wrote:
>>>
>>> On 08/16/2017 02:16 AM, Tamas K Lengyel wrote:
On Tue, Aug 15, 2017 at 2:06 AM, Jan Beulich wrote:
>>
This commit adds functionality to walk the guest's page tables using the
long-descriptor translation table format for both ARMv7 and ARMv8.
Similar to the hardware architecture, the implementation supports
different page granularities (4K, 16K, and 64K). The implementation is
based on ARM DDI 0487B
In this commit, we make use of the gpt walk functionality introduced in
the previous commits. If mem_access is active, hardware-based gva to ipa
translation might fail, as gva_to_ipa uses the guest's translation
tables, access to which might be restricted by the active VTTBR. To
side-step potential
This commit renames the function vgic_access_guest_memory to
access_guest_memory_by_ipa. As the function name suggests, the functions
expects an IPA as argument. All invocations of this function have been
adapted accordingly. Apart from that, we have adjusted all printk
messages for cleanup and to
The current implementation does not provide appropriate types for
short-descriptor translation table entries. As such, this commit adds new
types, which simplify managing the respective translation table entries.
Signed-off-by: Sergej Proskurin
Acked-by: Julien Grall
---
Cc: Stefano Stabellini
AArch64 supports pages with different (4K, 16K, and 64K) sizes. To
enable guest page table walks for various configurations, this commit
extends the defines and helpers of the current implementation.
Signed-off-by: Sergej Proskurin
Reviewed-by: Julien Grall
---
Cc: Stefano Stabellini
Cc: Julie
This commit adds (TCR_|TTBCR_)* defines to simplify access to the
respective register contents. At the same time, we adjust the macros
TCR_T0SZ and TCR_TG0_* by using the newly introduced TCR_T0SZ_SHIFT and
TCR_TG0_SHIFT instead of the hardcoded values.
Signed-off-by: Sergej Proskurin
Acked-by: J
The current implementation of GENMASK is capable of creating bitmasks of
32-bit values on AArch32 and 64-bit values on AArch64. As we need to
create masks for 64-bit values on AArch32 as well, in this commit we
introduce the GENMASK_ULL bit operation. Please note that the
GENMASK_ULL implementation
This commit moves the function vgic_access_guest_memory to guestcopy.c
and the header asm/guest_access.h. No functional changes are made.
Please note that the function will be renamed in the following commit.
Signed-off-by: Sergej Proskurin
Acked-by: Julien Grall
---
Cc: Stefano Stabellini
Cc:
This commit introduces a new helper that checks whether the target PTE
holds a page mapping or not. This helper will be used as part of the
following commits.
Signed-off-by: Sergej Proskurin
Reviewed-by: Julien Grall
---
Cc: Stefano Stabellini
Cc: Julien Grall
---
v6: Change the name of the lp
The function p2m_mem_access_check_and_get_page in mem_access.c
translates a gva to an ipa by means of the hardware functionality of the
ARM architecture. This is implemented in the function gva_to_ipa. If
mem_access is active, hardware-based gva to ipa translation might fail,
as gva_to_ipa uses the
We introduce the BIT_ULL macro to using values of unsigned long long as
to enable setting bits of 64-bit registers on AArch32. In addition,
this commit adds a define holding the register width of 64 bit
double-word registers. This define simplifies using the associated
constants in the following c
The function p2m_mem_access_check_and_get_page is called from the
function get_page_from_gva if mem_access is active and the
hardware-aided translation of the given guest virtual address (gva) into
machine address fails. That is, if the stage-2 translation tables
constrain access to the guests's pa
1 - 100 of 209 matches
Mail list logo
