On Mon, Jan 15, 2018 at 09:24:52PM -0600, Doug Goldstein wrote:
> There was no default documented but inspecting
> libxl__domain_build_info_setdefault() shows the default to be
> LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS.
>
> Signed-off-by: Doug Goldstein
> ---
> CC: Wei Liu
> CC: Ian Jackson
>>> On 15.01.18 at 19:26, wrote:
> On 15/01/18 11:07, Jan Beulich wrote:
>> --- a/docs/misc/xen-command-line.markdown
>> +++ b/docs/misc/xen-command-line.markdown
>> @@ -1849,6 +1849,15 @@ In the case that x2apic is in use, this
>> clustered mode. The default, given no hint from the **FADT**, is
On Mon, Jan 15, 2018 at 09:24:51PM -0600, Doug Goldstein wrote:
> In libxl__domain_build_info_setdefault() in
> tools/libxl/libxl_create.c the default for timer_mode for HVM
> and PVH is LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS so adjust the
> comments in the header to reflect this.
IMHO this is
flight 118088 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118088/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 117772
build-arm64-pvops
>>> On 15.01.18 at 19:12, wrote:
> Luwei Kang (7):
> x86: add a flag to enable Intel processor trace
> x86: configure vmcs for Intel processor trace virtualization
> x86: add intel proecessor trace support for cpuid
> x86: add intel processor trace context
> x86: Implement Intel Processo
flight 118078 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118078/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build fail REGR. vs. 118003
test-amd64-amd64-x
>>> On 16.01.18 at 09:43, wrote:
> flight 118078 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/118078/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-arm64-pvops 6 kernel-build
> >>> On 15.01.18 at 19:12, wrote:
> > Luwei Kang (7):
> > x86: add a flag to enable Intel processor trace
> > x86: configure vmcs for Intel processor trace virtualization
> > x86: add intel proecessor trace support for cpuid
> > x86: add intel processor trace context
> > x86: Implement
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 16 January 2018 08:58
> To: Paul Durrant
> Cc: xen-devel ; osstest-
> ad...@xenproject.org
> Subject: Re: [Xen-devel] [xen-unstable test] 118078: regressions - FAIL
>
> >>> On 16.01.18 at 09:43, wrote:
> > flight
>>> On 16.01.18 at 10:02, wrote:
>> >>> On 15.01.18 at 19:12, wrote:
>> > Luwei Kang (7):
>> > x86: add a flag to enable Intel processor trace
>> > x86: configure vmcs for Intel processor trace virtualization
>> > x86: add intel proecessor trace support for cpuid
>> > x86: add intel proce
>>> On 15.01.18 at 19:23, wrote:
> On 15/01/18 11:06, Jan Beulich wrote:
>> This also wants Andrew's "[PATCH RFC 11/44] x86/pt-shadow: Always set
>> _PAGE_ACCESSED on L4e updates".
>
> I've cleaned this patch up and committed it in preparation.
>
> http://xenbits.xen.org/gitweb/?p=xen.git;a=comm
> >>> On 16.01.18 at 10:02, wrote:
> >> >>> On 15.01.18 at 19:12, wrote:
> >> > Luwei Kang (7):
> >> > x86: add a flag to enable Intel processor trace
> >> > x86: configure vmcs for Intel processor trace virtualization
> >> > x86: add intel proecessor trace support for cpuid
> >> > x86: a
flight 118083 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118083/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which did not suc
On 01/16/2018 07:12 AM, Jan Beulich wrote:
On 15.01.18 at 17:54, wrote:
>> On Jan 12, 2018, at 05:19, Jan Beulich wrote:
>>>
>>> This is a very simplistic change limiting the amount of memory a running
>>> 64-bit PV guest has mapped (and hence available for attacking): Only the
>>> mappings
On Mon, Jan 15, 2018 at 09:23:20PM +, Michael Young wrote:
> Currently the boot of a pvh guest using the qemu-xen device model fails
> with the error
> xen emulation not implemented (yet)
> in the qemu-dm log file. This patch adds the missing -xen-attach
> argument.
>
> V2: Use b_info->type !
On Fri, 2018-01-12 at 18:00 +, Andrew Cooper wrote:
>
> @@ -152,14 +163,38 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr,
> uint64_t val)
> {
> const struct vcpu *curr = current;
> struct domain *d = v->domain;
> + const struct cpuid_policy *cp = d->arch.cpuid;
> struct ms
On 01/03/2018 05:47 AM, Manish Jaggi wrote:
Hi Sameer,
Hi Manish,
+
+/* Xen: Type definitions for iommu_domain */
+#define IOMMU_DOMAIN_UNMANAGED 0
+#define IOMMU_DOMAIN_DMA 1
+#define IOMMU_DOMAIN_IDENTITY 2
+
+/* Xen: Dummy iommu_domain */
+struct iommu_domain {
+ /* Runtime SMMU conf
On 01/03/2018 05:34 AM, Manish Jaggi wrote:
Hi Sameer,
Hi Manish,
+ unsigned int type;
+
+ /* Dummy compatibility defines */
+ unsigned long pgsize_bitmap;
+ struct iommu_domain_geometry geometry;
+
+ atomic_t ref;
+ /* Used to link iommu_domain contexts for a s
flight 118091 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118091/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 117930
test-armhf-armhf-
On 16/01/18 07:46, Jan Beulich wrote:
On 15.01.18 at 19:23, wrote:
>> On 15/01/18 11:06, Jan Beulich wrote:
>>> --- a/xen/arch/x86/x86_64/compat/entry.S
>>> +++ b/xen/arch/x86/x86_64/compat/entry.S
>>> @@ -199,6 +199,17 @@ ENTRY(cstar_enter)
>>> pushq $0
>>> movl $TRAP_sysc
On 16/01/18 09:33, Jan Beulich wrote:
On 15.01.18 at 19:23, wrote:
>> On 15/01/18 11:06, Jan Beulich wrote:
>>> This also wants Andrew's "[PATCH RFC 11/44] x86/pt-shadow: Always set
>>> _PAGE_ACCESSED on L4e updates".
>> I've cleaned this patch up and committed it in preparation.
>>
>> http:/
On Mon, Jan 15, 2018 at 11:07 AM, Jan Beulich wrote:
> First of all we don't need it on AMD systems. Additionally allow its use
> to be controlled by command line option. For best backportability, this
> intentionally doesn't use alternative instruction patching to achieve
> the intended effect -
On 16/01/18 13:12, George Dunlap wrote:
> On Mon, Jan 15, 2018 at 11:07 AM, Jan Beulich wrote:
>> First of all we don't need it on AMD systems. Additionally allow its use
>> to be controlled by command line option. For best backportability, this
>> intentionally doesn't use alternative instruction
On Fri, Jan 12, 2018 at 08:45:17PM +, Joao Martins wrote:
> On 01/12/2018 11:28 AM, Wei Liu wrote:
> > It is a variant of TSC clock source.
> >
> > Signed-off-by: Wei Liu
> > Signed-off-by: Andrew Cooper
> > Signed-off-by: Roger Pau Monné
> > ---
> > Changes since v1:
> > - Use the mapped
>>> On 16.01.18 at 12:56, wrote:
> On 16/01/18 09:33, Jan Beulich wrote:
> On 15.01.18 at 19:23, wrote:
>>> On 15/01/18 11:06, Jan Beulich wrote:
This also wants Andrew's "[PATCH RFC 11/44] x86/pt-shadow: Always set
_PAGE_ACCESSED on L4e updates".
>>> I've cleaned this patch up and
>>> On 16.01.18 at 12:51, wrote:
> On 16/01/18 07:46, Jan Beulich wrote:
> On 15.01.18 at 19:23, wrote:
>>> Also, can we collect these together into macros, rather than
>>> opencoding? We seem to have 3 distinct variations.
>> I had considered that (following the model you use in the SP2
>>
>>> On 16.01.18 at 13:12, wrote:
> On Mon, Jan 15, 2018 at 11:07 AM, Jan Beulich wrote:
>> First of all we don't need it on AMD systems. Additionally allow its use
>> to be controlled by command line option. For best backportability, this
>> intentionally doesn't use alternative instruction patch
according to Eduardo Habkost's commit fd3b02c889 all PCIEs now implement
INTERFACE_PCIE_DEVICE so we don't need is_express field anymore.
Devices that implements only INTERFACE_PCIE_DEVICE (is_express == 1)
or
devices that implements only INTERFACE_CONVENTIONAL_PCI_DEVICE (is_express == 0)
where n
Hi Julien,
On 01/16/2018 02:04 AM, Julien Grall wrote:
On 01/03/2018 05:47 AM, Manish Jaggi wrote:
Hi Sameer,
Hi Manish,
+
+/* Xen: Type definitions for iommu_domain */
+#define IOMMU_DOMAIN_UNMANAGED 0
+#define IOMMU_DOMAIN_DMA 1
+#define IOMMU_DOMAIN_IDENTITY 2
+
+/* Xen: Dummy iommu_
On Tue, Jan 16, 2018 at 12:21 PM, Juergen Gross wrote:
> On 16/01/18 13:12, George Dunlap wrote:
>> On Mon, Jan 15, 2018 at 11:07 AM, Jan Beulich wrote:
>>> First of all we don't need it on AMD systems. Additionally allow its use
>>> to be controlled by command line option. For best backportabili
On Tue, Jan 16, 2018 at 12:35 PM, Jan Beulich wrote:
On 16.01.18 at 13:12, wrote:
>> On Mon, Jan 15, 2018 at 11:07 AM, Jan Beulich wrote:
>>> First of all we don't need it on AMD systems. Additionally allow its use
>>> to be controlled by command line option. For best backportability, this
Hi Julien,
On 01/16/2018 02:11 AM, Julien Grall wrote:
On 01/03/2018 05:34 AM, Manish Jaggi wrote:
Hi Sameer,
Hi Manish,
+ unsigned int type;
+
+ /* Dummy compatibility defines */
+ unsigned long pgsize_bitmap;
+ struct iommu_domain_geometry geometry;
+
+ atomic
On Fri, Jan 12, 2018 at 01:24:09PM +, Wei Liu wrote:
> Hi all,
>
> Two solutions are proposed to mitigate Meltdown. One is called Vixen and the
> other is called Comet. The long term goal is to merge the two implementations
> to one.
>
> Here I list the differences between the two implementat
On Tue, Jan 16, 2018 at 12:46:10PM +, Wei Liu wrote:
> On Fri, Jan 12, 2018 at 01:24:09PM +, Wei Liu wrote:
> > Hi all,
> >
> > Two solutions are proposed to mitigate Meltdown. One is called Vixen and the
> > other is called Comet. The long term goal is to merge the two
> > implementation
Hi,
On 16/01/18 12:37, Manish Jaggi wrote:
On 01/16/2018 02:04 AM, Julien Grall wrote:
On 01/03/2018 05:47 AM, Manish Jaggi wrote:
+int devm_request_threaded_irq(struct device *dev, unsigned int irq,
irq_handler_t handler,
+ irq_handler_t thread_fn, unsigned long irqflags,
+
On 16/01/18 12:40, Manish Jaggi wrote:
Hi Julien,
Hi,
On 01/16/2018 02:11 AM, Julien Grall wrote:
On 01/03/2018 05:34 AM, Manish Jaggi wrote:
Hi Sameer,
Hi Manish,
+ unsigned int type;
+
+ /* Dummy compatibility defines */
+ unsigned long pgsize_bitmap;
+ stru
On 16/01/18 08:12, Jan Beulich wrote:
On 15.01.18 at 19:26, wrote:
>> On 15/01/18 11:07, Jan Beulich wrote:
>>> --- a/docs/misc/xen-command-line.markdown
>>> +++ b/docs/misc/xen-command-line.markdown
>>> @@ -1849,6 +1849,15 @@ In the case that x2apic is in use, this
>>> clustered mode. The
On 16/01/18 12:33, Jan Beulich wrote:
>>
>> On 15.01.18 at 19:23, wrote:
can we collect these together into macros, rather than
opencoding? We seem to have 3 distinct variations.
>>> I had considered that (following the model you use in the SP2
>>> series), but decided against it n
On 01/16/2018 06:44 PM, Julien Grall wrote:
On 16/01/18 12:40, Manish Jaggi wrote:
Hi Julien,
Hi,
On 01/16/2018 02:11 AM, Julien Grall wrote:
On 01/03/2018 05:34 AM, Manish Jaggi wrote:
Hi Sameer,
Hi Manish,
+ unsigned int type;
+
+ /* Dummy compatibility defines
Hi Manish,
On 16/01/18 13:27, Manish Jaggi wrote:
On 01/16/2018 06:44 PM, Julien Grall wrote:
On 16/01/18 12:40, Manish Jaggi wrote:
Hi Julien,
Hi,
On 01/16/2018 02:11 AM, Julien Grall wrote:
On 01/03/2018 05:34 AM, Manish Jaggi wrote:
Hi Sameer,
Hi Manish,
+ unsigned int
Hi Xen community
I have built and brought up Xen 4.8 on Renesas RCar H3. For a specific
requirement, I need to use the I2C bus of the board from Domain U. Is there
a way to use the I2C bus from the guest?
I have looked into para-virtualization and passthrough [1][2] but there
isn't enough support
Dear Ganesh,
Could you please specify your exact target board? Is it salvator-x or
starter kit premier (h3ulcb)?
Actually Renesas BSP 2.19.0 is easily being built for salvator-x. In
step 8 you should select an appropriate conf from
`meta-rcar-gen3/docs/sample/conf/salvator-x/`.
> But the Yocto bu
>>> On 16.01.18 at 14:20, wrote:
> The isolation is definitely not complete. Amongst other things, remote
> stacks are in view of an attacker, which is why my KAISER-prereq series
> pushes for the fully isolated per-pcpu range.
How are remote stacks visible? The local page tables contain only
ma
On 15/01/18 10:28, Jan Beulich wrote:
>> ctxt->io_emul_stub[10] = 0xff;
>> ctxt->io_emul_stub[11] = 0xd1;
>>
>> +/*
>> + * 3 bytes of P6_NOPS.
>> + * TODO: untangle ideal_nops from init/livepatch Kconfig options.
>> + */
>> +memcpy(&ctxt->io_emul_stub[12], "\x0f\x1f\
>>> On 16.01.18 at 14:55, wrote:
> On 15/01/18 10:28, Jan Beulich wrote:
>>> ctxt->io_emul_stub[10] = 0xff;
>>> ctxt->io_emul_stub[11] = 0xd1;
>>>
>>> +/*
>>> + * 3 bytes of P6_NOPS.
>>> + * TODO: untangle ideal_nops from init/livepatch Kconfig options.
>>> + */
>>> +
On 01/12/2018 01:01 PM, Andrew Cooper wrote:
>
> +if ( boot_cpu_has(X86_FEATURE_IBRSB) )
> +{
> +/*
> + * Even if we've chosen to not have IBRS set in Xen context, we still
> + * need the IBRS entry/exit logic to virtualise IBRS support for
> + * guests.
>
On 16/01/18 14:10, Boris Ostrovsky wrote:
> On 01/12/2018 01:01 PM, Andrew Cooper wrote:
>>
>> +if ( boot_cpu_has(X86_FEATURE_IBRSB) )
>> +{
>> +/*
>> + * Even if we've chosen to not have IBRS set in Xen context, we
>> still
>> + * need the IBRS entry/exit logic t
Once Xen knows what features/workarounds present on the platform, it
might be necessary to configure each online CPU.
Introduce a new callback "enable" that will be called on each online CPU to
configure the "capability".
The code is based on Linux v4.14 (where cpufeature.c comes from), the
expla
Cortex-A72, A73 and A75 MIDR will be used to a follow-up for hardening
the branch predictor.
This is part of XSA-254.
Signed-off-by: Julien Grall
---
xen/include/asm-arm/processor.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/p
Cortex-A57, A72, A73 and A75 are susceptible to branch predictor
aliasing and can theoritically be attacked by malicious code.
This patch implements a PSCI-based mitigation for these CPUs when
available. The call into firmware will invalidate the branch predictor
state, preventing any malicious en
Introduce a new macro MIDR_ALL_VERSIONS to match all variant/revision of a
given CPU model.
This is part of XSA-254.
Signed-off-by: Julien Grall
---
xen/arch/arm/cpuerrata.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 77258
On Tue, Jan 16, 2018 at 01:03:06PM +, Roger Pau Monné wrote:
> On Tue, Jan 16, 2018 at 12:46:10PM +, Wei Liu wrote:
> > On Fri, Jan 12, 2018 at 01:24:09PM +, Wei Liu wrote:
> > > Hi all,
> > >
> > > Two solutions are proposed to mitigate Meltdown. One is called Vixen and
> > > the
> >
Hi all,
This series provides a framework for mitigating branch predictor hardening on
Arm64 on exception entry.
It also implements a dummy PSCI "VERSION" call as the hook for affected
Cortex-A CPUs. This will invalidate the predictor state with the latest
Arm Trusted Firmware patches which will a
Aliasing attacked against CPU branch predictors can allow an attacker to
redirect speculative control flow on some CPUs and potentially divulge
information from one context to another.
This patch adds initial skeleton code behind a new Kconfig option to
enable implementation-specific mitigations a
On 01/16/2018 09:13 AM, Andrew Cooper wrote:
> On 16/01/18 14:10, Boris Ostrovsky wrote:
>> On 01/12/2018 01:01 PM, Andrew Cooper wrote:
>>>
>>> +if ( boot_cpu_has(X86_FEATURE_IBRSB) )
>>> +{
>>> +/*
>>> + * Even if we've chosen to not have IBRS set in Xen context, we
>>>
Added embedded-pv-de...@lists.xenproject.org
> On 16 Jan 2018, at 13:39, Saumya Rajesh wrote:
>
> Hi Xen community
>
> I have built and brought up Xen 4.8 on Renesas RCar H3. For a specific
> requirement, I need to use the I2C bus of the board from Domain U. Is there a
> way to use the I2C bu
1: x86: Meltdown band-aid against malicious 64-bit PV guests
2: x86: allow Meltdown band-aid to be disabled
Signed-off-by: Jan Beulich
---
v3: Addressing review comments (see individual patches).
v2: Addressing review comments for patch 1 (see there) and new
patch 2.
__
This is a very simplistic change limiting the amount of memory a running
64-bit PV guest has mapped (and hence available for attacking): Only the
mappings of stack, IDT, and TSS are being cloned from the direct map
into per-CPU page tables. Guest controlled parts of the page tables are
being copied
On 16/01/18 14:25, Boris Ostrovsky wrote:
> On 01/16/2018 09:13 AM, Andrew Cooper wrote:
>> On 16/01/18 14:10, Boris Ostrovsky wrote:
>>> On 01/12/2018 01:01 PM, Andrew Cooper wrote:
+if ( boot_cpu_has(X86_FEATURE_IBRSB) )
+{
+/*
+ * Even if we've
First of all we don't need it on AMD systems. Additionally allow its use
to be controlled by command line option. For best backportability, this
intentionally doesn't use alternative instruction patching to achieve
the intended effect - while we likely want it, this will be later
follow-up.
Signed
From: Manish Jaggi
Add a config option to enable VGIC Errata Code in Xen. Platforms which do not
have this errta can compile out this feature.
Signed-off-by: Manish Jaggi
---
xen/arch/arm/Kconfig | 9 +
1 file changed, 9 insertions(+)
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/K
From: Manish Jaggi
define accessors that take the register number as a parameter.
Signed-off-by: Manish Jaggi
---
xen/arch/arm/arm64/vsysreg.c | 92
1 file changed, 92 insertions(+)
diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsy
From: Manish Jaggi
Add a handler for reading the guest's view of the ICV_HPPIR1_EL1
register. This is a simple parsing of the available LRs, extracting the
highest available interrupt.
Signed-off-by: Manish Jaggi
---
xen/arch/arm/arm64/vsysreg.c| 24
xen/includ
From: Manish Jaggi
Add a handler for reading/writing the guest's view of the ICC_BPR1_EL1
register, which is located in the ICH_VMCR_EL2.BPR1 field.
Signed-off-by: Manish Jaggi
---
xen/arch/arm/arm64/vsysreg.c| 71 +
xen/include/asm-arm/arm64/sysregs
From: Manish Jaggi
Add a handler for writing the guest's view of the ICC_EOIR1_EL1
register. This involves dropping the priority of the interrupt,
and deactivating it if required.
Signed-off-by: Manish Jaggi
---
xen/arch/arm/arm64/vsysreg.c| 136
xe
From: Manish Jaggi
Add a handler for reading/writing the guest's view of the
ICC_IGRPEN1_EL1 register, which is located in the ICH_VMCR_EL2.VENG1 field.
Signed-off-by: Manish Jaggi
---
xen/arch/arm/arm64/vsysreg.c| 32
xen/include/asm-arm/arm64/sysregs.
From: Manish Jaggi
Add a handler for reading the guest's view of the ICC_IAR1_EL1
register. This involves finding the highest priority Group-1
interrupt, checking against both PMR and the active group
priority, activating the interrupt and setting the group
priority as active.
Signed-off-by: Man
From: Manish Jaggi
gicv3_ich_read/write_lr functions are static in gic-v3.c
This patch creates wrapper functions which can be used from outside the file.
Signed-off-by: Manish Jaggi
---
xen/arch/arm/gic-v3.c| 10 ++
xen/include/asm-arm/gic_v3.h | 7 +++
2 files changed, 17
From: Manish Jaggi
In order to start handling guest access to GICv3 system registers,
let's add a hook that will get called when we trap a system register
access.
This handling code is kept independent of other traps.
Set CONFIG_VGIC_ERRATA to enable this code.
Signed-off-by: Manish Jaggi
---
From: Manish Jaggi
This patchset is a Xen port of Marc's patchset.
arm64: KVM: Mediate access to GICv3 sysregs at EL2 [1]
The current RFC patchset is a subset of [1], as it handleing only Group1 traps
as a PoC. Most of the trap code is added in vsysreg.c. Trap handler function is
kept
independe
From: Manish Jaggi
In order to be able to trap Group-1 GICv3 system registers, we need to
set ICH_HCR_EL2.TALL1 before entering the guest. This is controlled by
the command line parameter group1_trap.
Singed-off-by: Manish Jaggi
---
xen/arch/arm/gic-v3.c | 11 ++-
xen/include/asm-a
Dear Rajesh,
You can try to get an I2C bus controller in DomU in PIO mode following
[1], keeping in mind [2].
If you want it DMA capable you need Renesas IPMMU support in XEN [3],
[4] to be incorporated.
[1] - https://xenbits.xen.org/docs/unstable/misc/arm/passthrough.txt
[2] -
https://
There was no default documented but inspecting
libxl__domain_build_info_setdefault() shows the default to be
LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS.
Signed-off-by: Doug Goldstein
---
CC: Wei Liu
CC: Ian Jackson
CC: Roger Pau Monné
# George for the 4.8 and 4.9 backport
CC: George Dunlap
c
On 16/01/18 15:21, Jan Beulich wrote:
> --- a/xen/include/asm-x86/x86_64/page.h
> +++ b/xen/include/asm-x86/x86_64/page.h
> @@ -24,8 +24,8 @@
> /* These are architectural limits. Current CPUs support only 40-bit phys. */
> #define PADDR_BITS 52
> #define VADDR_BITS 48
>
On 16/01/18 15:22, Jan Beulich wrote:
> First of all we don't need it on AMD systems. Additionally allow its use
> to be controlled by command line option. For best backportability, this
> intentionally doesn't use alternative instruction patching to achieve
> the intended effect - while we likely
On 1/12/18 8:20 AM, Wei Liu wrote:
> On Fri, Jan 12, 2018 at 03:17:04PM +0100, Olaf Hering wrote:
>> On Fri, Jan 12, Wei Liu wrote:
>>
>>> Vixen Comet
>>> Guest console Output onlyBi-directional
>>
>> With the proper patch i
On Tue, Jan 16, 2018 at 4:42 PM, Doug Goldstein wrote:
> On 1/12/18 8:20 AM, Wei Liu wrote:
>> On Fri, Jan 12, 2018 at 03:17:04PM +0100, Olaf Hering wrote:
>>> On Fri, Jan 12, Wei Liu wrote:
>>>
Vixen Comet
Guest console Output only
On Tue, Jan 16, 2018 at 12:46:10PM +, Wei Liu wrote:
> On Fri, Jan 12, 2018 at 01:24:09PM +, Wei Liu wrote:
> > Hi all,
> >
> > Two solutions are proposed to mitigate Meltdown. One is called Vixen and the
> > other is called Comet. The long term goal is to merge the two
> > implementation
On Tue, Jan 16, 2018 at 10:42:17AM -0600, Doug Goldstein wrote:
> On 1/12/18 8:20 AM, Wei Liu wrote:
> > On Fri, Jan 12, 2018 at 03:17:04PM +0100, Olaf Hering wrote:
> >> On Fri, Jan 12, Wei Liu wrote:
> >>
> >>> Vixen Comet
> >>> Guest console
>>> On 16.01.18 at 17:52, wrote:
> I've pushed comet-for-unstable to my xenbits/xen.git. That branch is a
> forward port of 4.10.0-shim-comet branch to staging.
>
> https://xenbits.xen.org/gitweb/?p=people/liuw/xen.git;a=shortlog;h=refs/head
> s/comet-for-unstable
>
> There will be follow-up pa
Hi Jan,
On Tue, Jan 16, 2018 at 08:21:52AM -0700, Jan Beulich wrote:
> This is a very simplistic change limiting the amount of memory a running
> 64-bit PV guest has mapped (and hence available for attacking): Only the
> mappings of stack, IDT, and TSS are being cloned from the direct map
> into p
On 16/01/18 11:10, David Woodhouse wrote:
> On Fri, 2018-01-12 at 18:00 +, Andrew Cooper wrote:
>> @@ -152,14 +163,38 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr,
>> uint64_t val)
>> {
>> const struct vcpu *curr = current;
>> struct domain *d = v->domain;
>> + const struct cpu
flight 118096 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118096/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build fail in 118078 REGR. vs. 118003
Tests which are fa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254
version 8
Information leak via side effects of speculative execution
UPDATES IN VERSION 8
PVH shim ("Comet") i
Hi Jan,
On 12/01/18 13:13, Jan Beulich wrote:
On 09.01.18 at 20:43, wrote:
When I compiled the snippet on x86 and Arm, no relocation is available
for the pointers to string in the array in the final binary. Yet they
are available in the object.
I can see them there in the binary I look at. I
Hi Manish,
On 02/01/18 09:27, manish.ja...@linaro.org wrote:
From: Manish Jaggi
This patch aims to add the support of IORT in Xen. Below is the list
of major components which this patchset provides.
a. Add support for parsing the IORT
b. Provides API to populate/query requesterid - streamID ma
Hi Manish,
On 02/01/18 09:27, manish.ja...@linaro.org wrote:
From: Manish Jaggi
Public API to populate and query map between requester id and
The commit message should not be indented.
streamId/DeviceID. IORT is parsed one time (outside this patch)
and two lists are created one for m
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Paul Durrant
> Sent: 16 January 2018 09:27
> To: 'Jan Beulich'
> Cc: xen-devel ; osstest-
> ad...@xenproject.org
> Subject: Re: [Xen-devel] [xen-unstable test] 118078: regressions - FAIL
>
On Tue, Jan 16, 2018 at 5:28 PM, Andy Smith wrote:
> Hi Jan,
>
> On Tue, Jan 16, 2018 at 08:21:52AM -0700, Jan Beulich wrote:
>> This is a very simplistic change limiting the amount of memory a running
>> 64-bit PV guest has mapped (and hence available for attacking): Only the
>> mappings of stack
On 16/01/18 17:11, Jan Beulich wrote:
On 16.01.18 at 17:52, wrote:
>> I've pushed comet-for-unstable to my xenbits/xen.git. That branch is a
>> forward port of 4.10.0-shim-comet branch to staging.
>>
>> https://xenbits.xen.org/gitweb/?p=people/liuw/xen.git;a=shortlog;h=refs/head
>> s/comet-f
On Tue, Jan 16, 2018 at 5:51 PM, George Dunlap wrote:
> On Tue, Jan 16, 2018 at 4:42 PM, Doug Goldstein wrote:
>> On 1/12/18 8:20 AM, Wei Liu wrote:
>>> On Fri, Jan 12, 2018 at 03:17:04PM +0100, Olaf Hering wrote:
On Fri, Jan 12, Wei Liu wrote:
> Vixen
flight 118099 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118099/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which did not suc
flight 118105 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118105/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Hi Manish,
I sent the previous e-mail too soon.
On 02/01/18 09:27, manish.ja...@linaro.org wrote:
From: Manish Jaggi
Public API to populate and query map between requester id and
streamId/DeviceID. IORT is parsed one time (outside this patch)
and two lists are created one for mapping be
On 16/01/18 17:28, Andy Smith wrote:
> Hi Jan,
>
> On Tue, Jan 16, 2018 at 08:21:52AM -0700, Jan Beulich wrote:
>> This is a very simplistic change limiting the amount of memory a running
>> 64-bit PV guest has mapped (and hence available for attacking): Only the
>> mappings of stack, IDT, and TSS
On 01/11/2018 04:36 AM, Ross Lagerwall wrote:
> The page given to gnttab_end_foreign_access() to free could be a
> compound page so use put_page() instead of free_page() since it can
> handle both compound and single pages correctly.
>
> This bug was discovered when migrating a Xen VM with several
Hi Manish,
On 02/01/18 09:28, manish.ja...@linaro.org wrote:
From: Manish Jaggi
Code to query estimated IORT size for hardware domain.
Please avoid indenting the commit message.
IORT for hardware domain is generated using the requesterId and deviceId map.
Signed-off-by: Manish Jaggi
On 01/15/2018 07:49 AM, osstest service owner wrote:
flight 118006 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118006/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-build
On 01/11/2018 04:36 AM, Ross Lagerwall wrote:
> When a netfront device is set up it registers a netdev fairly early on,
> before it has set up the queues and is actually usable. A userspace tool
> like NetworkManager will immediately try to open it and access its state
> as soon as it appears. The
On Tue, Jan 16, 2018 at 05:55:38PM +, Andrew Cooper wrote:
> On 16/01/18 17:11, Jan Beulich wrote:
> On 16.01.18 at 17:52, wrote:
> >> I've pushed comet-for-unstable to my xenbits/xen.git. That branch is a
> >> forward port of 4.10.0-shim-comet branch to staging.
> >>
> >> https://xenbits
1 - 100 of 121 matches
Mail list logo