On 17.07.19 00:27, Andrew Cooper wrote:
On 16/07/2019 05:20, Sarah Newman wrote:
On 7/15/19 8:48 PM, Juergen Gross wrote:
On 15.07.19 21:31, Sarah Newman wrote:
On 7/15/19 11:57 AM, Foerster, Leonard wrote:
...
A key cornerstone for Live-update is guest transparent live migration
...
-
On 17.07.2019 20:40, Andrew Cooper wrote:
> On 17/07/2019 14:02, Jan Beulich wrote:
>> On 17.07.2019 13:26, Andrew Cooper wrote:
>>> We do not want to be grovelling around in the old Xen's datastructures,
>>> because that adds a binary A=>B translation which is
>>> per-old-version-of-xen, meaning t
> -Original Message-
> From: Xen-devel On Behalf Of Juergen
> Gross
> Sent: 18 July 2019 10:00
> To: Andrew Cooper ; Sarah Newman ;
> Foerster, Leonard
> ; xen-devel@lists.xenproject.org
> Subject: Re: [Xen-devel] Design session report: Live-Updating Xen
>
> On 17.07.19 00:27, Andrew Co
On 17.07.2019 19:09, Andrew Cooper wrote:
> On 17/07/2019 14:07, Jan Beulich wrote:
>> On 17.07.2019 13:42, Andrew Cooper wrote:
>>> On 17/07/2019 07:42, Jan Beulich wrote:
With AMD apparently having abandoned XOP encoded insns, another option
would seem to be to simply wire all unrecogni
> -Original Message-
[snip]
>
> Longer term vision:
>
> * Have a tiny hypervisor between Guest and Xen that handles the common cases
> -> this enables (almost) zero downtime for the guest
> -> the tiny hypervisor will maintain the guest while the underlying xen
> is kexecing
On Wed, Jul 17, 2019 at 05:09:12PM +0200, Marek Marczykowski-Górecki wrote:
> On Wed, Jul 17, 2019 at 11:54:35AM +0200, Roger Pau Monné wrote:
> > On Wed, Jul 17, 2019 at 03:00:42AM +0200, Marek Marczykowski-Górecki wrote:
> > > @@ -220,14 +237,22 @@ void destroy_irq(unsigned int irq)
> > >
> > >
On 18/07/2019 10:18, Jan Beulich wrote:
> On 17.07.2019 19:09, Andrew Cooper wrote:
>> On 17/07/2019 14:07, Jan Beulich wrote:
>>> On 17.07.2019 13:42, Andrew Cooper wrote:
On 17/07/2019 07:42, Jan Beulich wrote:
> With AMD apparently having abandoned XOP encoded insns, another option
On Thu, Jul 18, 2019 at 11:00:23AM +0200, Juergen Gross wrote:
> On 17.07.19 00:27, Andrew Cooper wrote:
> > On 16/07/2019 05:20, Sarah Newman wrote:
> > > On 7/15/19 8:48 PM, Juergen Gross wrote:
> > > > On 15.07.19 21:31, Sarah Newman wrote:
> > > > > On 7/15/19 11:57 AM, Foerster, Leonard wrote:
On 18.07.19 11:40, Roger Pau Monné wrote:
On Thu, Jul 18, 2019 at 11:00:23AM +0200, Juergen Gross wrote:
On 17.07.19 00:27, Andrew Cooper wrote:
On 16/07/2019 05:20, Sarah Newman wrote:
On 7/15/19 8:48 PM, Juergen Gross wrote:
On 15.07.19 21:31, Sarah Newman wrote:
On 7/15/19 11:57 AM, Foer
On 18.07.2019 11:30, Andrew Cooper wrote:
> On 18/07/2019 10:18, Jan Beulich wrote:
>> On 17.07.2019 19:09, Andrew Cooper wrote:
>>> On 17/07/2019 14:07, Jan Beulich wrote:
On 17.07.2019 13:42, Andrew Cooper wrote:
> On 17/07/2019 07:42, Jan Beulich wrote:
>> With AMD apparently having
Hi,
Before I get too far into this I want to get some opinions from the wider
community...
At the moment when the first PCI device is assigned to a domain (i.e. passed
through) this will trigger construction of IOMMU page tables for that domain.
Similarly when the last PCI device is de-ass
From: Andrii Anisov
Using XEN_RUNSTATE_UPDATE mask during the process of copying runstate
values to guest causes runstate entry time to be eventually considered
negative on a calculation of the time delta. So the XEN_RUNSTATE_UPDATE
should be masked out during the calculation of the time spent in
On 7/18/19 9:52 AM, Juergen Gross wrote:
The Xen gntdev driver's checking of the number of allowed mapped pages
is in need of some sanitizing work.
Juergen Gross (2):
xen/gntdev: replace global limit of mapped pages by limit per call
xen/gntdev: switch from kcalloc() to kvcalloc()
drive
On 7/17/19 10:55 PM, Denis Obrezkov wrote:
Hi,
Hi,
Well, Xen has been supported the omap5 for quite a while. So there are
two possibilities regarding the current SMP code:
1) It is totally broken and therefore never worked on any omap5
platform.
2) It works but with maybe modification
On 18/07/2019 10:49, Paul Durrant wrote:
> Hi,
>
> Before I get too far into this I want to get some opinions from the wider
> community...
>
> At the moment when the first PCI device is assigned to a domain (i.e.
> passed through) this will trigger construction of IOMMU page tables for that
flight 139082 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139082/
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. 139030
Tests which did not
Hello George,
The patch was also CC'ed to you, but I got:
"554 esa1.hc3370-68.iphmx.com You are being rejected because your senderbase score
is below our accepted policy."
from your server.
ps. I hope I'm not bothering you too much.
On 18.07.19 12:54, Andrii Anisov wrote:
From: Andrii Aniso
On 17.07.2019 21:33, Tamas K Lengyel wrote:
> Calling _put_page_type while also holding the page_lock
> for that page can cause a deadlock.
>
> The comment being dropped is incorrect since it's now out-of-date.
>
> Signed-off-by: Tamas K Lengyel
The description covers ...
> --- a/xen/arch/x86/
On 17.07.2019 21:33, Tamas K Lengyel wrote:
> @@ -136,8 +137,8 @@ static inline bool _page_lock(struct page_info *page)
> cpu_relax();
> nx = x + (1 | PGT_locked);
> if ( !(x & PGT_validated) ||
> - !(x & PGT_count_mask) ||
> - !(nx & PGT_co
On 18.07.2019 11:54, Andrii Anisov wrote:
> Using XEN_RUNSTATE_UPDATE mask during the process of copying runstate
> values to guest causes runstate entry time to be eventually considered
> negative on a calculation of the time delta. So the XEN_RUNSTATE_UPDATE
> should be masked out during the calc
On 18.07.2019 12:13, Andrew Cooper wrote:
> On 18/07/2019 10:49, Paul Durrant wrote:
>> Hi,
>>
>>Before I get too far into this I want to get some opinions from the wider
>> community...
>>
>>At the moment when the first PCI device is assigned to a domain (i.e.
>> passed through) this wil
On 18/07/2019 12:16, Jan Beulich wrote:
> On 18.07.2019 12:13, Andrew Cooper wrote:
>> On 18/07/2019 10:49, Paul Durrant wrote:
>>> Hi,
>>>
>>>Before I get too far into this I want to get some opinions from the
>>> wider community...
>>>
>>>At the moment when the first PCI device is assign
On 17.07.2019 19:06, Andrew Cooper wrote:
> On 17/07/2019 15:08, Roger Pau Monné wrote:
>> As part of some PCI related cleanup I'm doing, which includes
>> expanding the usage of pci_sbdf_t, I'm also planning to add a custom
>> printf formatter for pci_sbdf_t [0], so that a SBDF can be printed
>> w
The helper maddr_to_virt() is used to translate a machine address to a
virtual address. To save some valuable address space, some part of the
machine address may be compressed.
In theory the PDX code is free to compress any bits so there are no
guarantee the machine index computed will be always g
Andrew had spotted these going in there, and we clearly want them
too.
1: x86/cpu/intel: Clear cache self-snoop capability in CPUs with known errata
2: x86/mtrr: Skip cache flushes on CPUs with cache self-snooping
Jan
___
Xen-devel mailing list
Xen-deve
On Thu, 2019-07-18 at 09:15 +, Jan Beulich wrote:
> On 17.07.2019 20:40, Andrew Cooper wrote:
> > On 17/07/2019 14:02, Jan Beulich wrote:
> > > On 17.07.2019 13:26, Andrew Cooper wrote:
> > > > We do not want to be grovelling around in the old Xen's
> > > > datastructures,
> > > > because that
On 12.07.2019 10:51, Norbert Manthey wrote:
> Guests can issue grant table operations and provide guest controlled
> data to them. This data is used as index for memory loads after bound
> checks have been done. To avoid speculative out-of-bound accesses, we
> use the array_index_nospec macro where
From: Ricardo Neri
Programming MTRR registers in multi-processor systems is a rather lengthy
process. Furthermore, all processors must program these registers in lock
step and with interrupts disabled; the process also involves flushing
caches and TLBs twice. As a result, the process may take a c
flight 139091 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139091/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 138376
test-amd64-amd64-qemuu-nested-am
From: Ricardo Neri
Processors which have self-snooping capability can handle conflicting
memory type across CPUs by snooping its own cache. However, there exists
CPU models in which having conflicting memory types still leads to
unpredictable behavior, machine check errors, or hangs.
Clear this
On 18/07/2019 13:09, Jan Beulich wrote:
> --- a/xen/arch/x86/cpu/intel.c
> +++ b/xen/arch/x86/cpu/intel.c
> @@ -15,6 +15,32 @@
> #include "cpu.h"
>
> /*
> + * Processors which have self-snooping capability can handle conflicting
> + * memory type across CPUs by snooping its own cache. Howeve
On 18/07/2019 13:10, Jan Beulich wrote:
> From: Ricardo Neri
>
> Programming MTRR registers in multi-processor systems is a rather lengthy
> process. Furthermore, all processors must program these registers in lock
> step and with interrupts disabled; the process also involves flushing
> caches an
flight 139099 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139099/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf cce01f538fb4d6ae8c13c88cfc0d3caf5baca833
baseline version:
ovmf 35e242b698cdc6205e99a
On Thu, Jul 18, 2019 at 4:47 AM Jan Beulich wrote:
>
> On 17.07.2019 21:33, Tamas K Lengyel wrote:
> > Calling _put_page_type while also holding the page_lock
> > for that page can cause a deadlock.
> >
> > The comment being dropped is incorrect since it's now out-of-date.
> >
> > Signed-off-by: T
On 03.07.2019 12:56, Alexandru Stefan ISAILA wrote:
> A/D bit writes (on page walks) can be considered benign by an introspection
> agent, so receiving vm_events for them is a pessimization. We try here to
> optimize by fitering these events out.
But you add the sending of more events - how does "
On Thu, Jul 18, 2019 at 4:56 AM Jan Beulich wrote:
>
> On 17.07.2019 21:33, Tamas K Lengyel wrote:
> > @@ -136,8 +137,8 @@ static inline bool _page_lock(struct page_info *page)
> > cpu_relax();
> > nx = x + (1 | PGT_locked);
> > if ( !(x & PGT_validated) ||
> > -
On 18.07.2019 14:23, Andrew Cooper wrote:
> On 18/07/2019 13:09, Jan Beulich wrote:
>> --- a/xen/arch/x86/cpu/intel.c
>> +++ b/xen/arch/x86/cpu/intel.c
>> @@ -15,6 +15,32 @@
>>#include "cpu.h"
>>
>>/*
>> + * Processors which have self-snooping capability can handle conflicting
>> + * me
On 7/17/19 7:39 PM, Dario Faggioli wrote:
>>> @@ -518,6 +521,14 @@ static void null_vcpu_remove(const struct
>>> scheduler *ops, struct vcpu *v)
>>>
>>> lock = vcpu_schedule_lock_irq(v);
>>>
>>> +/* If offline, the vcpu shouldn't be assigned, nor in the
>>> waitqueue */
>>> +if ( u
On 18.07.2019 14:55, Tamas K Lengyel wrote:
> On Thu, Jul 18, 2019 at 4:47 AM Jan Beulich wrote:
>> On 17.07.2019 21:33, Tamas K Lengyel wrote:
>>> @@ -900,6 +895,7 @@ static int share_pages(struct domain *sd, gfn_t sgfn,
>>> shr_handle_t sh,
>>>p2m_type_t smfn_type, cmfn_type;
>>>
On 18.07.2019 14:59, Tamas K Lengyel wrote:
> On Thu, Jul 18, 2019 at 4:56 AM Jan Beulich wrote:
>>
>> On 17.07.2019 21:33, Tamas K Lengyel wrote:
>>> @@ -136,8 +137,8 @@ static inline bool _page_lock(struct page_info *page)
>>>cpu_relax();
>>>nx = x + (1 | PGT_locked);
On Thu, Jul 18, 2019 at 7:12 AM Jan Beulich wrote:
>
> On 18.07.2019 14:55, Tamas K Lengyel wrote:
> > On Thu, Jul 18, 2019 at 4:47 AM Jan Beulich wrote:
> >> On 17.07.2019 21:33, Tamas K Lengyel wrote:
> >>> @@ -900,6 +895,7 @@ static int share_pages(struct domain *sd, gfn_t sgfn,
> >>> shr_han
On Thu, Jul 18, 2019 at 7:14 AM Jan Beulich wrote:
>
> On 18.07.2019 14:59, Tamas K Lengyel wrote:
> > On Thu, Jul 18, 2019 at 4:56 AM Jan Beulich wrote:
> >>
> >> On 17.07.2019 21:33, Tamas K Lengyel wrote:
> >>> @@ -136,8 +137,8 @@ static inline bool _page_lock(struct page_info *page)
> >>>
On 18/07/2019 14:07, Jan Beulich wrote:
> On 18.07.2019 14:23, Andrew Cooper wrote:
>> On 18/07/2019 13:09, Jan Beulich wrote:
>>> --- a/xen/arch/x86/cpu/intel.c
>>> +++ b/xen/arch/x86/cpu/intel.c
>>> @@ -15,6 +15,32 @@
>>>#include "cpu.h"
>>>
>>>/*
>>> + * Processors which have self-sn
Hi Julien,
I've checked latest Xen staging, the patch has not been integrated yet.
Please integrate the patch if no objections.
Thanks
On Mon, Jul 8, 2019 at 3:12 PM Julien Grall wrote:
>
> Hi Viktor,
>
> On 6/18/19 9:58 AM, Viktor Mitin wrote:
> > Some of the function generating nodes (e.g mak
From: Andrii Anisov
After changes introduced by 9cc0618 we are able to vmap/vunmap
page aligned addresses only.
So if we add a page address remainder to the mapped virtual address,
we have to mask it out before unmapping.
Signed-off-by: Andrii Anisov
---
xen/arch/arm/cpuerrata.c | 2 +-
1 file
On 18.07.2019 15:13, Tamas K Lengyel wrote:
> On Thu, Jul 18, 2019 at 7:12 AM Jan Beulich wrote:
>>
>> On 18.07.2019 14:55, Tamas K Lengyel wrote:
>>> On Thu, Jul 18, 2019 at 4:47 AM Jan Beulich wrote:
On 17.07.2019 21:33, Tamas K Lengyel wrote:
> @@ -900,6 +895,7 @@ static int share_pag
On 18.07.2019 15:16, Tamas K Lengyel wrote:
> On Thu, Jul 18, 2019 at 7:14 AM Jan Beulich wrote:
>>
>> On 18.07.2019 14:59, Tamas K Lengyel wrote:
>>> On Thu, Jul 18, 2019 at 4:56 AM Jan Beulich wrote:
On 17.07.2019 21:33, Tamas K Lengyel wrote:
> @@ -136,8 +137,8 @@ static inline b
On 18/07/2019 14:22, Andrii Anisov wrote:
> From: Andrii Anisov
>
> After changes introduced by 9cc0618 we are able to vmap/vunmap
> page aligned addresses only.
> So if we add a page address remainder to the mapped virtual address,
> we have to mask it out before unmapping.
>
> Signed-off-by: And
On 18/07/2019 14:38, Andrew Cooper wrote:
> On 18/07/2019 14:22, Andrii Anisov wrote:
>> From: Andrii Anisov
>>
>> After changes introduced by 9cc0618 we are able to vmap/vunmap
>> page aligned addresses only.
>> So if we add a page address remainder to the mapped virtual address,
>> we have to ma
Hi,
On 7/18/19 2:43 PM, Andrew Cooper wrote:
On 18/07/2019 14:38, Andrew Cooper wrote:
On 18/07/2019 14:22, Andrii Anisov wrote:
From: Andrii Anisov
After changes introduced by 9cc0618 we are able to vmap/vunmap
page aligned addresses only.
So if we add a page address remainder to the mapped
On Thu, Jul 18, 2019 at 01:54:26AM +0200, Marek Marczykowski-Górecki wrote:
> On Wed, Jul 17, 2019 at 12:18:43PM +0200, Roger Pau Monné wrote:
> > On Wed, Jul 17, 2019 at 03:00:43AM +0200, Marek Marczykowski-Górecki wrote:
> > > Allow device model running in stubdomain to enable/disable MSI(-X),
>
On Thu, Jul 18, 2019 at 7:33 AM Jan Beulich wrote:
>
> On 18.07.2019 15:13, Tamas K Lengyel wrote:
> > On Thu, Jul 18, 2019 at 7:12 AM Jan Beulich wrote:
> >>
> >> On 18.07.2019 14:55, Tamas K Lengyel wrote:
> >>> On Thu, Jul 18, 2019 at 4:47 AM Jan Beulich wrote:
> On 17.07.2019 21:33, Tam
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-qemut-rhel6hvm-intel
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.gi
On Thu, Jul 18, 2019 at 7:37 AM Jan Beulich wrote:
>
> On 18.07.2019 15:16, Tamas K Lengyel wrote:
> > On Thu, Jul 18, 2019 at 7:14 AM Jan Beulich wrote:
> >>
> >> On 18.07.2019 14:59, Tamas K Lengyel wrote:
> >>> On Thu, Jul 18, 2019 at 4:56 AM Jan Beulich wrote:
>
> On 17.07.2019 21:
On Thu, Jul 18, 2019 at 02:12:20AM +0200, Marek Marczykowski-Górecki wrote:
> On Wed, Jul 17, 2019 at 12:21:58PM +0200, Roger Pau Monné wrote:
> > On Wed, Jul 17, 2019 at 03:00:44AM +0200, Marek Marczykowski-Górecki wrote:
> > > Add libxc wrapper for PHYSDEVOP_msi_control introduced in previous
> >
On Wed, 2019-07-17 at 16:32 +, Jan Beulich wrote:
> On 17.07.2019 16:41, Petre Ovidiu PIRCALABU wrote:
> > On Wed, 2019-07-17 at 10:06 +, Jan Beulich wrote:
> > > On 16.07.2019 19:06, Petre Pircalabu wrote:
> > > > +static void vm_event_channels_free_buffer(struct
> > > > vm_event_channels_
GCC reports:
In file included from hvm.c:24:0:
/local/xen.git/xen/include/xen/trace.h: In function ‘tb_control’:
/local/xen.git/xen/include/xen/trace.h:60:13: error: ‘ENOSYS’
undeclared (first use in this function)
return -ENOSYS;
^~
Include xen/errno.h to resolve the issue.
Use bool rather than int/bool_t for 'cycles' to match the !CONFIG_TRACEBUFFER
version, and use unsigned int rather than int for 'extra' to match the
function it is forwarded to.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Stefano Stabellini
CC: Tim D
Hello Julien,
On 18.07.19 16:44, Julien Grall wrote:
My suggestion about vunmap() still stands though.
+1 for the vunmap solution.
It was my initial idea.
But, the issue is introduced by change 9cc0618. In particular, by the check in
`xen_pt_update()`
if ( !IS_ALIGNED(virt, PAGE_SIZE)
On Thu, Jul 18, 2019 at 7:52 AM Tamas K Lengyel wrote:
>
> On Thu, Jul 18, 2019 at 7:37 AM Jan Beulich wrote:
> >
> > On 18.07.2019 15:16, Tamas K Lengyel wrote:
> > > On Thu, Jul 18, 2019 at 7:14 AM Jan Beulich wrote:
> > >>
> > >> On 18.07.2019 14:59, Tamas K Lengyel wrote:
> > >>> On Thu, Jul
Hello Jan,
On 18.07.19 14:10, Jan Beulich wrote:
A concrete scenario where update_runstate_area() and vcpu_runstate_change()
can actually race would be very worthwhile to point out here. In particular
on Arm I'm not (yet?) seeing how this could happen.
The scenario is quite trivial: some vcpu
Hello Jan,
On 18.07.19 14:10, Jan Beulich wrote:
Considering the value of XEN_RUNSTATE_UPDATE it must be a rather rare race
anyway, I would guess.
I'm not sure about the exact rate of the race, but with following prints:
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index 25f6ab3
On 7/18/19 3:08 PM, Andrii Anisov wrote:
Hello Julien,
Hi,
On 18.07.19 16:44, Julien Grall wrote:
My suggestion about vunmap() still stands though.
+1 for the vunmap solution.
It was my initial idea.
But, the issue is introduced by change 9cc0618. In particular, by the
check in `xen_pt
On 18.07.2019 15:47, Tamas K Lengyel wrote:
> On Thu, Jul 18, 2019 at 7:33 AM Jan Beulich wrote:
>>
>> On 18.07.2019 15:13, Tamas K Lengyel wrote:
>>> On Thu, Jul 18, 2019 at 7:12 AM Jan Beulich wrote:
On 18.07.2019 14:55, Tamas K Lengyel wrote:
> On Thu, Jul 18, 2019 at 4:47 AM Jan
On Thu, Jul 18, 2019 at 8:28 AM Jan Beulich wrote:
>
> On 18.07.2019 15:47, Tamas K Lengyel wrote:
> > On Thu, Jul 18, 2019 at 7:33 AM Jan Beulich wrote:
> >>
> >> On 18.07.2019 15:13, Tamas K Lengyel wrote:
> >>> On Thu, Jul 18, 2019 at 7:12 AM Jan Beulich wrote:
>
> On 18.07.2019 14:
Using astyle (http://astyle.sourceforge.net) can greatly reduce the overhead of
manually checking and applying style-fixes to source-code. The included
.astylerc is the closest approximation of the established Xen style (including
styles not formally spelled out by CODING_STYLE but commonly request
On 18.07.2019 15:59, Petre Ovidiu PIRCALABU wrote:
> Before using xenforeignmemory_map_resource I investigated several
> different approaches:
> - Allocate the memory in hypervisor and xc_map_foreign_pages (doesn't
> work because you cannot "foreignmap" pages of your own domain.
> - Allocate the me
On 18.07.2019 16:35, Tamas K Lengyel wrote:
> On Thu, Jul 18, 2019 at 8:28 AM Jan Beulich wrote:
>> On 18.07.2019 15:47, Tamas K Lengyel wrote:
>>> I feel like we are going in circles and having the same conversations
>>> over and over without really making any headway. You introduced
>>> grabbing
On 15.07.19 16:08, Sergey Dyasli wrote:
On 05/07/2019 14:56, Dario Faggioli wrote:
On Fri, 2019-07-05 at 14:17 +0100, Sergey Dyasli wrote:
1) This crash is quite likely to happen:
[2019-07-04 18:22:46 UTC] (XEN) [ 3425.220660] Watchdog timer detects
that CPU2 is stuck!
[2019-07-04 18:22:46 UTC
On Thu, 2019-07-18 at 14:44 +, Jan Beulich wrote:
> On 18.07.2019 15:59, Petre Ovidiu PIRCALABU wrote:
> > Before using xenforeignmemory_map_resource I investigated several
> > different approaches:
> > - Allocate the memory in hypervisor and xc_map_foreign_pages
> > (doesn't
> > work because y
On Thu, Jul 18, 2019 at 8:47 AM Jan Beulich wrote:
>
> On 18.07.2019 16:35, Tamas K Lengyel wrote:
> > On Thu, Jul 18, 2019 at 8:28 AM Jan Beulich wrote:
> >> On 18.07.2019 15:47, Tamas K Lengyel wrote:
> >>> I feel like we are going in circles and having the same conversations
> >>> over and ove
flight 139094 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139094/
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
Hi Tamas,
Adding Lars, Artem and Iurii. Iurii has been working on a version for
clang-format recently.
On 7/18/19 3:43 PM, Tamas K Lengyel wrote:
Using astyle (http://astyle.sourceforge.net) can greatly reduce the overhead of
manually checking and applying style-fixes to source-code. The incl
On 18.07.2019 16:12, Andrii Anisov wrote:
> On 18.07.19 14:10, Jan Beulich wrote:
>> A concrete scenario where update_runstate_area() and vcpu_runstate_change()
>> can actually race would be very worthwhile to point out here. In particular
>> on Arm I'm not (yet?) seeing how this could happen.
>
>
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
.gitignore | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.gitignore b/.gitignore
index 8a19c8af04..3c947ac948 100644
--- a/.gitignore
+++ b/.gitignore
@@ -233,7 +233,7 @@ tools/tests/x86_
On Thu, Jul 18, 2019 at 11:29:39AM +0200, Roger Pau Monné wrote:
> On Wed, Jul 17, 2019 at 05:09:12PM +0200, Marek Marczykowski-Górecki wrote:
> > On Wed, Jul 17, 2019 at 11:54:35AM +0200, Roger Pau Monné wrote:
> > > On Wed, Jul 17, 2019 at 03:00:42AM +0200, Marek Marczykowski-Górecki
> > > wrote
On 18/07/2019 15:48, Juergen Gross wrote:
> On 15.07.19 16:08, Sergey Dyasli wrote:
>> On 05/07/2019 14:56, Dario Faggioli wrote:
>>> On Fri, 2019-07-05 at 14:17 +0100, Sergey Dyasli wrote:
1) This crash is quite likely to happen:
[2019-07-04 18:22:46 UTC] (XEN) [ 3425.220660] Watchd
On Thu, Jul 18, 2019 at 11:51:57AM +, Jan Beulich wrote:
> On 17.07.2019 19:06, Andrew Cooper wrote:
> > On 17/07/2019 15:08, Roger Pau Monné wrote:
> >> As part of some PCI related cleanup I'm doing, which includes
> >> expanding the usage of pci_sbdf_t, I'm also planning to add a custom
> >>
On 18.07.2019 16:43, Tamas K Lengyel wrote:
> --- a/CODING_STYLE
> +++ b/CODING_STYLE
> @@ -60,8 +60,8 @@ Bracing
> ---
>
> Braces ('{' and '}') are usually placed on a line of their own, except
> -for the do/while loop. This is unlike the Linux coding style and
> -unlike K&R. do/while
On Thu, Jul 18, 2019 at 9:02 AM Julien Grall wrote:
>
> Hi Tamas,
>
> Adding Lars, Artem and Iurii. Iurii has been working on a version for
> clang-format recently.
>
> On 7/18/19 3:43 PM, Tamas K Lengyel wrote:
> > Using astyle (http://astyle.sourceforge.net) can greatly reduce the
> > overhead
On Thu, Jul 18, 2019 at 9:14 AM Jan Beulich wrote:
>
> On 18.07.2019 16:43, Tamas K Lengyel wrote:
> > --- a/CODING_STYLE
> > +++ b/CODING_STYLE
> > @@ -60,8 +60,8 @@ Bracing
> > ---
> >
> > Braces ('{' and '}') are usually placed on a line of their own, except
> > -for the do/while loop.
On 18.07.2019 15:46, Roger Pau Monné wrote:
> In fact I don't think INTx should be enabled when MSI(-X) is disabled,
> QEMU already traps writes to the command register, and it will manage
> INTx enabling/disabling by itself. I think the only check required is
> that MSI(-X) cannot be enabled if I
On 18.07.2019 16:00, Andrew Cooper wrote:
> GCC reports:
>
> In file included from hvm.c:24:0:
> /local/xen.git/xen/include/xen/trace.h: In function ‘tb_control’:
> /local/xen.git/xen/include/xen/trace.h:60:13: error: ‘ENOSYS’
> undeclared (first use in this function)
> return -ENOSYS;
>
On 18.07.2019 16:00, Andrew Cooper wrote:
> Use bool rather than int/bool_t for 'cycles' to match the !CONFIG_TRACEBUFFER
> version, and use unsigned int rather than int for 'extra' to match the
> function it is forwarded to.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
albeit I'd hav
On 18.07.2019 17:11, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
I'm sorry for not having paid attention when adding these.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailm
On 18.07.2019 17:14, Roger Pau Monné wrote:
> On Thu, Jul 18, 2019 at 11:51:57AM +, Jan Beulich wrote:
>> On 17.07.2019 19:06, Andrew Cooper wrote:
>>> On 17/07/2019 15:08, Roger Pau Monné wrote:
As part of some PCI related cleanup I'm doing, which includes
expanding the usage of pci
Hi Tamas,
On 7/18/19 4:14 PM, Tamas K Lengyel wrote:
On Thu, Jul 18, 2019 at 9:02 AM Julien Grall wrote:
Hi Tamas,
Adding Lars, Artem and Iurii. Iurii has been working on a version for
clang-format recently.
On 7/18/19 3:43 PM, Tamas K Lengyel wrote:
Using astyle (http://astyle.sourceforge
On 18.07.19 17:20, Julien Grall wrote:
As Andrew pointed out, this also makes the interface more consistent with how
{,un}map_domain_page() currently works.
OK, got it.
BTW, in the x86 code they do apply PAGE_MASK to va before passing it to
`vunmap()`. I would cleanup all those places as w
On Thu, 2019-07-18 at 16:14 +0100, Sergey Dyasli wrote:
> On 18/07/2019 15:48, Juergen Gross wrote:
> >
> > I can easily reproduce the issue with any PV guest with more than 1
> > vcpu
> > by doing "xl save" and then "xl restore" again.
> >
> > With the reproducer being available I'm now diving i
On Thu, Jul 18, 2019 at 03:17:27PM +, Jan Beulich wrote:
> On 18.07.2019 15:46, Roger Pau Monné wrote:
> > In fact I don't think INTx should be enabled when MSI(-X) is disabled,
> > QEMU already traps writes to the command register, and it will manage
> > INTx enabling/disabling by itself. I t
On Thu, Jul 18, 2019 at 05:12:54PM +0200, Marek Marczykowski-Górecki wrote:
> On Thu, Jul 18, 2019 at 11:29:39AM +0200, Roger Pau Monné wrote:
> > On Wed, Jul 17, 2019 at 05:09:12PM +0200, Marek Marczykowski-Górecki wrote:
> > > On Wed, Jul 17, 2019 at 11:54:35AM +0200, Roger Pau Monné wrote:
> > >
These can easily be expressed with a variadic macro. No functional change.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
Interestingly, this results in fractionally different (but equally correct)
code generation in vlapic_update_timer().
Misc fixes/improvements to trace.h noticed during the build fix for
!CONFIG_TRACEBUFFER
Andrew Cooper (3):
xen/trace: Add trace.h to MAINTAINER
xen/trace: Implement TRACE_?D() in a more efficient fashon
xen/trace: Adjust types in function declarations
MAINTAINERS | 1 +
xen/i
... to match the existing trace.c entry
Reported-by: Jan Beulich
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index b8e4daae41..d18c46de91 1006
Use uint32_t consistently for 'event', bool consistently for 'cycles',
and unsigned int consistently for 'extra'
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/include/xen/trace.h | 6 +++---
1 file changed, 3 insertions(+), 3 delet
From: Andrii Anisov
Let vunmap align passed virtual address by PAGE_SIZE.
This also makes it consistent with how {,un}map_domain_page()
currently works.
With the main change, also:
- strip all existing vunmap() calls from prior masking
- replace opencoded PAGE_MASK macro in vm_index()
Signed-
On 18/07/2019 18:11, Andrii Anisov wrote:
> From: Andrii Anisov
>
> Let vunmap align passed virtual address by PAGE_SIZE.
You probably want to describe where this goes wrong currently on ARM here.
If you can come up with a suitable piece of text, I can fix up on commit.
> This also makes it con
>- Line 289: Files imported from Linux should not be touch here.
This is just a raw dump of what happens if I run astyle on all source
and header files. Obviously I won't attempt to upstream all these
changes you see in the gist. Respective maintainers are welcome to use
the tool if they find
>- Line 139: The { are commonly on the same line as struct or definition.
According to CODING_STYLE that's not how it should be.
Tamas
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
>- Line 276: The switch case indentation was correct from Xen PoV before
Removing "indent-switches" from the .astylerc actually leaves these
switches untouched, so that's an easy fix.
Tamas
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
1 - 100 of 138 matches
Mail list logo
