On Tue, Aug 14, 2018 at 01:38:09PM -0700, Christopher Clark wrote:
> Add zero-padding to #defined ACPI table strings that are copied.
> Provides sufficient characters to satisfy the length required to
> fully populate the destination and prevent array-bounds warnings.
>
> Signed-off-by: Christoph
On Tue, Aug 14, 2018 at 03:13:09PM -0700, Stefano Stabellini wrote:
> PV 9pfs requires the PV backend in QEMU. Make sure that libxl knows it.
>
> Signed-off-by: Stefano Stabellini
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenprojec
This is part of XSA-273 / CVE-2018-3646.
Signed-off-by: Jan Beulich
--- a/tools/libxc/xc_cpufeature.h
+++ b/tools/libxc/xc_cpufeature.h
@@ -147,6 +147,7 @@
/* Intel-defined CPU features, CPUID level 0x0007:0 (edx) */
#define X86_FEATURE_IBRSB 26 /* IBRS and IBPB support (used by Inte
On Wed, Aug 15, 2018 at 8:44 AM Jan Beulich wrote:
>
> >>> On 25.06.18 at 12:17, wrote:
> > This is unnecessary and triggers a warning in the hypervisor.
> >
> > Often systems have more processor entries in their ACPI tables than are
> > actually installed/active. The ACPI_STA_DEVICE_PRESENT bit
On 15/08/2018 08:47, Jan Beulich wrote:
> This is part of XSA-273 / CVE-2018-3646.
>
> Signed-off-by: Jan Beulich
Oops yes.
Acked-by: Andrew Cooper
This isn't strictly needed for security, as L1D Flush is only needed by
hypervisors, but its definitely odd to have it missing from 4.6.
~Andrew
Prevent the "BUG_ON(page_get_owner(pg) != d)" in
gnttab_unpopulate_status_frames() from triggering.
Reported-by: 王磊
Signed-off-by: Jan Beulich
---
It looks to me as if this was the only piece missing to make v2 grant
tables work on ARM, but this was build tested only anyway.
--- a/xen/include/a
Hi Konrad,
Thank you Konrad.
I tried other versions also, and Xen 4.8.5 stable branch is working
properly.
And i will investigate which patch causing this issue between xen-4.8 and
xen-4.9 branch.
Thank you,
Omkar B
--
This
message contains confidential information and is intended only
Make the version in setup.py agree with PYGRUB_VER.
Signed-off-by: Simon Rowe
---
tools/pygrub/setup.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/pygrub/setup.py b/tools/pygrub/setup.py
index 52dcf57..711bbbd 100644
--- a/tools/pygrub/setup.py
+++ b/tools/pygrub/s
On Wed, Aug 15, 2018 at 09:08:07AM +0100, Simon Rowe wrote:
> Make the version in setup.py agree with PYGRUB_VER.
>
> Signed-off-by: Simon Rowe
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/m
This is part of CVE-2018-3639 / XSA-263.
Signed-off-by: Jan Beulich
--- a/tools/libxc/xc_cpufeature.h
+++ b/tools/libxc/xc_cpufeature.h
@@ -147,5 +147,6 @@
/* Intel-defined CPU features, CPUID level 0x0007:0 (edx) */
#define X86_FEATURE_IBRSB 26 /* IBRS and IBPB support (used by Inte
>>> On 15.08.18 at 09:57, wrote:
> On 15/08/2018 08:47, Jan Beulich wrote:
>> This is part of XSA-273 / CVE-2018-3646.
>>
>> Signed-off-by: Jan Beulich
>
> Oops yes.
>
> Acked-by: Andrew Cooper
>
> This isn't strictly needed for security, as L1D Flush is only needed by
> hypervisors, but its
ded2a37d63 added const to atomic_read. Do the same for Arm
counterpart.
Signed-off-by: Wei Liu
---
Cc: Stefano Stabellini
Cc: Julien Grall
Cc: Jan Beulich
Cc: Andrew Cooper
Breakage due to XSA-273 changes.
---
xen/include/asm-arm/atomic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-
On 15/08/2018 09:28, Wei Liu wrote:
> ded2a37d63 added const to atomic_read. Do the same for Arm
> counterpart.
>
> Signed-off-by: Wei Liu
Acked-by: Andrew Cooper
Most likely needed for 4.6 as well.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists
7d98594e6e added const to atomic_read. Do the same for Arm
counterpart.
Signed-off-by: Wei Liu
---
Cc: Stefano Stabellini
Cc: Julien Grall
Cc: Jan Beulich
Cc: Andrew Cooper
Breakage from XSA-273 changes.
---
xen/include/asm-arm/atomic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On 08/15/2018 09:29 AM, Andrew Cooper wrote:
On 15/08/2018 09:28, Wei Liu wrote:
ded2a37d63 added const to atomic_read. Do the same for Arm
counterpart.
Signed-off-by: Wei Liu
Acked-by: Andrew Cooper
Most likely needed for 4.6 as well.
Feel free to add my ack on 4.6 patch as well:
Ack
flight 125899 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125899/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken in 125874
build-arm64
On Wed, Aug 15, 2018 at 09:51:35AM +0100, Julien Grall wrote:
>
>
> On 08/15/2018 09:29 AM, Andrew Cooper wrote:
> > On 15/08/2018 09:28, Wei Liu wrote:
> > > ded2a37d63 added const to atomic_read. Do the same for Arm
> > > counterpart.
> > >
> > > Signed-off-by: Wei Liu
> >
> > Acked-by: Andr
HI Julien,
As you suggested, I enabled early printk for hikey960 in xen-4.8 stable
branch and xen-4.11 stable branch.
Please find below xen-4.8 log after early printk:
--
Using modules provided by bootloader in FDT
Xen 4.8.5-pre (c/s Mon Jul
Hi,
On 08/15/2018 12:25 AM, Rich Persaud wrote:
On Aug 14, 2018, at 18:46, Julien Grall wrote:
Hi Rich,
On 08/14/2018 11:42 PM, Rich Persaud wrote:
On Aug 13, 2018, at 10:57, Ian Jackson wrote:
Both our arm64 boxes are out of commission and repairing them is
taking too long.
Apologies i
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/pv/domain.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
index 3230ac6..52108d4 100644
--- a/xen/arch/x86/pv/d
On Wed, Aug 15, 2018 at 10:54:11AM +0100, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
flight 125916 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125916/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen aa67b97ed34279c43a43d9ca46727b5746caa92e
baseline version:
xen ed5f
Apparently a copy-and-paste mistake.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -232,7 +232,7 @@ static __init int parse_pv_l1tf(const ch
/* Interpret 'pv-l1tf' alone in its positive boolean form. */
if ( *s == '\0' )
-opt_xpti
On 15/08/18 11:34, Jan Beulich wrote:
> Apparently a copy-and-paste mistake.
>
> Signed-off-by: Jan Beulich
Yikes.
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-
On 15/08/18 09:21, Jan Beulich wrote:
> This is part of CVE-2018-3639 / XSA-263.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Paul Durrant writes ("[PATCH] qemu-trad: stop using the default IOREQ server"):
> Because qemu-trad is using the legacy HVM param mechanism of hooking into
> Xen, it means that Xen has to maintain the notion of a 'default' IOREQ
> server which is where all I/O goes if no other device model claims i
>>> On 15.08.18 at 11:58, wrote:
> On Wed, Aug 15, 2018 at 10:54:11AM +0100, Andrew Cooper wrote:
>> Signed-off-by: Andrew Cooper
>
> Reviewed-by: Wei Liu
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://li
It took till the 4.5 backports of the L1TF prereqs that gcc 8.2 finally
noticed that the vPMU callers, not checking the function's return value,
may consume uninitialized data. Guard against this by storing zero on
the error path.
Signed-off-by: Jan Beulich
--- a/xen/include/asm-x86/hvm/vmx/vmcs
On 15/08/18 12:34, Jan Beulich wrote:
> It took till the 4.5 backports of the L1TF prereqs that gcc 8.2 finally
> noticed that the vPMU callers, not checking the function's return value,
> may consume uninitialized data. Guard against this by storing zero on
> the error path.
>
> Signed-off-by: Jan
>>> On 15.08.18 at 13:39, wrote:
> On 15/08/18 12:34, Jan Beulich wrote:
>> It took till the 4.5 backports of the L1TF prereqs that gcc 8.2 finally
>> noticed that the vPMU callers, not checking the function's return value,
>> may consume uninitialized data. Guard against this by storing zero on
>
flight 125918 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125918/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
>>> On 10.08.18 at 16:48, wrote:
> When emulating a rep I/O operation it is possible that the ioreq will
> describe a single operation that spans multiple GFNs. This is fine as long
> as all those GFNs fall within an MMIO region covered by a single device
> model, but unfortunately the higher leve
Please wire up a compat_ioctl handler for the xen privcmd handler
instead of adding these to a global table.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
>>> On 13.08.18 at 12:01, wrote:
> ... rather than setting it up once domain_create() has completed. This
> involves constructing a default value for dom0.
>
> No practical change in functionality.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
_
On 15/08/18 13:41, Jan Beulich wrote:
On 10.08.18 at 16:48, wrote:
>> When emulating a rep I/O operation it is possible that the ioreq will
>> describe a single operation that spans multiple GFNs. This is fine as long
>> as all those GFNs fall within an MMIO region covered by a single device
>>> On 13.08.18 at 12:01, wrote:
> ... rather than setting the limits up after domain_create() has completed.
>
> This removes all the gnttab infrastructure for calculating the number of dom0
> grant frames, opting instead to require the dom0 construction code to pass a
> sane value in via the co
On Wed, Aug 15, 2018 at 12:19:00AM -0600, Jan Beulich wrote:
> While this is only a start (IOCTL_PRIVCMD_MMAP* and IOCTL_PRIVCMD_DM_OP
> require more work), it at least allows some simple operations (like
> "xl dmesg") which have always been available on XenoLinux to work again
> with a 64-bit kern
>>> On 13.08.18 at 12:01, wrote:
> Now that the max_{grant,maptrack}_frames are specified from the very beginning
> of grant table construction, the various initialisation functions can be
> folded together and simplified as a result.
>
> Leave grant_table_init() as the public interface, which is
>>> On 13.08.18 at 12:01, wrote:
> This is in preparation to set up d->max_cpus and d->vcpu[] in domain_create(),
> and allow later parts of domain construction to have access to the values.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
__
Hi Andrew,
On 08/13/2018 11:01 AM, Andrew Cooper wrote:
... rather than setting it up once domain_create() has completed. This
involves constructing a default value for dom0.
No practical change in functionality.
Signed-off-by: Andrew Cooper
For the Arm bits:
Acked-by: Julien Grall
Chee
>>> On 13.08.18 at 12:01, wrote:
> Make dom0_max_vcpus() a common interface, and implement it on ARM by splitting
> the existing alloc_dom0_vcpu0() function in half.
>
> As domain_create() doesn't yet set up the vcpu array, the max value is also
> passed into alloc_dom0_vcpu0(). This is temporar
Hi Andrew,
On 08/13/2018 11:01 AM, Andrew Cooper wrote:
... rather than setting the limits up after domain_create() has completed.
This removes all the gnttab infrastructure for calculating the number of dom0
grant frames, opting instead to require the dom0 construction code to pass a
sane valu
flight 125898 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125898/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125702
test-armhf-armhf-libvirt 14 saver
On 15/08/18 14:04, Julien Grall wrote:
> Hi Andrew,
>
> On 08/13/2018 11:01 AM, Andrew Cooper wrote:
>> ... rather than setting the limits up after domain_create() has
>> completed.
>>
>> This removes all the gnttab infrastructure for calculating the number
>> of dom0
>> grant frames, opting instea
Hi all: I put an agenda + minutes link at
https://docs.google.com/document/d/1zf9saqOvxAsIDvHPIFpzy56zsUdhu4LcHouQ0Uf2RGw/edit?usp=sharing
I added L1 Terminal Fault to the agenda (as this likely will come up under AOB
anyway)
Lars
On 14/08/2018, 09:12, "Sergey Dyasli" wrote:
On Mon, 2018-
>>> On 13.08.18 at 12:01, wrote:
> @@ -423,6 +436,11 @@ struct domain *domain_create(domid_t domid,
>
> sched_destroy_domain(d);
>
> +if ( d->max_vcpus )
> +{
> +d->max_vcpus = 0;
> +XFREE(d->vcpu);
> +}
> if ( init_status & INIT_arch )
> arch_dom
>>> On 15.08.18 at 14:51, wrote:
> On Wed, Aug 15, 2018 at 12:19:00AM -0600, Jan Beulich wrote:
>> While this is only a start (IOCTL_PRIVCMD_MMAP* and IOCTL_PRIVCMD_DM_OP
>> require more work), it at least allows some simple operations (like
>> "xl dmesg") which have always been available on XenoL
Hello,
Now that the embargo on XSA-273 is up, we can start publicly discussing
the remaining work do, because there is plenty to do. In no particular
order...
1) Attempting to shadow dom0 from boot leads to some assertions very
very quickly. Shadowing dom0 after-the-fact leads to some very wei
Hi,
On 08/14/2018 04:17 PM, Roger Pau Monné wrote:
On Mon, Aug 13, 2018 at 11:01:09AM +0100, Andrew Cooper wrote:
For ARM, the call to arch_domain_create() needs to have completed before
domain_max_vcpus() will return the correct upper bound.
For each arch's dom0's, drop the temporary max_vcpu
On 15/08/18 14:17, Andrew Cooper wrote:
> Hello,
Apologies. Getting Dario's correct email address this time.
>
> Now that the embargo on XSA-273 is up, we can start publicly discussing
> the remaining work do, because there is plenty to do. In no particular
> order...
>
> 1) Attempting to shado
>>> On 09.08.18 at 11:20, wrote:
> --- a/xen/arch/x86/hvm/mtrr.c
> +++ b/xen/arch/x86/hvm/mtrr.c
> @@ -718,52 +718,56 @@ int hvm_set_mem_pinned_cacheattr(struct domain *d,
> uint64_t gfn_start,
> return 0;
> }
>
> -static int hvm_save_mtrr_msr(struct domain *d, hvm_domain_context_t *h)
>
>>> On 09.08.18 at 11:20, wrote:
> This is used to save data from a single instance.
>
> Signed-off-by: Alexandru Isaila
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listin
On 15/08/18 12:00, Ian Jackson wrote:
> Paul Durrant writes ("[PATCH] qemu-trad: stop using the default IOREQ
> server"):
>> Because qemu-trad is using the legacy HVM param mechanism of hooking into
>> Xen, it means that Xen has to maintain the notion of a 'default' IOREQ
>> server which is where
On Wed, Aug 15, 2018 at 07:16:43AM -0600, Jan Beulich wrote:
> >>> On 15.08.18 at 14:51, wrote:
> > On Wed, Aug 15, 2018 at 12:19:00AM -0600, Jan Beulich wrote:
> >> While this is only a start (IOCTL_PRIVCMD_MMAP* and IOCTL_PRIVCMD_DM_OP
> >> require more work), it at least allows some simple oper
>>> On 09.08.18 at 11:20, wrote:
> This is used to save data from a single instance.
>
> Signed-off-by: Alexandru Isaila
Reviewed-by: Jan Beulich
albeit I'm a little puzzled why ...
> --- a/xen/arch/x86/hvm/vlapic.c
> +++ b/xen/arch/x86/hvm/vlapic.c
> @@ -1458,26 +1458,33 @@ static int lapic_
Hi Andrew,
On 08/15/2018 02:08 PM, Andrew Cooper wrote:
On 15/08/18 14:04, Julien Grall wrote:
Hi Andrew,
On 08/13/2018 11:01 AM, Andrew Cooper wrote:
... rather than setting the limits up after domain_create() has
completed.
This removes all the gnttab infrastructure for calculating the num
>>> On 09.08.18 at 11:21, wrote:
> @@ -148,6 +145,11 @@ int hvm_save_one(struct domain *d, unsigned int
> typecode, unsigned int instance,
> !hvm_sr_handlers[typecode].save )
> return -EINVAL;
>
> +if ( hvm_sr_handlers[typecode].kind == HVMSR_PER_VCPU &&
> +instan
On 15/08/18 14:17, Julien Grall wrote:
>>> diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
>>> index 832632a..4124817 100644
>>> --- a/xen/arch/arm/vgic/vgic.c
>>> +++ b/xen/arch/arm/vgic/vgic.c
>>> @@ -951,27 +951,7 @@ void vgic_sync_hardware_irq(struct domain *d,
>>> unsigned
Hi Andrew,
On 08/15/2018 02:50 PM, Andrew Cooper wrote:
On 15/08/18 14:17, Julien Grall wrote:
diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index 832632a..4124817 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -951,27 +951,7 @@ void vgic_sync_hardwar
On 15/08/18 14:52, Julien Grall wrote:
> Hi Andrew,
>
> On 08/15/2018 02:50 PM, Andrew Cooper wrote:
>> On 15/08/18 14:17, Julien Grall wrote:
> diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
> index 832632a..4124817 100644
> --- a/xen/arch/arm/vgic/vgic.c
> +++ b/
On 15/08/18 14:11, Jan Beulich wrote:
On 13.08.18 at 12:01, wrote:
>> @@ -423,6 +436,11 @@ struct domain *domain_create(domid_t domid,
>>
>> sched_destroy_domain(d);
>>
>> +if ( d->max_vcpus )
>> +{
>> +d->max_vcpus = 0;
>> +XFREE(d->vcpu);
>> +}
>> i
On 15/08/18 15:21, Andrew Cooper wrote:
> On 15/08/18 14:17, Andrew Cooper wrote:
>> Hello,
>
> Apologies. Getting Dario's correct email address this time.
>
>>
>> Now that the embargo on XSA-273 is up, we can start publicly discussing
>> the remaining work do, because there is plenty to do. In
>>> On 15.08.18 at 15:17, wrote:
> 2) 32bit PV guests which use writeable pagetable support will
> automatically get shadowed when the clear the lower half.
... of a page table entry.
> Ideally, such
> guests should be modified to use hypercalls rather than the ptwr
> infrastructure (as its mor
On 15/08/18 16:10, Jan Beulich wrote:
On 15.08.18 at 15:17, wrote:
>> 2) 32bit PV guests which use writeable pagetable support will
>> automatically get shadowed when the clear the lower half.
>
> ... of a page table entry.
>
>> Ideally, such
>> guests should be modified to use hypercalls
flight 125920 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125920/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 125901 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125901/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt broken
build-arm64-xsm
On Aug 15, 2018, at 05:29, Julien Grall wrote:
>
> Hi,
>
>> On 08/15/2018 12:25 AM, Rich Persaud wrote:
>>> On Aug 14, 2018, at 18:46, Julien Grall wrote:
>>>
>>> Hi Rich,
>>>
> On 08/14/2018 11:42 PM, Rich Persaud wrote:
> On Aug 13, 2018, at 10:57, Ian Jackson wrote:
>
> B
>>> On 15.08.18 at 16:03, wrote:
> On 15/08/18 14:11, Jan Beulich wrote:
> On 13.08.18 at 12:01, wrote:
>>> @@ -423,6 +436,11 @@ struct domain *domain_create(domid_t domid,
>>>
>>> sched_destroy_domain(d);
>>>
>>> +if ( d->max_vcpus )
>>> +{
>>> +d->max_vcpus = 0;
>>>
>>> On 09.08.18 at 21:42, wrote:
> Edit the initialization code for AMD's SSBD via the LS_CFG MSR and
> enable it to pass the status to the initial spec-ctrl print_details at
> boot.
>
> Signed-off-by: Brian Woods
> ---
Please have a brief revision log here.
> --- a/xen/arch/x86/cpu/amd.c
> ++
Andrew Cooper writes ("[PATCH] qemu-trad: stop using the default IOREQ server"):
> Paul is OoO for a while, so replying on his behalf.
Thank you.
> Qemu-trad has no support for MMCFG, which is the memory mapped interface
> which supersedes the more legacy cfc/cf8 handling for PCI config space
> a
>>> On 09.08.18 at 21:42, wrote:
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -611,14 +611,9 @@ static void init_amd(struct cpuinfo_x86 *c)
> ssbd_amd_ls_cfg_mask = 1ull << bit;
> }
>
> - if (ssbd_amd_ls_cfg_mask && !rdmsr_safe(MSR_AMD64_LS_C
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2018-14678 / XSA-274
version 3
Linux: Uninitialized state in x86 PV failsafe callback path
UPDATES IN VERSION 3
Fix spelling in CREDITS.
ISSUE DESCRIP
From: Paul Durrant
Because qemu-trad is using the legacy HVM param mechanism of hooking into
Xen, it means that Xen has to maintain the notion of a 'default' IOREQ
server which is where all I/O goes if no other device model claims it.
Maintaining this code in Xen has a cost and it would be good i
OSVW data is technically per-cpu, but it is the firmwares reponsibility to
make it equivelent on each cpu. A guests OSVW data is sources from global
data in Xen, clearly making it per-domain data rather than per-vcpu data.
Move the data from struct arch_svm_struct to struct svm_domain, and call
s
flight 125903 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125903/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814
build-amd64-libvirt
On Wed, 15 Aug 2018, Jan Beulich wrote:
> Prevent the "BUG_ON(page_get_owner(pg) != d)" in
> gnttab_unpopulate_status_frames() from triggering.
>
> Reported-by: 王磊
> Signed-off-by: Jan Beulich
>
> ---
> It looks to me as if this was the only piece missing to make v2 grant
> tables work on ARM, b
Newer versions of binutils are capable of emitting an exact number bytes worth
of optimised nops, which are P6 nops. Use this in preference to .skip when
available.
Check at boot time whether the toolchain nops are the correct for the running
hardware, andskip optimising nops entirely when possib
On 08/15/2018 10:15 AM, Omkar Bolla wrote:
HI Julien,
Hello,
As you suggested, I enabled early printk for hikey960 in xen-4.8 stable
branch and xen-4.11 stable branch.
Looking at the logs, Xen is placed differently in the memory:
- Xen 4.8: 0x1aa0
- Xen 4.11: 0x
On Tue, Jul 24, 2018 at 07:42:21AM -0600, Jan Beulich wrote:
> >>> On 12.07.18 at 09:29, wrote:
> > Forgot to Cc maintainers.
>
> Konrad, Ross: Ping?
Reviewed-by: Konrad Rzeszutek Wilk
Thank you!
>
> Jan
>
> > On Wed, Jul 11, 2018 at 05:34:49PM +0200, Roger Pau Monne wrote:
> >> And replace t
Use bool when appropraite, remove extranious brackets and fix up comment
style.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/mm/shadow/types.h | 22 --
1 file changed, 12 insertions
Remove an unecessary if().
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/mm/shadow/common.c | 2 +-
xen/arch/x86/mm/shadow/multi.c | 3 +--
xen/include/asm-x86/domain.h| 2 +-
3 files changed, 3 in
... as the only user of sl1mfn would prefer it that way.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/mm/shadow/common.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/
Replace pfn_to_paddr(mfn_x(...)) with mfn_to_maddr(), and replace an opencoded
gfn_to_gaddr().
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/mm/shadow/multi.c | 11 +--
1 file changed, 5 inserti
Drop the now-unused SH_L1E_MMIO_GFN_SHIFT definition.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/mm/shadow/types.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x8
Use l1e_get_mfn() in place of l1e_get_pfn() when applicable, and fix up style
on affected lines.
For sh_remove_shadow_via_pointer(), map_domain_page() is guaranteed to succeed
so there is no need to ASSERT() its success. This allows the pointer
arithmetic to folded into the previous expression, a
Minor cleanup which has accumulated while doing other work. No functional
change anywhere.
Andrew Cooper (6):
x86/mm: Use mfn_eq()/mfn_add() rather than opencoded variations
x86/shadow: Use more appropriate conversion functions
x86/shadow: Switch shadow_domain.has_fast_mmio_entries to bool
flight 75071 distros-debian-squeeze real [real]
http://osstest.xensource.com/osstest/logs/75071/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-i386-squeeze-netboot-pygrub 10 debian-di-install fail like
75053
test-amd64-amd64-i386-squeeze-ne
flight 125923 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125923/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On Tue, 14 Aug 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 08/14/2018 10:33 PM, Stefano Stabellini wrote:
> > On Mon, 16 Jul 2018, Julien Grall wrote:
> > > Currently, lpae_is_{table, mapping} helpers will always return false on
> > > entry with the valid bit unset. However, it would be useful
On 15/08/18 14:32, Julien Grall wrote:
> Hi Andrew,
#ifdef CONFIG_ARM_32
/*
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 45f3841..3d3b30c 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -20,6 +20,7 @@
#include
On Mon, 13 Aug 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 01/08/18 00:27, Stefano Stabellini wrote:
> > Move generic initializations out of construct_dom0 so that they can be
> > reused.
> >
> > Rename prepare_dtb to prepare_dtb_hwdom to avoid confusion.
> >
> > No functional changes in this
On Mon, 13 Aug 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 01/08/18 00:27, Stefano Stabellini wrote:
> > Call a new function, "create_domUs", from setup_xen to start DomU VMs.
> >
> > Introduce support for the "xen,domU" compatible node on device tree.
> > Create new DomU VMs based on the info
On Mon, 13 Aug 2018, Julien Grall wrote:
> On 01/08/18 00:27, Stefano Stabellini wrote:
> > Call a new function, "create_domUs", from setup_xen to start DomU VMs.
> >
> > Introduce support for the "xen,domU" compatible node on device tree.
> > Create new DomU VMs based on the information found on
On Mon, 13 Aug 2018, Julien Grall wrote:
> Hi,
>
> Title: You don't really introduce "construct_domU". You implement it. So a
> better title would be "Implement construct_domU".
OK
> On 01/08/18 00:27, Stefano Stabellini wrote:
> > Similar to construct_dom0, construct_domU creates a barebone Do
On Mon, 13 Aug 2018, Julien Grall wrote:
> Hi,
>
> On 01/08/18 00:27, Stefano Stabellini wrote:
> > allocate_memory only deals with directly mapped memory. Rename it to
> > allocate_memory_11.
> >
> > Signed-off-by: Stefano Stabellini
> >
> > ---
> > Changes in v3:
> > - add patch
> > ---
> >
flight 125928 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125928/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 125923
Tests which
On Mon, 13 Aug 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 01/08/18 00:28, Stefano Stabellini wrote:
> > Introduce functions to generate a basic domU device tree, similar to the
> > existing functions in tools/libxl/libxl_arm.c.
> >
> > Signed-off-by: Stefano Stabellini
> > ---
> > Changes in
On 07/02/2018 09:54 AM, Juergen Gross wrote:
> On 25/06/18 12:34, Jan Beulich wrote:
>> Its only caller is __init, so to avoid section mismatch warnings when a
>> compiler decides to not inline the function marke this function so as
>> well. Take the opportunity and also make the function actually
On 07/02/2018 09:52 AM, Juergen Gross wrote:
> On 25/06/18 12:19, Jan Beulich wrote:
>> This already gets done in HYPERVISOR_mca().
>>
>> Signed-off-by: Jan Beulich
> Reviewed-by: Juergen Gross
>
Applied to for-linus-4.19.
-boris
___
Xen-devel maili
On 07/02/2018 10:38 AM, Juergen Gross wrote:
> On 25/06/18 12:45, Jan Beulich wrote:
>> As the sequence of invocations matters, add "tty" only after "hvc" when
>> a VGA console is available (which is often the case for Dom0, but hardly
>> ever for DomU).
>>
>> Signed-off-by: Jan Beulich
> Reviewed
1 - 100 of 123 matches
Mail list logo
