Roger,
I'm still catching up on the map-inclusive and map-reserved stuff.
I have a couple questions below.
On 9/21/18 10:20 PM, Roger Pau Monne wrote:
And just rely on arch_iommu_hwdom_init to setup the correct inclusive
mappings as it's done for Intel.
AMD has code in amd_iommu_hwdom_init to
On Mon, Sep 24, 2018 at 02:28:26PM +0100, Julien Grall wrote:
> Hi Roger,
>
> On 09/12/2018 11:29 AM, Roger Pau Monné wrote:
> > On Wed, Sep 12, 2018 at 10:48:42AM +0100, Julien Grall wrote:
> > > Hi,
> > >
> > > On 09/12/2018 10:16 AM, Roger Pau Monné wrote:
> > > > On Wed, Sep 12, 2018 at 11:13
On Tue, Oct 02, 2018 at 02:37:31PM +0700, Suravee Suthikulpanit wrote:
> Roger,
>
> I'm still catching up on the map-inclusive and map-reserved stuff.
> I have a couple questions below.
>
> On 9/21/18 10:20 PM, Roger Pau Monne wrote:
> > And just rely on arch_iommu_hwdom_init to setup the correct
iommu_hwdom_inclusive was used where iommu_hwdom_reserved should be
used.
Reported-by: Suravee Suthikulpanit
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
---
Changes since v1:
- New in this version.
---
xen/drivers/passthrough/iommu.c | 2 +-
xen/drivers/passthrough/x86/iommu.c | 2
And just rely on arch_iommu_hwdom_init to setup the correct inclusive
mappings as it's done for Intel.
AMD has code in amd_iommu_hwdom_init to setup inclusive mappings up to
max_pdx, remove this since it's now a duplication of
arch_iommu_hwdom_init. Note that AMD mapped every page with a valid
mfn
On Mon, Oct 01, 2018 at 07:57:19PM +0100, Julien Grall wrote:
> The PV fields kernel, ramdisk, cmdline are only there for compatibility
> with old toolstack. Instead of manually copying them over to there new
> field, use the deprecated_by attribute in the IDL.
>
> Suggested-by: Roger Pau Monné
>
>>> On 01.10.18 at 18:07, wrote:
> On 01/10/2018 17:48, George Dunlap wrote:
>> On 10/01/2018 04:40 PM, Andrew Cooper wrote:
>>> If there isn't an obvious fix, then the switch of default scheduler
>>> needs reverting until there is a fix present. This is currently
>>> blocking master.
>>
>> Agre
Hi Julien, Stefano,
Do you have any suggestions on how to share one interrupt between Doms?
The issue is that a gpio controller has 32 in/out port, however it only has one
binded interrupt. The interrupt handler needs to check the status bits to check
which port has interrupt coming.
In my case,
>>> On 02.10.18 at 10:08, wrote:
> iommu_hwdom_inclusive was used where iommu_hwdom_reserved should be
> used.
>
> Reported-by: Suravee Suthikulpanit
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@li
On 02/10/2018 10:29, Jan Beulich wrote:
On 01.10.18 at 18:07, wrote:
>> On 01/10/2018 17:48, George Dunlap wrote:
>>> On 10/01/2018 04:40 PM, Andrew Cooper wrote:
If there isn't an obvious fix, then the switch of default scheduler
needs reverting until there is a fix present. This
>>> On 28.09.18 at 21:13, wrote:
> These entries are not always sorted by checkpolicy. Enforce the sorting
> (which can be done manually if using an unpatched checkpolicy) when
> loading the policy so that later uses by the security server do not
> incorrectly use the initial sid.
"Enforce the s
On Mon, Oct 01, 2018 at 07:57:21PM +0100, Julien Grall wrote:
> Currently, the toolstack is considering Arm guest always PV. However,
> they are very similar to PVH because HW virtualization extension are used
> and QEMU is not started. So switch Arm guest type to PVH.
>
> To keep compatibility wi
>>> On 29.09.18 at 11:22, wrote:
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -899,6 +899,19 @@ hardware domain is architecture dependent.
> Note that specifying zero as domU value means zero, while for dom0 it means
> to use the default.
>
> +##
On Tue, 2018-10-02 at 09:29 +0100, Jan Beulich wrote:
> > > > On 01.10.18 at 18:07, wrote:
> >
> > We should ignore a mismatch of the scheduler. Failures when setting
> > parameters for a matching scheduler should not be ignored IMO.
>
> Well, depends on whether the scheduler was explicitly chos
>>> On 29.09.18 at 11:22, wrote:
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -48,7 +48,12 @@ void __xsm_action_mismatch_detected(void);
> * There is no xsm_default_t argument available, so the value from the
> assertion
> * is used to initialize the variable.
> */
>
>>> On 02.10.18 at 11:24, wrote:
> On Tue, 2018-10-02 at 09:29 +0100, Jan Beulich wrote:
>> > > > On 01.10.18 at 18:07, wrote:
>> >
>> > We should ignore a mismatch of the scheduler. Failures when setting
>> > parameters for a matching scheduler should not be ignored IMO.
>>
>> Well, depends on
flight 75336 distros-debian-snapshot real [real]
http://osstest.xensource.com/osstest/logs/75336/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
On Tue, 2018-10-02 at 10:36 +0100, Jan Beulich wrote:
> > > > On 02.10.18 at 11:24, wrote:
> >
> No. See Jürgen's response. The default scheduler (irrespective of
> whether it was chosen via command line option) should not matter.
> Any means to force a non-default scheduler (and it indeed looks
Hi,
Thanks,
Basic state change is working now, after using above script.
As I said, I want to share buffer between two domains.
Could you please suggest outlines, how can I share buffer between 2
domains(Guest and Host)?
Thanks,
Omkar B
On Fri, Sep 28, 2018 at 7:12 PM Juergen Gross wrote:
> O
On 10/01/2018 06:58 PM, Dario Faggioli wrote:
> On Mon, 2018-10-01 at 18:07 +0200, Juergen Gross wrote:
>> On 01/10/2018 17:48, George Dunlap wrote:
>>> On 10/01/2018 04:40 PM, Andrew Cooper wrote:
On 01/10/18 16:35, Wei Liu wrote:
>> Wait, the migration code reads the scheduler parameters
Hi Roger,
On 02/10/2018 09:56, Roger Pau Monné wrote:
On Mon, Oct 01, 2018 at 07:57:21PM +0100, Julien Grall wrote:
Currently, the toolstack is considering Arm guest always PV. However,
they are very similar to PVH because HW virtualization extension are used
and QEMU is not started. So switch
While indirect calls have always been more expensive than direct ones,
their cost has further increased with the Spectre v2 mitigations. In a
number of cases we simply pointlessly use them in the first place. In
many other cases the indirection solely exists to abstract from e.g.
vendor specific ha
In a number of cases the targets of indirect calls get determined once
at boot time. In such cases we can replace those calls with direct ones
via our alternative instruction patching mechanism.
Some of the targets (in particular the hvm_funcs ones) get established
only in pre-SMP initcalls, makin
This is intentionally not touching hooks used rarely (or not at all)
during the lifetime of a VM, like {domain,vcpu}_initialise or cpu_up,
as well as nested, VM event, and altp2m ones (they can all be done
later, if so desired). Virtual Interrupt delivery ones will be dealt
with in a subsequent pat
While not strictly necessary, change the VMX initialization logic to
update the function table in start_vmx() from NULL rather than to NULL,
to make more obvious that we won't ever change an already (explictly)
initialized function pointer.
Signed-off-by: Jan Beulich
Acked-by: Kevin Tian
Reviewe
Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
---
v2: Drop open-coded number from macro invocation.
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -184,7 +184,7 @@ void ctxt_switch_levelling(const struct
}
if (ctxt_switch_masking)
- ctxt_swit
Instead of loading a pointer at each use site, have a single runtime
instance of struct genapic, copying into it from the individual
instances. The individual instances can this way also be moved to .init
(also adjust apic_probe[] at this occasion).
Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
For (I hope) obvious reasons only the ones used at runtime get
converted.
Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
---
v2: Drop open-coded numbers from macro invocations.
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -29,12 +29,12 @@
void send_IPI_mask(const cpumask_t *mask, in
For now only the ones used during entering/exiting of idle states are
converted. Additionally pm_idle{,_save} and lapic_timer_{on,off} can't
be converted, as they may get established rather late (when Dom0 is
already active).
Note that for patching to be deferred until after the pre-SMP initcalls
This reduces the post-init memory footprint, eliminates a pointless
level of indirection at the use sites, and allows for subsequent
alternatives call patching.
Take the opportunity and also add a name to the PowerNow! instance.
Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
---
v2: New.
---
This looks to be the only frequently executed hook; don't bother
patching any other ones.
Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
---
v2: New.
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -364,7 +364,8 @@ int __cpufreq_driver_target(struct cpufr
{
ARM is intended to gain support for heterogeneous IOMMUs on a single
system. This not only disallows boot time replacement of respective
indirect calls (handling of which is the main goal of the introduction
here), but more generally disallows calls using the iommu_ops() return
value directly - all
In !IOMMU_MIXED mode there's no need to go through an extra level of
indirection. In order to limit code churn, call sites using struct
domain_iommu's platform_ops don't get touched here, however.
Signed-off-by: Jan Beulich
---
v4: New.
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen
This is intentionally not touching hooks used rarely (or not at all)
during the lifetime of a VM.
Signed-off-by: Jan Beulich
---
v4: New.
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -228,7 +228,8 @@ void __hwdom_init iommu_hwdom_init(struc
==
On Tue, 2018-10-02 at 11:06 +0100, George Dunlap wrote:
> On 10/01/2018 06:58 PM, Dario Faggioli wrote:
> >
> > George, let me know if you're working on a fix already, or if I
> > should
> > do that myself.
>
> I reverted the credit2 default; but really we need to have a design
> discussion about
>>> On 25.09.18 at 16:14, wrote:
> Emulation requiring device model assistance uses a form of instruction
> re-execution, assuming that the second (and any further) pass takes
> exactly the same path. This is a valid assumption as far as use of CPU
> registers goes (as those can't change without a
Hi,
On 02/10/2018 11:18, Jan Beulich wrote:
ARM is intended to gain support for heterogeneous IOMMUs on a single
system. This not only disallows boot time replacement of respective
indirect calls (handling of which is the main goal of the introduction
here), but more generally disallows calls us
>>> On 25.09.18 at 16:25, wrote:
> Emulation requiring device model assistance uses a form of instruction
> re-execution, assuming that the second (and any further) pass takes
> exactly the same path. This is a valid assumption as far use of CPU
> registers goes (as those can't change without any
flight 128291 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128291/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 128215
test-armhf-armhf-libvirt 14 sav
>>> On 02.10.18 at 12:38, wrote:
> On 02/10/2018 11:18, Jan Beulich wrote:
>> ARM is intended to gain support for heterogeneous IOMMUs on a single
>> system. This not only disallows boot time replacement of respective
>> indirect calls (handling of which is the main goal of the introduction
>> her
On 02/10/18 11:36, Jan Beulich wrote:
On 25.09.18 at 16:14, wrote:
>> Emulation requiring device model assistance uses a form of instruction
>> re-execution, assuming that the second (and any further) pass takes
>> exactly the same path. This is a valid assumption as far as use of CPU
>> regi
Hi,
On 02/10/2018 11:42, Jan Beulich wrote:
On 02.10.18 at 12:38, wrote:
On 02/10/2018 11:18, Jan Beulich wrote:
ARM is intended to gain support for heterogeneous IOMMUs on a single
system. This not only disallows boot time replacement of respective
indirect calls (handling of which is the ma
flight 128278 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128278/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR.
vs. 125898
test-amd
Roger,
On 10/2/18 3:08 PM, Roger Pau Monne wrote:
> And just rely on arch_iommu_hwdom_init to setup the correct inclusive
> mappings as it's done for Intel.
>
> AMD has code in amd_iommu_hwdom_init to setup inclusive mappings up to
> max_pdx, remove this since it's now a duplication of
> arch_iom
... and try to improve readability of some of the output.
1: drop bogus casts from dump_cpu()
2: drop bogus casts from dump_lapic_regs()
3: drop bogus casts from dump_hpet()
4: drop bogus casts from dump_mtrr()
Jan
___
Xen-devel mailing list
Xen-deve
Also avoid printing the MSR flags (they're always zero as of commit
2f1add6e1c "x86/vmx: Don't leak host syscall MSR state into HVM
guests"), and print FPU registers only when the respective flag
indicates the space holds valid data.
Adjust format specifiers a little at the same time, in particula
The casts weren't even to the right type - all LAPIC registers are
32-bit (pairs/groups of registers may be combined to form larger logical
ones, but this is not visible in the given data representation).
Signed-off-by: Jan Beulich
--- a/tools/misc/xen-hvmctx.c
+++ b/tools/misc/xen-hvmctx.c
@@ -
Also specify field widths of the multiple similar lines printed in the
course of the loop, to help readability.
Make the iteration variable unsigned.
Signed-off-by: Jan Beulich
--- a/tools/misc/xen-hvmctx.c
+++ b/tools/misc/xen-hvmctx.c
@@ -316,23 +316,20 @@ static void dump_rtc(void)
static
Also make the iteration variable unsigned.
Signed-off-by: Jan Beulich
--- a/tools/misc/xen-hvmctx.c
+++ b/tools/misc/xen-hvmctx.c
@@ -344,19 +344,17 @@ static void dump_pmtimer(void)
static void dump_mtrr(void)
{
HVM_SAVE_TYPE(MTRR) p;
-int i;
+unsigned int i;
+
READ(p);
-
>>> On 02.10.18 at 13:00, wrote:
> On 02/10/2018 11:42, Jan Beulich wrote:
> On 02.10.18 at 12:38, wrote:
>>> On 02/10/2018 11:18, Jan Beulich wrote:
ARM is intended to gain support for heterogeneous IOMMUs on a single
system. This not only disallows boot time replacement of respect
Ping? Can I get an ack or otherwise from an AMD maintainer?
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 27 September 2018 13:46
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Suravee Suthikulpanit
> ; Brian Woods
> Subject: [PATCH] amd-iom
Ping? Can I get an ack or otherwise from an AMD maintainer?
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 26 September 2018 14:44
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Suravee Suthikulpanit
> ; Brian Woods
> Subject: [PATCH v2] amd-
flight 128281 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128281/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-migrupgrade 22 guest-migrate/src_host/dst_host fail REGR. vs.
128084
test-amd64
flight 128304 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128304/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 128249
test-armhf-armhf-libvirt-raw 13 saveresto
>>> On 02.10.18 at 12:51, wrote:
> On 02/10/18 11:36, Jan Beulich wrote:
> On 25.09.18 at 16:14, wrote:
>>> Emulation requiring device model assistance uses a form of instruction
>>> re-execution, assuming that the second (and any further) pass takes
>>> exactly the same path. This is a valid
Hi Jan,
On 02/10/2018 12:58, Jan Beulich wrote:
Well, that's what I would have done if you hadn't brought up the
mixed-IOMMU case - clearly, without being able to test, I wouldn't
have dared to try and implement patching of indirect calls for ARM.
I can certainly drop that patch, but in the end
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 02 October 2018 11:13
> To: xen-devel
> Cc: Andrew Cooper ; Paul Durrant
> ; Wei Liu
> Subject: [PATCH v4 02/12] x86/HVM: patch indirect calls through hvm_funcs
> to direct ones
>
> This is intentionally not touc
On 02/10/18 11:12, Jan Beulich wrote:
> --- a/xen/include/xen/lib.h
> +++ b/xen/include/xen/lib.h
> @@ -66,6 +66,10 @@
>
> #define ROUNDUP(x, a) (((x) + (a) - 1) & ~((a) - 1))
>
> +#define count_va_arg_(dot, a1, a2, a3, a4, a5, a6, a7, a8, x, ...) x
> +#define count_va_arg(args...) \
> +co
Hi Andrew,
On 02/10/2018 14:21, Andrew Cooper wrote:
On 02/10/18 11:12, Jan Beulich wrote:
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -66,6 +66,10 @@
#define ROUNDUP(x, a) (((x) + (a) - 1) & ~((a) - 1))
+#define count_va_arg_(dot, a1, a2, a3, a4, a5, a6, a7, a8, x, ...)
On 02/10/18 14:28, Julien Grall wrote:
> Hi Andrew,
>
> On 02/10/2018 14:21, Andrew Cooper wrote:
>> On 02/10/18 11:12, Jan Beulich wrote:
>>> --- a/xen/include/xen/lib.h
>>> +++ b/xen/include/xen/lib.h
>>> @@ -66,6 +66,10 @@
>>> #define ROUNDUP(x, a) (((x) + (a) - 1) & ~((a) - 1))
>>> +#defi
On 02/10/2018 14:35, Andrew Cooper wrote:
On 02/10/18 14:28, Julien Grall wrote:
Hi Andrew,
On 02/10/2018 14:21, Andrew Cooper wrote:
On 02/10/18 11:12, Jan Beulich wrote:
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -66,6 +66,10 @@
#define ROUNDUP(x, a) (((x) + (a) - 1)
On Mon 01-10-18 11:34:25, David Hildenbrand wrote:
> On 01/10/2018 10:40, Michal Hocko wrote:
> > On Fri 28-09-18 17:03:57, David Hildenbrand wrote:
> > [...]
> >
> > I haven't read the patch itself but I just wanted to note one thing
> > about this part
> >
> >> For paravirtualized devices it is
On 10/2/18 6:39 AM, Jan Beulich wrote:
On 25.09.18 at 16:25, wrote:
>> Emulation requiring device model assistance uses a form of instruction
>> re-execution, assuming that the second (and any further) pass takes
>> exactly the same path. This is a valid assumption as far use of CPU
>> regist
On Tue, Oct 02, 2018 at 04:12:08AM -0600, Jan Beulich wrote:
> In a number of cases the targets of indirect calls get determined once
> at boot time. In such cases we can replace those calls with direct ones
> via our alternative instruction patching mechanism.
>
> Some of the targets (in particul
>>> On 02.10.18 at 15:21, wrote:
> On 02/10/18 11:12, Jan Beulich wrote:
>> --- a/xen/include/xen/lib.h
>> +++ b/xen/include/xen/lib.h
>> @@ -66,6 +66,10 @@
>>
>> #define ROUNDUP(x, a) (((x) + (a) - 1) & ~((a) - 1))
>>
>> +#define count_va_arg_(dot, a1, a2, a3, a4, a5, a6, a7, a8, x, ...) x
>
>>> On 02.10.18 at 15:55, wrote:
> On Tue, Oct 02, 2018 at 04:12:08AM -0600, Jan Beulich wrote:
>> In a number of cases the targets of indirect calls get determined once
>> at boot time. In such cases we can replace those calls with direct ones
>> via our alternative instruction patching mechanism
Make handling of cpupool data in domain config more consistent.
Patch 1 is updating the cpupool in domain's config when moving the
domain to another cpupool.
Patch 2 allows to specify a cpupool on the destination host for domain
migration.
Juergen Gross (2):
libxl: modify domain config when mo
Add an option to specify the cpupool on the target machine when doing
a migration of a domain. Currently a domain is always migrated to the
cpupool with the same name as on the source machine.
Specifying "-c " will migrate the domain to the specified
cpupool on the target machine. Specifying an em
Today the domain config info contains the cpupool name the domain was
started in only if the cpupool was specified at domain creation. Moving
the domain to another cpupool later won't change that information.
Correct that by modifying the domain config accordingly.
Signed-off-by: Juergen Gross
-
On 02/10/18 15:06, Jan Beulich wrote:
On 02.10.18 at 15:21, wrote:
>> On 02/10/18 11:12, Jan Beulich wrote:
>>> --- a/xen/include/xen/lib.h
>>> +++ b/xen/include/xen/lib.h
>>> @@ -66,6 +66,10 @@
>>>
>>> #define ROUNDUP(x, a) (((x) + (a) - 1) & ~((a) - 1))
>>>
>>> +#define count_va_arg_(d
Andrew Cooper writes ("Re: [Xen-devel] [PATCH 2/2] xl: add target cpupool
parameter to xl migrate"):
> Is this the wisest way to extend the interface? We already have -C to
> specify new configuration, and only have 26*2 short options to use.
Very good question.
> What if the user could supply
>>> On 02.10.18 at 16:23, wrote:
> On 02/10/18 15:06, Jan Beulich wrote:
> On 02.10.18 at 15:21, wrote:
>>> On 02/10/18 11:12, Jan Beulich wrote:
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -66,6 +66,10 @@
#define ROUNDUP(x, a) (((x) + (a) - 1) & ~((
On 02/10/18 15:19, Juergen Gross wrote:
> Add an option to specify the cpupool on the target machine when doing
> a migration of a domain. Currently a domain is always migrated to the
> cpupool with the same name as on the source machine.
>
> Specifying "-c " will migrate the domain to the specifie
On 02/10/2018 16:42, Andrew Cooper wrote:
> On 02/10/18 15:19, Juergen Gross wrote:
>> Add an option to specify the cpupool on the target machine when doing
>> a migration of a domain. Currently a domain is always migrated to the
>> cpupool with the same name as on the source machine.
>>
>> Specify
This patch is a pre-requisite for fixing the logdirty VGA issue
(display freezes when switching to a new altp2m view early in a
domain's lifetime), but sent separately for easier review.
The new ept_set_ad_sync() function has been added to update all
active altp2ms' ept.ad. New altp2ms will inherit
On 02/10/2018 15:47, Michal Hocko wrote:
> On Mon 01-10-18 11:34:25, David Hildenbrand wrote:
>> On 01/10/2018 10:40, Michal Hocko wrote:
>>> On Fri 28-09-18 17:03:57, David Hildenbrand wrote:
>>> [...]
>>>
>>> I haven't read the patch itself but I just wanted to note one thing
>>> about this part
This run is configured for baseline tests only.
flight 75338 qemu-mainline real [real]
http://osstest.xensource.com/osstest/logs/75338/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
On 02/10/18 15:43, Jan Beulich wrote:
On 02.10.18 at 16:23, wrote:
>> On 02/10/18 15:06, Jan Beulich wrote:
>> On 02.10.18 at 15:21, wrote:
On 02/10/18 11:12, Jan Beulich wrote:
> --- a/xen/include/xen/lib.h
> +++ b/xen/include/xen/lib.h
> @@ -66,6 +66,10 @@
>
Commit 3b4adba ("tools/libxl: include scheduler parameters in the
output of xl list -l") added scheduling parameters to the set of
information collected by libxl_retrieve_domain_configuration(), in
order to report that information in `xl list -l`.
Unfortunately, libxl_retrieve_domain_configuration
On 10/02/2018 04:49 PM, George Dunlap wrote:
> Commit 3b4adba ("tools/libxl: include scheduler parameters in the
> output of xl list -l") added scheduling parameters to the set of
> information collected by libxl_retrieve_domain_configuration(), in
> order to report that information in `xl list -l`
On 02/10/2018 09:32, Peng Fan wrote:
Hi Julien, Stefano,
Hi Peng,
Do you have any suggestions on how to share one interrupt between Doms?
Sharing interrupts are usually a pain. You would need to forward the
interrupts to all the domains using that interrupt and wait for them to
EOI. This
>>> On 02.10.18 at 17:40, wrote:
> On 02/10/18 15:43, Jan Beulich wrote:
> On 02.10.18 at 16:23, wrote:
>>> On 02/10/18 15:06, Jan Beulich wrote:
>>> On 02.10.18 at 15:21, wrote:
> On 02/10/18 11:12, Jan Beulich wrote:
>> --- a/xen/include/xen/lib.h
>> +++ b/xen/include/xen/l
> To: xen-devel@lists.xenproject.org
> From: Daniel De Graaf
> Sent by: "Xen-devel"
> Date: 09/28/2018 09:13PM
> Cc: George Dunlap , Daniel De Graaf
> Subject: [Xen-devel] [PATCH] flask: Add check for io{port,mem}con sorting
>
> These entries are not always sorted by checkpolicy. Enforce the so
Hello Razvan.
Have Your patch been accepted in Xen hypervisor?
Searching through git I have found commit
"61bdddb82151fbf51c58f6ebc1b4a687942c45a8" on "Thu Jun 28 10:54:01 2018 +0300".
Is that commit deals with the error?
With best regards
Sergey Kovalev.
__
On 01/10/18 13:09, Jan Beulich wrote:
> Use separate tracking variables for the hardware domain and DomU-s.
>
> No functional change intended.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject
Instead of just doing it for the BSP. This requires storing the
maximum number of possible vCPUs in xc_dom_image.
This has been a latent bug so far because PVH doesn't yet support
pci-passthrough, so the effective memory cache attribute is forced to
WB by the hypervisor. Note also that even withou
On 01/10/18 13:09, Jan Beulich wrote:
> Use separate tracking variables for the hardware domain and DomU-s.
>
> No functional change intended, but adjust the comment in
> init_speculation_mitigations() to match prior as well as resulting code.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Coope
On 01/10/18 13:10, Jan Beulich wrote:
> While commit 2a3b34ec47 ("x86/spec-ctrl: Yet more fixes for xpti=
> parsing") indeed fixed "xpti=dom0", it broke "xpti=no-dom0", in that
> this then became equivalent to "xpti=no". In particular, the presence
> of "xpti=" alone on the command line means nothi
On 01/10/18 13:11, Jan Beulich wrote:
> Just like the otherwise similar "xpti=" allows for, to revert back to
> built-in defaults.
>
> Signed-off-by: Jan Beulich
I've made my opinion on this matter clear on several occasions.
This is not a change I'm happy with taking.
~Andrew
This patch adds a new method to the VT-d IOMMU implementation to find the
MFN currently mapped by the specified DFN along with a wrapper function
in generic IOMMU code to call the implementation if it exists.
NOTE: This patch only adds a Xen-internal interface. This will be used by
a subsequ
The name 'iommu_use_hap_pt' suggests that that P2M table is in use as the
domain's IOMMU pagetable which, prior to this patch, is not strictly true
since the macro did not test whether the domain actually has IOMMU
mappings.
Signed-off-by: Paul Durrant
Reviewed-by: Kevin Tian
Acked-by: Julien Gr
...meaning 'device DMA frame number' i.e. a frame number mapped in the IOMMU
(rather than the MMU) and hence used for DMA address translation.
This patch is a largely cosmetic change that substitutes the terms 'gfn'
and 'gaddr' for 'dfn' and 'daddr' in all the places where the frame number
or addr
This patch removes the implicit domain_crash() from iommu_map(),
unmap_page() and iommu_iotlb_flush() and turns them into straightforward
wrappers that check the existence of the relevant iommu_op and call
through to it. This makes them usable by PV IOMMU code to be delivered in
future patches.
Thi
...in intel_iommu_unmap_page().
This patch also includes some non-functional modifications in
intel_iommu_map_page().
Signed-off-by: Paul Durrant
Acked-by: Kevin Tian
---
Cc: Wei Liu
Cc: Jan Beulich
Cc: George Dunlap
v8:
- New in v8. (Split from the next patch in the series as requested by
This series contains pre-requisites and clean-up needed for paravirtual
IOMMU support.
I have separated these patches to avoid further delaying their application
whilst I re-work the implementation of paravirtual IOMMU after review of
v6 of the series. Several of them already have all necessary ac
The name 'need_iommu()' is a little confusing as it suggests a domain needs
to use the IOMMU but something might not be set up yet, when in fact it
represents a tri-state value (not a boolean as might be expected) where
-1 means 'IOMMU mappings being set up' and 1 means 'IOMMU mappings have
been fu
...for some uses of get_page_from_gfn().
There are many occurrences of the following pattern in the code:
q = ? P2M_ALLOC : P2M_UNSHARE;
page = get_page_from_gfn(d, gfn, &p2mt, q);
if ( p2m_is_paging(p2mt) )
{
if ( page )
put_page(page);
p2m_mem_pagi
This patch modifies the methods in struct iommu_ops to use type-safe DFN
and MFN. This follows on from the prior patch that modified the functions
exported in xen/iommu.h.
Signed-off-by: Paul Durrant
Reviewed-by: Wei Liu
Reviewed-by: Kevin Tian
Reviewed-by: Roger Pau Monne
Acked-by: Jan Beulic
This patch modifies the declaration of the entry points to the IOMMU
sub-system to use dfn_t and mfn_t in place of unsigned long. A subsequent
patch will similarly modify the methods in the iommu_ops structure.
Signed-off-by: Paul Durrant
Reviewed-by: Wei Liu
Reviewed-by: Kevin Tian
Reviewed-by
So far I have had zero review from AMD maintainers of this series. Can I please
get acks or otherwise on the relevant patches?
Paul
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 02 October 2018 18:00
> To: xen-devel@lists.xenproject.org
> Cc: Paul D
1 - 100 of 110 matches
Mail list logo
