Re: [PATCH v1 6/6] device property: Switch to use new generic UUID API

2017-07-25 Thread Andy Shevchenko 
On Wed, Jul 26, 2017 at 3:21 AM, Rafael J. Wysocki  wrote:
> On Tuesday, July 25, 2017 05:12:35 PM Mika Westerberg wrote:
>> On Wed, Jul 19, 2017 at 09:28:57PM +0300, Andy Shevchenko wrote:
>> > There are new types and helpers that are supposed to be used in new code.
>> >
>> > As a preparation to get rid of legacy types and API functions do
>> > the conversion here.
>> >
>> > Cc: "Rafael J. Wysocki" 
>> > Cc: Mika Westerberg 
>>
>> Acked-by: Mika Westerberg 
>
> OK
>
> Andy, do you want me to apply this?

If you would like to.

The patch is now pretty independent since necessary stuff made v4.13-rc1.

-- 
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 6/6] device property: Switch to use new generic UUID API

2017-07-25 Thread Rafael J. Wysocki 
On Wednesday, July 26, 2017 03:35:01 AM Andy Shevchenko wrote:
> On Wed, Jul 26, 2017 at 3:21 AM, Rafael J. Wysocki  wrote:
> > On Tuesday, July 25, 2017 05:12:35 PM Mika Westerberg wrote:
> >> On Wed, Jul 19, 2017 at 09:28:57PM +0300, Andy Shevchenko wrote:
> >> > There are new types and helpers that are supposed to be used in new code.
> >> >
> >> > As a preparation to get rid of legacy types and API functions do
> >> > the conversion here.
> >> >
> >> > Cc: "Rafael J. Wysocki" 
> >> > Cc: Mika Westerberg 
> >>
> >> Acked-by: Mika Westerberg 
> >
> > OK
> >
> > Andy, do you want me to apply this?
> 
> If you would like to.
> 
> The patch is now pretty independent since necessary stuff made v4.13-rc1.

OK

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 6/6] device property: Switch to use new generic UUID API

2017-07-25 Thread Rafael J. Wysocki 
On Tuesday, July 25, 2017 05:12:35 PM Mika Westerberg wrote:
> On Wed, Jul 19, 2017 at 09:28:57PM +0300, Andy Shevchenko wrote:
> > There are new types and helpers that are supposed to be used in new code.
> > 
> > As a preparation to get rid of legacy types and API functions do
> > the conversion here.
> > 
> > Cc: "Rafael J. Wysocki" 
> > Cc: Mika Westerberg 
> 
> Acked-by: Mika Westerberg 

OK

Andy, do you want me to apply this?

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC Part1 PATCH v3 02/17] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature

2017-07-25 Thread Borislav Petkov 
On Tue, Jul 25, 2017 at 10:29:40AM -0500, Tom Lendacky wrote:
> But early_identify_cpu() calls get_cpu_cap() which will check for cpuid
> leaf 0x8008 support and set x86_phys_bits.

Right, but it can't be less than 32, can it? And if it is more than 32
bits, then it probably doesn't really matter on 32-bit. Unless it is
less than 36 bits and you do PAE...

> I'll try to build and run a 32-bit kernel and see how this all flows.

Yeah, that would be good.

Thanks.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC Part1 PATCH v3 02/17] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature

2017-07-25 Thread Borislav Petkov 
On Tue, Jul 25, 2017 at 09:58:54AM -0500, Tom Lendacky wrote:
> True, but it is more about being accurate and making sure the value is
> correct where ever it may be used.

So early_identify_cpu() initializes phys_bits to 32 on 32-bit.
Subtracting it there would actually make actively it wrong, AFAICT.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 1/6] efi: Switch to use new generic UUID API

2017-07-25 Thread Andy Shevchenko 
On Thu, 2017-07-20 at 13:18 +0100, Ard Biesheuvel wrote:
> On 19 July 2017 at 19:28, Andy Shevchenko
>  wrote:
> > There are new types and helpers that are supposed to be used in new
> > code.
> > 
> > As a preparation to get rid of legacy types and API functions do
> > the conversion here.
> > 
> > Cc: Matt Fleming 
> > Cc: Ard Biesheuvel 
> > Signed-off-by: Andy Shevchenko 
> 
> Acked-by: Ard Biesheuvel 


Thanks!

Christoph, can we apply this one at least to move things forward?

