From: Razvan Cojocaru
For the default EPT view we have xc_set_mem_access_multi(), which
is able to set an array of pages to an array of access rights with
a single hypercall. However, this functionality was lacking for the
altp2m subsystem, which could only set page restrictions for one
page at a
On Tue, Dec 12, 2017 at 09:07:46AM +, Paul Durrant wrote:
>> -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
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. This memory is unfortunately not reported as
reserved, but rather
flight 117101 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117101/
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
Any comments on this patch?. Thanks.
On 12/7/2017 4:26 PM, Govinda Tatti wrote:
The life-cycle of a PCI device in Xen pciback is complex and is constrained
by the generic PCI locking mechanism.
- It starts with the device being bound to us, for which we do a function
reset (done via SysFS so
For certain applications it is desirable to rapidly boot a KVM virtual
machine. In cases where legacy hardware and software support within the
guest is not needed, Qemu should be able to boot directly into the
uncompressed Linux kernel binary without the need to run firmware.
There already exists
The start info structure that is defined as part of the x86/HVM direct
boot ABI and used for starting Xen PVH guests would be more versatile if
it also included a way to pass information about the memory map to the
guest. This would allow KVM guests to share the same entry point.
---
include/xen/i
Changes from v2:
* All structures (including memory map table entries) are padded and
aligned to an 8 byte boundary.
* Removed the "packed" attributes and made changes to comments as
suggested by Jan.
Changes from v1:
* Adopted Paolo's suggestion for defining a v2 PVH ABI that include
Commit f5775e0b6116 ("x86/xen: discard RAM regions above the maximum
reservation") left host memory not assigned to dom0 as available for
memory hotplug.
Unfortunately this also meant that those regions could be used by
others. Specifically, commit fa564ad96366 ("x86/PCI: Enable a 64bit BAR
on AMD
I have the following traceback from xen-netback, under kernel 4.9.58.
Does anyone know what might be going on here?
[ cut here ]
kernel BUG at drivers/net/xen-netback/rx.c:325!
invalid opcode: [#1] SMP
task: 88028f18cec0 task.stack: c90045e08000
RIP: e030:[]
On 12/12/2017 05:18 AM, Jan Beulich wrote:
> Add a respective dependency.
>
> Signed-off-by: Jan Beulich
Committed to for-linus-4.15.
-boris
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-d
On 12/08/2017 06:17 AM, Jan Beulich wrote:
> Unconditionally reporting a value seen on the P4 or older invokes
> functionality like io_apic_get_unique_id() on 32-bit builds, resulting
> in a panic() with sufficiently many CPUs and/or IO-APICs. Doing what
> that function does would be the hypervisor
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.
>
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 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:
> 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 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:
> 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:
> 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
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
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
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 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
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
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
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
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-
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.
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
[+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 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
>
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
[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
[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
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
>>> 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 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
[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 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);
>
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
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
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
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
... 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/
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
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
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_
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
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
>>> 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
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
> -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
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
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
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
>>> 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
>>> 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 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
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
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 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
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
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 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 &&
> +
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
[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
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
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
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 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
-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
-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-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-249
version 2
broken x86 shadow mode refcount overflow check
UPDATES IN VERSION 2
Public release.
Provide metadata file.
ISSUE DESCRIPTI
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
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
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
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
..., 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/
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
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
* 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] */
>
>>> 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,
>>> 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
* 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
* 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
__
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
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
1 - 100 of 112 matches
Mail list logo