On Fri, Aug 17, 2018 at 11:41:24AM +0200, David Hildenbrand wrote:
> On 17.08.2018 11:03, Rafael J. Wysocki wrote:
> > On Fri, Aug 17, 2018 at 10:56 AM David Hildenbrand wrote:
> >>
> >> On 17.08.2018 10:41, Greg Kroah-Hartman wrote:
> >>> On Fri, Aug 17, 2018 at 09:59:00AM +0200, David
>>> On 14.08.18 at 15:43, wrote:
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -1304,11 +1304,9 @@ static void __hwdom_init intel_iommu_hwdom_init(struct
> domain *d)
> {
> struct acpi_drhd_unit *drhd;
>
> -if ( !iommu_hwdom_passthrough
On 17/08/2018 10:52, Roger Pau Monné wrote:
> On Fri, Aug 17, 2018 at 11:50:53AM +0200, Roger Pau Monne wrote:
>> Fixes the ARM build breakage introduced by 54ed251dc7.
> It's not a build fix but a runtime fix, so the 'build' in the above
> sentence should be removed if this ends up in the repo.
On Fri, Aug 17, 2018 at 03:41:31AM -0600, Jan Beulich wrote:
> >>> On 17.08.18 at 11:29, wrote:
> > As said in the commit message, this is done to avoid an extra check in
> > get_page_from_l1e I assume, so should the extra check also be dropped
> > here?
>
> I'm afraid I don't understand: I
On Fri, Aug 17, 2018 at 11:50:53AM +0200, Roger Pau Monne wrote:
> Fixes the ARM build breakage introduced by 54ed251dc7.
It's not a build fix but a runtime fix, so the 'build' in the above
sentence should be removed if this ends up in the repo.
___
>>> On 14.08.18 at 15:43, wrote:
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -681,6 +681,19 @@ Flag that makes a dom0 boot in PVHv2 mode.
> Flag that makes a dom0 use shadow paging. Only works when "pvh" is
> enabled.
>
> +### dom0-iommu
> +>
On Fri, Aug 17, 2018 at 03:20:11AM -0600, Jan Beulich wrote:
> Rather than special casing the ->iomem_caps check in x86's
> get_page_from_l1e() for the dom_xen case, let's be more tolerant in
> general, along the lines of rangeset_is_empty(): A never allocated
> rangeset can't possibly contain or
Fixes the ARM build breakage introduced by 54ed251dc7.
Signed-off-by: Roger Pau Monné
---
I've only build-tested this on x86.
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/libxc/xc_domain.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index
>>> On 14.08.18 at 15:43, wrote:
> To iommu_hwdom_strict and iommu_hwdom_passthrough which is more
> descriptive of their usage. Also change their type from bool_t to
> bool.
>
> No functional change.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
with one remark:
> @@ -175,7
>>> On 17.08.18 at 11:29, wrote:
> On Fri, Aug 17, 2018 at 03:20:11AM -0600, Jan Beulich wrote:
>> Rather than special casing the ->iomem_caps check in x86's
>> get_page_from_l1e() for the dom_xen case, let's be more tolerant in
>> general, along the lines of rangeset_is_empty(): A never
On 17.08.2018 11:03, Rafael J. Wysocki wrote:
> On Fri, Aug 17, 2018 at 10:56 AM David Hildenbrand wrote:
>>
>> On 17.08.2018 10:41, Greg Kroah-Hartman wrote:
>>> On Fri, Aug 17, 2018 at 09:59:00AM +0200, David Hildenbrand wrote:
From: Vitaly Kuznetsov
Well require to call
>>> On 17.08.18 at 10:59, wrote:
> On 17/08/2018 08:21, Jan Beulich wrote:
>> --- a/xen/include/asm-x86/asm_defns.h
>> +++ b/xen/include/asm-x86/asm_defns.h
>> @@ -186,6 +186,20 @@ void ret_from_intr(void);
>> UNLIKELY_END_SECTION "\n" \
>> ".Llikely." #tag ".%=:"
>>
On Fri, Aug 17, 2018 at 03:20:11AM -0600, Jan Beulich wrote:
> Rather than special casing the ->iomem_caps check in x86's
> get_page_from_l1e() for the dom_xen case, let's be more tolerant in
> general, along the lines of rangeset_is_empty(): A never allocated
> rangeset can't possibly contain or
Rather than special casing the ->iomem_caps check in x86's
get_page_from_l1e() for the dom_xen case, let's be more tolerant in
general, along the lines of rangeset_is_empty(): A never allocated
rangeset can't possibly contain or overlap any range.
Reported-by: Andrew Cooper
Signed-off-by: Jan
On Fri, Aug 17, 2018 at 10:56 AM David Hildenbrand wrote:
>
> On 17.08.2018 10:41, Greg Kroah-Hartman wrote:
> > On Fri, Aug 17, 2018 at 09:59:00AM +0200, David Hildenbrand wrote:
> >> From: Vitaly Kuznetsov
> >>
> >> Well require to call add_memory()/add_memory_resource() with
> >>
On 17/08/2018 08:21, Jan Beulich wrote:
> --- a/xen/include/asm-x86/asm_defns.h
> +++ b/xen/include/asm-x86/asm_defns.h
> @@ -186,6 +186,20 @@ void ret_from_intr(void);
> UNLIKELY_END_SECTION "\n" \
> ".Llikely." #tag ".%=:"
>
> +#define LINKONCE_PROLOGUE(sym)
On Fri, Aug 17, 2018 at 10:41 AM Greg Kroah-Hartman
wrote:
>
> On Fri, Aug 17, 2018 at 09:59:00AM +0200, David Hildenbrand wrote:
> > From: Vitaly Kuznetsov
> >
> > Well require to call add_memory()/add_memory_resource() with
> > device_hotplug_lock held, to avoid a lock inversion. Allow
On 17.08.2018 10:41, Greg Kroah-Hartman wrote:
> On Fri, Aug 17, 2018 at 09:59:00AM +0200, David Hildenbrand wrote:
>> From: Vitaly Kuznetsov
>>
>> Well require to call add_memory()/add_memory_resource() with
>> device_hotplug_lock held, to avoid a lock inversion. Allow external modules
>> (e.g.
On Thu, Aug 16, 2018 at 10:43:54AM -0600, Tamas K Lengyel wrote:
> I double checked and the option is set properly but I'm still getting
> the same non-present entry faults as before. At the moment I don't
> have serial access so not sure how to verify that the option took
> effect. This is my
On 17/08/2018 08:23, Jan Beulich wrote:
> ... and (of course) also maddr / direct-map-offset ones.
>
> Most x86 systems don't actually require the use of PDX compression. Now
> that we have patching for the conversion code in place anyway, extend it
> to use simple MOV when possible. Introduce a
On Fri, Aug 17, 2018 at 09:59:00AM +0200, David Hildenbrand wrote:
> From: Vitaly Kuznetsov
>
> Well require to call add_memory()/add_memory_resource() with
> device_hotplug_lock held, to avoid a lock inversion. Allow external modules
> (e.g. hv_balloon) that make use of
On 17/08/2018 08:20, Jan Beulich wrote:
> Subsequent changes require this (too wide anyway imo) dependency to be
> dropped.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On 17.08.2018 10:20, Rafael J. Wysocki wrote:
> On Fri, Aug 17, 2018 at 9:59 AM David Hildenbrand wrote:
>>
>> There seem to be some problems as result of 30467e0b3be ("mm, hotplug:
>> fix concurrent memory hot-add deadlock"), which tried to fix a possible
>> lock inversion reported and discussed
On Fri, Aug 17, 2018 at 9:59 AM David Hildenbrand wrote:
>
> There seem to be some problems as result of 30467e0b3be ("mm, hotplug:
> fix concurrent memory hot-add deadlock"), which tried to fix a possible
> lock inversion reported and discussed in [1] due to the two locks
> a)
>>> On 16.08.18 at 18:43, wrote:
> Booting just linux with both options works just fine, I grepped the
> dmesg log for the device that causes the issues with Xen but there are
> no errors in the log:
Well, this as well as ...
> I double checked and the option is set properly but I'm still
From: Vitaly Kuznetsov
Well require to call add_memory()/add_memory_resource() with
device_hotplug_lock held, to avoid a lock inversion. Allow external modules
(e.g. hv_balloon) that make use of add_memory()/add_memory_resource() to
lock device hotplug.
Signed-off-by: Vitaly Kuznetsov
[modify
There seem to be some problems as result of 30467e0b3be ("mm, hotplug:
fix concurrent memory hot-add deadlock"), which tried to fix a possible
lock inversion reported and discussed in [1] due to the two locks
a) device_lock()
b) mem_hotplug_lock
While add_memory() first takes b),
Reading through the code and studying how mem_hotplug_lock is to be used,
I noticed that there are two places where we can end up calling
device_online()/device_offline() - online_pages()/offline_pages() without
the mem_hotplug_lock. And there are other places where we call
>>> On 17.08.18 at 06:52, wrote:
> flight 126019 xen-unstable-smoke real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/126019/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-armhf-armhf-xl 12
flight 126021 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126021/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 12 guest-start fail REGR. vs. 125923
Tests which
flight 125914 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125914/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw broken
Tests which are
This run is configured for baseline tests only.
flight 75076 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75076/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75068
On Thu, Aug 16, 2018 at 01:22:41PM -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.
> Add BUILD_BUG_ON sizeof
>>> On 17.08.18 at 00:04, wrote:
> On Tue, Jul 10, 2018 at 04:14:11AM -0600, Jan Beulich wrote:
>> Having noticed that VMLOAD alone is about as fast as a single of the
>> involved WRMSRs, I thought it might be a reasonable idea to also use it
>> for PV. Measurements, however, have shown that an
This replaces 5 instructions by a single one, further reducing code size,
cache, and TLB footprint (in particular on systems supporting BMI2).
Signed-off-by: Jan Beulich
---
Irrespective of the note regarding a possible alternative route, I think
the change here is an improvement until someone
... and (of course) also maddr / direct-map-offset ones.
Most x86 systems don't actually require the use of PDX compression. Now
that we have patching for the conversion code in place anyway, extend it
to use simple MOV when possible. Introduce a new pseudo-CPU-feature to
key the patching off of.
Both replace 6 instructions by a single one, further reducing code size,
cache, and TLB footprint (in particular on systems supporting BMI2).
Signed-off-by: Jan Beulich
---
v2: Avoid quoted symbols; use gcc's new V operand modifier instead.
Re-base.
--- a/xen/arch/x86/mm.c
+++
This allows to fold 6 instructions into a single one, reducing code size
quite a bit, especially when not considering the fallback functions
(which won't ever need to be brought into iCache or their mappings into
iTLB on systems supporting BMI2).
Make use of gcc's new V operand modifier, even if
Subsequent changes require this (too wide anyway imo) dependency to be
dropped.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
#include
#include
#include
---
This run is configured for baseline tests only.
flight 75075 xen-4.11-testing real [real]
http://osstest.xensource.com/osstest/logs/75075/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail
1: remove page.h and processor.h inclusion from asm_defns.h
2: use PDEP/PEXT for maddr/direct-map-offset conversion when available
3: use PDEP/PEXT for PFN/PDX conversion when available
4: use MOV for PFN/PDX conversion when possible
5: use PDEP for PTE flags insertion when available
Putting them on separate lines was suggested before, and is going to
become necessary eventually anyway as things get added here. Split them
now, and put the respective pieces in CONFIG_* conditionals at the same
time.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
Reviewed-by: Roger Pau
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
---
v3: Move declaration to pv/domain.h. Re-base.
v2: Add CONFIG_PV conditional.
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -289,6 +289,12 @@ int pv_domain_initialise(struct domain *
return rc;
}
+bool __init
Given what pt_pci_init() actually does, rename it properly and move its
declaration to pci.h, move the only call in acpi_mmcfg_init().
No functional change.
Signed-off-by: Zhenzhong Duan
Tested-by: Gopalasetty, Manoj
---
xen/arch/x86/setup.c |2 --
pci_conf_read8() needs pci mmcfg mapping to work on multiple pci segments
system such as HPE Superdome-Flex.
Move acpi_mmcfg_init() call in acpi_boot_init() before calling
acpi_parse_dmar() so that when pci_conf_read8() is called in
acpi_parse_dev_scope(), we already have the mapping set up.
>>> On 16.08.18 at 22:02, wrote:
> On Wed, Aug 15, 2018 at 10:00:48AM -0600, Jan Beulich wrote:
>> >>> On 09.08.18 at 21:42, wrote:
>> > --- a/xen/arch/x86/spec_ctrl.c
>> > +++ b/xen/arch/x86/spec_ctrl.c
>>
>> First of all - I'm not convinced some of the AMD specific code here
>> wouldn't
I'm not really convinced of the change done in v3, even less so with
x86'es pv/domain.h not really having been suitable for inclusion in
spec-ctrl.c (needed an extra, seemingly unrelated adjustment), but
in the interest of getting this done, here you go.
1: x86: report use of PCID together with
Restore symmetry between get_page_from_le(): pv_l1tf_check_le is
uniformly invoked from outside of them. They're no longer getting called
for non-present PTEs. This way the slightly odd three-way return value
meaning of the higher level ones can also be got rid of.
Introduce local variables
>>> On 27.07.18 at 16:20, wrote:
> In order to mostly eliminate abuse of what Xen leaves in the RSB by
> guest level attackers, fill the RSB with almost-NULL pointers right
> before entering guest context.
>
> The placement of the initialization code is intentional: If it was put
> in e.g.
101 - 149 of 149 matches
Mail list logo
