On Thu, 2019-06-13 at 17:00 +0300, Razvan Cojocaru wrote:
> Remove myself as vm_event maintaner, add Alexandru and Petre as
> Bitdefender vm_event maintainers.
>
> Signed-off-by: Razvan Cojocaru
>
Acked-by: Petre Pircalabu
___
Xen-devel mailing list
On 13.06.2019 17:00, Razvan Cojocaru wrote:
> Remove myself as vm_event maintaner, add Alexandru and Petre as
> Bitdefender vm_event maintainers.
>
> Signed-off-by: Razvan Cojocaru
Acked-by: Alexandru Isaila
___
Xen-devel mailing list
Xen-devel@list
flight 137860 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137860/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a860eb9668c1a2ad875874ca3822a49a5321879f
baseline version:
ovmf b0663641c977f97bef785
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 17 June 2019 18:37
> To: Paul Durrant
> Cc: qemu-de...@nongnu.org; xen-devel@lists.xenproject.org; Stefano Stabellini
>
> Subject: Re: [PATCH 4/4] xen: Avoid VLA
>
> On Mon, Jun 17, 2019 at 05:39:09PM
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 17 June 2019 18:19
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Stefano Stabellini
> ; qemu-de...@nongnu.org
> Subject: Re: [Xen-devel] [PATCH 3/4] xen: Import Xen public headers used by
>
Some of the function generating nodes (e.g make_timer_node)
take in a dt_device_node parameter, but never used it.
It is actually misused when creating DT for DomU.
So it is the best to remove the parameter.
Suggested-by: Julien Grall
Signed-off-by: Viktor Mitin
---
xen/arch/arm/domain_build.c
>>> On 17.06.19 at 23:28, wrote:
> On Thu, 2 May 2019, Jan Beulich wrote:
>> >>> On 30.04.19 at 23:02, wrote:
>> > --- a/xen/include/public/domctl.h
>> > +++ b/xen/include/public/domctl.h
>> > @@ -571,12 +571,24 @@ struct xen_domctl_bind_pt_irq {
>> > */
>> > #define DPCI_ADD_MAPPING 1
>>> On 17.06.19 at 19:39, wrote:
> On 29/05/2019 11:17, Jan Beulich wrote:
>> In particular with an enabled IOMMU (but not really limited to this
>> case), trying to invoke fixup_irqs() after having already done
>> disable_IO_APIC() -> clear_IO_APIC() is a rather bad idea:
>>
>> RIP:e008:[] a
>>> On 17.06.19 at 22:23, wrote:
> On 13/06/2019 14:22, Jan Beulich wrote:
>> This also takes care of several of the shift values wrongly having been
>> specified as hex rather than dec.
>>
>> Take the opportunity and add further fields.
>>
>> Signed-off-by: Jan Beulich
>>
>> --- a/xen/drivers/pa
>>> On 17.06.19 at 21:07, wrote:
> On Thu, Jun 13, 2019 at 07:22:31AM -0600, Jan Beulich wrote:
>> --- a/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
>> +++ b/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
>> @@ -346,26 +346,57 @@ struct amd_iommu_dte {
>> #define IOMMU_EXCLUSION_LIMIT_HIGH_MASK
On 13/06/2019 14:22, Jan Beulich wrote:
> Also introduce a field in struct amd_iommu caching the most recently
> written control register. All writes should now happen exclusively from
> that cached value, such that it is guaranteed to be up to date.
>
> Take the opportunity and add further fields.
>>> On 18.06.19 at 07:56, wrote:
> flight 137854 xen-4.10-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/137854/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-xl-qemut-stubdom-debianhvm
>>> On 17.06.19 at 20:50, wrote:
> Also change srat_region_mask to uint64_t as it is used to store the
> return value of pdx_init_mask. uint64_t is always greater or equal to
> u64.
>
> Signed-off-by: Stefano Stabellini
Non-Arm bits
Acked-by: Jan Beulich
but could you make the title sound less
>>> On 17.06.19 at 20:27, wrote:
> On 17/06/2019 18:55, Andrew Cooper wrote:
>> On 17/06/2019 18:39, Andrew Cooper wrote:
>>> On 29/05/2019 11:17, Jan Beulich wrote:
In particular with an enabled IOMMU (but not really limited to this
case), trying to invoke fixup_irqs() after having alre
>>> On 17.06.19 at 21:49, wrote:
> This code was never updated when the 32bit build of Xen was dropped.
>
> * Expand the now-redundant ptr_reg macro.
> * The number of iterations in the loop can be halfed by using 64bit writes,
>without consuming any extra execution resource in the pipeline
On 18/06/2019 11:33, Jan Beulich wrote:
On 17.06.19 at 21:49, wrote:
>> This code was never updated when the 32bit build of Xen was dropped.
>>
>> * Expand the now-redundant ptr_reg macro.
>> * The number of iterations in the loop can be halfed by using 64bit writes,
>>without consuming
On 13/06/2019 14:23, Jan Beulich wrote:
> At the same time restrict its scope to just the single source file
> actually using it, and abstract accesses by introducing a union of
> pointers. (A union of the actual table entries is not used to make it
> impossible to [wrongly, once the 128-bit form g
>>> On 18.06.19 at 11:54, wrote:
> On 13/06/2019 14:22, Jan Beulich wrote:
>> Also introduce a field in struct amd_iommu caching the most recently
>> written control register. All writes should now happen exclusively from
>> that cached value, such that it is guaranteed to be up to date.
>>
>> Tak
On Tue, Jun 18, 2019 at 08:55:53AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> >
> > On Mon, Jun 17, 2019 at 05:45:44PM +0100, Anthony PERARD wrote:
> > > On Mon, Jun 17, 2019 at 05:15:51PM +0100, Paul Durrant wrote:
> > >
Hi Stefano,
On 17/06/2019 22:24, Stefano Stabellini wrote:
On Wed, 1 May 2019, Julien Grall wrote:
Hi,
On 30/04/2019 22:02, Stefano Stabellini wrote:
Now that map_mmio_regions takes a p2mt parameter, there is no need to
keep "mmio" in the name. The p2mt parameter does a better job at
expressi
Hi,
On 17/06/2019 23:32, Stefano Stabellini wrote:
On Wed, 1 May 2019, Julien Grall wrote:
Hi,
On 30/04/2019 22:02, Stefano Stabellini wrote:
Add a new memory policy option for the iomem parameter.
Possible values are:
- arm_devmem, device nGRE, the default on ARM
- arm_memory, WB cachable me
From: Joe Perches
There are mode change and rename only patches that are unrecognized
by the get_maintainer.pl script.
Recognize them.
[ Linux commit 0455c74788fd5aad4399f00e3fbbb7e87450ca58 ]
Reported-by: Heinrich Schuchardt
CC: Julien Grall
Signed-off-by: Joe Perches
Signed-off-by: Volody
On 17/06/2019 23:43, Stefano Stabellini wrote:
On Tue, 7 May 2019, Julien Grall wrote:
+#define MEMORY_POLICY_ARM_DEV_nGRE 0
+/* Arm only. Outer Shareable, Outer/Inner Write-Back Cacheable memory */
+#define MEMORY_POLICY_ARM_MEM_WB 1
I am wondering whether we should put Arm (r
On 30/04/2019 22:02, Stefano Stabellini wrote:
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 89fe80f..a6c5e30 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -415,6 +415,21 @@ static void init_console_info(libxl__gc *gc,
Only 'ch
Hi Julien,
Julien Grall writes:
> Hi Volodymyr,
>
> On 6/11/19 7:46 PM, Volodymyr Babchuk wrote:
>> This enumeration controls TEE type for a domain. Currently there is
>> two possible options: either 'none' or 'optee'.
>>
>> 'none' is the default value and it basically disables TEE support at
>>
flight 137858 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137858/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install
fail REGR. vs. 13
Following "xen: Fix build with public headers", import other Xen
public headers that are describing interfaces.
Import fbif.h, kbdif.h, netif.h, console.h, xenbus.h, protocols.h.
While editing xenfb.c, remove the include of event_channel.h as it
isn't needed.
The headers are cleaned up a bit whi
Following 37677d7db3 "Clean up a few header guard symbols", QEMU start
to fail to build:
In file included from ~/xen/tools/../tools/include/xen/io/blkif.h:31:0,
from ~/xen/tools/qemu-xen-dir/hw/block/xen_blkif.h:5,
from ~/xen/tools/qemu-xen-dir/hw/block/xen-block.
Hi,
Fix the build in osstest and some cleanup
For reference:
Recent flight failure:
https://lists.xenproject.org/archives/html/xen-devel/2019-06/msg01022.html
Bisect result:
https://lists.xenproject.org/archives/html/xen-devel/2019-06/msg01029.html
Thanks.
Anthony PERARD (4):
xen: Fix build
Avoid using a variable length array.
We allocate the `dirty_bitmap' buffer only once when we start tracking
for dirty bits.
Signed-off-by: Anthony PERARD
---
Notes:
v2:
- Allocate the bitmap buffer only once when we start tracking dirty bits.
(instead of at every function call)
xen-mapcache.c doesn't needs params.h.
xen-hvm.c uses defines available in params.h but so is xen_common.h
which is included before. HVM_PARAM_* flags are only needed to make
xc_hvm_param_{get,set} calls so including only xenctrl.h, which is
where the definition the function is, should be enough.
On 13/06/2019 14:23, Jan Beulich wrote:
> At the same time restrict its scope to just the single source file
> actually using it, and abstract accesses by introducing a union of
> pointers. (A union of the actual table entries is not used to make it
> impossible to [wrongly, once the 128-bit form g
On 6/18/19 1:23 PM, Anthony PERARD wrote:
> Avoid using a variable length array.
>
> We allocate the `dirty_bitmap' buffer only once when we start tracking
> for dirty bits.
>
Suggested-by: Paul Durrant
Reviewed-by: Philippe Mathieu-Daudé
> Signed-off-by: Anthony PERARD
> ---
>
> Notes:
>
>>> On 18.06.19 at 13:31, wrote:
> On 13/06/2019 14:23, Jan Beulich wrote:
>> At the same time restrict its scope to just the single source file
>> actually using it, and abstract accesses by introducing a union of
>> pointers. (A union of the actual table entries is not used to make it
>> impossi
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 18 June 2019 12:24
> To: qemu-de...@nongnu.org
> Cc: Anthony Perard ; Paul Durrant
> ; Stefano
> Stabellini ; xen-devel@lists.xenproject.org
> Subject: [PATCH v2 3/4] xen: Drop includes of xen/hvm/params
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 18 June 2019 12:24
> To: qemu-de...@nongnu.org
> Cc: Anthony Perard ; Paul Durrant
> ; Stefano
> Stabellini ; xen-devel@lists.xenproject.org
> Subject: [PATCH v2 4/4] xen: Avoid VLA
>
> Avoid using a va
>>> On 18.06.19 at 12:37, wrote:
> On 13/06/2019 14:23, Jan Beulich wrote:
>> At the same time restrict its scope to just the single source file
>> actually using it, and abstract accesses by introducing a union of
>> pointers. (A union of the actual table entries is not used to make it
>> impossi
At the moment the IOMMU flags are not used in p2m-pt and could be used
on other application.
This patch aims to clean the use of IOMMU flags on the AMD p2m side.
Signed-off-by: Alexandru Isaila
Suggested-by: George Dunlap
---
xen/arch/x86/mm/p2m-pt.c | 85 ++
On 13/06/2019 14:23, Jan Beulich wrote:
> This is in preparation of actually enabling x2APIC mode, which requires
> this wider IRTE format to be used.
>
> A specific remark regarding the first hunk changing
> amd_iommu_ioapic_update_ire(): This bypass was introduced for XSA-36,
> i.e. by 94d4a1119d
Patchew URL:
https://patchew.org/QEMU/20190618112341.513-1-anthony.per...@citrix.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Xen-devel] [PATCH v2 0/4] Fix build of Xen support + cleanup
Type: series
Message-id: 20190618112341
On Tue, Jun 18, 2019 at 12:23:38PM +0100, Anthony PERARD wrote:
> Following 37677d7db3 "Clean up a few header guard symbols", QEMU start
> to fail to build:
>
> In file included from ~/xen/tools/../tools/include/xen/io/blkif.h:31:0,
> from ~/xen/tools/qemu-xen-dir/hw/block/xen_blk
On 18/06/2019 12:53, Jan Beulich wrote:
On 18.06.19 at 12:37, wrote:
>> On 13/06/2019 14:23, Jan Beulich wrote:
>>> At the same time restrict its scope to just the single source file
>>> actually using it, and abstract accesses by introducing a union of
>>> pointers. (A union of the actual ta
On 13/06/2019 14:24, Jan Beulich wrote:
> Mapping the MMIO space and obtaining feature information needs to happen
> slightly earlier, such that for x2APIC support we can set XTEn prior to
> calling amd_iommu_update_ivrs_mapping_acpi() and
> amd_iommu_setup_ioapic_remapping().
>
> Signed-off-by: Ja
On 13/06/2019 14:25, Jan Beulich wrote:
> Early enabling (to enter x2APIC mode) requires deferring of the IRQ
> setup.
I can accept that this might be how the IOMMU infrastructure currently
functions (and therefore won't block this series), but this behaviour
isn't correct.
We should not have bif
+xen-devel
Hello Julien,
> I am a bit confused. Linux is able to bring-up CPU in hyp mode with the
> current
> U-boot. Why would we need more changes for Xen?
TI's ROM code starts all CPUs in NS PL1, doesn't matter if it is boot or
secondary core.
If you look at Linux code [1], you'll see, tha
On 13/06/2019 14:26, Jan Beulich wrote:
> In order to be able to express all possible destinations we need to make
> use of this non-MSI-capability based mechanism. The new IRQ controller
> structure can re-use certain MSI functions, though.
>
> For now general and PPR interrupts still share a sing
On 18/06/2019 12:19, Volodymyr Babchuk wrote:
Hi Julien,
Hi,
Julien Grall writes:
+
+=item B
+
+Allow a guest to use OP-TEE. Note that a virtualization-aware OP-TEE
+is required for this. If this option is selected, guest will be able
OOI, what happen if OP-TEE does not support virtual
On 18/06/2019 13:28, Andrii Anisov wrote:
+xen-devel
Please don't cross-post e-mail. If you move the thread to xen-devel, then
xen-users should be droppped.
Hello Julien,
I am a bit confused. Linux is able to bring-up CPU in hyp mode with the current
U-boot. Why would we need more chan
>>> On 18.06.19 at 14:16, wrote:
> On 18/06/2019 12:53, Jan Beulich wrote:
> On 18.06.19 at 12:37, wrote:
>>> On 13/06/2019 14:23, Jan Beulich wrote:
--- a/xen/drivers/passthrough/amd/iommu_intr.c
+++ b/xen/drivers/passthrough/amd/iommu_intr.c
@@ -23,6 +23,23 @@
#include
On 18.06.19 15:54, Julien Grall wrote:
Switch to hyp-mode is fairly complex and depends on your processor. Hence why
it was dropped in both Linux and Xen.
Julien, I know it. We already discussed that few years ago.
However, calling an SMC would be acceptable to me. Stefano, any opinion?
On 13/06/2019 14:28, Jan Beulich wrote:
> While for 32-bit IRTEs I think we can safely continue to assume that the
> writes will translate to a single MOV, the use of CMPXCHG16B is more
> heavy handed than necessary for the 128-bit form, and the flushing
> didn't get done along the lines of what th
flight 137867 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137867/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemut-ws16-amd64 15 guest-saverestore.2 fail in 137729 pass
in 137867
test-amd64-i386-q
On 13/06/2019 14:27, Jan Beulich wrote:
> @@ -1346,7 +1399,7 @@ int __init amd_iommu_init(void)
> /* per iommu initialization */
> for_each_amd_iommu ( iommu )
> {
> -rc = amd_iommu_init_one(iommu);
> +rc = amd_iommu_init_one(iommu, !xt);
This logic is very subtle,
Sorry I've re-read your statement, and got another idea.
On 18.06.19 16:27, Andrii Anisov wrote:
On 18.06.19 15:54, Julien Grall wrote:
Switch to hyp-mode is fairly complex and depends on your processor.
Switch to hyp-mode depends on the processor. So it may be complex. Or not.
Hence why i
XSM was broken (patch 1) and the removal of arch_evtchn_inject() was
only partially done (patch 2).
1: XSM: adjust Kconfig names
2: x86: drop arch_evtchn_inject()
I'm not going to wait for any acks; in case of issues further incremental
fixups will need to do.
These adjustments will also be need
>>> On 18.06.19 at 15:40, wrote:
> On 13/06/2019 14:27, Jan Beulich wrote:
>> @@ -1346,7 +1399,7 @@ int __init amd_iommu_init(void)
>> /* per iommu initialization */
>> for_each_amd_iommu ( iommu )
>> {
>> -rc = amd_iommu_init_one(iommu);
>> +rc = amd_iommu_init_one
Since the Kconfig option renaming was not backported, the new uses of
involved CONFIG_* settings should have been adopted to the existing
names in the XSA-295 series. Do this now, also changing XSM_SILO to just
SILO to better match its FLASK counterpart.
To avoid breaking the Kconfig menu structur
For whatever reason this was omitted from the backport of d9195962a6
("events: drop arch_evtchn_inject()").
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -562,12 +562,6 @@ int hvm_local_events_need_delivery(struc
return !hvm_interrupt_blocked(v, int
On 18/06/2019 15:04, Jan Beulich wrote:
> For whatever reason this was omitted from the backport of d9195962a6
> ("events: drop arch_evtchn_inject()").
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.x
Hi Jan,
On 18/06/2019 15:04, Jan Beulich wrote:
Since the Kconfig option renaming was not backported, the new uses of
involved CONFIG_* settings should have been adopted to the existing
names in the XSA-295 series. Do this now, also changing XSM_SILO to just
SILO to better match its FLASK counte
>>> On 18.06.19 at 16:11, wrote:
> On 18/06/2019 15:04, Jan Beulich wrote:
>> Since the Kconfig option renaming was not backported, the new uses of
>> involved CONFIG_* settings should have been adopted to the existing
>> names in the XSA-295 series. Do this now, also changing XSM_SILO to just
>>
Julien Grall writes:
> On 18/06/2019 12:19, Volodymyr Babchuk wrote:
>>
>> Hi Julien,
>
> Hi,
>
>>
>> Julien Grall writes:
+
+=item B
+
+Allow a guest to use OP-TEE. Note that a virtualization-aware OP-TEE
+is required for this. If this option is selected, guest will be
(+ Ian)
On 18/06/2019 15:26, Jan Beulich wrote:
On 18.06.19 at 16:11, wrote:
On 18/06/2019 15:04, Jan Beulich wrote:
Since the Kconfig option renaming was not backported, the new uses of
involved CONFIG_* settings should have been adopted to the existing
names in the XSA-295 series. Do this n
>>> On 18.06.19 at 15:28, wrote:
> On 13/06/2019 14:28, Jan Beulich wrote:
>> While for 32-bit IRTEs I think we can safely continue to assume that the
>> writes will translate to a single MOV, the use of CMPXCHG16B is more
>> heavy handed than necessary for the 128-bit form, and the flushing
>> di
>>> On 18.06.19 at 16:44, wrote:
> On 18/06/2019 15:26, Jan Beulich wrote:
>> What I'd like to ask for in the future in any case though is that after
>> pushing stuff to stable trees you would please check the osstest
>> reports, and in case of regressions invest at least some time into
>> figurin
On 6/18/19 3:30 PM, Volodymyr Babchuk wrote:
Julien Grall writes:
On 18/06/2019 12:19, Volodymyr Babchuk wrote:
Hi Julien,
Hi,
Julien Grall writes:
+
+=item B
+
+Allow a guest to use OP-TEE. Note that a virtualization-aware OP-TEE
+is required for this. If this option is selected, g
Julien Grall writes:
> On 6/18/19 3:30 PM, Volodymyr Babchuk wrote:
>>
>>
>> Julien Grall writes:
>>
>>> On 18/06/2019 12:19, Volodymyr Babchuk wrote:
Hi Julien,
>>>
>>> Hi,
>>>
Julien Grall writes:
>> +
>> +=item B
>> +
>> +Allow a guest to use OP-TEE. Note th
>>> On 18.06.19 at 13:57, wrote:
> On 13/06/2019 14:23, Jan Beulich wrote:
>> This is in preparation of actually enabling x2APIC mode, which requires
>> this wider IRTE format to be used.
>>
>> A specific remark regarding the first hunk changing
>> amd_iommu_ioapic_update_ire(): This bypass was in
Hello Jan,
On 17.06.19 09:28, Jan Beulich wrote:
We may require existing runstate area unregistering if the system is aware
of it. But it is for the new interface.
The old one has no documentation about the unregistering. The implicit way
is known to us, but not known to users.
How to solve the
>>> On 18.06.19 at 17:32, wrote:
> On 17.06.19 09:28, Jan Beulich wrote:
>>> We may require existing runstate area unregistering if the system is aware
>>> of it. But it is for the new interface.
>>> The old one has no documentation about the unregistering. The implicit way
>>> is known to us, but
On 18/06/2019 14:27, Andrii Anisov wrote:
On 18.06.19 15:54, Julien Grall wrote:
Switch to hyp-mode is fairly complex and depends on your processor. Hence why
it was dropped in both Linux and Xen.
Julien, I know it. We already discussed that few years ago.
However, calling an SMC would b
branch xen-unstable
xenbranch xen-unstable
job build-arm64
testid xen-build
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem ch
On 11/06/2019 11:20, Jan Beulich wrote:
On 10.06.19 at 16:51, wrote:
>> On 15/03/2019 10:56, Jan Beulich wrote:
>>> +#if __GNUC__ > 7 /* can't check for __AVX512VBMI2__ here */
>> Why not?
> Because that would require passing -mavx512vbmi2 (or enabling the
> feature via #pragma) which in turn
On 15/03/2019 10:58, Jan Beulich wrote:
> This completes support of AVX512BW in the insn emulator, and leaves just
> the scatter/gather ones open in the AVX512F set.
>
> Signed-off-by: Jan Beulich
> ---
> v5: New.
> ---
> TBD: The *blendm* inline functions don't reliably produce the intended
>
On Tue, 18 Jun 2019, Julien Grall wrote:
> On 18/06/2019 13:28, Andrii Anisov wrote:
> > +xen-devel
>
> Please don't cross-post e-mail. If you move the thread to xen-devel, then
> xen-users should be droppped.
>
> >
> > Hello Julien,
> >
> > > I am a bit confused. Linux is able to bring-up CPU
On Tue, Jun 11, 2019 at 06:42:33AM -0600, Jan Beulich wrote:
> >>> On 10.06.19 at 18:28, wrote:
> > On 23/05/2019 13:18, Jan Beulich wrote:
> >> At least for more recent CPUs, following what BKDG / PPR suggest for the
> >> BIOS to surface via ACPI we can make ourselves independent of Dom0
> >> upl
On Fri, May 31, 2019 at 09:52:04AM -0600, Jan Beulich wrote:
> [CAUTION: External Email]
>
> Don't do this once per IOMMU, nor after setting up the IOMMU interrupt
> (which will want to schedule this tasklet). In fact it can be
> initialized at build time.
>
> Signed-off-by: Jan Beulich
Acked-b
On 6/14/19 11:38 AM, Jan Beulich wrote:
this_cpu{,_ptr}() are shorter, and have previously been marked as
preferred in Xen anyway.
Signed-off-by: Jan Beulich
Acked-by: Daniel De Graaf
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https
flight 137971 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137971/
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 137896 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137896/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 7 xen-boot fail REGR. vs. 133580
test-amd64-i386-qem
Some logging messages made more sense as argo debug
logs rather than standard Xen logs. Use argo_dprintk
to only print this info if argo DEBUG is enabled.
Signed-off-by: Nicholas Tsirakis
---
xen/common/argo.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/xen/commo
On Tue, 18 Jun 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 17/06/2019 22:24, Stefano Stabellini wrote:
> > On Wed, 1 May 2019, Julien Grall wrote:
> > > Hi,
> > >
> > > On 30/04/2019 22:02, Stefano Stabellini wrote:
> > > > Now that map_mmio_regions takes a p2mt parameter, there is no need to
On Tue, 18 Jun 2019, Jan Beulich wrote:
> >>> On 17.06.19 at 23:28, wrote:
> > On Thu, 2 May 2019, Jan Beulich wrote:
> >> >>> On 30.04.19 at 23:02, wrote:
> >> > --- a/xen/include/public/domctl.h
> >> > +++ b/xen/include/public/domctl.h
> >> > @@ -571,12 +571,24 @@ struct xen_domctl_bind_pt_irq
flight 137898 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137898/
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-i386-libvirt 13 migrat
flight 137985 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137985/
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
On Tue, 18 Jun 2019, Julien Grall wrote:
> On 30/04/2019 22:02, Stefano Stabellini wrote:
> > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> > index 89fe80f..a6c5e30 100644
> > --- a/tools/libxl/libxl_create.c
> > +++ b/tools/libxl/libxl_create.c
> > @@ -415,6 +415,21 @@ sta
Sorry for the formatting.
On Tue, 18 Jun 2019, 23:09 Stefano Stabellini,
wrote:
> On Tue, 18 Jun 2019, Julien Grall wrote:
> > On 30/04/2019 22:02, Stefano Stabellini wrote:
> > > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> > > index 89fe80f..a6c5e30 100644
> > > --- a
On Tue, 18 Jun 2019, Julien Grall wrote:
> Sorry for the formatting.
>
> On Tue, 18 Jun 2019, 23:09 Stefano Stabellini, wrote:
> On Tue, 18 Jun 2019, Julien Grall wrote:
> > On 30/04/2019 22:02, Stefano Stabellini wrote:
> > > diff --git a/tools/libxl/libxl_create.c b/tools/libx
flight 137901 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137901/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd d946d8f14c81df5c94524f0c759db84880bbcae8
baseline version:
freebsd 4fd6fe044c7
On Tue, 18 Jun 2019, Stefano Stabellini wrote:
> On Tue, 18 Jun 2019, Jan Beulich wrote:
> > >>> On 17.06.19 at 23:28, wrote:
> > > On Thu, 2 May 2019, Jan Beulich wrote:
> > >> >>> On 30.04.19 at 23:02, wrote:
> > >> > --- a/xen/include/public/domctl.h
> > >> > +++ b/xen/include/public/domctl.h
Add a p2mt parameter to map_mmio_regions, pass p2m_mmio_direct_dev on
ARM and p2m_mmio_direct on x86 -- no changes in behavior. On x86,
introduce a macro to strip away the last parameter and rename the
existing implementation of map_mmio_regions to __map_mmio_regions.
Use __map_mmio_regions in vpci
Introduce a new libxc function that makes use of the new memory_policy
parameter added to the XEN_DOMCTL_memory_mapping hypercall.
The parameter values are the same for the XEN_DOMCTL_memory_mapping
hypercall (0 is MEMORY_POLICY_DEFAULT). Pass MEMORY_POLICY_DEFAULT by
default -- no changes in beha
iomem settings fall under the broader category of "Non-PCI device
passthrough": they are not security supported. Make it clearer.
Signed-off-by: Stefano Stabellini
CC: t...@xen.org
CC: konrad.w...@oracle.com
CC: Julien Grall
CC: jbeul...@suse.com
CC: andrew.coop...@citrix.com
CC: ian.jack...@eu.
Add a new memory policy option for the iomem parameter.
Possible values are:
- arm_dev_nGnRE, Device-nGnRE, the default on ARM
- arm_mem_WB, WB cachable memory
- x86_UC_minus: uncachable memory, the default on x86
Store the parameter in a new field in libxl_iomem_range.
Pass the memory policy opt
Reuse the existing padding field to pass memory policy information. On
Arm, the caller can specify whether the memory should be mapped as
Device-nGnRE (Device Memory on Armv7) at stage-2, which is the default
and the only possibility today, or cacheable memory write-back. The
resulting memory attri
Hi all,
This series introduces a memory policy parameter for the iomem option,
so that we can map an iomem region into a guest as cacheable memory.
I removed other things related to reserved-memory on Arm, I'll send them
separately.
Cheers,
Stefano
The following changes since commit 2ac48fd5
flight 137902 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137902/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 133596
build-amd64-pre
On 6/17/19 2:28 AM, Juergen Gross wrote:
On 09.05.19 19:25, Ankur Arora wrote:
Xen ballooning uses hollow struct pages (with the underlying GFNs being
populated/unpopulated via hypercalls) which are used by the grant logic
to map grants from other domains.
This patch allows the default xenhos
On 6/17/19 2:36 AM, Juergen Gross wrote:
On 09.05.19 19:25, Ankur Arora wrote:
Largely mechanical changes: the exported grant table symbols now take
xenhost_t * as a parameter. Also, move the grant table global state
inside xenhost_t.
If there's more than one xenhost, then initialize both.
Sig
On 6/17/19 2:50 AM, Juergen Gross wrote:
On 09.05.19 19:25, Ankur Arora wrote:
As part of xenbus init, both frontend, backend interfaces need to talk
on the correct xenbus. This might be a local xenstore (backend) or might
be a XS_PV/XS_HVM interface (frontend) which needs to talk over xenbus
1 - 100 of 109 matches
Mail list logo
