>>> On 15.09.16 at 18:40, wrote:
> On 09/15/2016 12:05 PM, Jan Beulich wrote
>
>>> Maybe even without changes to mk_dsdt.c
>> But isn't that the critical part?
>
> Not necessarily since we'd use --gpl option only for
> dsdt_anycpu_qemu_xen, dsdt_anycpu and dsdt_15cpu and these files are not
> u
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 expose to guests, let's handle them by white
flight 100973 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100973/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail in 100970 pass in
100973
test-amd64-i386-qemuu-rhel6
On Thu, Sep 15, 2016 at 5:07 PM, Andy Lutomirski wrote:
> On Thu, Sep 15, 2016 at 4:33 PM, Kyle Huey wrote:
>> +int get_cpuid_mode(unsigned long adr)
>> +{
>> + unsigned int val;
>> +
>> + if (test_thread_flag(TIF_NOCPUID))
>> + val = ARCH_CPUID_SIGSEGV;
>> + else
This run is configured for baseline tests only.
flight 67718 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67718/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair 9 xen-boot/src_h
This run is configured for baseline tests only.
flight 67719 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67719/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm 6 xen-boot
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:
>> On Tue, Sep 13, 2016 at 01:30:17PM +0200, Dario Faggioli wrote:
>> >
>> > Do you mind sharing just a bit more, such as:
>> > - number of pcpus
>> > - number of vcpus of the vari
This run is configured for baseline tests only.
flight 67720 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67720/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 490acf8908f797982f367bfeb4bdf3ebe0764e42
baseline v
On Thu, Sep 15, 2016 at 4:33 PM, Kyle Huey wrote:
> Intel supports faulting on the CPUID instruction in newer processors. Bit
> 31 of MSR_PLATFORM_INFO advertises support for this feature. It is
> documented in detail in Section 2.3.2 of
> http://www.intel.com/content/dam/www/public/us/en/document
On Thu, Sep 15, 2016 at 4:33 PM, Kyle Huey wrote:
> arch_prctl is currently 64-bit only. Wire it up for 32-bits, as a no-op for
> now. Rename the second arg to a more generic name.
>
> Signed-off-by: Kyle Huey
> ---
> arch/x86/entry/syscalls/syscall_32.tbl | 1 +
> arch/x86/include/asm/proto.h
flight 100971 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100971/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs.
100966
Regressions
On Thu, Sep 15, 2016 at 4:33 PM, Kyle Huey wrote:
Reviewed-by: Andy Lutomirski
although this is really Borislav's domain.
OTOH, if you're planning on changing Linux's Xen MSR helpers to mask
the feature out, that should be in the same patch or an earlier patch.
___
On Thu, Sep 15, 2016 at 12:37 PM, Andy Lutomirski wrote:
> On Thu, Sep 15, 2016 at 12:11 PM, Kyle Huey wrote:
>> On Thu, Sep 15, 2016 at 3:25 AM, Jan Beulich wrote:
>> On 15.09.16 at 12:05, wrote:
On 14/09/16 22:01, Kyle Huey wrote:
> Xen advertises the underlying support for CPUID
rr (http://rr-project.org/), a userspace record-and-replay reverse-
execution debugger, would like to trap and emulate the CPUID instruction.
This would allow us to a) mask away certain hardware features that rr does
not support (e.g. RDRAND) and b) enable trace portability across machines
by provi
Intel supports faulting on the CPUID instruction in newer processors. Bit
31 of MSR_PLATFORM_INFO advertises support for this feature. It is
documented in detail in Section 2.3.2 of
http://www.intel.com/content/dam/www/public/us/en/documents/application-notes/virtualization-technology-flexmigration
Signed-off-by: Kyle Huey
---
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/msr-index.h | 1 +
arch/x86/kernel/cpu/scattered.c| 14 ++
3 files changed, 16 insertions(+)
diff --git a/arch/x86/include/asm/cpufeatures.h
b/arch/x86/include/asm/cpufeatures.h
index
arch_prctl is currently 64-bit only. Wire it up for 32-bits, as a no-op for
now. Rename the second arg to a more generic name.
Signed-off-by: Kyle Huey
---
arch/x86/entry/syscalls/syscall_32.tbl | 1 +
arch/x86/include/asm/proto.h | 5 -
arch/x86/kernel/process.c | 1
On Thu, Sep 15, 2016 at 1:38 PM, H. Peter Anvin wrote:
> On September 14, 2016 6:17:51 PM PDT, Andy Lutomirski
> wrote:
>>On Wed, Sep 14, 2016 at 3:03 PM, Kyle Huey wrote:
>>> On Wed, Sep 14, 2016 at 2:35 PM, Dave Hansen
>>> wrote:
On 09/14/2016 02:01 PM, Kyle Huey wrote:
>>
Is any o
flight 100970 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100970/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail REGR. vs. 100965
test-amd64-i386-qe
On September 14, 2016 6:17:51 PM PDT, Andy Lutomirski
wrote:
>On Wed, Sep 14, 2016 at 3:03 PM, Kyle Huey wrote:
>> On Wed, Sep 14, 2016 at 2:35 PM, Dave Hansen
>> wrote:
>>> On 09/14/2016 02:01 PM, Kyle Huey wrote:
>
>>> Is any of this useful to optimize away at compile-time? We have
>config
>
On 09/15/2016 03:11 PM, Kyle Huey wrote:
> On Thu, Sep 15, 2016 at 3:25 AM, Jan Beulich wrote:
> On 15.09.16 at 12:05, wrote:
>>> On 14/09/16 22:01, Kyle Huey wrote:
Xen advertises the underlying support for CPUID faulting but not does pass
through writes to the relevant MSR, nor do
On Thu, Sep 15, 2016 at 12:11 PM, Kyle Huey wrote:
> On Thu, Sep 15, 2016 at 3:25 AM, Jan Beulich wrote:
> On 15.09.16 at 12:05, wrote:
>>> On 14/09/16 22:01, Kyle Huey wrote:
Xen advertises the underlying support for CPUID faulting but not does pass
through writes to the relevant
On Thu, Sep 15, 2016 at 3:25 AM, Jan Beulich wrote:
On 15.09.16 at 12:05, wrote:
>> On 14/09/16 22:01, Kyle Huey wrote:
>>> Xen advertises the underlying support for CPUID faulting but not does pass
>>> through writes to the relevant MSR, nor does it virtualize it, so it does
>>> not actuall
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
On Thu, Sep 15, 2016 at 5:28 AM, Julien Grall wrote:
> Hello all,
>
> The ARM architecture mandates the use of a break-before-make sequence when
> changing translation entries if the page table is shared between multiple
> CPUs whenever a valid entry is replaced by another valid entry (see D4.7.1
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 memory. This patch extends the vm_event interfac
flight 100969 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100969/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 490acf8908f797982f367bfeb4bdf3ebe0764e42
baseline version:
ovmf f8db6527da8678f1480f0
flight 100966 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100966/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100951
test-amd64-amd64-xl-rtds
Setting response flags in vm_event are only ever safe if the vCPUs are paused.
To reflect this we move all checks within the if block that already checks
whether this is the case. Checks that are only supported on one architecture
we relocate the bitmask operations to the arch-specific handlers to
When emulating instructions Xen's emulator maintains a small i-cache fetched
from the guest memory. This patch extends the vm_event interface to allow
overwriting this i-cache via a buffer returned in the vm_event response.
When responding to a SOFTWARE_BREAKPOINT event (INT3) the monitor subscrib
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 memory. This patch extends the vm_event interface to allow
>> returning this i-cache via the vm_e
On 09/15/2016 12:05 PM, Jan Beulich wrote
>> Maybe even without changes to mk_dsdt.c
> But isn't that the critical part?
Not necessarily since we'd use --gpl option only for
dsdt_anycpu_qemu_xen, dsdt_anycpu and dsdt_15cpu and these files are not
used by the non-GPL caller, which is libxl (it on
>>> On 15.09.16 at 17:27, wrote:
> On Wed, Sep 14, 2016 at 11:58 PM, Jan Beulich wrote:
> On 14.09.16 at 18:20, wrote:
>>> On Wed, Sep 14, 2016 at 9:55 AM, Jan Beulich wrote:
>>> On 13.09.16 at 20:12, wrote:
> When emulating instructions the emulator maintains a small i-cache fetch
>>> On 15.09.16 at 17:28, wrote:
> Something along the lines of this (attached as well to prevent line
> wrapping)
Looks reasonable with some polishing (GPL=y on the make lines and
using C_SRC-$(GPL) and CSRC-y).
> Maybe even without changes to mk_dsdt.c
But isn't that the critical part? And -
flight 100965 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100965/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100960
test-amd64-i386-xl-qemuu-wi
On Thu, 2016-09-15 at 16:11 +0100, Wei Liu wrote:
> On Thu, Sep 15, 2016 at 03:50:25PM +0100, Wei Liu wrote:
> >
> > CC Ian who might have some ideas on this.
> >
> > On Wed, Sep 14, 2016 at 04:22:24PM +0200, Cedric Bosdonnat wrote:
> > >
> > > Hi all,
> > >
> > > I wanted to get libvirt's libx
On Thu, Sep 08, 2016 at 09:20:26AM +0200, Juergen Gross wrote:
> 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
___
Xen-devel mailing list
Xen-devel
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 of type DEVICEMODEL is requeste
On 09/15/2016 10:21 AM, Jan Beulich wrote:
On 15.09.16 at 16:07, wrote:
>> On 09/15/2016 09:48 AM, Julien Grall wrote:
>>> On 15/09/2016 13:39, Boris Ostrovsky wrote:
One option could be to provide a 'gpl_all' (or some such) target in
libacpi in addition to 'all' and that target wil
On Wed, Sep 14, 2016 at 11:58 PM, Jan Beulich wrote:
On 14.09.16 at 18:20, wrote:
>> On Wed, Sep 14, 2016 at 9:55 AM, Jan Beulich wrote:
>> On 13.09.16 at 20:12, wrote:
When emulating instructions the emulator maintains a small i-cache fetched
from the guest memory. This patc
flight 100968 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100968/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On Thu, Sep 08, 2016 at 09:20:24AM +0200, Juergen Gross wrote:
> 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 Xenst
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, the backend state wasn't initialized by
netback_probe() at this point,
On Thu, Sep 15, 2016 at 03:50:25PM +0100, Wei Liu wrote:
> CC Ian who might have some ideas on this.
>
> On Wed, Sep 14, 2016 at 04:22:24PM +0200, Cedric Bosdonnat wrote:
> > Hi all,
> >
> > I wanted to get libvirt's libxl driver have per-domain logs like all other
> > drivers. After
> > looking
CC Ian who might have some ideas on this.
On Wed, Sep 14, 2016 at 04:22:24PM +0200, Cedric Bosdonnat wrote:
> Hi all,
>
> I wanted to get libvirt's libxl driver have per-domain logs like all other
> drivers. After
> looking at the libxl and XenToolLogger it seems I'll need to add the feature
>
>>> 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 all bets
>> are off anyway).
>
>
On Fri, Sep 09, 2016 at 12:13:46PM +0200, Juergen Gross wrote:
> On 09/09/16 12:00, 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
Hi Andrew:
Sorry to bother you. To make sure we are on the right direction, it's
better to get feedback from you before we go further step. Could you
have a look? Thanks.
On 8/17/2016 8:05 PM, Lan, Tianyu wrote:
Hi All:
The following is our Xen vIOMMU high level design for detail
discussion
>>> On 15.09.16 at 16:07, wrote:
> On 09/15/2016 09:48 AM, Julien Grall wrote:
>> On 15/09/2016 13:39, Boris Ostrovsky wrote:
>>> One option could be to provide a 'gpl_all' (or some such) target in
>>> libacpi in addition to 'all' and that target will be careful about not
>>> including these small
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 all bets
are off anyway).
Not clear why do_invalid_op() on the stack. There
On Thu, Sep 15, 2016 at 04:05:17PM +0200, Filipe Manco wrote:
> On 14-09-2016 12:10, Wei Liu wrote:
> >CC xen-devel as well.
> >
> >On Tue, Sep 13, 2016 at 02:11:27PM +0200, Filipe Manco wrote:
> >>In case of error during netback_probe() (e.g. an entry missing on the
> >>xenstore) netback_remove()
On 09/15/2016 09:48 AM, Julien Grall wrote:
> Hi Boris,
>
> On 15/09/2016 13:39, Boris Ostrovsky wrote:
>> On 09/15/2016 06:22 AM, Wei Liu wrote:
>>> On Thu, Sep 15, 2016 at 11:20:08AM +0100, Julien Grall wrote:
Hi Wei,
On 15/09/2016 11:18, Wei Liu wrote:
> On Wed, Sep 14, 2016 a
On 14-09-2016 12:10, Wei Liu wrote:
CC xen-devel as well.
On Tue, Sep 13, 2016 at 02:11:27PM +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 Xenbus
On 09/15/2016 04:55 PM, Wei Liu wrote:
> On Thu, Sep 15, 2016 at 04:52:32PM +0300, Razvan Cojocaru wrote:
>> On 09/15/2016 04:49 PM, Wei Liu wrote:
>>> On Thu, Sep 15, 2016 at 04:39:47PM +0300, Razvan Cojocaru wrote:
On 09/07/2016 07:01 PM, Jan Beulich wrote:
On 07.09.16 at 11:12, wr
On Thu, Sep 15, 2016 at 04:52:32PM +0300, Razvan Cojocaru wrote:
> On 09/15/2016 04:49 PM, Wei Liu wrote:
> > On Thu, Sep 15, 2016 at 04:39:47PM +0300, Razvan Cojocaru wrote:
> >> On 09/07/2016 07:01 PM, Jan Beulich wrote:
> >> On 07.09.16 at 11:12, wrote:
> Currently it is only possible
On 09/15/2016 04:49 PM, Wei Liu wrote:
> On Thu, Sep 15, 2016 at 04:39:47PM +0300, Razvan Cojocaru wrote:
>> On 09/07/2016 07:01 PM, Jan Beulich wrote:
>> On 07.09.16 at 11:12, wrote:
Currently it is only possible to set mem_access restrictions only for
a contiguous range of GFNs (or
Hi,
On 15/09/2016 12:28, Julien Grall wrote:
The helper p2m_create_table is only called to create a brand new table.
Signed-off-by: Julien Grall
Reviewd-by: Stefano Stabellini
I made 2 typoes here. It should be:
Reviewed-by: Stefano Stabellini
Regards,
--
Julien Grall
_
On Thu, Sep 15, 2016 at 04:39:47PM +0300, Razvan Cojocaru wrote:
> On 09/07/2016 07:01 PM, Jan Beulich wrote:
> On 07.09.16 at 11:12, wrote:
> >> Currently it is only possible to set mem_access restrictions only for
> >> a contiguous range of GFNs (or, as a particular case, for a single GFN).
Hi Boris,
On 15/09/2016 13:39, Boris Ostrovsky wrote:
On 09/15/2016 06:22 AM, Wei Liu wrote:
On Thu, Sep 15, 2016 at 11:20:08AM +0100, Julien Grall wrote:
Hi Wei,
On 15/09/2016 11:18, Wei Liu wrote:
On Wed, Sep 14, 2016 at 11:21:39AM -0400, Boris Ostrovsky wrote:
On 09/07/2016 02:59 PM, Bor
On 15/09/2016 13:35, Boris Ostrovsky wrote:
On 09/15/2016 04:58 AM, Julien Grall wrote:
I think Jan mentioned at some point that certain versions of Windows
require an early revision although IIRC it was 2.0. So perhaps at some
point we could drop support for pre-2.0 versions, but this was neve
On 09/07/2016 07:01 PM, Jan Beulich wrote:
On 07.09.16 at 11:12, wrote:
>> Currently it is only possible to set mem_access restrictions only for
>> a contiguous range of GFNs (or, as a particular case, for a single GFN).
>> This patch introduces a new libxc function taking an array of GFNs.
>
This run is configured for baseline tests only.
flight 67714 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67714/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-i386-pvgrub 10 guest-start
This run is configured for baseline tests only.
flight 67717 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67717/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f8db6527da8678f1480f08ba99b745279e8d104a
baseline v
flight 100967 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100967/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On 09/15/2016 03:22 PM, Ed Swierk wrote:
> On Thu, Sep 15, 2016 at 2:15 AM, Denis V. Lunev wrote:
>> On 09/13/2016 11:59 PM, Konrad Rzeszutek Wilk wrote:
>>> On Thu, Sep 01, 2016 at 10:57:48AM -0700, Ed Swierk wrote:
Windows 8, 10 and Server 2012 guests hang intermittently while booting
On 09/15/2016 06:22 AM, Wei Liu wrote:
> On Thu, Sep 15, 2016 at 11:20:08AM +0100, Julien Grall wrote:
>> Hi Wei,
>>
>> On 15/09/2016 11:18, Wei Liu wrote:
>>> On Wed, Sep 14, 2016 at 11:21:39AM -0400, Boris Ostrovsky wrote:
On 09/07/2016 02:59 PM, Boris Ostrovsky wrote:
> The goal here is
On 09/15/2016 04:58 AM, Julien Grall wrote:
> Hi Boris,
>
> On 15/09/2016 03:17, Boris Ostrovsky wrote:
>>
>> - julien.gr...@arm.com wrote:
>>
>>> Hi Stefano,
>>>
>>> On 14/09/2016 21:48, Stefano Stabellini wrote:
On Wed, 14 Sep 2016, Julien Grall wrote:
> On 14/09/2016 02:06, Stefano
On Thu, Sep 15, 2016 at 2:15 AM, Denis V. Lunev wrote:
> On 09/13/2016 11:59 PM, Konrad Rzeszutek Wilk wrote:
> > On Thu, Sep 01, 2016 at 10:57:48AM -0700, Ed Swierk wrote:
> >> Windows 8, 10 and Server 2012 guests hang intermittently while booting
> >> on Xen 4.5.3 with 1 vCPU and 4 e1000 vNICs,
On 09/15/2016 02:28 PM, Julien Grall wrote:
> The function p2m_set_mem_access can be re-implemented using the generic
> functions p2m_get_entry and __p2m_set_entry.
>
> Also the function apply_p2m_changes is dropped completely as it is not
> used anymore.
>
> Signed-off-by: Julien Grall
> Review
The helper p2m_create_table is only called to create a brand new table.
Signed-off-by: Julien Grall
Reviewd-by: Stefano Stabellini
---
Changes in v2:
- Add Stefano's reviewed-by
---
xen/arch/arm/p2m.c | 56 ++
1 file changed, 6 in
The back pointer will be usefult later to get the domain when we only
have the p2m in hand.
Signed-off-by: Julien Grall
---
Changes in v2:
- Patch added
---
xen/arch/arm/p2m.c| 1 +
xen/include/asm-arm/p2m.h | 3 +++
2 files changed, 4 insertions(+)
diff --git a/xen/arch/ar
The function p2m_insert_mapping can be re-implemented using the generic
function p2m_set_entry.
Note that the mapping is not reverted anymore if Xen fails to insert a
mapping. This was added to ensure the MMIO are not kept half-mapped
in case of failure and to follow the x86 counterpart. This was
Each entry in the page table has to be cleaned when the IOMMU does not
support coherent walk. Rather than querying every time the page table is
updated, it is possible to do it only once when the p2m is initialized.
This is because this value can never change, Xen would be in big trouble
otherwise
__p2m_lookup is just a wrapper to p2m_get_entry.
Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
---
It might be possible to rework the memaccess code to take advantage
of all the parameters. I will defer this to the memaccess folks.
Changes in v2:
- Add Stefano's
A follow-up patch will add more case to the switch that will require the
IPA. So move the computation out of the switch.
Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
---
Changes in v2:
- Add Stefano's acked-by
---
xen/arch/arm/traps.c | 36 ++
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
---
Changes in v2:
- Use uint8_t rather than unsigned int
- Replaced paddr_t by uint8_t in p2m_shatter_page
---
xen/arch/arm/p2m.c | 4 ++--
1 file chan
Sometimes the invalidation of the TLBs can be deferred until the p2m is
unlocked. This is for instance the case when multiple mappings are
removed. In other case, such as shattering a superpage, an immediate
flush is required.
Keep track whether a flush is needed directly in the p2m_domain structu
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 the code and the changes, the
current implementation
The function p2m_insert_mapping can be re-implemented using the generic
function p2m_set_entry.
Also drop the operation REMOVE in apply_* as nobody is using it anymore.
Note that the functions could have been dropped in one go at the end,
however I find easier to drop the operations one by one avo
Hello all,
The ARM architecture mandates the use of a break-before-make sequence when
changing translation entries if the page table is shared between multiple
CPUs whenever a valid entry is replaced by another valid entry (see D4.7.1
in ARM DDI 0487A.j for more details).
The current P2M code doe
Those helpers are very small and often used. Let know the compiler they
can be inlined.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Changes in v2:
- Add Stefano's reviewed-by
---
xen/arch/arm/p2m.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
dif
Earlier patches exported the p2m interface (p2m_get_entry and
p2m_set_entry) to allow splitting xen/arch/arm/p2m.c. Those functions
require the callers to lock the p2m, so we need to export p2m_*_lock
helpers.
All helpers but p2m_write_unlock but p2m_write_unlock are moved in
xen/include/asm-arm/p
The function p2m_set_mem_access can be re-implemented using the generic
functions p2m_get_entry and __p2m_set_entry.
Also the function apply_p2m_changes is dropped completely as it is not
used anymore.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
Cc: Razvan Cojocaru
Cc: Tamas K
This will be used later in functions that will be defined earlier in the
file.
Signed-off-by: Julien Grall
---
xen/arch/arm/p2m.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index b4f75e8..413780b 100644
--- a/xen/a
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 whether the mapping exists. If
it exists, return t
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 this purpose,
it is better to implement a generic fun
The ARM architecture mandates to use of a break-before-make sequence
when changing translation entries if the page table is shared between
multiple CPUs whenever a valid entry is replaced by another valid entry
(see D4.7.1 in ARM DDI 0487A.j for more details).
The break-before-make sequence can be
The function relinquish_p2m_mapping can be re-implemented using
p2m_{get,set}_entry by iterating over the range mapped and using the
mapping order given by the callee.
Given that the preemption was chosen arbitrarily, it is now done on every
512 iterations. Meaning that Xen may check more often if
Use the level and the entry to know whether an entry is a superpage.
A superpage can only happen below level 3.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Changes in v2:
- Use bool instead of bool_t
- Add Stefano's reviewed-by
---
xen/arch/arm/p2m.c | 5
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 comment in the current code claimed it. As the function
to make clear of the usage. I.e it is used to inform whether Xen needs
to clean the entry after writing in the page table.
Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
---
Changes in v2:
- Add Stefano's acked-by
---
xen/arch/arm/p2m.c | 8
1 file changed, 4 ins
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
---
Changes in v2:
- Use level_orders rather than level_shifts - PAGE_SHIFT
- Move the definition of level_order
p2m_mem_access_radix_set is expecting a gfn in a parameter. Rename the
parameter 'pfn' to 'gfn' to match its content and use the typesafe gfn
to avoid possible misusage.
Also rename the parameter to gfn to match its content.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
C
This run is configured for baseline tests only.
flight 67715 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67715/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvops 5 kernel-build
Hi Edgar,
On Thu, Sep 15, 2016 at 10:26:46AM +0200, Edgar E. Iglesias wrote:
>On Thu, Sep 15, 2016 at 08:20:33AM +0800, Peng Fan wrote:
>> Hi Edgar,
>> On Wed, Sep 14, 2016 at 04:16:58PM +0200, Edgar E. Iglesias wrote:
>> >On Wed, Sep 14, 2016 at 08:40:09PM +0800, Peng Fan wrote:
>> >> On Wed, Sep
flight 100964 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100964/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On Tue, Sep 13, 2016 at 11:38:35AM +0100, Julien Grall wrote:
> Hi Shannon,
>
> On 13/09/16 08:03, Shannon Zhao wrote:
> >
> >
> >On 2016/9/12 23:18, Julien Grall wrote:
> >>Hi Shannon,
> >>
> >>On 02/09/16 03:55, Shannon Zhao wrote:
> >>>From: Shannon Zhao
> >>>
> >>>Here it adds the ACPI tables
flight 67716 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67716/
Perfect :-)
All tests in this flight passed as required
baseline version:
flight 67673
jobs:
build-amd64 pass
build-armh
Hi Stefano,
On 06/09/2016 19:57, Stefano Stabellini wrote:
On Thu, 28 Jul 2016, Julien Grall wrote:
The function p2m_insert_mapping can be re-implemented using the generic
function p2m_set_entry.
Note that the mapping is not reverted anymore if Xen fails to insert a
mapping. This was added to
On 14/09/16 16:11, Tamas K Lengyel wrote:
> On Wed, Sep 14, 2016 at 7:38 AM, George Dunlap
> wrote:
>> On 13/09/16 19:12, Tamas K Lengyel wrote:
>>> Setting response flags in vm_event are only ever safe if the vCPUs are
>>> paused.
>>> To reflect this we move all checks within the if block that
1 - 100 of 124 matches
Mail list logo
