flight 111544 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111544/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e9651c12721d882f384ef10b7467af4ba56387c3
baseline version:
ovmf 401d1343cb0279908a748
This run is configured for baseline tests only.
flight 71664 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71664/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 7 xen-boot
flight 111522 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111522/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 111403
test-armhf-armhf-
On Tue, Mar 28, 2017 at 05:30:24PM +0200, Juergen Gross wrote:
> On 28/03/17 16:27, Boris Ostrovsky wrote:
> > On 03/28/2017 04:08 AM, Jan Beulich wrote:
> > On 28.03.17 at 03:57, wrote:
> >>> I think there is indeed a disconnect between target memory (provided by
> >>> the toolstack) and cur
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Stefano Stabellini
> Sent: Friday, July 7, 2017 4:50 PM
> To: Roger Pau Monné
> Cc: edgar.igles...@xilinx.com; 'Stefano Stabellini' ;
> Vikram Sethi ; 'Wei Chen' ;
> 'Steve Capper' ; 'Andre Prz
On Fri, 7 Jul 2017, Paul Durrant wrote:
> > -Original Message-
> > From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> > Sent: 22 June 2017 23:15
> > To: Paul Durrant
> > Cc: xen-de...@lists.xenproject.org; qemu-de...@nongnu.org; qemu-
> > bl...@nongnu.org; Stefano Stabellini ; Anth
On Fri, 7 Jul 2017, Roger Pau Monné wrote:
> On Thu, Jul 06, 2017 at 03:55:28PM -0500, Vikram Sethi wrote:
> > > > > AER: Will PCIe non-fatal and fatal errors (secondary bus reset for
> > > > > fatal)
> > > > > be
> > > recoverable in Xen?
> > > > > Will drivers in doms be notified about fatal er
On Fri, 7 Jul 2017, Volodymyr Babchuk wrote:
> >> I run test in DomU:
> >> real 113.08
> >> user 0.00
> >> sys 113.04
> >>
> > Ok, so there's contention for pCPUs. Dom0's vCPUs are CPU hogs, while,
> > if my assumption above is correct, the "SMC vCPU" of the DomU is I/O
> > bound, in the sense that
flight 111523 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111523/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail REGR. vs.
110441
Tests which a
On Fri, Jul 7, 2017 at 12:30 PM, Julien Grall wrote:
> Hi Chris,
>
> On 07/07/17 00:12, Chris Patterson wrote:
>>>
>>>
>>> So why do you want the hardware domain to interact with the ictlr? Could
>>> not
>>> you hide it completely?
>>>
>>
>> snip
>>
>>> What would happen if you enable the interrup
[sorry, my finger slips. let me rephrase my last sentence.]
>
>> For example, if you have a particular task in the VM that you need must
>> absolutely execute for at least 10ms every 100ms, you can:
>> - inside the VM, pin the task to vCPU 0, and give it top priority;
>> - at the Xen level, give (
On Wed, Jul 5, 2017 at 4:51 AM, Dario Faggioli
wrote:
> On Mon, 2017-07-03 at 14:42 -0400, Meng Xu wrote:
>> On Mon, Jul 3, 2017 at 10:58 AM, Andrii Anisov > m> wrote:
>> >
>> Once the scheduling policy is determined, you will need to configure
>> the VCPUs' parameters based on the systems' worklo
From: Ross Lagerwall
When the guest unplugs the emulated NICs, cleanup the peer for each NIC
as it is not needed anymore. Most importantly, this allows the tap
interfaces which QEMU holds open to be closed and removed.
Signed-off-by: Ross Lagerwall
Acked-by: Anthony PERARD
Signed-off-by: Stefa
On Wed, Jul 5, 2017 at 4:29 AM, Dario Faggioli
wrote:
> On Tue, 2017-07-04 at 11:12 -0400, Meng Xu wrote:
>> On Tue, Jul 4, 2017 at 8:28 AM, Andrii Anisov > > wrote:
>> >
>> > So you are suggesting to introduce more RT schedulers with
>> > different algorithms. Did I get you right?
>>
>> The EDF s
m.git tags/xen-20170707-tag
for you to fetch changes up to 4daf62594d13dfca2ce3a74dd3bddee5f54d7127:
xen/pt: Fixup addr validation in xen_pt_pci_config_access_check (2017-07-07
11:13:10 -0700)
Xen
Initialize xenfb properly, as all other backends, from its own
"initialise" function.
Remove the dependency of vkbd on vfb: use qemu_console_lookup_by_index
to find the principal console (to get the size of the screen) instead of
relying on a vfb backend to be available (which adds a dependency
be
From: Anoob Soman
xen_pt_pci_config_access_check checks if addr >= 0xFF. 0xFF is a valid
address and should not be ignored.
Signed-off-by: Anoob Soman
Acked-by: Anthony PERARD
Signed-off-by: Stefano Stabellini
---
hw/xen/xen_pt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
On 2017-07-07 12:00:26 +0100, Wei Liu wrote:
> On Thu, Jul 06, 2017 at 02:45:18AM -0600, Jan Beulich wrote:
> > >>> On 05.07.17 at 21:38, wrote:
> > > On 2017-07-04 09:46:58 -0600, Jan Beulich wrote:
> > >> >>> On 27.06.17 at 19:14, wrote:
> > >>
> > >> First of all, please Cc all maintainers of
On 2017-07-06 02:45:18 -0600, Jan Beulich wrote:
> >>> On 05.07.17 at 21:38, wrote:
> > On 2017-07-04 09:46:58 -0600, Jan Beulich wrote:
> >> >>> On 27.06.17 at 19:14, wrote:
> >>
> >> First of all, please Cc all maintainers of code you modify.
> >
> > I was using the names spit out by the scri
On Fri, Jul 7, 2017 at 12:25 PM, Julien Grall wrote:
> Hi Chris,
>
>
> On 06/07/17 23:00, Chris Patterson wrote:
The purpose of tegra_interrupt_compat is to maintain a tegra-specific
whitelist of interrupt controllers we know how to route. Presumably,
there may be custom board
flight 111516 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111516/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-arndale 6 xen-install fail in 111466 pass in 111516
test-armhf-armhf-libvirt
On Fri, 7 Jul 2017, Thomas Gleixner wrote:
> On Fri, 7 Jul 2017, Juergen Gross wrote:
>
> > Commit bf22ff45bed664aefb5c4e43029057a199b7070c ("genirq: Avoid
> > unnecessary low level irq function calls") breaks Xen guest
> > save/restore handling.
> >
> > The main problem are the PV devices using
On 07/07/17 15:51, Juergen Gross wrote:
> Commit bf22ff45bed664aefb5c4e43029057a199b7070c ("genirq: Avoid
> unnecessary low level irq function calls") breaks Xen guest
> save/restore handling.
>
> The main problem are the PV devices using Xen event channels as
> interrupt sources which are represe
On 07/07/17 18:41, Thomas Gleixner wrote:
> On Fri, 7 Jul 2017, Juergen Gross wrote:
>
>> Commit bf22ff45bed664aefb5c4e43029057a199b7070c ("genirq: Avoid
>> unnecessary low level irq function calls") breaks Xen guest
>> save/restore handling.
>>
>> The main problem are the PV devices using Xen eve
Hi again,
On 7 July 2017 at 09:41, Dario Faggioli wrote:
> On Fri, 2017-07-07 at 18:02 +0300, Volodymyr Babchuk wrote:
>> Hello Dario,
>>
> Hi!
>
>> On 20 June 2017 at 13:11, Dario Faggioli
>> wrote:
>> > On Mon, 2017-06-19 at 11:36 -0700, Volodymyr Babchuk wrote:
>> > >
>> > > Thanks. Actually,
flight 111535 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111535/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 13 mig
On Fri, 2017-07-07 at 18:02 +0300, Volodymyr Babchuk wrote:
> Hello Dario,
>
Hi!
> On 20 June 2017 at 13:11, Dario Faggioli
> wrote:
> > On Mon, 2017-06-19 at 11:36 -0700, Volodymyr Babchuk wrote:
> > >
> > > Thanks. Actually, we discussed this topic internally today. Main
> > > concern today i
On Fri, 7 Jul 2017, Juergen Gross wrote:
> Commit bf22ff45bed664aefb5c4e43029057a199b7070c ("genirq: Avoid
> unnecessary low level irq function calls") breaks Xen guest
> save/restore handling.
>
> The main problem are the PV devices using Xen event channels as
> interrupt sources which are repre
Hello,
I noticed that PCI passthrough for an LSI SAS HBA 9211 did not longer work (at
least under Windows) when using Xen 4.8.1.
I then bisected through various released versions and finally I narrowed it
down to
4.5.5 (with qemu from Xen 4.6.5) -> working
4.6.0-rc1 (with qemu from Xen 4.6.5)
[I just add some of my thoughts when I read this document.]
> +## Hardware perspective
> +
> + CAT/CDP defines a range of MSRs to assign different cache access patterns
> + which are known as CBMs, each CBM is associated with a COS.
> +
> + ```
> + E.g. L2 CAT:
> + +--
Hi Chris,
On 07/07/17 00:12, Chris Patterson wrote:
So why do you want the hardware domain to interact with the ictlr? Could not
you hide it completely?
snip
What would happen if you enable the interrupt here for the guest? Should not
you do it when the guest is requesting to enable (see v
Hi Chris,
On 06/07/17 23:00, Chris Patterson wrote:
The purpose of tegra_interrupt_compat is to maintain a tegra-specific
whitelist of interrupt controllers we know how to route. Presumably,
there may be custom boards out there that may have additional
interrupt routing capabilities that this p
Hi Ivan,
On 05/07/17 14:50, Ivan Pavic wrote:
On 07/05/2017 02:55 PM, Julien Grall wrote:
Hi Ivan,
On 05/07/17 13:36, Ivan Pavic wrote:
On 07/05/2017 01:27 PM, Julien Grall wrote:
On 04/07/17 21:20, Ivan Pavić2 wrote:
Hello,
Hi Ivan,
I'm testing IRQ latency on exynos5422. I'm using Xe
Hi,
On 06/07/17 07:20, Lan Tianyu wrote:
On 2017年07月05日 21:25, Julien Grall wrote:
Furthermore, on ARM we would be able to create the vIOMMU but it would
be unusable. Indeed, IOMMU are only used to protect devices. But you
don't see any way to say "This device is protected by the IOMMU". Did I
Hi,
On 06/07/17 04:10, Lan Tianyu wrote:
On 2017年07月05日 21:25, Julien Grall wrote:
+
+- XEN_DOMCTL_create_viommu
+Create vIOMMU device with vIOMMU_type, capabilities, MMIO
+base address and length. Hypervisor returns viommu_id. Capabilities
should
+be in range of value returned by que
>>> On 07.07.17 at 08:48, wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -95,22 +95,91 @@ static DEFINE_PER_CPU(struct vmx_pi_blocking_vcpu,
> vmx_pi_blocking);
> uint8_t __read_mostly posted_intr_vector;
> static uint8_t __read_mostly pi_wakeup_vector;
>
>
On Wed, Jul 05, 2017 at 02:56:35PM +0100, Anoob Soman wrote:
> xen_pt_pci_config_access_check checks if addr >= 0xFF. 0xFF is a valid
> address and should not be ignored.
>
> Signed-off-by: Anoob Soman
Acked-by: Anthony PERARD
> ---
> hw/xen/xen_pt.c | 2 +-
> 1 file changed, 1 insertion(+),
flight 111526 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111526/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 401d1343cb0279908a748fd0ff27609ccc300b43
baseline version:
ovmf 5e72dacc83bb47d1fae99
>>> On 07.07.17 at 08:48, wrote:
> This number is used to calculate the average vcpus per pcpu ratio.
>
> Signed-off-by: Chao Gao
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 07.07.17 at 08:48, wrote:
> This patch adds a field, counter, in struct vmx_pi_blocking_vcpu to track
> how many entries are on the pi blocking list.
>
> Signed-off-by: Chao Gao
Looks okay now, but didn't you have ASSERT()s in place earlier
on checking the counter isn't zero before decre
>>> On 07.07.17 at 08:49, wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -190,7 +190,9 @@ static void vmx_vcpu_block(struct vcpu *v)
> */
> ASSERT(old_lock == NULL);
>
> -per_cpu(vmx_pi_blocking, v->processor).counter++;
> +per_cpu(vmx_pi_blo
>>> On 07.07.17 at 05:53, wrote:
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -302,6 +302,39 @@ static int update_domain_cpuid_info(struct domain *d,
> return 0;
> }
>
> +static int vcpu_set_vmce(struct vcpu *v,
> + const struct xen_domctl_ext_vc
Hello Dario,
On 20 June 2017 at 13:11, Dario Faggioli wrote:
> On Mon, 2017-06-19 at 11:36 -0700, Volodymyr Babchuk wrote:
>> On 19 June 2017 at 10:54, Stefano Stabellini
>> wrote:
>> > True. However, Volodymyr took the time to demonstrate the
>> > performance of
>> > EL0 apps vs. stubdoms with
All,
I am pleased to announce the release of Xen 4.6.6. This is
available immediately from its git repository
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.6
(tag RELEASE-4.6.6) or from the XenProject download page
https://xenproject.org/downloads/xen-archives/xen-46-s
All,
I am pleased to announce the release of Xen 4.7.3. This is
available immediately from its git repository
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.7
(tag RELEASE-4.7.3) or from the XenProject download page
https://xenproject.org/downloads/xen-archives/xen-proj
Commit bf22ff45bed664aefb5c4e43029057a199b7070c ("genirq: Avoid
unnecessary low level irq function calls") breaks Xen guest
save/restore handling.
The main problem are the PV devices using Xen event channels as
interrupt sources which are represented as an "irq chip" in the kernel.
When saving the
On Thu, Jul 06, 2017 at 05:04:54PM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH v4 15/16] osstest: introduce a script to
> create a FreeBSD flight"):
> > The logic to create a FreeBSD build job is added to
> > make-freebsd-flight. This includes creating a FreeBSD build job, and
> >
On Fri, Jul 07, 2017 at 07:49:32PM +0530, Bhupinder Thakur wrote:
> Hi Wei,
>
> On 7 July 2017 at 19:30, Wei Liu wrote:
> > On Fri, Jul 07, 2017 at 07:22:14PM +0530, Bhupinder Thakur wrote:
> >> >> -static struct domain *create_domain(int domid)
> >> >> +static int console_init(struct console *co
flight 111506 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111506/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail in
111389 pass in 111506
test-amd64-a
Hi Wei,
On 7 July 2017 at 19:30, Wei Liu wrote:
> On Fri, Jul 07, 2017 at 07:22:14PM +0530, Bhupinder Thakur wrote:
>> >> -static struct domain *create_domain(int domid)
>> >> +static int console_init(struct console *con, struct domain *dom, void
>> >> **data)
>> >> {
>> >> - struct domain
On 07/07/17 14:01, Sergey Dyasli wrote:
> On Thu, 2017-07-06 at 06:28 -0600, Jan Beulich wrote:
> On 06.07.17 at 12:23, wrote:
>>> On Tue, 2017-07-04 at 09:04 -0600, Jan Beulich wrote:
>>> On 26.06.17 at 12:44, wrote:
> +{
> +struct vmx_msr_policy *p = &hvm_max_vmx_msr_policy;
On Fri, Jul 07, 2017 at 11:56:43AM +0100, Wei Liu wrote:
> On Wed, Jul 05, 2017 at 02:52:41PM -0500, Venu Busireddy wrote:
> > > [...]
> > > > diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c
> > > > index 89c2b25..10a48a9 100644
> > > > --- a/tools/xl/xl_vmcontrol.c
> > > > +++ b/too
On Fri, Jul 07, 2017 at 07:22:14PM +0530, Bhupinder Thakur wrote:
> >> -static struct domain *create_domain(int domid)
> >> +static int console_init(struct console *con, struct domain *dom, void
> >> **data)
> >> {
> >> - struct domain *dom;
> >> char *s;
> >> + int err = -1;
> >>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2017-10913,CVE-2017-10914 / XSA-218
version 5
Races in the grant table unmap code
UPDATES IN VERSION 5
CVEs assigned.
ISSUE DESCRIPTION
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2017-10917 / XSA-221
version 3
NULL pointer deref in event channel poll
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2017-10918 / XSA-222
version 3
stale P2M mappings due to insufficient error checking
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
==
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2017-10915 / XSA-219
version 3
x86: insufficient reference counts during shadow emulation
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
==
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2017-10923 / XSA-225
version 3
arm: vgic: Out-of-bound access when sending SGIs
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2017-10919 / XSA-223
version 3
ARM guest disabling interrupt may crash Xen
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
===
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2017-10911 / XSA-216
version 5
blkif responses leak backend stack data
UPDATES IN VERSION 5
CVE assigned.
ISSUE DESCRIPTION
=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2017-10916 / XSA-220
version 3
x86: PKRU and BND* leakage between vCPU-s
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2017-10912 / XSA-217
version 3
page transfer may allow PV guest to elevate privilege
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
==
Hi Wei,
>>
>> struct console {
>> + char *ttyname;
>> int master_fd;
>> int master_pollfd_idx;
>> int slave_fd;
>> int log_fd;
>> struct buffer buffer;
>> char *xspath;
>> + char *log_suffix;
>
> I suppose both new fields can be const.
ok. I will make
Create a new function attribute, __nostackp, that can used to turn off
stack protection on a per function basis.
Signed-off-by: Tom Lendacky
---
include/linux/compiler-gcc.h |2 ++
include/linux/compiler.h |4
2 files changed, 6 insertions(+)
diff --git a/include/linux/compiler
Add support to check if SME has been enabled and if memory encryption
should be activated (checking of command line option based on the
configuration of the default state). If memory encryption is to be
activated, then the encryption mask is set and the kernel is encrypted
"in place."
Signed-off-
Add a cmdline_find_option() function to look for cmdline options that
take arguments. The argument is returned in a supplied buffer and the
argument length (regardless of whether it fits in the supplied buffer)
is returned, with -1 indicating not found.
Signed-off-by: Tom Lendacky
---
arch/x86/i
Add the support to encrypt the kernel in-place. This is done by creating
new page mappings for the kernel - a decrypted write-protected mapping
and an encrypted mapping. The kernel is encrypted by copying it through
a temporary buffer.
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/mem_enc
Currently, native_make_p4d() is only defined when CONFIG_PGTABLE_LEVELS
is greater than 4. Create a macro that will allow for defining and using
native_make_p4d() when CONFIG_PGTABLES_LEVELS is not greater than 4.
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/pgtable_types.h |5 +
When accessing memory using /dev/mem (or /dev/kmem) use the proper
encryption attributes when mapping the memory.
To insure the proper attributes are applied when reading or writing
/dev/mem, update the xlate_dev_mem_ptr() function to use memremap()
which will essentially perform the same steps of
Xen does not currently support SME for PV guests. Clear the SME CPU
capability in order to avoid any ambiguity.
Reviewed-by: Borislav Petkov
Reviewed-by: Juergen Gross
Signed-off-by: Tom Lendacky
---
arch/x86/xen/enlighten_pv.c |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/xe
Since video memory needs to be accessed decrypted, be sure that the
memory encryption mask is not set for the video ranges.
Reviewed-by: Borislav Petkov
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/vga.h | 14 +-
arch/x86/mm/pageattr.c |2 ++
drivers/gp
Provide support so that kexec can be used to boot a kernel when SME is
enabled.
Support is needed to allocate pages for kexec without encryption. This
is needed in order to be able to reboot in the kernel in the same manner
as originally booted.
Additionally, when shutting down all of the CPUs w
Add support to check if memory encryption is active in the kernel and that
it has been enabled on the AP. If memory encryption is active in the kernel
but has not been enabled on the AP, then set the memory encryption bit (bit
23) of MSR_K8_SYSCFG to enable memory encryption on that AP and allow th
Update the KVM support to work with SME. The VMCB has a number of fields
where physical addresses are used and these addresses must contain the
memory encryption mask in order to properly access the encrypted memory.
Also, use the memory encryption mask when creating and using the nested
page table
The IOMMU is programmed with physical addresses for the various tables
and buffers that are used to communicate between the device and the
driver. When the driver allocates this memory it is encrypted. In order
for the IOMMU to access the memory as encrypted the encryption mask needs
to be included
Since DMA addresses will effectively look like 48-bit addresses when the
memory encryption mask is set, SWIOTLB is needed if the DMA mask of the
device performing the DMA does not support 48-bits. SWIOTLB will be
initialized to create decrypted bounce buffers for use by these devices.
Signed-off-b
Move the setting of the cpuinfo_x86.microcode field from amd_init() to
early_amd_init() so that it is available earlier in the boot process. This
avoids having to read MSR_AMD64_PATCH_LEVEL directly during early boot.
Reviewed-by: Borislav Petkov
Signed-off-by: Tom Lendacky
---
arch/x86/kernel/
When Secure Memory Encryption is enabled, the trampoline area must not
be encrypted. A CPU running in real mode will not be able to decrypt
memory that has been encrypted because it will not be able to use addresses
with the memory encryption mask.
Reviewed-by: Borislav Petkov
Signed-off-by: Tom
Add warnings to let the user know when bounce buffers are being used for
DMA when SME is active. Since the bounce buffers are not in encrypted
memory, these notifications are to allow the user to determine some
appropriate action - if necessary. Actions can range from utilizing an
IOMMU, replacin
Add support for changing the memory encryption attribute for one or more
memory pages. This will be useful when we have to change the AP trampoline
area to not be encrypted. Or when we need to change the SWIOTLB area to
not be encrypted in support of devices that can't support the encryption
mask r
Persistent memory is expected to persist across reboots. The encryption
key used by SME will change across reboots which will result in corrupted
persistent memory. Persistent memory is handed out by block devices
through memory remapping functions, so be sure not to map this memory as
encrypted.
The SMP MP-table is built by UEFI and placed in memory in a decrypted
state. These tables are accessed using a mix of early_memremap(),
early_memunmap(), phys_to_virt() and virt_to_phys(). Change all accesses
to use early_memremap()/early_memunmap(). This allows for proper setting
of the encryption
Boot data (such as EFI related data) is not encrypted when the system is
booted because UEFI/BIOS does not run with SME active. In order to access
this data properly it needs to be mapped decrypted.
Update early_memremap() to provide an arch specific routine to modify the
pagetable protection attr
When SME is active, pagetable entries created for EFI need to have the
encryption mask set as necessary.
When the new pagetable pages are allocated they are mapped encrypted. So,
update the efi_pgt value that will be used in cr3 to include the encryption
mask so that the PGD table can be read succ
The efi_mem_type() function currently returns a 0, which maps to
EFI_RESERVED_TYPE, if the function is unable to find a memmap entry for
the supplied physical address. Returning EFI_RESERVED_TYPE implies that
a memmap entry exists, when it doesn't. Instead of returning 0, change
the function to re
Add a function that will return the E820 type associated with an address
range.
Reviewed-by: Borislav Petkov
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/e820/api.h |2 ++
arch/x86/kernel/e820.c | 26 +++---
2 files changed, 25 insertions(+), 3 deletio
Add a function that will determine if a supplied physical address matches
the address of an EFI table.
Reviewed-by: Matt Fleming
Reviewed-by: Borislav Petkov
Signed-off-by: Tom Lendacky
---
drivers/firmware/efi/efi.c | 33 +
include/linux/efi.h|7 +
Add support to be able to either encrypt or decrypt data in place during
the early stages of booting the kernel. This does not change the memory
encryption attribute - it is used for ensuring that data present in either
an encrypted or decrypted memory area is in the proper state (for example
the i
The cr3 register entry can contain the SME encryption mask that indicates
the PGD is encrypted. The encryption mask should not be used when
creating a virtual address from the cr3 register, so remove the SME
encryption mask in the read_cr3_pa() function.
During early boot SME will need to use a n
The boot data and command line data are present in memory in a decrypted
state and are copied early in the boot process. The early page fault
support will map these areas as encrypted, so before attempting to copy
them, add decrypted mappings so the data is accessed properly when copied.
For the
Create a pgd_pfn() macro similar to the p[4um]d_pfn() macros and then
use the p[g4um]d_pfn() macros in the p[g4um]d_page() macros instead of
duplicating the code.
Reviewed-by: Borislav Petkov
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/pgtable.h | 16 +---
1 file changed,
Add early_memremap() support to be able to specify encrypted and
decrypted mappings with and without write-protection. The use of
write-protection is necessary when encrypting data "in place". The
write-protect attribute is considered cacheable for loads, but not
stores. This implies that the hardw
Changes to the existing page table macros will allow the SME support to
be enabled in a simple fashion with minimal changes to files that use these
macros. Since the memory encryption mask will now be part of the regular
pagetable macros, we introduce two new macros (_PAGE_TABLE_NOENC and
_KERNPG_
Add support to the early boot code to use Secure Memory Encryption (SME).
Since the kernel has been loaded into memory in a decrypted state, encrypt
the kernel in place and update the early pagetables with the memory
encryption mask so that new pagetable entries will use memory encryption.
The rou
Currently there is a check if the address being mapped is in the ISA
range (is_ISA_range()), and if it is, then phys_to_virt() is used to
perform the mapping. When SME is active, the default is to add pagetable
mappings with the encryption bit set unless specifically overridden. The
resulting paget
When System Memory Encryption (SME) is enabled, the physical address
space is reduced. Adjust the x86_phys_bits value to reflect this
reduction.
Reviewed-by: Borislav Petkov
Signed-off-by: Tom Lendacky
---
arch/x86/kernel/cpu/amd.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions
Add support for Secure Memory Encryption (SME). This initial support
provides a Kconfig entry to build the SME support into the kernel and
defines the memory encryption mask that will be used in subsequent
patches to mark pages as encrypted.
Reviewed-by: Borislav Petkov
Signed-off-by: Tom Lendack
Update the CPU features to include identifying and reporting on the
Secure Memory Encryption (SME) feature. SME is identified by CPUID
0x801f, but requires BIOS support to enable it (set bit 23 of
MSR_K8_SYSCFG). Only show the SME feature as available if reported by
CPUID and enabled by BIOS.
The ioremap() function is intended for mapping MMIO. For RAM, the
memremap() function should be used. Convert calls from ioremap() to
memremap() when re-mapping RAM.
This will be used later by SME to control how the encryption mask is
applied to memory mappings, with certain memory locations being
This patch series provides support for AMD's new Secure Memory Encryption (SME)
feature.
SME can be used to mark individual pages of memory as encrypted through the
page tables. A page of memory that is marked encrypted will be automatically
decrypted when read from DRAM and will be automatically
1 - 100 of 139 matches
Mail list logo
