>>> On 11.12.17 at 22:59, wrote:
> On 08/12/2017 09:49, Jan Beulich wrote:
>>> + * The layout of each entry in the memory map table is as follows and no
>>> + * padding is used between entries in the array:
>>> + *
>>> + * 0 ++
>>> + *| addr | Base address
>>> + * 8
On Fri, Dec 08, 2017 at 11:06:43AM +, Paul Durrant wrote:
>> -Original Message-
>> From: Chao Gao [mailto:chao@intel.com]
>> Sent: 07 December 2017 06:57
>> To: Paul Durrant
>> Cc: Stefano Stabellini ; Wei Liu
>> ; Andrew Cooper ; Tim
>> (Xen.org) ; George Dunlap ;
>> xen-de...@lis
On 12/12/2017 05:54 AM, elena.ufimts...@oracle.com wrote:
From: Elena Ufimtseva
It is expected that the symbol has type STT_FUNC in livpatch.ignore.functions
sections, but it is incorrect and results in functions not to be ignored.
To actually ignore functions in livepatch.ignore.functions sect
Hi Sameer,
On 12/05/2017 09:29 AM, Sameer Goel wrote:
+static
+struct arm_smmu_device *arm_smmu_get_by_fwnode(struct fwnode_handle *fwnode)
+{
+ struct arm_smmu_device *smmu = NULL;
+
+ spin_lock(&arm_smmu_devices_lock);
+ list_for_each_entry(smmu, &arm_smmu_devices, devices)
> -Original Message-
[snip]
>
> Hi, Paul.
>
> I merged the two qemu patches, the privcmd patch [1] and did some tests.
> I encountered a small issue and report it to you, so you can pay more
> attention to it when doing some tests. The symptom is that using the new
> interface to map gran
>>> On 11.12.17 at 15:59, wrote:
> On Thu, Dec 07, 2017 at 04:51:32AM -0700, Jan Beulich wrote:
>> >>> On 04.12.17 at 11:24, wrote:
>> > +if ( (end > s) && (end - reloc_size >= _end - _start) )
>>
>> In your earlier mails following v1 you had __pa(_end) here on the
>> right side. Why is t
>>> On 11.12.17 at 16:12, wrote:
> On Thu, Dec 07, 2017 at 05:02:02AM -0700, Jan Beulich wrote:
>> >>> On 04.12.17 at 11:24, wrote:
>> > Current limit, PFN_DOWN(xen_phys_start), introduced by commit b280442
>> > (x86: make Xen early boot code relocatable) is not reliable. Potentially
>> > its val
On 12/12/2017 09:06, Jan Beulich wrote:
On 11.12.17 at 22:59, wrote:
>> On 08/12/2017 09:49, Jan Beulich wrote:
+ * The layout of each entry in the memory map table is as follows and no
+ * padding is used between entries in the array:
+ *
+ * 0 ++
+
On Tuesday, 12 December 2017 5:16:06 AM AEDT Xen. org security team wrote:
> Xen Security Advisory CVE-2017-15595 / XSA-240
>version 6
>
>Unlimited recursion in linear pagetable de-typing
>
> UPDATES IN VERSION 6
>
>
>
On Tue, Dec 12, 2017 at 10:03 AM, Steven Haigh wrote:
> On Tuesday, 12 December 2017 5:16:06 AM AEDT Xen. org security team wrote:
>> Xen Security Advisory CVE-2017-15595 / XSA-240
>>version 6
>>
>>Unlimited recursion in linear pagetable de-t
Add a respective dependency.
Signed-off-by: Jan Beulich
---
drivers/xen/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 4.15-rc3/drivers/xen/Kconfig
+++ 4.15-rc3-xen-ACPI_PROCESSOR-Dom0/drivers/xen/Kconfig
@@ -269,7 +269,7 @@ config XEN_ACPI_HOTPLUG_CPU
config XEN_ACPI_P
The two patches here are entirely independent (i.e. they could by applied
in any order and/or go through separate trees), but for the warning to go
away both are necessary.
1: x86: consider effective protection attributes in W+X check
2: x86-64/Xen: eliminate W+X pages
Signed-off-by: Jan Beulich
Using just the leaf page table entry flags would cause a false warning
in case _PAGE_RW is clear or _PAGE_NX is set in a higher level entry.
Hand through both the current entry's flags as well as the accumulated
effective value (the latter as pgprotval_t instead of pgprot_t, as it's
not an actual e
A few thousand such pages are usually left around due to the re-use of
L1 tables having been provided by the hypervisor (Dom0) or tool stack
(DomU). Set NX in the direct map variant, which needs to be done in L2
due to the dual use of the re-used L1s.
For x86_configure_nx() to actually do what it
* Jan Beulich wrote:
> Using just the leaf page table entry flags would cause a false warning
> in case _PAGE_RW is clear or _PAGE_NX is set in a higher level entry.
Good find - I assume this bug can cause both false positives and false
negatives
as well, right?
Thanks,
Ingo
__
* Jan Beulich wrote:
> A few thousand such pages are usually left around due to the re-use of
> L1 tables having been provided by the hypervisor (Dom0) or tool stack
> (DomU). Set NX in the direct map variant, which needs to be done in L2
> due to the dual use of the re-used L1s.
>
> For x86_co
>>> On 12.12.17 at 11:36, wrote:
> * Jan Beulich wrote:
>
>> Using just the leaf page table entry flags would cause a false warning
>> in case _PAGE_RW is clear or _PAGE_NX is set in a higher level entry.
>
> Good find - I assume this bug can cause both false positives and false
> negatives
>>> On 12.12.17 at 11:38, wrote:
> * Jan Beulich wrote:
>> --- 4.15-rc3/arch/x86/xen/mmu_pv.c
>> +++ 4.15-rc3-x86_64-Xen-avoid-W+X/arch/x86/xen/mmu_pv.c
>> @@ -1902,6 +1902,16 @@ void __init xen_setup_kernel_pagetable(p
>> /* Graft it onto L4[511][510] */
>> copy_page(level2_kernel_pgt,
* Jan Beulich wrote:
> >>> On 12.12.17 at 11:38, wrote:
> > * Jan Beulich wrote:
> >> --- 4.15-rc3/arch/x86/xen/mmu_pv.c
> >> +++ 4.15-rc3-x86_64-Xen-avoid-W+X/arch/x86/xen/mmu_pv.c
> >> @@ -1902,6 +1902,16 @@ void __init xen_setup_kernel_pagetable(p
> >>/* Graft it onto L4[511][510] */
>
1: don't overrun array
2: improve insn selection
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
flight 72678 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72678/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i
..., largely to shrink code size a little:
- use TEST instead of CMP with zero immediate
- use MOVZWL instead of AND with 0x immediate
- compute final highmem_bk value in registers, accessing memory just
once
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/boot/mem.S
+++ b/xen/arch/x86/boot/
The bounds check needs to be done after the increment, not before, or
else it needs to use a one lower immediate. Also use word operations
rather than byte ones for both the increment and the compare (allowing
E820_BIOS_MAX to be more easily bumped, should the need ever arise).
Signed-off-by: Jan
On 12/12/17 11:10, Jan Beulich wrote:
> The bounds check needs to be done after the increment, not before, or
> else it needs to use a one lower immediate. Also use word operations
> rather than byte ones for both the increment and the compare (allowing
> E820_BIOS_MAX to be more easily bumped, sho
On 12/12/17 11:10, Jan Beulich wrote:
> ..., largely to shrink code size a little:
> - use TEST instead of CMP with zero immediate
> - use MOVZWL instead of AND with 0x immediate
> - compute final highmem_bk value in registers, accessing memory just
> once
>
> Signed-off-by: Jan Beulich
Rev
Hi all,
Re the Windows PV drivers - I've tried v8.2.0 on Windows 10, and it required
me to put Windows into TEST MODE to still load the drivers. Bringing it out of
test mode results in the Xen PV drivers being uninstalled.
I now have to create a Windows Server 2016 DomU and I'm wondering if the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-249
version 2
broken x86 shadow mode refcount overflow check
UPDATES IN VERSION 2
Public release.
Provide metadata file.
ISSUE DESCRIPTI
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-248
version 2
x86 PV guests may gain access to internally used pages
UPDATES IN VERSION 2
Public release.
Provide metadata file.
ISSUE DESC
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-250
version 2
improper x86 shadow mode refcount error handling
UPDATES IN VERSION 2
Public release.
Provide metadata file.
ISSUE DESCRIPT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-251
version 2
improper bug check in x86 log-dirty handling
UPDATES IN VERSION 2
Public release.
Provide information for Xen 4.10-in-prep
flight 117079 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117079/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-i386
On 12/12/17 11:18, Jan Beulich wrote:
> Add a respective dependency.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
flight 117075 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117075/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl broken
test-arm64-arm64-xl-cre
flight 117080 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117080/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl broken
test-arm64-arm64-xl-c
[adhoc adhoc]
harness 67f2142: production-config[-cambridge]: update TftpDiVersion_j...
117089: trouble: broken/preparing/queued
flight 117089 xen-unstable running [adhoc]
http://logs.test-lab.xenproject.org/osstest/logs/117089/
Failures and problems with tests :-(
Tests which did not succeed a
On 12/12/17 11:48, Jan Beulich wrote:
On 12.12.17 at 11:38, wrote:
>> * Jan Beulich wrote:
>>> --- 4.15-rc3/arch/x86/xen/mmu_pv.c
>>> +++ 4.15-rc3-x86_64-Xen-avoid-W+X/arch/x86/xen/mmu_pv.c
>>> @@ -1902,6 +1902,16 @@ void __init xen_setup_kernel_pagetable(p
>>> /* Graft it onto L4[511][5
>>> On 28.11.17 at 16:08, wrote:
> @@ -1905,7 +1906,8 @@ static int mod_l1_entry(l1_pgentry_t *pl1e,
> l1_pgentry_t nl1e,
> }
>
> /* Translate foreign guest address. */
> -if ( paging_mode_translate(pg_dom) )
> +if ( cmd != MMU_PT_UPDATE_NO_TRANSLATE &&
> +
flight 117081 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117081/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm broken
build-i386
On 12/12/17 13:25, Jan Beulich wrote:
On 28.11.17 at 16:08, wrote:
>> @@ -1905,7 +1906,8 @@ static int mod_l1_entry(l1_pgentry_t *pl1e,
>> l1_pgentry_t nl1e,
>> }
>>
>> /* Translate foreign guest address. */
>> -if ( paging_mode_translate(pg_dom) )
>> +if
Replace the qcode_to_keycode table with automatically
generated tables.
Missing entries in qcode_to_keycode now fixed:
- Q_KEY_CODE_KP_COMMA -> 0x2d
Signed-off-by: Daniel P. Berrange
---
Makefile | 1 +
hw/char/escc.c | 126 +++--
This is a followup to
v1: https://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg02047.html
v2: https://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg02471.html
v3: https://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg02517.html
v4: https://lists.nongnu.org/archive/html/q
Replace the scancode2linux table with an automatically
generated table. In doing so, the XenFB keyboard
handler is also converted to the modern InputEvent
framework.
Signed-off-by: Daniel P. Berrange
---
hw/display/xenfb.c | 138 +
1 file chang
Replace the qcode_to_keycode_set1, qcode_to_keycode_set2,
and qcode_to_keycode_set3 tables with automatically
generated tables.
Missing entries in qcode_to_keycode_set1 now fixed:
- Q_KEY_CODE_SYSRQ -> 0x54
- Q_KEY_CODE_PRINT -> 0x54 (NB ignored due to special case)
- Q_KEY_CODE_AGAIN -> 0xe00
Replace the keymap_qcode table with automatically generated
tables.
Missing entries in keymap_qcode now fixed:
Q_KEY_CODE_ASTERISK -> KEY_KPASTERISK
Q_KEY_CODE_KP_MULTIPLY -> KEY_KPASTERISK
Q_KEY_CODE_STOP -> KEY_STOP
Q_KEY_CODE_AGAIN -> KEY_AGAIN
Q_KEY_CODE_PROPS -> KEY_PROPS
Q_KEY_C
>>> On 12.12.17 at 12:18, wrote:
> On 12/12/17 11:10, Jan Beulich wrote:
>> The bounds check needs to be done after the increment, not before, or
>> else it needs to use a one lower immediate. Also use word operations
>> rather than byte ones for both the increment and the compare (allowing
>> E82
>>> On 12.12.17 at 12:21, wrote:
> On 12/12/17 11:10, Jan Beulich wrote:
>> ..., largely to shrink code size a little:
>> - use TEST instead of CMP with zero immediate
>> - use MOVZWL instead of AND with 0x immediate
>> - compute final highmem_bk value in registers, accessing memory just
>>
>>> On 12.12.17 at 14:52, wrote:
> On 12/12/17 13:25, Jan Beulich wrote:
> On 28.11.17 at 16:08, wrote:
>>> @@ -1905,7 +1906,8 @@ static int mod_l1_entry(l1_pgentry_t *pl1e,
> l1_pgentry_t nl1e,
>>> }
>>>
>>> /* Translate foreign guest address. */
>>> -if ( paging
Thanks Jan for your review comments. Please see below for my
comments.
On 12/8/2017 3:34 AM, Jan Beulich
wrote:
On 07.12.17 at 23:21, wrote:
Due to the complexity with the PCI loc
flight 117076 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117076/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-amd64
The parts of this series aren't really dependent upon one another,
they belong together solely because of their origin.
1: x86/shadow: drop further 32-bit relics
2: x86/shadow: remove pointless loops over all vCPU-s
3: x86/shadow: ignore sh_pin() failure in one more case
4: x86/shadow: widen refer
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 12 December 2017 13:25
> To: Paul Durrant
> Cc: Andrew Cooper ; Wei Liu
> ; George Dunlap ; Ian
> Jackson ; Stefano Stabellini
> ; xen-devel@lists.xenproject.org; Tim (Xen.org)
>
> Subject: Re: [PATCH v14 07/11] x
Thanks Jan for your review comments. Please see below for my comments.
On 12/8/2017 3:34 AM, Jan Beulich wrote:
On 07.12.17 at 23:21, wrote:
Due to the complexity with the PCI lock we cannot do the reset when a
device is bound ('echo $BDF > bind') or when unbound ('echo $BDF > unbind')
as the
>>> On 12.12.17 at 15:48, wrote:
> Thanks Jan for your review comments. Please see below for my comments.
First of all - can you please do something about your reply style?
HTML mail should be avoided. You'll see that the (plain text) reply
as a result is rather hard to follow, too.
> --- a/Docu
PV guests don't ever get shadowed in other than 4-level mode anymore;
commit 5a3ce8f85e ("x86/shadow: drop stray name tags from
sh_{guest_get,map}_eff_l1e()") didn't go quite fare enough (and there's
a good chance that further cleanup opportunity exists, which I simply
didn't notice).
Signed-off-b
The vCPU count can be had more directly.
Signed-off-by: Jan Beulich
---
In the sh_make_shadow() case the question is whether it really was
intended to count all vCPU-s, rather than e.g. only all initialized
ones. I guess the problem would be the phase before the guest
actually starts secondary pr
Following what we've already done in the XSA-250 fix, convert another
sh_pin() caller to no longer fail the higher level operation if pinning
fails, as pinning is a performance optimization only in those places.
Suggested-by: Tim Deegan
Signed-off-by: Jan Beulich
---
Would it be worth making sh_
On Fri, Dec 08, 2017 at 02:24:24PM -0600, Bjorn Helgaas wrote:
> I'd rather change pcie_flr() so you could *always* call it, and it
> would return 0, -ENOTTY, or whatever, based on whether FLR is
> supported. Is that feasible?
>
> I don't like the "Can I do this? Ok, do this" style of interfaces.
Utilize as many of the bits available in the union as possible, without
(just to be on the safe side) colliding with any of the bits outside of
PGT_type_mask.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/private.h
+++ b/xen/arch/x86/mm/shadow/private.h
@@ -510,7 +510,7 @@ void sh_dest
Stop open-coding SHARED_M2P() and drop a pointless use of it from
paging_mfn_is_dirty() (!VALID_M2P() is a superset of SHARED_M2P()) and
another one from free_page_type() (prior assertions render this
redundant).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2371
... in preference over paging_mark_dirty(), when the PFN is known
anyway.
Signed-off-by: Jan Beulich
---
This has a contextual dependency on
https://lists.xenproject.org/archives/html/xen-devel/2017-12/msg00151.html
which is ready to go in, just waiting for the tree to fully re-open.
--- a/xen/
On 12/12/2017 9:01 AM, Jan Beulich wrote:
On 12.12.17 at 15:48, wrote:
Thanks Jan for your review comments. Please see below for my comments.
First of all - can you please do something about your reply style?
HTML mail should be avoided. You'll see that the (plain text) reply
as a result is
flight 117085 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117085/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-prev
Moving xen-devel to bcc and addressing win-pv-devel list...
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Steven Haigh
> Sent: 12 December 2017 11:33
> To: xen-de...@lists.xen.org
> Subject: [Xen-devel] Windows PV drivers and Windows
On 08/12/17 08:19, Tim Deegan wrote:
> Hi,
>
> At 02:31 -0700 on 06 Dec (1512527481), Jan Beulich wrote:
> On 30.11.17 at 10:10, wrote:
>>> i.e. the guest specified a runstate area address which has a non-present
>>> mapping in the page tables [EC=0002 CR2=88003d405220], but that's
>>> not
On 12/12/2017 1:09 AM, Manish Jaggi wrote:
> Hi Sameer,
>
> On 12/05/2017 09:29 AM, Sameer Goel wrote:
>
>> +static
>> +struct arm_smmu_device *arm_smmu_get_by_fwnode(struct fwnode_handle *fwnode)
>> +{
>> + struct arm_smmu_device *smmu = NULL;
>> +
>> + spin_lock(&arm_smmu_devices_lock);
>
[adhoc adhoc]
harness 67f2142: production-config[-cambridge]: update TftpDiVersion_j...
117103: trouble: preparing
flight 117103 xen-unstable running [adhoc]
http://logs.test-lab.xenproject.org/osstest/logs/117103/
Failures and problems with tests :-(
Tests which did not succeed and are blockin
>>> On 18.10.17 at 13:40, wrote:
> +static int vpci_portio_read(const struct hvm_io_handler *handler,
> +uint64_t addr, uint32_t size, uint64_t *data)
> +{
> +struct domain *d = current->domain;
const?
> +unsigned int reg;
> +pci_sbdf_t sbdf;
> +uint32
>>> On 18.10.17 at 13:40, wrote:
> +int __hwdom_init register_vpci_mmcfg_handler(struct domain *d, paddr_t addr,
> + unsigned int start_bus,
> + unsigned int end_bus,
> +
On 12/12/2017 03:07 PM, Jan Beulich wrote:
> Utilize as many of the bits available in the union as possible, without
> (just to be on the safe side) colliding with any of the bits outside of
> PGT_type_mask.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/mm/shadow/private.h
> +++ b/xen/ar
[adhoc adhoc]
harness 67f2142: production-config[-cambridge]: update TftpDiVersion_j...
117105: tolerable ALL FAIL
flight 117105 xen-unstable adhoc [adhoc]
http://logs.test-lab.xenproject.org/osstest/logs/117105/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking
[adhoc adhoc]
harness 67f2142: production-config[-cambridge]: update TftpDiVersion_j...
117093: trouble: broken/pass
flight 117093 xen-unstable adhoc [adhoc]
http://logs.test-lab.xenproject.org/osstest/logs/117093/
Failures and problems with tests :-(
Tests which did not succeed and are blockin
flight 117084 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117084/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
test-arm64-arm
On 12/12/2017 03:08 PM, Jan Beulich wrote:
> Stop open-coding SHARED_M2P() and drop a pointless use of it from
> paging_mfn_is_dirty() (!VALID_M2P() is a superset of SHARED_M2P()) and
> another one from free_page_type() (prior assertions render this
> redundant).
>
> Signed-off-by: Jan Beulich
>
[+cc Boris, Juergen, xen-devel]
On Mon, Dec 11, 2017 at 04:04:52PM +0100, Christian König wrote:
> Xen hides a bit of system memory from the OS for its own purpose by
> intercepting e820. This memory is unfortunately not reported as
> reserved, but rather completely invisible.
>
> Avoid this addr
On 12/12/2017 01:38 PM, Christian König wrote:
> Am 12.12.2017 um 19:12 schrieb Bjorn Helgaas:
>> [+cc Boris, Juergen, xen-devel]
>>
>> On Mon, Dec 11, 2017 at 04:04:52PM +0100, Christian König wrote:
>>> Xen hides a bit of system memory from the OS for its own purpose by
>>> intercepting e820. Thi
The only differences between copy_to_guest (formerly called
raw_copy_to_guest_helper) and raw_copy_from_guest is:
- The direction of the memcpy
- The permission use for translating the address
Extend copy_to_guest to support copying from guest VA by adding using a
bit in the flags to tell
In a follow-up patch, it will be necessary to pass more flags to the
function.
Rename flush_dcache to flags and introduce a define to tell whether the
cache needs to be flushed after the copy.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Changes in v2:
- Add Stef
The function kernel_zimage is dealing with IPA but uses gvirt_to_maddr to
do the translation. This is currently working fine because the stage-1 MMU
is disabled.
Furthermore, the function is implementing its own copy to guest resulting
in code duplication and making more difficult to update the lo
This new function will be used in a follow-up patch to copy data to the guest
using the IPA (aka guest physical address) and then clean the cache.
Signed-off-by: Julien Grall
---
Changes in v2:
- Use the new interface
---
xen/arch/arm/guestcopy.c | 9 +
xen/include
p2m_tlb_flush is called in 2 places: p2m_alloc_table and
p2m_force_tlb_flush_sync.
p2m_alloc_table is called when the domain is initialized and could be
replace by a call to p2m_force_tlb_flush_sync with the P2M write locked.
This seems a bit pointless but would allow to have a single API for
flu
Rename p2m_flush_tlb and p2m_flush_tlb_sync to respectively
p2m_tlb_flush and p2m_force_tlb_flush_sync.
At first glance, inverting 'flush' and 'tlb' might seem pointless but
would be helpful in the future in order to get more easily some code ported
from x86 P2M or even to shared with.
For p2m_f
The function dtb_load is dealing with IPA but uses gvirt_to_maddr to do
the translation. This is currently working fine because the stage-1 MMU
is disabled.
Rather than relying on such assumption, use the new
copy_to_guest_phys_flush_dcache. This also result to a slightly more
comprehensible code.
Currently, guest_copy assumes the copy will only be done for the current
vCPU. copy_guest is meant to be vCPU agnostic, so extend the prototype
to pass the vCPU.
At the same time, encapsulate the vCPU in an union to allow extension
for copying from a guest domain (ipa case) in the future.
Signed-
Multiple places in the code requires to flush the TLBs only when
p2m->need_flush is set.
Rather than open-coding it, introduce a new helper p2m_tlb_flush_sync to
do it.
Note that p2m_tlb_flush_sync is exported as it might be used by other
part of Xen.
Signed-off-by: Julien Grall
Reviewed-by: St
Hi all,
This patch series is a collection of cleanup around stage-2 handling. They
are consolidating different pieces of the hypervisor. This will make easier
to maintain and update stage-2 change in the future.
For all the changes see in each patch.
Cheers,
Julien Grall (16):
xen/arm: raw_co
The only differences between copy_to_guest and access_guest_memory_by_ipa are:
- The latter does not support copying data crossing page boundary
- The former is copying from/to guest VA whilst the latter from
guest PA
copy_to_guest can easily be extended to support copying from/to gues
The two helpers do_trap_instr_abort_guest and do_trap_data_abort_guest
are used trap stage-2 abort. While the former is only handling prefetch
abort and the latter data abort, they are very similarly and does not
warrant to have separate helpers.
For instance, merging the both will make easier to
The function copy_to_guest can easily be extended to support zeroing
guest VA. To avoid using a new bit, it is considered that a NULL buffer
(i.e buf == NULL) means the guest memory will be zeroed.
Lastly, reimplement raw_clear_guest using copy_to_guest.
Signed-off-by: Julien Grall
---
Chan
mmio_info_t is currently filled by do_trap_data_guest_abort but only
important when emulation an MMIO region.
A follow-up patch will merge stage-2 prefetch abort and stage-2 data abort
in a single helper. To prepare that, mmio_info_t is now filled by
try_handle_mmio.
Signed-off-by: Julien Grall
The function initrd_load is dealing with IPA but uses gvirt_to_maddr to
do the translation. This is currently working fine because the stage-1 MMU
is disabled.
Furthermore, the function is implementing its own copy to guest resulting
in code duplication and making more difficult to update the logi
All the helpers within arch/arm/guestcopy.c are doing the same things:
copy data from/to the guest.
At the moment, the logic is duplicated in each helpers making more
difficult to implement new variant.
The first step for the consolidation is to get a common prototype and a
base. For convenience
mmio_info_t is used to gather information in order do emulation of a
region. Guest virtual address is unlikely to be a useful information and
not currently used. So remove the field gva from mmio_info_t and replace
by a local variable.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
flight 117063 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117063/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl broken
build-amd64
On Tue, 12 Dec 2017, Julien Grall wrote:
> All the helpers within arch/arm/guestcopy.c are doing the same things:
> copy data from/to the guest.
>
> At the moment, the logic is duplicated in each helpers making more
> difficult to implement new variant.
>
> The first step for the consolidation is
On Tue, 12 Dec 2017, Julien Grall wrote:
> The only differences between copy_to_guest (formerly called
> raw_copy_to_guest_helper) and raw_copy_from_guest is:
> - The direction of the memcpy
> - The permission use for translating the address
>
> Extend copy_to_guest to support copying from
On Tue, 12 Dec 2017, Julien Grall wrote:
> The function copy_to_guest can easily be extended to support zeroing
> guest VA. To avoid using a new bit, it is considered that a NULL buffer
> (i.e buf == NULL) means the guest memory will be zeroed.
>
> Lastly, reimplement raw_clear_guest using copy_to
On Tue, 12 Dec 2017, Julien Grall wrote:
> Currently, guest_copy assumes the copy will only be done for the current
> vCPU. copy_guest is meant to be vCPU agnostic, so extend the prototype
> to pass the vCPU.
>
> At the same time, encapsulate the vCPU in an union to allow extension
> for copying f
On Tue, 12 Dec 2017, Julien Grall wrote:
> The only differences between copy_to_guest and access_guest_memory_by_ipa are:
> - The latter does not support copying data crossing page boundary
> - The former is copying from/to guest VA whilst the latter from
> guest PA
>
> copy_to_guest c
On Tue, 12 Dec 2017, Julien Grall wrote:
> This new function will be used in a follow-up patch to copy data to the guest
> using the IPA (aka guest physical address) and then clean the cache.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> Changes in v2:
>
On Tue, 12 Dec 2017, Julien Grall wrote:
> The two helpers do_trap_instr_abort_guest and do_trap_data_abort_guest
> are used trap stage-2 abort. While the former is only handling prefetch
> abort and the latter data abort, they are very similarly and does not
> warrant to have separate helpers.
>
1 - 100 of 112 matches
Mail list logo
