First and foremost make timer_softirq_action() avoid growing the heap
if its new size can't be stored without truncation. 64k entries is a
lot, and I don't think we're at risk of actually running into the issue,
but I also think it's better not to allow for hard to debug problems to
occur in the fi
flight 137222 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137222/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 137105
test-armhf-armhf-libvirt 14 sav
flight 137208 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137208/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadowbroken
test-amd64-amd64-xl-qemuu-debian
On 6/4/19 19:43, Jan Beulich wrote:
On 04.06.19 at 12:49, wrote:
On Jun 4, 2019, at 1:44 AM, Baodong Chen wrote:
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -368,4 +368,16 @@ config DOM0_MEM
Leave empty if you are not sure what to specify.
+config TRACEBUFFER
+ bool
Xen internal running status(trace event) will be saved to
trace memory when enabled. trace event data and config params can be
read/changed by system control hypercall at run time.
Can be disabled for smaller code footprint.
Signed-off-by: Baodong Chen
---
xen/common/Kconfig | 9 +
On Tue, 4 Jun 2019, Julien Grall wrote:
> On 6/4/19 6:59 PM, Stefano Stabellini wrote:
> > On Tue, 14 May 2019, Julien Grall wrote:
> > > At the moment, set_fixmap may replace a valid entry without following
> > > the break-before-make sequence. This may result to TLB conflict abort.
> > >
> > > R
On Tue, 14 May 2019, Julien Grall wrote:
> The function create_xen_entries() may be called concurrently. For
> instance, while the vmap allocation is protected by a spinlock, the
> mapping is not.
Do you have an example of potential concurrent calls of
create_xen_entries() which doesn't involve co
On Tue, 14 May 2019, Julien Grall wrote:
> The page-table walker is configured to use the same shareability and
> cacheability as the access performed when updating the page-tables. This
> means cleaning the cache for secondary CPUs runtime page-tables is
> unnecessary.
All right. Is there an expl
On Tue, 4 Jun 2019, Julien Grall wrote:
> On 6/4/19 6:39 PM, Stefano Stabellini wrote:
> > On Tue, 4 Jun 2019, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 6/4/19 6:09 PM, Stefano Stabellini wrote:
> > > > On Tue, 4 Jun 2019, Julien Grall wrote:
> > > > > Hi Jan,
> > > > >
> > > > > On 6/
On Tue, 14 May 2019, Julien Grall wrote:
> The two helpers {destroy, modify}_xen_mappings don't check that the
> start is always before the end. This should never happen but if it
> happens, it will result to unexpected behavior.
>
> Catch such issues earlier on by adding an ASSERT in destroy_xen_
On Tue, 14 May 2019, Julien Grall wrote:
> Since commit f60658c6ae "xen/arm: Stop relocating Xen", the function
> setup_page_tables() does not require any information from the FDT.
>
> So the initialization of the page-tables can be done much earlier in the
> boot process. The earliest setup_page_
On 6/4/19 6:39 PM, Stefano Stabellini wrote:
On Tue, 4 Jun 2019, Julien Grall wrote:
Hi Stefano,
On 6/4/19 6:09 PM, Stefano Stabellini wrote:
On Tue, 4 Jun 2019, Julien Grall wrote:
Hi Jan,
On 6/4/19 8:06 AM, Jan Beulich wrote:
On 03.06.19 at 19:15, wrote:
On Tue, May 21, 2019 at 05:52:
On 6/4/19 6:59 PM, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
At the moment, set_fixmap may replace a valid entry without following
the break-before-make sequence. This may result to TLB conflict abort.
Rather than dealing with Break-Before-Make in set_fixmap, every ca
When merging a levelled policy, stale out-of-range leaves may remain.
Introduce a helper to clear them, and test a number of the subtle corner
cases.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Sergey Dyasli
---
tools/tests/cpu-policy/test-cpu-policy.
There is now enough complexity that a fuzzing harness is a good idea, and
enough supporting logic to implement one which AFL seems happy with.
Take the existing recalculate_synth() helper and export it as
x86_cpuid_policy_recalc_synth(), as it is needed by the fuzzing harness.
Signed-off-by: Andr
These are the final pieces to getting the fuzzing harness working correctly.
I accidentally left AFL running for a week while I was travelling, so this
certified "8d 15h crash-free".
Andrew Cooper (2):
libx86: Helper for clearing out-of-range CPUID leaves
tools/fuzz: Add a cpu-policy fuzzing
On 6/4/19 12:51 PM, Stefano Stabellini wrote:
> On Mon, 3 Jun 2019, Boris Ostrovsky wrote:
>> On 6/3/19 2:25 PM, Stefano Stabellini wrote:
>>> On Tue, 28 May 2019, Boris Ostrovsky wrote:
On 5/28/19 6:48 PM, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> On arm64 swiotlb
On 03/06/2019 09:13, Jan Beulich wrote:
On 31.05.19 at 22:43, wrote:
>> On 31/05/2019 02:54, Jan Beulich wrote:
>>> This is faster than using the software implementation, and the insn is
>>> available on all half-way recent hardware. Therefore convert
>>> generic_hweight() to out-of-line func
On Tue, 4 Jun 2019, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [qemu-upstream-4.11-testing test]
> 136184: regressions - FAIL"):
> > I agree with you it would be desirable to test both LIVEPATCH and
> > non-LIVEPATCH, and I understand about limitation of resources and test
>
flight 137196 qemu-upstream-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137196/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken in 134504
build-arm64
Stefano Stabellini writes ("Re: [Xen-devel] [qemu-upstream-4.11-testing test]
136184: regressions - FAIL"):
> I agree with you it would be desirable to test both LIVEPATCH and
> non-LIVEPATCH, and I understand about limitation of resources and test
> matrix explosion.
>
> Given the chance, I thin
On Tue, 4 Jun 2019, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [qemu-upstream-4.11-testing test]
> 136184: regressions - FAIL"):
> > On Tue, 4 Jun 2019, Julien Grall wrote:
> > > Per the discussion before, the .config is different between the 2 flights.
> > > QEMU testing is
On Tue, 14 May 2019, Julien Grall wrote:
> At the moment, set_fixmap may replace a valid entry without following
> the break-before-make sequence. This may result to TLB conflict abort.
>
> Rather than dealing with Break-Before-Make in set_fixmap, every call to
> set_fixmap is paired with a call t
flight 137191 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137191/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 133580
Tests which did not
Stefano Stabellini writes ("Re: [Xen-devel] [qemu-upstream-4.11-testing test]
136184: regressions - FAIL"):
> On Tue, 4 Jun 2019, Julien Grall wrote:
> > Per the discussion before, the .config is different between the 2 flights.
> > QEMU testing is not selecting CONFIG_LIVEPATCH while staging-4.11
Anthony PERARD writes ("[PATCH 9/9] libxl_disk: Implement missing timeout for
libxl_cdrom_insert"):
> Since the previous patch "libxl_disk: Use ev_qmp in libxl_cdrom_insert",
> there are no kind of timeout anymore, add one back.
Hrm. The patch itself looks good, so
Acked-by: Ian Jackson
But I
Anthony PERARD writes ("[PATCH 8/9] libxl_disk: Use ev_qmp in
libxl_cdrom_insert"):
> libxl_cdrom_insert is now asynchronous when QEMU is involve. And the
> cdrom is now openned by libxl before sending a file descriptor to QEMU.
This patch has much of the meat. It seems to contain the appropriat
On Tue, 4 Jun 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 6/4/19 12:12 AM, Stefano Stabellini wrote:
> > On Wed, 29 May 2019, Julien Grall wrote:
> > > Ping, it would be good to know which bits I dropped...
> > >
> > > On 21/05/2019 11:09, Julien Grall wrote:
> > > > Hi,
> > > >
> > > > On 5/
On Tue, 4 Jun 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 6/4/19 6:09 PM, Stefano Stabellini wrote:
> > On Tue, 4 Jun 2019, Julien Grall wrote:
> > > Hi Jan,
> > >
> > > On 6/4/19 8:06 AM, Jan Beulich wrote:
> > > > > > > On 03.06.19 at 19:15, wrote:
> > > > > On Tue, May 21, 2019 at 05:52:12
Anthony PERARD writes ("[PATCH 7/9] libxl: Move qmp_parameters_* prototypes to
libxl_internal.h"):
> .. and rename them to libxl__qmp_param_*.
>
> This is to allow other files than libxl_qmp.c to make QMP calls with
> parameters.
Acked-by: Ian Jackson
__
On 04/06/2019 17:11, Julien Grall wrote:
Hi Jan,
On 5/31/19 10:53 AM, Jan Beulich wrote:
According to Linux commit e75bef2a4f ("arm64: Select
ARCH_HAS_FAST_MULTIPLIER") this is a further improvement over the
variant using only bitwise operations on at least some hardware, and no
worse on other.
Anthony PERARD writes ("[PATCH 6/9] libxl_disk: Cut libxl_cdrom_insert into
steps .."):
> This patch cut libxl_cdrom_insert into different step/function but there
> are still called synchronously. A later patch will call them
> asynchronously when QMP is involved.
>
> The json_lock has been repla
Hi Stefano,
On 6/4/19 6:09 PM, Stefano Stabellini wrote:
On Tue, 4 Jun 2019, Julien Grall wrote:
Hi Jan,
On 6/4/19 8:06 AM, Jan Beulich wrote:
On 03.06.19 at 19:15, wrote:
On Tue, May 21, 2019 at 05:52:12PM +0100, Julien Grall wrote:
The same error cannot be reproduced on laxton*. Looking
Anthony PERARD writes ("[PATCH 5/9] libxl_disk: Reorganise libxl_cdrom_insert"):
> This is in preparation of cutting libxl_cdrom_insert into several
> functions to allow asynchronous callbacks.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-deve
Anthony PERARD writes ("[PATCH 4/9] libxl_internal: Create new lock for devices
hotplug via QMP"):
> The current lock `domain_userdata_lock' can't be used when modification
> to a guest is done by sending command to QEMU, this is a slow process
> and requires to call CTX_UNLOCK, which is not possi
On Tue, 4 Jun 2019, Julien Grall wrote:
> Hi Jan,
>
> On 6/4/19 8:06 AM, Jan Beulich wrote:
> > > > > On 03.06.19 at 19:15, wrote:
> > > On Tue, May 21, 2019 at 05:52:12PM +0100, Julien Grall wrote:
> > > > The same error cannot be reproduced on laxton*. Looking at the test
> > > > history,
> > >
Hi Stefano,
On 6/3/19 11:02 PM, Stefano Stabellini wrote:
pfn_pdx_hole_setup is meant to skip the first MAX_ORDER bits, but
actually it only skips the first MAX_ORDER-1 bits. The issue was
probably introduced by bdb5439c3f ("x86_64: Ensure frame-table
compression leaves MAX_ORDER aligned"), when
Hi Stefano,
On 6/3/19 11:02 PM, Stefano Stabellini wrote:
pfn_to_pdx expects an address, not a size, as a parameter. Specifically,
it expects the end address, then the masks calculations compensate for
any holes between start and end. Thus, we should pass the end address to
pfn_to_pdx.
The init
flight 137276 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137276/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Anthony PERARD writes ("[PATCH 3/9] libxl_internal: Split out userdata lock
function"):
> We are going to create a new lock and want to reuse the same machinery.
> Also, hide the detail of struct libxl__domain_userdata_lock as this is
> only useful as a pointer by the rest of libxl.
>
> No functi
On Mon, 3 Jun 2019, Boris Ostrovsky wrote:
> On 6/3/19 2:25 PM, Stefano Stabellini wrote:
> > On Tue, 28 May 2019, Boris Ostrovsky wrote:
> >> On 5/28/19 6:48 PM, Stefano Stabellini wrote:
> >>> From: Stefano Stabellini
> >>>
> >>> On arm64 swiotlb is often (not always) already initialized by mem_
Anthony PERARD writes ("[PATCH 2/9] libxl: Pointer on usage of
libxl__domain_userdata_lock"):
> It is currently difficult to know how/when/why the userdata lock is
> supposed to be used. Add some pointers to the hotplug comments.
Acked-by: Ian Jackson
> diff --git a/tools/libxl/libxl_internal.h
Anthony PERARD writes ("[PATCH 1/9] libxl_internal: Remove lost comment"):
> That comment as been separated from the function it defines by
> 4197d3abbb3055d3798254eb7ba239bfb5824360, but then was not useful
> anymore when the libxl__device_disk_add() prototype was removed by
> 22ea8ad02e465e32cd40
Hi Jan,
On 6/4/19 5:21 PM, Jan Beulich wrote:
On 03.06.19 at 18:03, wrote:
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -442,6 +442,8 @@ int check_descriptor(const struct domain *d, seg_desc_t
*desc);
extern paddr_t mem_hotplug;
+extern struct domain *dom_xen, *dom
>>> On 04.06.19 at 18:14, wrote:
> On 27/05/2019 09:31, Chao Gao wrote:
>> --- /dev/null
>> +++ b/tools/misc/xen-ucode.c
>> @@ -0,0 +1,78 @@
>> +#define _GNU_SOURCE
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>>
Hi Jan,
On 6/4/19 5:14 PM, Jan Beulich wrote:
On 03.06.19 at 18:03, wrote:
While Arm never had a M2P, the implementation of mfn_to_gmfn is pretty
bogus as we directly return the MFN passed in parameter.
Thankfully, the use of mfn_to_gmfn is pretty limited on Arm today. There
are only 3 caller
>>> On 03.06.19 at 18:03, wrote:
> --- a/xen/include/asm-x86/mm.h
> +++ b/xen/include/asm-x86/mm.h
> @@ -442,6 +442,8 @@ int check_descriptor(const struct domain *d, seg_desc_t
> *desc);
>
> extern paddr_t mem_hotplug;
>
> +extern struct domain *dom_xen, *dom_io, *dom_cow;/* for vmcorein
On Tue, Jun 04, 2019 at 07:02:06AM -0600, Jan Beulich wrote:
> >>> On 04.06.19 at 10:48, wrote:
> > On Mon, Jun 03, 2019 at 07:00:25AM -0600, Jan Beulich wrote:
> >> This reverts commit b6bd02b7a877f9fac2de69e64d8245d56f92ab25. The change
> >> was redundant with amd_iommu_detect_one_acpi() already
On 27/05/2019 09:31, Chao Gao wrote:
> This patch provides a tool for late microcode update.
>
> Signed-off-by: Konrad Rzeszutek Wilk
> Signed-off-by: Chao Gao
> ---
> Changes in v7:
> - introduce xc_microcode_update() rather than xc_platform_op()
> - avoid creating bounce buffer twice
> - ren
>>> On 03.06.19 at 18:03, wrote:
> While Arm never had a M2P, the implementation of mfn_to_gmfn is pretty
> bogus as we directly return the MFN passed in parameter.
>
> Thankfully, the use of mfn_to_gmfn is pretty limited on Arm today. There
> are only 3 callers:
> - iommu_hwdom_init: mfn_to_
Hi Jan,
On 5/31/19 10:53 AM, Jan Beulich wrote:
According to Linux commit e75bef2a4f ("arm64: Select
ARCH_HAS_FAST_MULTIPLIER") this is a further improvement over the
variant using only bitwise operations on at least some hardware, and no
worse on other.
Suggested-by: Andrew Cooper
Signed-off-
On 03/06/2019 23:26, Tamas K Lengyel wrote:
> On Mon, Jun 3, 2019 at 4:22 PM Tamas K Lengyel wrote:
/* XEN_DOMCTL_mem_sharing_op.
- * The CONTROL sub-domctl is used for bringup/teardown. */
+ * The CONTROL sub-domctl is used for bringup/teardown.
+ * Please note that mem shari
On 04/06/2019 15:23, Petre Ovidiu PIRCALABU wrote:
> On Fri, 2019-05-31 at 16:01 -0700, Andrew Cooper wrote:
>> On 30/05/2019 07:18, Petre Pircalabu wrote:
>>> Modified xc_mem_paging_enable to use directly xc_vm_event_enable
>>> and
>>> moved the ring_page handling from client to libxc (xenpaging).
>>> On 03.06.19 at 18:03, wrote:
> No functional changes intended.
>
> Signed-off-by: Julien Grall
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 30/05/2019 15:18, Petre Pircalabu wrote:
> +#define to_channels(_vme) container_of((_vme), vm_event_channels_t, vme)
> +
> +static int vm_event_channels_init(xc_interface *xch, xenevtchn_handle *xce,
> + domid_t domain_id, vm_event_ops_t *ops,
> +
>>> On 27.05.19 at 10:31, wrote:
> --- a/xen/arch/x86/microcode_amd.c
> +++ b/xen/arch/x86/microcode_amd.c
> @@ -78,8 +78,9 @@ struct mpbhdr {
> static DEFINE_SPINLOCK(microcode_update_lock);
>
> /* See comment in start_update() for cases when this routine fails */
> -static int collect_cpu_in
>>> On 27.05.19 at 10:31, wrote:
> We can remove the per-cpu cache field in struct ucode_cpu_info since
> it has been replaced by a global cache. It would leads to only one field
> remaining in ucode_cpu_info. Then, this struct is removed and the
> remaining field (cpu signature) is stored in per-
>>> On 27.05.19 at 10:31, wrote:
> +bool microcode_update_cache(struct microcode_patch *patch)
> +{
> +
> +ASSERT(spin_is_locked(µcode_mutex));
> +
> +if ( !microcode_ops->match_cpu(patch) )
> +return false;
> +
> +if ( !microcode_cache )
> +microcode_cache = patch;
> +
On 30/05/2019 15:18, Petre Pircalabu wrote:
> In high throughput introspection scenarios where lots of monitor
> vm_events are generated, the ring buffer can fill up before the monitor
> application gets a chance to handle all the requests thus blocking
> other vcpus which will have to wait for a s
>>> On 27.05.19 at 10:31, wrote:
> --- a/xen/arch/x86/microcode_intel.c
> +++ b/xen/arch/x86/microcode_intel.c
> @@ -134,14 +134,28 @@ static int collect_cpu_info(unsigned int cpu_num,
> struct cpu_signature *csig)
> return 0;
> }
>
> -static inline int microcode_update_match(
> -unsi
On 6/3/19 4:26 AM, Jan Beulich wrote:
On 16.05.19 at 23:37, wrote:
Disable it by default as it is only an experimental subsystem.
Signed-off-by: Tamas K Lengyel
Daniel, it looks like you weren't Cc-ed here, but your ack is needed.
Jan
Acked-by: Daniel De Graaf
_
On Fri, 2019-05-31 at 16:01 -0700, Andrew Cooper wrote:
> On 30/05/2019 07:18, Petre Pircalabu wrote:
> > Modified xc_mem_paging_enable to use directly xc_vm_event_enable
> > and
> > moved the ring_page handling from client to libxc (xenpaging).
> >
> > Restricted vm_event_control usage only to si
>>> On 04.06.19 at 15:35, wrote:
> On 04/06/2019 13:43, Jan Beulich wrote:
>> Split out this mostly arch-independent code into a common-code helper
>> function. (This does away with Arm's arch_init_memory() altogether.)
>>
>> On x86 this needs to happen before acpi_boot_init(): Commit 9fa94e1058
>
All,
while 4.11.2 still suffers delays, 4.10.4 is about due now as well.
Please point out backports you find missing from its staging tree.
I have these two already queued
b144cf45d5 x86/vhpet: avoid 'small' time diff test on resume
e2105180f9 x86/spec-ctrl: Knights Landing/Mill are ret
On 04/06/2019 13:55, Julien Grall wrote:
>> @@ -476,8 +474,6 @@ struct arch_domain
>> #define has_pirq(d) (!!((d)->arch.emulation_flags &
>> X86_EMU_USE_PIRQ))
>> #define has_vpci(d) (!!((d)->arch.emulation_flags &
>> X86_EMU_VPCI))
>> -#define has_arch_pdevs(d) (!list_empty(
On 6/4/19 2:14 PM, Jan Beulich wrote:
On 04.06.19 at 15:05, wrote:
Hi Jan,
On 6/4/19 2:03 PM, Jan Beulich wrote:
On 04.06.19 at 14:55, wrote:
On 6/4/19 1:42 PM, Jan Beulich wrote:
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -121,7 +121,9 @@ struct pci_dev {
};
On 04/06/2019 13:44, Jan Beulich wrote:
> A couple of adjustments are needed to code checking for dom_cow, but
> since there are pretty few it is probably better to adjust those than
> to set up and keep around a never used domain.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 04/06/2019 13:43, Jan Beulich wrote:
> Split out this mostly arch-independent code into a common-code helper
> function. (This does away with Arm's arch_init_memory() altogether.)
>
> On x86 this needs to happen before acpi_boot_init(): Commit 9fa94e1058
> ("x86/ACPI: also parse AMD IOMMU tables
Hello Julien,
Julien Grall writes:
> On 6/1/19 5:07 PM, Volodymyr Babchuk wrote:
>>
>> Hi Julien,
>
> Hi Volodymyr,
>
>> Julien Grall writes:
>>
>>> Hi Volodymyr,
>>>
>>> I tried to apply the patches to staging but fail because the patches
>>> contains =20. Do you have a tree with the series app
>>> On 04.06.19 at 15:05, wrote:
> Hi Jan,
>
> On 6/4/19 2:03 PM, Jan Beulich wrote:
> On 04.06.19 at 14:55, wrote:
>>> On 6/4/19 1:42 PM, Jan Beulich wrote:
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -121,7 +121,9 @@ struct pci_dev {
};
On 5/31/19 10:44 AM, Konrad Rzeszutek Wilk wrote:
> On May 31, 2019 10:41:16 AM EDT, Juergen Gross wrote:
>> On 06/05/2019 10:11, Juergen Gross wrote:
>>> On 03/05/2019 17:04, Roger Pau Monne wrote:
There's no reason to request physically contiguous memory for those
allocations.
>>>
Hi Jan,
On 6/4/19 2:03 PM, Jan Beulich wrote:
On 04.06.19 at 14:55, wrote:
On 6/4/19 1:42 PM, Jan Beulich wrote:
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -121,7 +121,9 @@ struct pci_dev {
};
#define for_each_pdev(domain, pdev) \
-list_for_each_entry(pdev, &(do
>>> On 04.06.19 at 14:55, wrote:
> On 6/4/19 1:42 PM, Jan Beulich wrote:
>> --- a/xen/include/xen/pci.h
>> +++ b/xen/include/xen/pci.h
>> @@ -121,7 +121,9 @@ struct pci_dev {
>> };
>>
>> #define for_each_pdev(domain, pdev) \
>> -list_for_each_entry(pdev, &(domain->arch.pdev_list), domai
>>> On 04.06.19 at 10:48, wrote:
> On Mon, Jun 03, 2019 at 07:00:25AM -0600, Jan Beulich wrote:
>> This reverts commit b6bd02b7a877f9fac2de69e64d8245d56f92ab25. The change
>> was redundant with amd_iommu_detect_one_acpi() already calling
>> pci_ro_device().
>>
>> Signed-off-by: Jan Beulich
>
>
Hi,
On 6/4/19 1:42 PM, Jan Beulich wrote:
Its management shouldn't be arch-specific, and in particular there
should be no need for special precautions when creating the special
domains.
At this occasion
- correct parenthesization of for_each_pdev(),
- stop open-coding for_each_pdev() in vPCI co
>>> On 04.06.19 at 14:40, wrote:
> This #ifdef-ary isn't necessary, and the logic can live in a plain if()
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
A couple of adjustments are needed to code checking for dom_cow, but
since there are pretty few it is probably better to adjust those than
to set up and keep around a never used domain.
Signed-off-by: Jan Beulich
---
v2: Use #if/#else. Split out emul-priv-op.c change.
---
While for now this avoid
Split out this mostly arch-independent code into a common-code helper
function. (This does away with Arm's arch_init_memory() altogether.)
On x86 this needs to happen before acpi_boot_init(): Commit 9fa94e1058
("x86/ACPI: also parse AMD IOMMU tables early") only appeared to work
fine - it's really
Its management shouldn't be arch-specific, and in particular there
should be no need for special precautions when creating the special
domains.
At this occasion
- correct parenthesization of for_each_pdev(),
- stop open-coding for_each_pdev() in vPCI code.
Signed-off-by: Jan Beulich
--- a/xen/a
Rather than checking that a page table is _not_ "owned" by the fake COW
domain, check that it's owned by the domain actually wanting to install
it.
Switch away from BUG_ON() at the same time.
Signed-off-by: Jan Beulich
---
v2: Split out from larger patch to make further adjustments.
---
Thinking
This #ifdef-ary isn't necessary, and the logic can live in a plain if()
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/include/xen/bitops.h | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/xen/include/
flight 137181 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137181/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
Tests which did not
Patch 3 fixes a really bad bug of mine, and while at it I thought I
would carry out the other recently noticed work item here right
away (patch 4). Patches 1 and 2 are preparatory.
1: x86/PV: tighten page table ownership check in emul-priv-op.c:read_cr()
2: PCI: move pdev_list field to common stru
For find_iommu_for_device() to consistently (independent of ACPI tables)
return NULL for the PCI devices corresponding to IOMMUs, make sure
IOMMUs don't get mapped to themselves by ivrs_mappings[].
While amd_iommu_add_device() won't be called for IOMMUs from
pci_add_device(), as IOMMUs have got ma
>>> On 04.06.19 at 11:04, wrote:
> On 03/06/2019 14:00, Jan Beulich wrote:
>> This reverts commit b6bd02b7a877f9fac2de69e64d8245d56f92ab25. The change
>> was redundant with amd_iommu_detect_one_acpi() already calling
>> pci_ro_device().
>
> Seeing as amd_iommu_detect_one_acpi() hasn't changed for
This patch aims to have mem access vm events sent from the emulator.
This is useful where we want to only emulate a page walk without
checking the EPT, but we still want to check the EPT when emulating
the instruction that caused the page walk. In this case, the original
EPT fault is caused by the
>>> On 04.06.19 at 12:49, wrote:
>> On Jun 4, 2019, at 1:44 AM, Baodong Chen wrote:
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -368,4 +368,16 @@ config DOM0_MEM
>>
>>Leave empty if you are not sure what to specify.
>>
>> +config TRACEBUFFER
>> +bool "Enable trace
Ping?
On Tue, Apr 09, 2019 at 05:45:33PM +0100, Anthony PERARD wrote:
> This patch series fix libxl_cdrom_insert to work with a depriviledge QEMU. For
> that, we need to use libxl__ev_qmp. For that, we need a new lock because
> userdata_lock can't be used anymore.
>
> Patch series available in t
> On Jun 4, 2019, at 1:44 AM, Baodong Chen wrote:
>
> Xen internal running status(trace event) will be saved to
> trace memory when enabled. trace event data and config params can be
> read/changed by system control hypercall at run time.
>
> Can be disabled for smaller code footprint.
>
> Si
Hi Stefano,
On 6/4/19 12:12 AM, Stefano Stabellini wrote:
On Wed, 29 May 2019, Julien Grall wrote:
Ping, it would be good to know which bits I dropped...
On 21/05/2019 11:09, Julien Grall wrote:
Hi,
On 5/20/19 11:56 PM, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
The
On Fri, 2019-05-31 at 16:26 -0700, Andrew Cooper wrote:
> On 30/05/2019 07:18, Petre Pircalabu wrote:
> >
>
> This is an internal helper, so can reasonably be expected to not be
> called with junk, and can do away with the param pointer.
>
> Something like
>
> static int xc_vm_event_ring_pfn_pa
>>> On 04.06.19 at 11:57, wrote:
>
> On 6/4/19 10:17 AM, Jan Beulich wrote:
> On 04.06.19 at 11:01, wrote:
>>> On 6/4/19 8:06 AM, Jan Beulich wrote:
>>> On 03.06.19 at 19:15, wrote:
> It turns out that the first commit that fails to boot on rochester is
> e202feb713 xen/cmd
On 6/4/19 10:17 AM, Jan Beulich wrote:
On 04.06.19 at 11:01, wrote:
On 6/4/19 8:06 AM, Jan Beulich wrote:
On 03.06.19 at 19:15, wrote:
It turns out that the first commit that fails to boot on rochester is
e202feb713 xen/cmdline: Fix buggy strncmp(s, LITERAL, ss - s) construct
(even wit
>>> On 04.06.19 at 10:48, wrote:
> On Mon, Jun 03, 2019 at 07:00:25AM -0600, Jan Beulich wrote:
>> This reverts commit b6bd02b7a877f9fac2de69e64d8245d56f92ab25. The change
>> was redundant with amd_iommu_detect_one_acpi() already calling
>> pci_ro_device().
>>
>> Signed-off-by: Jan Beulich
>
>
flight 137178 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137178/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 12
guest-start/debianhvm.repeat fail REGR.
>>> On 04.06.19 at 11:04, wrote:
> On 03/06/2019 14:00, Jan Beulich wrote:
>> This reverts commit b6bd02b7a877f9fac2de69e64d8245d56f92ab25. The change
>> was redundant with amd_iommu_detect_one_acpi() already calling
>> pci_ro_device().
>
> Seeing as amd_iommu_detect_one_acpi() hasn't changed for
>>> On 04.06.19 at 11:01, wrote:
> On 6/4/19 8:06 AM, Jan Beulich wrote:
> On 03.06.19 at 19:15, wrote:
>>> It turns out that the first commit that fails to boot on rochester is
>>>e202feb713 xen/cmdline: Fix buggy strncmp(s, LITERAL, ss - s) construct
>>> (even with the "eb8acba82a xen:
Xen internal running status(trace event) will be saved to
trace memory when enabled. trace event data and config params can be
read/changed by system control hypercall at run time.
Can be disabled for smaller code footprint.
Signed-off-by: Baodong Chen
---
xen/common/Kconfig | 12 +
On 03/06/2019 14:00, Jan Beulich wrote:
> This reverts commit b6bd02b7a877f9fac2de69e64d8245d56f92ab25. The change
> was redundant with amd_iommu_detect_one_acpi() already calling
> pci_ro_device().
Seeing as amd_iommu_detect_one_acpi() hasn't changed for many years, and
b6bd02b7 was a functional
Hi Jan,
On 6/4/19 8:06 AM, Jan Beulich wrote:
On 03.06.19 at 19:15, wrote:
On Tue, May 21, 2019 at 05:52:12PM +0100, Julien Grall wrote:
The same error cannot be reproduced on laxton*. Looking at the test history,
it looks like qemu-upstream-4.12-testing flight has run successfully a few
time
1 - 100 of 107 matches
Mail list logo
