On 07/08/2019, 19:40, "Viktor Mitin" wrote:
On Wed, Aug 7, 2019 at 9:04 PM Lars Kurth wrote:
>
>
> On 05/08/2019, 18:49, "Lars Kurth" wrote:
>
> On 02/08/2019, 14:36, "Lars Kurth" wrote:
>
> On 02/08/2019, 14:03, "Julien Grall" wrote:
>
>
On 07.08.2019 16:31, Juergen Gross wrote:
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -44,6 +44,13 @@ config COVERAGE
If unsure, say N here.
+config SPINLOCK_DEBUG
+ bool "Spinlock debugging"
+ default DEBUG
+ ---help---
+ Enable debugging features of
On 07.08.2019 21:41, Andrew Cooper wrote:
--- /dev/null
+++ b/docs/glossary.rst
@@ -0,0 +1,37 @@
+Glossary
+
+
+.. Terms should appear in alphabetical order
+
+.. glossary::
+
+ control domain
+ A :term:`domain`, commonly dom0, with the permission and responsibility
+ to create
On 07.08.2019 20:36, Oleksandr wrote:
There's one more thing for the re-alloc case though (besides
cosmetic aspects): The incoming pointer should also be verified
to be of correct type.
Jan, how this could be technically implemented, or are these any existing
examples in Xen?
See x86's copy_
On 08.08.2019 04:53, Marek Marczykowski-Górecki wrote:
On Wed, Aug 07, 2019 at 09:26:00PM +0200, Marek Marczykowski-Górecki wrote:
On Wed, Aug 07, 2019 at 06:34:09PM +0200, Jan Beulich wrote:
On 07.08.2019 18:04, Marek Marczykowski-Górecki wrote:
On Wed, Aug 07, 2019 at 05:58:59PM +0200, Jan
Hi John,
john.hubb...@gmail.com writes:
> diff --git a/arch/powerpc/mm/book3s64/iommu_api.c
> b/arch/powerpc/mm/book3s64/iommu_api.c
> index b056cae3388b..e126193ba295 100644
> --- a/arch/powerpc/mm/book3s64/iommu_api.c
> +++ b/arch/powerpc/mm/book3s64/iommu_api.c
> @@ -203,6 +202,7 @@ static voi
On 07.08.19 20:11, Andrew Cooper wrote:
On 07/08/2019 15:31, Juergen Gross wrote:
While hunting a locking problem in my core scheduling series I have
added some debugging aids to spinlock handling making it easier to
find the root cause for the problem.
Making use of the already lock profiling
On 07.08.19 19:17, Andrew Cooper wrote:
On 07/08/2019 15:31, Juergen Gross wrote:
Instead of enabling spinlock debugging for debug builds only add a
dedicated Kconfig option for that purpose which defaults to DEBUG.
Signed-off-by: Juergen Gross
---
xen/Kconfig.debug | 7 +++
xe
On 07.08.19 19:05, Andrew Cooper wrote:
On 07/08/2019 15:31, Juergen Gross wrote:
Add the cpu currently holding the lock to struct lock_debug. This makes
analysis of locking errors easier and it can be tested whether the
correct cpu is releasing a lock again.
Signed-off-by: Juergen Gross
Lo
Hi Oleksandr-san,
> From: Oleksandr, Sent: Thursday, August 8, 2019 1:01 AM
>
>
> Hi, Shimoda-san.
>
> Thank you for the review.
You're welcome.
> > +/* Xen IOMMU ops */
> >> +static int __must_check ipmmu_iotlb_flush_all(struct domain *d)
> >> +{
> >> +struct ipmmu_vmsa_xen_domain *xen_
On 8/7/19 7:36 PM, Ira Weiny wrote:
On Wed, Aug 07, 2019 at 10:46:49AM +0200, Michal Hocko wrote:
On Wed 07-08-19 10:37:26, Jan Kara wrote:
On Fri 02-08-19 12:14:09, John Hubbard wrote:
On 8/2/19 7:52 AM, Jan Kara wrote:
On Fri 02-08-19 07:24:43, Matthew Wilcox wrote:
On Fri, Aug 02, 2019 at
flight 139787 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139787/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 129313
test-amd64-amd64-xl-
On Wed, Aug 07, 2019 at 09:26:00PM +0200, Marek Marczykowski-Górecki wrote:
> On Wed, Aug 07, 2019 at 06:34:09PM +0200, Jan Beulich wrote:
> > On 07.08.2019 18:04, Marek Marczykowski-Górecki wrote:
> > > On Wed, Aug 07, 2019 at 05:58:59PM +0200, Jan Beulich wrote:
> > > > On 07.08.2019 17:51, Mare
Ping...
Any comments?
Thanks
Zhang Chen
> -Original Message-
> From: Zhang, Chen
> Sent: Saturday, July 27, 2019 12:27 AM
> To: Ian Jackson ; Wei Liu ; Anthony
> PERARD ; xen-devel@lists.xenproject.org
> Cc: Zhang Chen ; Zhang, Chen
> Subject: [PATCH V4] tools/libxl: Add iothread suppor
On Wed, Aug 07, 2019 at 10:46:49AM +0200, Michal Hocko wrote:
> On Wed 07-08-19 10:37:26, Jan Kara wrote:
> > On Fri 02-08-19 12:14:09, John Hubbard wrote:
> > > On 8/2/19 7:52 AM, Jan Kara wrote:
> > > > On Fri 02-08-19 07:24:43, Matthew Wilcox wrote:
> > > > > On Fri, Aug 02, 2019 at 02:41:46PM +
flight 139790 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139790/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 139688
test-armhf-armhf-libvirt-raw 13 saveresto
On Thu, Aug 08, 2019 at 02:31:57AM +0200, Marek Marczykowski-Górecki wrote:
> When booting Xen via xen.efi, there is /mapbs option to workaround
> certain platform issues (added in f36886bdf4 "EFI/early: add /mapbs to
> map EfiBootServices{Code,Data}"). Add support for efi=mapbs on Xen
> cmdline fo
When booting Xen via xen.efi, there is /mapbs option to workaround
certain platform issues (added in f36886bdf4 "EFI/early: add /mapbs to
map EfiBootServices{Code,Data}"). Add support for efi=mapbs on Xen
cmdline for the same effect and parse it very early in the
multiboot2+EFI boot path.
Normally
On 07/08/2019 23:49, Hans van Kranenburg wrote:
> Hi, (dropped most of the Cc:)
>
> On 8/7/19 9:41 PM, Andrew Cooper wrote:
>> Put together an introduction page for the Sphinx/RST docs, along with a
>> glossary which will accumulate over time.
>> [...]
> I've been using Xen for 13+ years now, so I'
Hi, (dropped most of the Cc:)
On 8/7/19 9:41 PM, Andrew Cooper wrote:
> Put together an introduction page for the Sphinx/RST docs, along with a
> glossary which will accumulate over time.
> [...]
I've been using Xen for 13+ years now, so I'm not really able to provide
feedback about how someone ne
On Tue, 15 Jan 2019, Julien Grall wrote:
> > > > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > > > index cc6b464..d48f77e 100644
> > > > --- a/xen/arch/arm/domain_build.c
> > > > +++ b/xen/arch/arm/domain_build.c
> > > > @@ -2094,6 +2094,88 @@ static int __init construc
flight 139778 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139778/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-pvshim12 guest-start fail never pass
test-amd64-amd64-libvirt-xsm 13 migrat
On Tue, 15 Jan 2019, Julien Grall wrote:
> On 1/3/19 10:07 PM, Stefano Stabellini wrote:
> > On Mon, 24 Dec 2018, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 12/5/18 5:28 PM, Stefano Stabellini wrote:
> > > > Signed-off-by: Stefano Stabellini
> > > > ---
> > > >docs/misc/arm/device-t
Hi, Julien.
Sorry for the possible format issues.
> > No, it is not disabled. But, ipmmu_irq() uses another mmu->lock. So, I
> > think, there won't be a deadlock.
> >
> > Or I really missed something?
> >
> > If we worry about ipmmu_tlb_invalidate() which is called here (to
> > perform a flush by
flight 139816 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139816/
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
flight 139775 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139775/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12
guest-start/debianhvm.repeat fail REGR. v
Put together an introduction page for the Sphinx/RST docs, along with a
glossary which will accumulate over time.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Stefano Stabellini
CC: Wei Liu
CC: Julien Grall
CC: Roger Pau Monné
CC: Lars Kurth
A re
(+ Lars)
Hi,
On 8/7/19 5:01 PM, Oleksandr wrote:
+ * you can found at:
+ * url:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git
+ * branch: v4.14.75-ltsi/rcar-3.9.6
+ * commit: e206eb5b81a60e64c35fbc3a999b1a0db2b98044
+ * and Xen's SMMU driver:
+ * xen/drivers/
On Tue, 15 Jan 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 1/3/19 7:07 PM, Stefano Stabellini wrote:
> > On Mon, 24 Dec 2018, Julien Grall wrote:
> > > Hi,
> > >
> > > On 12/5/18 5:28 PM, Stefano Stabellini wrote:
> > > > We don't have a clear way to know how many virtual SPIs we need for the
On Wed, Aug 7, 2019 at 9:04 PM Lars Kurth wrote:
>
>
> On 05/08/2019, 18:49, "Lars Kurth" wrote:
>
> On 02/08/2019, 14:36, "Lars Kurth" wrote:
>
> On 02/08/2019, 14:03, "Julien Grall" wrote:
>
>
>
> On 02/08/2019 14:02, Julien Grall wrote:
> > Hi Jan,
>
Hi, Jan, Volodymyr.
c. re-allocate struct with flexible buffer.
option c. is about structures like this:
struct arrlen
{
size_t len;
int data[1];
};
This is Oleksandr's case.
So for option a. we can use _xreallocate(ptr, size, align)
For option b. we can use xrealloc_ar
Hi Stefano,
On 8/6/19 10:49 PM, Stefano Stabellini wrote:
Reserved memory regions are automatically remapped to dom0. Their device
tree nodes are also added to dom0 device tree. However, the dom0 memory
node is not currently extended to cover the reserved memory regions
ranges as required by the
On 8/7/19 11:00 AM, Paolo Bonzini wrote:
> On 07/08/19 19:49, Richard Henderson wrote:
>> On 8/7/19 1:33 AM, tony.ngu...@bt.com wrote:
>>> @@ -551,6 +551,7 @@ void virtio_address_space_write(VirtIOPCIProxy *proxy,
>>> hwaddr addr,
>>> /* As length is under guest control, handle illegal va
Hi Dario, George,
Dom0less with sched=null is broken on staging, it simply hangs soon
after Xen is finished loading things. My impression is that vcpus are
not actually started. I did a git bisection and it pointed to:
commit d545f1d6c2519a183ed631cfca7aff0baf29fde5 (refs/bisect/bad)
Author: Dari
On 07/08/2019 15:31, Juergen Gross wrote:
> While hunting a locking problem in my core scheduling series I have
> added some debugging aids to spinlock handling making it easier to
> find the root cause for the problem.
>
> Making use of the already lock profiling and enhancing it a little
> bit p
On 05/08/2019, 18:49, "Lars Kurth" wrote:
On 02/08/2019, 14:36, "Lars Kurth" wrote:
On 02/08/2019, 14:03, "Julien Grall" wrote:
On 02/08/2019 14:02, Julien Grall wrote:
> Hi Jan,
>
> On
On 07/08/19 19:49, Richard Henderson wrote:
> On 8/7/19 1:33 AM, tony.ngu...@bt.com wrote:
>> @@ -551,6 +551,7 @@ void virtio_address_space_write(VirtIOPCIProxy *proxy,
>> hwaddr addr,
>> /* As length is under guest control, handle illegal values. */
>> return;
>> }
>> +
On 8/7/19 1:33 AM, tony.ngu...@bt.com wrote:
> @@ -551,6 +551,7 @@ void virtio_address_space_write(VirtIOPCIProxy *proxy,
> hwaddr addr,
> /* As length is under guest control, handle illegal values. */
> return;
> }
> +/* FIXME: memory_region_dispatch_write ignores MO_BS
Support for FIFO event channel ABI was first introduced in Xen 4.4
(see 88910061ec6). Make this support tunable, since the choice of which
event channel ABI has implications for hibernation. Consider resuming a
pre Xen 4.4 hibernated Linux guest. During resume from hibernation, there
are two kernel
On 8/7/19 1:33 AM, tony.ngu...@bt.com wrote:
> @@ -1246,7 +1246,7 @@ typedef uint64_t FullLoadHelper(CPUArchState *env,
> target_ulong addr,
>
> static inline uint64_t __attribute__((always_inline))
> load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi,
> -uintptr_t ret
Hi,
Nevertheless
I'd appreciate if the type-unsafe _xrealloc() didn't remain the
only re-allocation construct, as to avoiding people using it just
because there's no better alternative.
I got your point.
--
Regards,
Oleksandr Tyshchenko
___
Xe
On 07/08/2019 15:31, Juergen Gross wrote:
> Instead of enabling spinlock debugging for debug builds only add a
> dedicated Kconfig option for that purpose which defaults to DEBUG.
>
> Signed-off-by: Juergen Gross
> ---
> xen/Kconfig.debug | 7 +++
> xen/common/spinlock.c | 4 ++
On 07/08/2019 15:31, Juergen Gross wrote:
> Add the cpu currently holding the lock to struct lock_debug. This makes
> analysis of locking errors easier and it can be tested whether the
> correct cpu is releasing a lock again.
>
> Signed-off-by: Juergen Gross
Looking at the structure:
xen.git/x
Hi Stefano,
On 07/08/2019 17:49, Stefano Stabellini wrote:
Commit 4941bfb "xen/arm64: macros: Introduce an assembly macro to alias
x30" moved
lr .reqx30
to macros.h. A later patch (1396dab "xen/arm64: head: Don't clobber
x30/lr in the macro PRINT") started to use "lr" in head.S, ho
Commit 4941bfb "xen/arm64: macros: Introduce an assembly macro to alias
x30" moved
lr .reqx30
to macros.h. A later patch (1396dab "xen/arm64: head: Don't clobber
x30/lr in the macro PRINT") started to use "lr" in head.S, however, it
didn't add an #include macros.h to head.S. This commi
On 06/08/2019 22:49, Stefano Stabellini wrote:
static void __init process_multiboot_node(const void *fdt, int node,
const char *name,
u32 address_cells, u32 size_cells)
@@ -307,7 +334,11 @@ static int __in
flight 139810 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139810/
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
Hi Stefano,
On 06/08/2019 22:49, Stefano Stabellini wrote:
Improve early_print_info to also print the banks saved in
bootinfo.reserved_mem. Print them right after RESVD, increasing the same
index.
Signed-off-by: Stefano Stabellini
---
Changes in v4:
- new patch
---
xen/arch/arm/bootfdt.c | 9
Hi Stefano,
On 06/08/2019 22:49, Stefano Stabellini wrote:
As we parse the device tree in Xen, keep track of the reserved-memory
regions as they need special treatment (follow-up patches will make use
of the stored information.)
Reuse process_memory_node to add reserved-memory regions to the
bo
On 07.08.2019 18:04, Marek Marczykowski-Górecki wrote:
On Wed, Aug 07, 2019 at 05:58:59PM +0200, Jan Beulich wrote:
On 07.08.2019 17:51, Marek Marczykowski-Górecki wrote:
On Wed, Aug 07, 2019 at 05:33:05PM +0200, Jan Beulich wrote:
On 07.08.2019 17:17, Marek Marczykowski-Górecki wrote:
Act
flight 139777 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139777/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c30fbac4e210a81695a7708997241de0535dbc28
baseline version:
ovmf 76e40d7be239893dbf984
On 8/7/19 1:32 AM, tony.ngu...@bt.com wrote:
> device_endian has been made redundant by MemOp.
>
> Signed-off-by: Tony Nguyen
> ---
> include/exec/cpu-common.h | 8
> 1 file changed, 8 deletions(-)
Reviewed-by: Richard Henderson
r~
___
X
On 8/7/19 1:31 AM, tony.ngu...@bt.com wrote:
> Simplify endianness comparisons with consistent use of the more
> expressive MemOp.
>
> Suggested-by: Richard Henderson
> Signed-off-by: Tony Nguyen ---
Reviewed-by: Richard Henderson
r~
___
Xen-deve
Hi Stefano,
On 06/08/2019 22:49, Stefano Stabellini wrote:
Change the signature of process_memory_node to match
device_tree_node_func. Thanks to this change, the next patch will be
able to use device_tree_for_each_node to call process_memory_node on all
the children of a provided node.
Return e
On 07/08/2019 17:08, Julien Grall wrote:
Hi Stefano,
On 06/08/2019 22:49, Stefano Stabellini wrote:
Add new parameters to device_tree_for_each_node: node, depth,
address_cells, size_cells.
address_cells (resp. size_cells) are named address_cells_p (resp. size_cells_p)
in the code.
But I
On Mon, Jul 29, 2019 at 04:39:44PM +0100, Anthony PERARD wrote:
> A Xen PVH guest doesn't have a RTC that OVMF would expect, so
> PcatRealTimeClockRuntimeDxe fails to initialize and prevent the
> firmware from finish to boot. To prevent that, we will use
> XenRealTimeClockLib which simply always re
Hi Stefano,
On 06/08/2019 22:49, Stefano Stabellini wrote:
Add new parameters to device_tree_for_each_node: node, depth,
address_cells, size_cells.
address_cells (resp. size_cells) are named address_cells_p (resp. size_cells_p)
in the code.
But I am not convinced you need them. Per the DT s
On 8/7/19 8:59 AM, Richard Henderson wrote:
> On 8/7/19 1:31 AM, tony.ngu...@bt.com wrote:
>> + &serial_mm_ops[end == DEVICE_LITTLE_ENDIAN ? 0 :
>> 1],
>
> This is of course "end != DEVICE_LITTLE_ENDIAN".
And by that I mean drop the ?: operator.
r~
__
On Mon, Jul 29, 2019 at 04:39:42PM +0100, Anthony PERARD wrote:
> XenIoPvhDxe use XenIoMmioLib to reserve some space to be use by the
> Grant Tables.
>
> The call is only done if it is necessary, we simply detect if the
> guest is PVH, as in this case there is currently no PCI bus, and no
> PCI Xe
On Wed, Aug 07, 2019 at 05:58:59PM +0200, Jan Beulich wrote:
> On 07.08.2019 17:51, Marek Marczykowski-Górecki wrote:
> > On Wed, Aug 07, 2019 at 05:33:05PM +0200, Jan Beulich wrote:
> > > On 07.08.2019 17:17, Marek Marczykowski-Górecki wrote:
> > > > Actually, I've already tried, but every other
On 07.08.2019 17:57, Andrew Cooper wrote:
On 07/08/2019 16:08, Jan Beulich wrote:
On 07.08.2019 17:00, Andrew Cooper wrote:
On 07/08/2019 15:30, Jan Beulich wrote:
On 07.08.2019 15:41, Andrew Cooper wrote:
Furthermore, if there is this problem for event channels, then
there is
almost certainl
Hi, Shimoda-san.
Thank you for the review.
From: Oleksandr Tyshchenko, Sent: Saturday, August 3, 2019 1:40 AM
From: Oleksandr Tyshchenko
The IPMMU-VMSA is VMSA-compatible I/O Memory Management Unit (IOMMU)
which provides address translation and access protection functionalities
to proces
On Mon, Jul 29, 2019 at 04:39:40PM +0100, Anthony PERARD wrote:
> On a Xen PVH guest, none of the existing serial or console interface
> works, so we add a new one, based on XenConsoleSerialPortLib, and
> implemented via SerialDxe.
>
> That is a simple console implementation that can works on both
On 8/7/19 1:31 AM, tony.ngu...@bt.com wrote:
> + &serial_mm_ops[end == DEVICE_LITTLE_ENDIAN ? 0 :
> 1],
This is of course "end != DEVICE_LITTLE_ENDIAN".
r~
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lis
On 07.08.2019 17:51, Marek Marczykowski-Górecki wrote:
On Wed, Aug 07, 2019 at 05:33:05PM +0200, Jan Beulich wrote:
On 07.08.2019 17:17, Marek Marczykowski-Górecki wrote:
Actually, I've already tried, but every other build I try, I get even
less useful call trace, for example debug unstable b
On 07/08/2019 16:08, Jan Beulich wrote:
> On 07.08.2019 17:00, Andrew Cooper wrote:
>> On 07/08/2019 15:30, Jan Beulich wrote:
>>> On 07.08.2019 15:41, Andrew Cooper wrote:
Furthermore, if there is this problem for event channels, then
there is
almost certainly a related problem for
On 8/7/19 1:31 AM, tony.ngu...@bt.com wrote:
> Preparation to replace device_endian with MemOp.
>
> Mapping device_endian onto MemOp limits behaviour changes to this
> relatively smaller patch.
>
> The next patch will replace all device_endian usages with the
> equivalent MemOp. That patch will b
On Mon, Jul 29, 2019 at 04:39:38PM +0100, Anthony PERARD wrote:
> PcdFSBClock is used by SecPeiDxeTimerLibCpu, the TimerLib
> implementation. It will also be used by XenTimerDxe. Override
> PcdFSBClock to match Xen vLAPIC timer frequency.
I'm kind of surprised that his is not automatically detecte
On Wed, Aug 07, 2019 at 05:33:05PM +0200, Jan Beulich wrote:
> On 07.08.2019 17:17, Marek Marczykowski-Górecki wrote:
> > On Wed, Aug 07, 2019 at 04:45:43PM +0200, Jan Beulich wrote:
> > > On 07.08.2019 15:26, Marek Marczykowski-Górecki wrote:
> > > > Hi,
> > > >
> > > > Xen 4.12 crashes when bo
On Mon, Jul 29, 2019 at 04:39:37PM +0100, Anthony PERARD wrote:
> When running in a Xen PVH guest, there's nothing to do in
> PciAcpiInitialization() because there isn't any PCI bus. When the Host
> Bridge DID isn't recognised, simply continue. (The value of
> PcdOvmfHostBridgePciDevId would be 0 b
On 8/7/19 1:30 AM, tony.ngu...@bt.com wrote:
> Temporarily no-op size_memop was introduced to aid the conversion of
> memory_region_dispatch_{read|write} operand "unsigned size" into
> "MemOp op".
>
> Now size_memop is implemented, again hard coded size but with
> MO_{8|16|32|64}. This is more exp
On 8/7/19 1:30 AM, tony.ngu...@bt.com wrote:
> Temporarily no-op size_memop was introduced to aid the conversion of
> memory_region_dispatch_{read|write} operand "unsigned size" into
> "MemOp op".
>
> Now size_memop is implemented, again hard coded size but with
> MO_{8|16|32|64}. This is more exp
On 8/7/19 1:30 AM, tony.ngu...@bt.com wrote:
> Temporarily no-op size_memop was introduced to aid the conversion of
> memory_region_dispatch_{read|write} operand "unsigned size" into
> "MemOp op".
>
> Now size_memop is implemented, again hard coded size but with
> MO_{8|16|32|64}. This is more exp
> On 7. Aug 2019, at 15:41, Andrew Cooper wrote:
>
> On 07/08/2019 12:20, Eslam Elnikety wrote:
>> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
>> index 19486d5e32..654b4fdd22 100644
>> --- a/xen/include/public/domctl.h
>> +++ b/xen/include/public/domctl.h
>> @@ -64,6
On 8/7/19 1:29 AM, tony.ngu...@bt.com wrote:
> Convert memory_region_dispatch_{read|write} operand "unsigned size"
> into a "MemOp op".
>
> Signed-off-by: Tony Nguyen
> ---
> include/exec/memop.h | 18 +-
> include/exec/memory.h | 9 +
> memory.c | 7 +
(Adding Juergen.)
Hi, thanks for the resend.
David Woodhouse writes ("[PATCH v2] tools/xenstore: Do not abort xenstore-ls if
a node disappears while iterating"):
> From: David Woodhouse
>
> When recursing, a node sometimes disappears. Deal with it and move on
> instead of aborting and failing
On Mon, Jul 29, 2019 at 04:39:32PM +0100, Anthony PERARD wrote:
> When running as a Xen PVH guest, there is no CMOS to read the memory
> size from. Rework GetSystemMemorySize(Below|Above)4gb() so they can
> work without CMOS by reading the e820 table.
>
> Rework XenPublishRamRegions to also care
On 07.08.2019 17:17, Marek Marczykowski-Górecki wrote:
On Wed, Aug 07, 2019 at 04:45:43PM +0200, Jan Beulich wrote:
On 07.08.2019 15:26, Marek Marczykowski-Górecki wrote:
Hi,
Xen 4.12 crashes when booting on UEFI (with multiboot2) unless I disable
runtime services. The crash happens shortly
On 8/7/19 1:29 AM, tony.ngu...@bt.com wrote:
> The memory_region_dispatch_{read|write} operand "unsigned size" is
> being converted into a "MemOp op".
>
> Convert interfaces by using no-op size_memop.
>
> After all interfaces are converted, size_memop will be implemented
> and the memory_region_d
On 8/7/19 1:26 AM, tony.ngu...@bt.com wrote:
> +/* Size in bytes to MemOp. */
> +static inline MemOp size_memop(unsigned size)
> +{
> +/*
> + * FIXME: No-op to aid conversion of memory_region_dispatch_{read|write}
> + * "unsigned size" operand into a "MemOp op".
> + */
> +retur
From: David Woodhouse
When recursing, a node sometimes disappears. Deal with it and move on
instead of aborting and failing to print the rest of what was
requested.
Either EACCES or ENOENT may occur as the result of race conditions with
updates; any other error should abort as before.
Signed-of
On Wed, 2019-08-07 at 13:04 +0200, Juergen Gross wrote:
> csched2_deinit() is leaking the run-queue memory.
>
> Signed-off-by: Juergen Gross
>
Acked-by: Dario Faggioli
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE ht
On Mon, Jul 29, 2019 at 04:39:31PM +0100, Anthony PERARD wrote:
> When the Xen PVH entry point has been used, hvmloader hasn't run and
> hasn't prepared an E820 table. The only way left to get an E820 table
> is to ask Xen via an hypercall, the call can only be made once so keep
> the result cached
On 07.08.2019 17:00, Andrew Cooper wrote:
On 07/08/2019 15:30, Jan Beulich wrote:
On 07.08.2019 15:41, Andrew Cooper wrote:
Furthermore, if there is this problem for event channels, then there is
almost certainly a related problem for grant tables.
The control in Xen should be expressed in a p
On Mon, Jul 29, 2019 at 04:39:29PM +0100, Anthony PERARD wrote:
> XenPvhDetected() can be used to figure out if OVMF has started via the
> Xen PVH entry point.
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
> Signed-off-by: Anthony PERARD
> Acked-by: Laszlo Ersek
Thanks, I've got
On 8/7/19 3:22 AM, Paolo Bonzini wrote:
> On 07/08/19 10:32, tony.ngu...@bt.com wrote:
>> +#if defined(HOST_WORDS_BIGENDIAN)
>> + .endianness = MO_BE,
>> +#else
>> + .endianness = MO_LE,
>> +#endif
>
> Host endianness is just 0, isn't it?
Yes. Just leaving a comment to that effect here for
On 07/08/2019 15:30, Jan Beulich wrote:
> On 07.08.2019 15:41, Andrew Cooper wrote:
>> On 07/08/2019 12:20, Eslam Elnikety wrote:
>>> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
>>> index 19486d5e32..654b4fdd22 100644
>>> --- a/xen/include/public/domctl.h
>>> +++ b/xen/in
On 07.08.2019 15:26, Marek Marczykowski-Górecki wrote:
Hi,
Xen 4.12 crashes when booting on UEFI (with multiboot2) unless I disable
runtime services. The crash happens shortly after starting dom0 kernel.
Unfortunately I don't have serial console there, so the only log I have
is a photo of VGA c
Hi,
On 07/08/2019 15:35, Jan Beulich wrote:
On 07.08.2019 13:20, Eslam Elnikety wrote:
>> --- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -338,6 +338,7 @@ struct domain
struct evtchn **evtchn_group[NR_EVTCHN_GROUPS]; /* all other buckets */
unsigned int max_evtch
On Mon, Jul 29, 2019 at 04:39:21PM +0100, Anthony PERARD wrote:
> Check if there's a start of the day struct provided to PVH guest, save
> the ACPI RSDP address for later.
>
> This patch import import arch-x86/hvm/start_info.h from xen.git.
You seem to change the types when importing start_info.h
On 07.08.2019 13:20, Eslam Elnikety wrote:
Adding support for FIFO event channel ABI was first introduced in Xen 4.4
(see 88910061ec6). Make this support tunable, since the choice of which
event channel ABI has implications for hibernation. Consider resuming a
pre Xen 4.4 hibernated Linux guest.
Today adding locks located in a struct to lock profiling requires a
unique type index for each structure. This makes it hard to add any
new structure as the related sysctl interface needs to be changed, too.
Instead of using an index the already existing struct name specified
in lock_profile_regis
Instead of enabling spinlock debugging for debug builds only add a
dedicated Kconfig option for that purpose which defaults to DEBUG.
Signed-off-by: Juergen Gross
---
xen/Kconfig.debug | 7 +++
xen/common/spinlock.c | 4 ++--
xen/include/xen/spinlock.h | 2 +-
3 files changed,
Add the cpu currently holding the lock to struct lock_debug. This makes
analysis of locking errors easier and it can be tested whether the
correct cpu is releasing a lock again.
Signed-off-by: Juergen Gross
---
xen/common/spinlock.c | 31 +--
xen/include/xen/spin
While hunting a locking problem in my core scheduling series I have
added some debugging aids to spinlock handling making it easier to
find the root cause for the problem.
Making use of the already lock profiling and enhancing it a little
bit produces some really valuable diagnostic data e.g. when
Print the lock profile data when the system crashes and add some more
information for each lock data (lock address, cpu holding the lock).
This is especially beneficial for watchdog triggered crashes in case
of deadlocks.
In order to have the cpu holding the lock available let the
LOCK_PROFILE co
On 07.08.2019 15:41, Andrew Cooper wrote:
On 07/08/2019 12:20, Eslam Elnikety wrote:
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 19486d5e32..654b4fdd22 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -64,6 +64,9 @@ struct xen_domctl_
On Mon, Jul 29, 2019 at 04:39:18PM +0100, Anthony PERARD wrote:
> The ACPI Timer isn't present in a PVH guest, but local APIC works on
> both PVH and HVM.
>
> Note that the use of SecPeiDxeTimerLibCpu might be an issue with a
> driver of type DXE_RUNTIME_DRIVER. I've attempted to find out which of
flight 139773 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139773/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 12 guest-start fail REGR. vs. 139698
Tests which did not s
On 07/08/2019 14:26, Marek Marczykowski-Górecki wrote:
> Hi,
>
> Xen 4.12 crashes when booting on UEFI (with multiboot2) unless I disable
> runtime services. The crash happens shortly after starting dom0 kernel.
> Unfortunately I don't have serial console there, so the only log I have
> is a photo
1 - 100 of 203 matches
Mail list logo
