As the dicsussion [1] in mailing list. We'd better to have
a barrier after reading CNTPCT in get_cycles. If there is
not any barrier there. When get_cycles being used in some
seqlock critical context in the future, the seqlock can be
speculated potentially.
In order to reduce the impact of new
It seems the arm inline function get_cycles has used 8 spaces for
line indent since 2012. This patch correct them to 4 spaces and
remove extra space between function name and bracket.
Signed-off-by: Wei Chen
---
xen/include/asm-arm/time.h | 40 +++---
1 file
flight 158142 xen-unstable-smoke real [real]
flight 158148 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158142/
http://logs.test-lab.xenproject.org/osstest/logs/158148/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which
flight 158136 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158136/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
flight 158132 xen-unstable real [real]
flight 158144 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158132/
http://logs.test-lab.xenproject.org/osstest/logs/158144/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
flight 158141 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158141/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 4e511554872c318f8bce196f1cddf69432886bfa
baseline version:
ovmf
flight 158133 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158133/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail REGR. vs. 152631
flight 158137 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158137/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e5908945368163bb15c8c1a49745f4c1138f1ab4
baseline version:
ovmf
On Mon, 2021-01-04 at 18:44 -0500, boris.ostrov...@oracle.com wrote:
> On 1/4/21 6:19 PM, David Woodhouse wrote:
> > On Mon, 2021-01-04 at 18:04 -0500, boris.ostrov...@oracle.com
> > wrote:
> > > Why not xen_hvm_cpu_die too? common_cpu_die() sounds like something
> > > we should do, and the other
On 1/4/21 6:19 PM, David Woodhouse wrote:
> On Mon, 2021-01-04 at 18:04 -0500, boris.ostrov...@oracle.com wrote:
>> On 1/4/21 5:37 PM, David Woodhouse wrote:
>>> @@ -33,9 +33,11 @@ static void __init
>>> xen_hvm_smp_prepare_cpus(unsigned int max_cpus)
>>> int cpu;
>>>
>>>
On Mon, 2021-01-04 at 18:04 -0500, boris.ostrov...@oracle.com wrote:
> On 1/4/21 5:37 PM, David Woodhouse wrote:
> >
> > @@ -33,9 +33,11 @@ static void __init
> > xen_hvm_smp_prepare_cpus(unsigned int max_cpus)
> > int cpu;
> >
> > native_smp_prepare_cpus(max_cpus);
> > -
On 1/4/21 5:37 PM, David Woodhouse wrote:
>
> @@ -33,9 +33,11 @@ static void __init xen_hvm_smp_prepare_cpus(unsigned int
> max_cpus)
> int cpu;
>
> native_smp_prepare_cpus(max_cpus);
> - WARN_ON(xen_smp_intr_init(0));
>
> - xen_init_lock_cpu(0);
> + if
Everything previously done by list_domains() is now done with
build_list_domain_format() and format().
Signed-off-by: Elliott Mitchell
---
tools/xl/xl_list.c | 90 +++---
1 file changed, 53 insertions(+), 37 deletions(-)
diff --git a/tools/xl/xl_list.c
Implement a generalized output formatting function for the `xl list`
subcommands. Notably `xl list` and `xl vm-list` could make use of
alternative output list formats.
Signed-off-by: Elliott Mitchell
---
I'm a bit unsure of #include . When looking for an
implementation of ARRAY_SIZE(), that
Add several features to specify output. Allow omitting potentially
unneeded lines and add argument for exact line format.
Signed-off-by: Elliott Mitchell
---
tools/xl/xl_list.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/tools/xl/xl_list.c
Often it is desireable to only list a specific subset of fields, or list
them in an unusual order. Previously `xl list` gave output in a fixed
order, now add "-F" to allow specifying fields and formatting.
Signed-off-by: Elliott Mitchell
---
tools/xl/xl_cmdtable.c | 14
format() is meant to be a powerful tool, sweep the remaining bits
away. Unfortunately I am unable to test this portion.
Signed-off-by: Elliott Mitchell
---
tools/xl/xl_list.c | 44
1 file changed, 8 insertions(+), 36 deletions(-)
diff --git
While the "vm-list" subcommand has far fewer fields than the "list"
subcommand, one might still desire to list a subset of the fields.
Signed-off-by: Elliott Mitchell
---
tools/xl/xl_cmdtable.c | 7 -
tools/xl/xl_list.c | 66 +-
2 files changed,
Add several features to specify output. Allow omitting potentially
unneeded lines and add argument for exact line format.
Signed-off-by: Elliott Mitchell
---
tools/xl/xl_cmdtable.c | 2 ++
tools/xl/xl_list.c | 16 +---
2 files changed, 15 insertions(+), 3 deletions(-)
diff
With a generalized formatting function now available, start to replace
the old specialized formatting bits.
Signed-off-by: Elliott Mitchell
---
tools/xl/xl_list.c | 40 ++--
1 file changed, 10 insertions(+), 30 deletions(-)
diff --git a/tools/xl/xl_list.c
There is potential for the info and info_free variable's purposes to
diverge. If info was overwritten with a distinct value, yet info_free
still needed deallocation a bug would occur on this line. Preemptively
address this issue (making use of divergent info/info_free values is
under
Simply a minor housekeeping task. Unfortunately no single order really
dominates. Some spots use the option name, some the option letter.
Signed-off-by: Elliott Mitchell
---
tools/xl/xl_cmdtable.c | 4 ++--
tools/xl/xl_list.c | 22 +++---
2 files changed, 13
The domain listing commands have more in common with each other than
hypervisor information commands.
Signed-off-by: Elliott Mitchell
---
I'm concerned about my header-stripping job. Notably the headers
, , and were removed from *both*
files. This could be cause for celebration, or this
create_domain()'s use of printf_info_sexp() could be merged down to a
single dump_by_config(), do so. This results in an extra JSON dictionary
in output, but I doubt that is an issue for dry-run or debugging output.
Signed-off-by: Elliott Mitchell
---
tools/xl/xl_vmcontrol.c | 14
printf_info()/list_domains_details() had been serving fairly similar
purposes. Increase their consistency (add file-handle and output_format
arguments to list_domains_details(), reorder arguments) and then rename
to better reflect their functionality.
Both were simply outputting full domain
With libxl having gotten a lot more constant, now printf_info_sexp() and
printf_info_one_json() can add consts. May not be particularly
important, but it is best to mark things constant when they are known to
be so.
Signed-off-by: Elliott Mitchell
---
tools/xl/xl.h | 2 +-
This should result in fewer branch instructions and a small performance
gain.
Signed-off-by: Elliott Mitchell
---
tools/libs/light/libxl_internal.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/libs/light/libxl_internal.c
b/tools/libs/light/libxl_internal.c
Anything *_is_empty(), *_is_default(), or *_gen_json() is going to be
examining the pointed to thing, not modifying it. This potentially
results in higher-performance output. This also allows spreading
constants further, allowing more checking and security.
Signed-off-by: Elliott Mitchell
---
The first 8 patches should be fairly uncontroversial, and could be
preemptively applied before the rest are ready. They fell out as part
of trying to implement my first step; splitting a few xl subcommands off
of xl_info.c.
Found several functions in libxl which could have arguments marked
On Mon, Dec 21, 2020 at 06:28:35PM +, Julien Grall wrote:
> On 21/12/2020 17:30, Elliott Mitchell wrote:
> > I doubt this is the only bug exposed by
> > 5a37207df52066efefe419c677b089a654d37afc.
>
> Are you saying that with my patch dropped, Xen will boot but with it
> will not?
I thought
On Mon, 2021-01-04 at 17:09 -0500, boris.ostrov...@oracle.com wrote:
>
> I actually think this should go further in that only IPI-related ops
> should be conditioned on vector callback presence. The rest are
> generic VCPU routines that are not necessarily interrupt/event-
> related. And if they
On 1/4/21 3:51 PM, David Woodhouse wrote:
> On Mon, 2021-01-04 at 14:06 -0500, boris.ostrov...@oracle.com wrote:
>>
>> OK, but we still need to do something about virt_spin_lock_key.
> Right, I suppose we should just call xen_init_spinlocks() and then my
> defensive check stops being defensive
On Mon, 2021-01-04 at 14:06 -0500, boris.ostrov...@oracle.com wrote:
> On 1/4/21 12:32 PM, David Woodhouse wrote:
> > On Mon, 2021-01-04 at 12:06 -0500, boris.ostrov...@oracle.com wrote
> > :
> > > > @@ -115,7 +115,7 @@ PV_CALLEE_SAVE_REGS_THUNK(xen_vcpu_stolen);
> > > >void __init
On 1/4/21 12:32 PM, David Woodhouse wrote:
> On Mon, 2021-01-04 at 12:06 -0500, boris.ostrov...@oracle.com wrote:
>>> @@ -115,7 +115,7 @@ PV_CALLEE_SAVE_REGS_THUNK(xen_vcpu_stolen);
>>> void __init xen_init_spinlocks(void)
>>> {
>>>/* Don't need to use pvqspinlock code if there is
On Mon, Jan 04, 2021 at 12:30:44PM +0100, Manuel Bouyer wrote:
> On Tue, Dec 29, 2020 at 01:46:30PM +0100, Roger Pau Monné wrote:
> > Also a little bit below these prototypes are the dummy implementations
> > of osdep_xenforeignmemory_restrict,
> > osdep_xenforeignmemory_map_resource and
> >
On 02/01/2021 19:20, Charles Gonçalves wrote:
> Sure.
>
> The goal is to emulate a scenario where a compromised guest attacks
> another
> tenant in the same physical host reading/changing the memory content.
> E.g., extract the RSA key.
>
> I'll be in the domU kernel space. I'm assuming that
On Mon, Jan 04, 2021 at 11:31:56AM +0100, Manuel Bouyer wrote:
> On Tue, Dec 29, 2020 at 03:02:15PM +0100, Roger Pau Monné wrote:
> > On Mon, Dec 14, 2020 at 05:36:12PM +0100, Manuel Bouyer wrote:
> > > ---
> > > tools/libs/light/libxl_create.c | 8
> > > 1 file changed, 4 insertions(+),
On Mon, 4 Jan 2021, Andrew Cooper wrote:
> On 04/01/2021 17:30, Stefano Stabellini wrote:
> > On Mon, 4 Jan 2021, Zheng, Fam wrote:
> >> On Mon, 2021-01-04 at 10:38 +0100, Roger Pau Monné wrote:
> >>> On Wed, Dec 23, 2020 at 12:10:43PM -0800, Stefano Stabellini wrote:
> On Wed, 23 Dec 2020,
On Mon, Jan 04, 2021 at 05:35:23PM +0100, Jan Beulich wrote:
> Thanks.
>
> > Manuel, can we get confirmation that this fixes your issue?
>
> I'll give it some time before committing for him to confirm,
> but I guess I'd like to time out by the end of the week.
Yes, it works for me
--
Manuel
flight 158134 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158134/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On Thu, 24 Dec 2020, Julien Grall wrote:
> From: Julien Grall
>
> clang 11 will throw the following error while build Xen:
>
> scif-uart.c:333:33: error: cast to smaller integer type 'enum port_types'
> from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]
> uart->params =
Several lock-order violations have been encountered while attempting to fork
VMs with nestedhvm=1 set. This patch resolves the issues.
The order violations stems from a call to p2m_flush_nestedp2m being performed
whenever the hostp2m changes. This functions always takes the p2m lock for the
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/mm/mem_sharing.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index c428fd16ce..4a02c7d6f2 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@
On 04/01/2021 17:30, Stefano Stabellini wrote:
> On Mon, 4 Jan 2021, Zheng, Fam wrote:
>> On Mon, 2021-01-04 at 10:38 +0100, Roger Pau Monné wrote:
>>> On Wed, Dec 23, 2020 at 12:10:43PM -0800, Stefano Stabellini wrote:
On Wed, 23 Dec 2020, Andrew Cooper wrote:
> On 23/12/2020 19:45,
On 04/01/2021 17:30, Stefano Stabellini wrote:
On Mon, 4 Jan 2021, Zheng, Fam wrote:
On Mon, 2021-01-04 at 10:38 +0100, Roger Pau Monné wrote:
On Wed, Dec 23, 2020 at 12:10:43PM -0800, Stefano Stabellini wrote:
On Wed, 23 Dec 2020, Andrew Cooper wrote:
On 23/12/2020 19:45, Stefano
On Mon, Jan 04, 2021 at 03:12:02PM +0100, Roger Pau Monne wrote:
> Current check for DM_OP availability in osdep_xendevicemodel_open will
> always fail, because using DOMID_INVALID as the domain parameter will
> make the hypervisor return -ESRCH, which will disable the usage of
> the DOM_OP
On Mon, 2021-01-04 at 12:06 -0500, boris.ostrov...@oracle.com wrote:
> > @@ -115,7 +115,7 @@ PV_CALLEE_SAVE_REGS_THUNK(xen_vcpu_stolen);
> > void __init xen_init_spinlocks(void)
> > {
> >/* Don't need to use pvqspinlock code if there is only 1 vCPU. */
> > - if
On Mon, 4 Jan 2021, Zheng, Fam wrote:
> On Mon, 2021-01-04 at 10:38 +0100, Roger Pau Monné wrote:
> > On Wed, Dec 23, 2020 at 12:10:43PM -0800, Stefano Stabellini wrote:
> > > On Wed, 23 Dec 2020, Andrew Cooper wrote:
> > > > On 23/12/2020 19:45, Stefano Stabellini wrote:
> > > > > On Wed, 23 Dec
On Mon, 2021-01-04 at 11:50 -0500, boris.ostrov...@oracle.com wrote:
> > diff --git a/arch/x86/xen/enlighten_hvm.c
> > b/arch/x86/xen/enlighten_hvm.c
> > index a1c07e0c888e..7a6ef517e81a 100644
> > --- a/arch/x86/xen/enlighten_hvm.c
> > +++ b/arch/x86/xen/enlighten_hvm.c
> > @@ -164,10 +164,10 @@
On Mon, Jan 04, 2021 at 11:29:51AM +0100, Manuel Bouyer wrote:
> On Tue, Dec 29, 2020 at 12:16:01PM +0100, Roger Pau Monné wrote:
> > Might need some kind of log message, and will also required your
> > Signed-off-by (or from the original author of the patch).
> >
> > On Mon, Dec 14, 2020 at
On Mon, Jan 4, 2021 at 7:31 AM Andrew Cooper wrote:
>
> On 03/01/2021 18:47, Tamas K Lengyel wrote:
> > Running Xen compiled with UBSAN produces a warning for mismatched size. It's
> > benign but this patch silences the warning.
> >
> > Signed-off-by: Tamas K Lengyel
> > ---
> >
On Mon, Jan 04, 2021 at 06:09:07PM +0100, Roger Pau Monné wrote:
> We usually take a different approach for Linux and FreeBSD in
> order to support all kernels: test if the new ioctl is available, or
> else fallback to the old implementation. But this requires having the
> new header even on old
On Mon, Jan 04, 2021 at 11:26:45AM +0100, Manuel Bouyer wrote:
> On Tue, Dec 29, 2020 at 12:52:43PM +0100, Roger Pau Monné wrote:
> > On Mon, Dec 14, 2020 at 05:36:09PM +0100, Manuel Bouyer wrote:
> > > ---
> > > tools/libs/evtchn/netbsd.c | 8
> > > 1 file changed, 4 insertions(+), 4
On Mon, Jan 4, 2021 at 11:48 AM Andrew Cooper wrote:
>
> On 04/01/2021 16:32, Tamas K Lengyel wrote:
> > On Mon, Jan 4, 2021 at 11:21 AM Jan Beulich wrote:
> >> On 04.01.2021 14:28, Tamas K Lengyel wrote:
> >>> On Mon, Jan 4, 2021 at 6:57 AM Andrew Cooper
> >>> wrote:
> On 03/01/2021
On 12/24/20 6:53 AM, David Woodhouse wrote:
> From: David Woodhouse
>
> When xen_have_vector_callback is false, we still register the PV spinlock
> kicker IPI on the secondary CPUs. Stop doing that.
>
> Signed-off-by: David Woodhouse
> ---
> arch/x86/xen/spinlock.c | 6 +++---
> 1 file
On Mon, Jan 04, 2021 at 11:25:52AM +0100, Manuel Bouyer wrote:
> On Tue, Dec 29, 2020 at 12:46:38PM +0100, Roger Pau Monné wrote:
> > What would happen when a new device (or ioctl to and existing one) is
> > added?
> >
> > You would then run into issues of newer versions of Xen not building on
>
Hello all.
[Sorry for the possible format issues]
On Tue, Dec 22, 2020 at 12:41 PM Andrew Cooper
wrote:
> On 21/12/2020 08:10, Jan Beulich wrote:
> > On 17.12.2020 20:18, Andrew Cooper wrote:
> >> On 15/12/2020 16:26, Jan Beulich wrote:
> >>> This is together with its only caller,
On 12/24/20 6:53 AM, David Woodhouse wrote:
> From: David Woodhouse
>
> In the case where xen_have_vector_callback is false, we still register
> the IPI vectors in xen_smp_intr_init() for the secondary CPUs even
> though they aren't going to be used. Stop doing that.
>
> Signed-off-by: David
On 04/01/2021 16:32, Tamas K Lengyel wrote:
> On Mon, Jan 4, 2021 at 11:21 AM Jan Beulich wrote:
>> On 04.01.2021 14:28, Tamas K Lengyel wrote:
>>> On Mon, Jan 4, 2021 at 6:57 AM Andrew Cooper
>>> wrote:
On 03/01/2021 18:41, Tamas K Lengyel wrote:
> Required to introspect events
On 28.12.2020 18:58, Roger Pau Monné wrote:
> On Mon, Dec 07, 2020 at 11:38:42AM +0100, Jan Beulich wrote:
>> First of all introduce a local variable for the to be allocated struct.
>> The compiler can't CSE all the occurrences (I'm observing 80 bytes of
>> code saved with gcc 10). Additionally,
On 12/24/20 6:53 AM, David Woodhouse wrote:
> From: David Woodhouse
>
> It's useful to be able to test non-vector event channel delivery, to make
> sure Linux will work properly on older Xen which doesn't have it.
>
> It's also useful for those working on Xen and Xen-compatible hypervisors,
>
On 12/24/20 6:53 AM, David Woodhouse wrote:
> From: David Woodhouse
>
> With INTX or GSI delivery, Xen uses the event channel structures of CPU0.
>
> If the interrupt gets handled by Linux on a different CPU, then no events
> are seen as pending. Rather than introducing locking to allow other
On 12/24/20 6:53 AM, David Woodhouse wrote:
> From: David Woodhouse
>
> For a while, event channel notification via the PCI platform device
> has been broken, because we attempt to communicate with xenstore before
> we even have notifications working, with the xs_reset_watches() call
> in
On 28.12.2020 19:24, Roger Pau Monné wrote:
> On Mon, Dec 07, 2020 at 11:36:38AM +0100, Jan Beulich wrote:
>> None of the four reasons causing vpci_msix_arch_mask_entry() to get
>> called (there's just a single call site) are impossible or illegal prior
>> to an entry actually having got set up:
On Mon, Jan 4, 2021 at 11:21 AM Jan Beulich wrote:
>
> On 04.01.2021 14:28, Tamas K Lengyel wrote:
> > On Mon, Jan 4, 2021 at 6:57 AM Andrew Cooper
> > wrote:
> >>
> >> On 03/01/2021 18:41, Tamas K Lengyel wrote:
> >>> Required to introspect events originating from nested VMs.
> >>>
> >>>
flight 158119 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158119/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 14 guest-start fail REGR. vs. 152332
On 04.01.2021 14:28, Tamas K Lengyel wrote:
> On Mon, Jan 4, 2021 at 6:57 AM Andrew Cooper
> wrote:
>>
>> On 03/01/2021 18:41, Tamas K Lengyel wrote:
>>> Required to introspect events originating from nested VMs.
>>>
>>> Signed-off-by: Tamas K Lengyel
>>> ---
>>> xen/arch/x86/hvm/monitor.c
On 04.01.2021 16:53, Roger Pau Monné wrote:
> On Mon, Jan 04, 2021 at 02:56:12PM +0100, Jan Beulich wrote:
>> On 28.12.2020 16:30, Roger Pau Monné wrote:
>>> I would like to have Andrew's opinion on this one (as you and him tend
>>> to modify more asm code than myself). There are quite a lot of
On 04.01.2021 16:45, Roger Pau Monné wrote:
> On Mon, Jan 04, 2021 at 04:16:18PM +0100, Jan Beulich wrote:
>> On 04.01.2021 15:56, Roger Pau Monné wrote:
>>> On Mon, Jan 04, 2021 at 02:43:52PM +0100, Jan Beulich wrote:
On 28.12.2020 11:54, Roger Pau Monné wrote:
> On Mon, Nov 09, 2020 at
On 04.01.2021 16:41, Andrew Cooper wrote:
> On 04/01/2021 15:22, Jan Beulich wrote:
>> On 04.01.2021 16:04, Andrew Cooper wrote:
>>> On 23/12/2020 15:13, Jan Beulich wrote:
This array can be large when many grant frames are permitted; avoid
allocating it when it's not going to be used
On Mon, Jan 04, 2021 at 02:56:12PM +0100, Jan Beulich wrote:
> On 28.12.2020 16:30, Roger Pau Monné wrote:
> > I would like to have Andrew's opinion on this one (as you and him tend
> > to modify more asm code than myself). There are quite a lot of
> > addition to the assembly code, and IMO it
On Mon, Jan 04, 2021 at 09:16:33AM -0600, Josh Poimboeuf wrote:
> > There's another fun scenario:
> >
> > 0x00 CALL *pv_ops.save_flPUSHF
> > 0x01 NOP2
> > ..
> > 0x03 NOP5
> > ..
> > 0x07
On Mon, Jan 04, 2021 at 04:16:18PM +0100, Jan Beulich wrote:
> On 04.01.2021 15:56, Roger Pau Monné wrote:
> > On Mon, Jan 04, 2021 at 02:43:52PM +0100, Jan Beulich wrote:
> >> On 28.12.2020 11:54, Roger Pau Monné wrote:
> >>> On Mon, Nov 09, 2020 at 11:54:09AM +0100, Jan Beulich wrote:
> Now
On 04/01/2021 15:22, Jan Beulich wrote:
> On 04.01.2021 16:04, Andrew Cooper wrote:
>> On 23/12/2020 15:13, Jan Beulich wrote:
>>> This array can be large when many grant frames are permitted; avoid
>>> allocating it when it's not going to be used anyway, by doing this only
>>> in
On 04.01.2021 16:04, Andrew Cooper wrote:
> On 23/12/2020 15:13, Jan Beulich wrote:
>> This array can be large when many grant frames are permitted; avoid
>> allocating it when it's not going to be used anyway, by doing this only
>> in gnttab_populate_status_frames().
>>
>> Signed-off-by: Jan
On Mon, Jan 04, 2021 at 03:09:52PM +0100, Peter Zijlstra wrote:
> On Tue, Dec 22, 2020 at 11:18:10PM -0600, Josh Poimboeuf wrote:
>
> > For example, this scenario is allowed:
> >
> > Alt1Alt2Alt3
> >
> >0x00 CALL *pv_ops.save_flCALL
On 04.01.2021 15:56, Roger Pau Monné wrote:
> On Mon, Jan 04, 2021 at 02:43:52PM +0100, Jan Beulich wrote:
>> On 28.12.2020 11:54, Roger Pau Monné wrote:
>>> On Mon, Nov 09, 2020 at 11:54:09AM +0100, Jan Beulich wrote:
Now that the IOMMU for guests can't be enabled "on demand" anymore,
On Mon, Jan 04, 2021 at 03:03:07PM +0100, Jan Beulich wrote:
> On 29.12.2020 11:54, Roger Pau Monné wrote:
> > My preference however would be for this to use vmap. Could the mapping
> > be established in acpi_fadt_parse_sleep_info instead of having to map
> > and unmap every time in
On 23/12/2020 15:13, Jan Beulich wrote:
> This array can be large when many grant frames are permitted; avoid
> allocating it when it's not going to be used anyway, by doing this only
> in gnttab_populate_status_frames().
>
> Signed-off-by: Jan Beulich
> ---
> v2: Defer allocation to when a
On 04/01/2021 14:56, Roger Pau Monné wrote:
> On Mon, Jan 04, 2021 at 02:43:52PM +0100, Jan Beulich wrote:
>> On 28.12.2020 11:54, Roger Pau Monné wrote:
>>> On Mon, Nov 09, 2020 at 11:54:09AM +0100, Jan Beulich wrote:
Now that the IOMMU for guests can't be enabled "on demand" anymore,
On Mon, Jan 04, 2021 at 02:43:52PM +0100, Jan Beulich wrote:
> On 28.12.2020 11:54, Roger Pau Monné wrote:
> > On Mon, Nov 09, 2020 at 11:54:09AM +0100, Jan Beulich wrote:
> >> Now that the IOMMU for guests can't be enabled "on demand" anymore,
> >> there's also no reason to expose the related
On 04.01.2021 15:16, Julien Grall wrote:
> Hi Jan,
>
> On 04/01/2021 13:37, Jan Beulich wrote:
>> On 24.12.2020 10:57, Julien Grall wrote:
>>> Hi Jan,
>>>
>>> On 23/12/2020 15:13, Jan Beulich wrote:
This array can be large when many grant frames are permitted; avoid
allocating it when
Hi Paul,
On 04/01/2021 09:28, Paul Durrant wrote:
-Original Message-
From: Julien Grall
Sent: 22 December 2020 15:44
To: xen-devel@lists.xenproject.org
Cc: hongy...@amazon.co.uk; Julien Grall ; Jan Beulich
; Paul
Durrant
Subject: [PATCH for-4.15 1/4] xen/iommu: Check if the IOMMU was
flight 158116 qemu-mainline real [real]
flight 158129 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158116/
http://logs.test-lab.xenproject.org/osstest/logs/158129/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not
On 03.01.2021 07:40, Dylanger Daly wrote:
> Trying to debug Credit2
> https://wiki.xenproject.org/wiki/Credit2_Scheduler#Dumping_Status_and_Params
>
> It should be possible to get some debug output on what Credit2 is doing via
> pressing 'r' on the Serial Debug port
>
> Does anyone know if
On 24.12.2020 16:24, Julien Grall wrote:
> From: Julien Grall
>
> Replace all the use of 1 << 31 with 1UL << 31 to prevent undefined
> behavior in the SMMU driver.
>
> Signed-off-by: Julien Grall
With, as already pointed out by Hans, 1UL replaced by 1U in
title and description
Reviewed-by:
flight 158123 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158123/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
Hi Jan,
On 04/01/2021 13:37, Jan Beulich wrote:
On 24.12.2020 10:57, Julien Grall wrote:
Hi Jan,
On 23/12/2020 15:13, Jan Beulich wrote:
This array can be large when many grant frames are permitted; avoid
allocating it when it's not going to be used anyway, by doing this only
in
Current check for DM_OP availability in osdep_xendevicemodel_open will
always fail, because using DOMID_INVALID as the domain parameter will
make the hypervisor return -ESRCH, which will disable the usage of
the DOM_OP interface.
Fix this by checking the errno code of the test ioctl against
the
On Tue, Dec 22, 2020 at 11:18:10PM -0600, Josh Poimboeuf wrote:
> For example, this scenario is allowed:
>
> Alt1Alt2Alt3
>
>0x00 CALL *pv_ops.save_flCALL xen_save_flPUSHF
>0x01
On 29.12.2020 11:51, Roger Pau Monné wrote:
> On Mon, Nov 23, 2020 at 01:40:12PM +0100, Jan Beulich wrote:
>> Use of __acpi_map_table() here was at least close to an abuse already
>> before, but it will now consistently return NULL here. Drop the layering
>> violation and use set_fixmap()
On 29.12.2020 11:54, Roger Pau Monné wrote:
> On Wed, Dec 23, 2020 at 04:09:07PM +0100, Jan Beulich wrote:
>> On 30.11.2020 14:02, Jan Beulich wrote:
>>> On 24.11.2020 12:04, Jan Beulich wrote:
On 23.11.2020 17:14, Andrew Cooper wrote:
> On 23/11/2020 16:07, Roger Pau Monné wrote:
>>
On 28.12.2020 16:30, Roger Pau Monné wrote:
> On Wed, Nov 25, 2020 at 09:51:33AM +0100, Jan Beulich wrote:
>> --- a/xen/arch/x86/x86_64/compat/entry.S
>> +++ b/xen/arch/x86/x86_64/compat/entry.S
>> @@ -29,8 +29,6 @@ ENTRY(entry_int82)
>> mov %rsp, %rdi
>> call do_entry_int82
On 28.12.2020 13:54, Roger Pau Monné wrote:
> On Wed, Nov 25, 2020 at 09:49:21AM +0100, Jan Beulich wrote:
>> This file has a long dependencies list and asm-offsets.h, generated from
>> it, has a long list of dependents. IOW if any of the former changes, all
>> of the latter will be rebuilt, even
On 28.12.2020 13:00, Roger Pau Monné wrote:
> On Wed, Nov 25, 2020 at 09:45:56AM +0100, Jan Beulich wrote:
>> This file has a long dependencies list (through asm-offsets.s) and a
>> long list of dependents. IOW if any of the former changes, all of the
>> latter will be rebuilt, even if there's no
On 28.12.2020 11:54, Roger Pau Monné wrote:
> On Mon, Nov 09, 2020 at 11:54:09AM +0100, Jan Beulich wrote:
>> Now that the IOMMU for guests can't be enabled "on demand" anymore,
>> there's also no reason to expose the related CPUID bit "just in case".
>>
>> Signed-off-by: Jan Beulich
>
> I'm not
On 24.12.2020 10:57, Julien Grall wrote:
> Hi Jan,
>
> On 23/12/2020 15:13, Jan Beulich wrote:
>> This array can be large when many grant frames are permitted; avoid
>> allocating it when it's not going to be used anyway, by doing this only
>> in gnttab_populate_status_frames().
>>
>>
On Mon, Jan 04, 2021 at 11:56:14AM +0100, Manuel Bouyer wrote:
> On Tue, Dec 29, 2020 at 03:38:53PM +0100, Roger Pau Monné wrote:
> > On Mon, Dec 14, 2020 at 05:36:18PM +0100, Manuel Bouyer wrote:
> > > ---
> > > tools/xenpaging/xenpaging.c | 5 +++--
> > > 1 file changed, 3 insertions(+), 2
On Mon, Jan 4, 2021 at 6:57 AM Andrew Cooper wrote:
>
> On 03/01/2021 18:41, Tamas K Lengyel wrote:
> > Required to introspect events originating from nested VMs.
> >
> > Signed-off-by: Tamas K Lengyel
> > ---
> > xen/arch/x86/hvm/monitor.c| 32 ++--
> >
On Mon, Jan 4, 2021 at 8:04 AM Andrew Cooper wrote:
>
> On 03/01/2021 19:01, Tamas K Lengyel wrote:
> > Add option to the monitor interface to disable walking of the guest
> > pagetable
> > on certain events. This is a performance optimization for tools that never
> > require that information or
1 - 100 of 129 matches
Mail list logo