> 
> > ---
> >  drivers/firmware/efi/cper.c | 10 ++---
> >  include/linux/cper.h| 94 ++--
> > -
> >  include/linux/efi.h |  4 +-
> >  3 files changed, 54 insertions(+), 54 deletions(-)
> > 
> > diff --git a/drivers/firmware/efi/cper.c
> > b/drivers/firmware/efi/cper.c
> > index 48a8f69da42a..684e65c11dde 100644
> > --- a/drivers/firmware/efi/cper.c
> > +++ b/drivers/firmware/efi/cper.c
> > @@ -534,7 +534,7 @@ static void
> >  cper_estatus_print_section(const char *pfx, struct
> > acpi_hest_generic_data *gdata,
> >    int sec_no)
> >  {
> > -   uuid_le *sec_type = (uuid_le *)gdata->section_type;
> > +   guid_t *sec_type = (guid_t *)gdata->section_type;
> > __u16 severity;
> > char newpfx[64];
> > 
> > @@ -545,12 +545,12 @@ cper_estatus_print_section(const char *pfx,
> > struct acpi_hest_generic_data *gdata
> > printk("%s""Error %d, type: %s\n", pfx, sec_no,
> >    cper_severity_str(severity));
> > if (gdata->validation_bits & CPER_SEC_VALID_FRU_ID)
> > -   printk("%s""fru_id: %pUl\n", pfx, (uuid_le *)gdata-
> > >fru_id);
> > +   printk("%s""fru_id: %pUl\n", pfx, gdata->fru_id);
> > if (gdata->validation_bits & CPER_SEC_VALID_FRU_TEXT)
> > printk("%s""fru_text: %.20s\n", pfx, gdata-
> > >fru_text);
> > 
> > snprintf(newpfx, sizeof(newpfx), "%s%s", pfx, INDENT_SP);
> > -   if (!uuid_le_cmp(*sec_type, CPER_SEC_PROC_GENERIC)) {
> > +   if (guid_equal(sec_type, _SEC_PROC_GENERIC)) {
> > struct cper_sec_proc_generic *proc_err =
> > acpi_hest_get_payload(gdata);
> > 
> > printk("%s""section_type: general processor
> > error\n", newpfx);
> > @@ -558,7 +558,7 @@ cper_estatus_print_section(const char *pfx,
> > struct acpi_hest_generic_data *gdata
> > cper_print_proc_generic(newpfx, proc_err);
> > else
> > goto err_section_too_small;
> > -   } else if (!uuid_le_cmp(*sec_type, CPER_SEC_PLATFORM_MEM)) {
> > +   } else if (guid_equal(sec_type, _SEC_PLATFORM_MEM)) {
> > struct cper_sec_mem_err *mem_err =
> > acpi_hest_get_payload(gdata);
> > 
> > printk("%s""section_type: memory error\n", newpfx);
> > @@ -568,7 +568,7 @@ cper_estatus_print_section(const char *pfx,
> > struct acpi_hest_generic_data *gdata
> >    gdata->error_data_length);
> > else
> > goto err_section_too_small;
> > -   } else if (!uuid_le_cmp(*sec_type, CPER_SEC_PCIE)) {
> > +   } else if (guid_equal(sec_type, _SEC_PCIE)) {
> > struct cper_sec_pcie *pcie =
> > acpi_hest_get_payload(gdata);
> > 
> > printk("%s""section_type: PCIe error\n", newpfx);
> > diff --git a/include/linux/cper.h b/include/linux/cper.h
> > index 4c671fc2081e..723e952fde0d 100644
> > --- a/include/linux/cper.h
> > +++ b/include/linux/cper.h
> > @@ -74,36 +74,36 @@ enum {
> >   * Corrected Machine Check
> >   */
> >  #define
> > CPER_NOTIFY_CMC 
> >    \
> > -   UUID_LE(0x2DCE8BB1, 0xBDD7, 0x450e, 0xB9, 0xAD, 0x9C,
> > 0xF4, \
> > -   0xEB, 0xD4, 0xF8, 0x90)
> > +   GUID_INIT(0x2DCE8BB1, 0xBDD7, 0x450e, 0xB9, 0xAD, 0x9C,
> > 0xF4,   \
> > + 0xEB, 0xD4, 0xF8, 0x90)
> >  /* Corrected Platform Error */
> >  #define
> > CPER_NOTIFY_CPE 
> >    \
> > -   UUID_LE(0x4E292F96, 0xD843, 0x4a55, 0xA8, 0xC2, 0xD4,
> > 0x81, \
> > -   0xF2, 0x7E, 0xBE, 0xEE)
> > +   GUID_INIT(0x4E292F96, 0xD843, 0x4a55, 0xA8, 0xC2, 0xD4,
> > 0x81,   \
> > + 0xF2, 0x7E, 0xBE, 0xEE)
> >  /* Machine Check Exception */
> >  #define
> > CPER_NOTIFY_MCE 
> >    \
> > -   UUID_LE(0xE8F56FFE, 0x919C, 0x4cc5, 0xBA, 0x88, 0x65,
> > 0xAB, \
> > -   0xE1, 0x49, 0x13, 0xBB)
> > +   GUID_INIT(0xE8F56FFE, 0x919C, 0x4cc5, 0xBA, 0x88, 0x65,
> > 0xAB,   \
> > + 0xE1, 0x49, 0x13, 0xBB)
> >  /* PCI Express Error */
> >  #define
> > CPER_NOTIFY_PCIE   \
>

RE: [RFC Part1 PATCH v3 13/17] x86/io: Unroll string I/O when SEV is active

2017-07-25 Thread David Laight 
From: Brijesh Singh
> Sent: 24 July 2017 20:08
> From: Tom Lendacky 
> 
> Secure Encrypted Virtualization (SEV) does not support string I/O, so
> unroll the string I/O operation into a loop operating on one element at
> a time.
> 
> Signed-off-by: Tom Lendacky 
> Signed-off-by: Brijesh Singh 
> ---
>  arch/x86/include/asm/io.h | 26 ++
>  1 file changed, 22 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
> index e080a39..2f3c002 100644
> --- a/arch/x86/include/asm/io.h
> +++ b/arch/x86/include/asm/io.h
> @@ -327,14 +327,32 @@ static inline unsigned type in##bwl##_p(int port)   
> \
>   \
>  static inline void outs##bwl(int port, const void *addr, unsigned long 
> count) \
>  {

Is it even worth leaving these as inline functions?
Given the speed of IO cycles it is unlikely that the cost of calling a real
function will be significant.
The code bloat reduction will be significant.

David

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html