On Tue, 16 Jul 2019 at 02:55, Jordan Niethe wrote:
>
> Currently the reserved bits of the Processor Compatibility Register
> (PCR) are cleared as per the Programming Note in Section 1.3.3 of the
> ISA. An update is planned for the ISA so that PCR reserved bits should
> be set. Set the reserved
It always returns 0 (success) and its return type should really be void.
Over that, many drivers have added error handling code based on its
return value, which is not required at all.
change its return type to void and update all the callers.
Signed-off-by: Viresh Kumar
---
V2->V3:
- Update
On Mon, Jul 15, 2019 at 06:56:12PM +1000, Oliver O'Halloran wrote:
> The eeh_sysfs_remove_device() function is supposed to clear the
> EEH_DEV_SYSFS flag since it indicates the EEH sysfs entries have been added
> for a pci_dev.
>
> When the sysfs files are removed eeh_remove_device() the eeh_dev
On Mon, Jul 15, 2019 at 06:56:11PM +1000, Oliver O'Halloran wrote:
> In eeh_notify_resume_show() the pci_dn for the device is looked up once in
> the declaration block and then once after checking for a NULL eeh_dev.
> Remove the second lookup since it's pointless.
>
> Signed-off-by: Oliver
On Mon, Jul 15, 2019 at 06:56:10PM +1000, Oliver O'Halloran wrote:
> There are several EEH sysfs properties that only exists when the
> "ibm,is-open-sriov-pf" property appears in the device tree node of the PCI
> device. This used on pseries to indicate to the guest that the hypervisor
> allows
On Mon, Jul 15, 2019 at 06:56:09PM +1000, Oliver O'Halloran wrote:
> The EEH_ATTR_SHOW() helper is used to display fields from struct eeh_dev
> not struct pci_dn.
>
> Signed-off-by: Oliver O'Halloran
Good.
Reviewed-by: Sam Bobroff
> ---
> arch/powerpc/kernel/eeh_sysfs.c | 2 +-
> 1 file
On Mon, Jul 15, 2019 at 06:56:08PM +1000, Oliver O'Halloran wrote:
> At the point where we start inserting ranges into the EEH address cache the
> binding between pci_dev and eeh_dev has already been set up. Instead of
> consulting the pci_dn tree we can retrieve the eeh_dev directly using
>
"Aneesh Kumar K.V" writes:
> This is similar to what ACPI does. Nvdimm layer doesn't bring the SCM device
> numa node online. Hence we need to make sure we always use an online node
> as ndr_desc.numa_node. Otherwise this result in kernel crashes. The target
> node is used by dax/kmem and that
Currently the reserved bits of the Processor Compatibility Register
(PCR) are cleared as per the Programming Note in Section 1.3.3 of the
ISA. An update is planned for the ISA so that PCR reserved bits should
be set. Set the reserved bits of the PCR as required.
Acked-by: Alistair Popple
On Mon, 2019-07-15 at 19:03 -0300, Thiago Jung Bauermann wrote:
> > > Indeed. The idea is that QEMU can offer the flag, old guests can
> > > reject
> > > it (or even new guests can reject it, if they decide not to
> > > convert into
> > > secure VMs) and the feature negotiation will succeed with
Michael S. Tsirkin writes:
> On Mon, Jul 15, 2019 at 07:03:03PM -0300, Thiago Jung Bauermann wrote:
>>
>> Michael S. Tsirkin writes:
>>
>> > On Mon, Jul 15, 2019 at 05:29:06PM -0300, Thiago Jung Bauermann wrote:
>> >>
>> >> Michael S. Tsirkin writes:
>> >>
>> >> > On Sun, Jul 14, 2019 at
On Mon, Jul 15, 2019 at 07:03:03PM -0300, Thiago Jung Bauermann wrote:
>
> Michael S. Tsirkin writes:
>
> > On Mon, Jul 15, 2019 at 05:29:06PM -0300, Thiago Jung Bauermann wrote:
> >>
> >> Michael S. Tsirkin writes:
> >>
> >> > On Sun, Jul 14, 2019 at 02:51:18AM -0300, Thiago Jung Bauermann
Michael S. Tsirkin writes:
> On Mon, Jul 15, 2019 at 05:29:06PM -0300, Thiago Jung Bauermann wrote:
>>
>> Michael S. Tsirkin writes:
>>
>> > On Sun, Jul 14, 2019 at 02:51:18AM -0300, Thiago Jung Bauermann wrote:
>> >>
>> >>
>> >> Michael S. Tsirkin writes:
>> >>
>> >> > So this is what I
On Mon, Jul 15, 2019 at 05:29:06PM -0300, Thiago Jung Bauermann wrote:
>
> Michael S. Tsirkin writes:
>
> > On Sun, Jul 14, 2019 at 02:51:18AM -0300, Thiago Jung Bauermann wrote:
> >>
> >>
> >> Michael S. Tsirkin writes:
> >>
> >> > So this is what I would call this option:
> >> >
> >> >
Michael S. Tsirkin writes:
> On Sun, Jul 14, 2019 at 02:51:18AM -0300, Thiago Jung Bauermann wrote:
>>
>>
>> Michael S. Tsirkin writes:
>>
>> > So this is what I would call this option:
>> >
>> > VIRTIO_F_ACCESS_PLATFORM_IDENTITY_ADDRESS
>> >
>> > and the explanation should state that all
Christoph Hellwig writes:
> On Mon, Jul 15, 2019 at 04:03:17PM +0200, Halil Pasic wrote:
>> > I thought about that but couldn't put my finger on a general concept.
>> > Is it "guest with memory inaccessible to the host"?
>> >
>>
>> Well, force_dma_unencrypted() is a much better name thatn
Hello Janani,
Thanks for reviewing the patch.
janani writes:
> On 2019-07-12 23:45, Thiago Jung Bauermann wrote:
>> powerpc is also going to use this feature, so put it in a generic location.
>>
>> Signed-off-by: Thiago Jung Bauermann
>> Reviewed-by: Thomas Gleixner
>> ---
>> arch/Kconfig
On Thu, 11 Jul 2019, Hoan Tran OS wrote:
> Remove CONFIG_NODES_SPAN_OTHER_NODES as it's enabled
> by default with NUMA.
As I told you before this does not mention that the option is now enabled
even for x86(32bit) configurations which did not enable it before and does
not longer depend on
On Thu, 2019-07-11 at 14:53 +1000, Michael Ellerman wrote:
> Hi Maddy,
>
> Madhavan Srinivasan writes:
> > diff --git a/arch/powerpc/platforms/powernv/opal-imc.c
> > b/arch/powerpc/platforms/powernv/opal-imc.c
> > index 186109bdd41b..e04b20625cb9 100644
> > ---
At the beginning of setup_64.c, it has,
#ifdef DEBUG
#define DBG(fmt...) udbg_printf(fmt)
#else
#define DBG(fmt...)
#endif
where DBG() could be compiled away, and generate warnings,
arch/powerpc/kernel/setup_64.c: In function 'initialize_cache_info':
On Mon, Jul 15, 2019 at 09:03:46PM +0900, Masahiro Yamada wrote:
> On Mon, Jul 15, 2019 at 4:30 PM Segher Boessenkool
> wrote:
> >
> > On Mon, Jul 15, 2019 at 05:05:34PM +1000, Michael Ellerman wrote:
> > > Segher Boessenkool writes:
> > > > Yes, that is why I used the environment variable, all
Hi,
On 7/12/19 10:00 PM, Michal Hocko wrote:
> On Fri 12-07-19 15:37:30, Will Deacon wrote:
>> Hi all,
>>
>> On Fri, Jul 12, 2019 at 02:12:23PM +0200, Michal Hocko wrote:
>>> On Fri 12-07-19 10:56:47, Hoan Tran OS wrote:
>>> [...]
It would be good if we can enable it by-default. Otherwise,
Michael Ellerman a écrit :
Christophe Leroy writes:
PPC32 also have flush_dcache_range() so it can also support
ARCH_HAS_PMEM_API and ARCH_HAS_UACCESS_FLUSHCACHE without changes.
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2
On 7/15/19 9:30 AM, Christoph Hellwig wrote:
> On Mon, Jul 15, 2019 at 04:03:17PM +0200, Halil Pasic wrote:
>>> I thought about that but couldn't put my finger on a general concept.
>>> Is it "guest with memory inaccessible to the host"?
>>>
>>
>> Well, force_dma_unencrypted() is a much better
On 2019-07-12 23:45, Thiago Jung Bauermann wrote:
powerpc is also going to use this feature, so put it in a generic
location.
Signed-off-by: Thiago Jung Bauermann
Reviewed-by: Thomas Gleixner
---
arch/Kconfig | 3 +++
arch/s390/Kconfig | 3 ---
arch/x86/Kconfig | 4 +---
3 files
On Sun, Jul 14, 2019 at 02:51:18AM -0300, Thiago Jung Bauermann wrote:
>
>
> Michael S. Tsirkin writes:
>
> > On Thu, Jun 27, 2019 at 10:58:40PM -0300, Thiago Jung Bauermann wrote:
> >>
> >> Michael S. Tsirkin writes:
> >>
> >> > On Mon, Jun 03, 2019 at 10:13:59PM -0300, Thiago Jung Bauermann
On Mon, Jul 15, 2019 at 04:03:17PM +0200, Halil Pasic wrote:
> > I thought about that but couldn't put my finger on a general concept.
> > Is it "guest with memory inaccessible to the host"?
> >
>
> Well, force_dma_unencrypted() is a much better name thatn sev_active():
> s390 has no AMD SEV,
On Mon, Jul 15, 2019 at 03:56:04PM +0200, Christian Borntraeger wrote:
> I think Vasily already has a clone3 patch for s390x with 435.
Excellent. I'll leave the # 435 reserved for clone3 on s390x in until
this patch has landed. It shouldn't be a merge conflict and if so it
should be trivial.
On Fri, 12 Jul 2019 18:55:47 -0300
Thiago Jung Bauermann wrote:
>
> [ Cc'ing Tom Lendacky which I forgot to do earlier. Sorry about that. ]
>
> Hello Halil,
>
> Thanks for the quick review.
>
> Halil Pasic writes:
>
> > On Fri, 12 Jul 2019 02:36:31 -0300
> > Thiago Jung Bauermann wrote:
>
I think Vasily already has a clone3 patch for s390x with 435.
On 14.07.19 21:22, Christian Brauner wrote:
> A while ago Arnd made it possible to give new system calls the same
> syscall number on all architectures (except alpha). To not break this
> nice new feature let's mark 435 for clone3 as
On Mon, Jul 15, 2019 at 06:43:12PM +1000, Alexey Kardashevskiy wrote:
> > e.g. if you have a DMA that supports 40-bit DMA addressing we could
> > always treat it as if supports 32-bit addressing,and I thought the
> > powerpc code does that,
>
> powerpc does that and this is what the patchset is
On Mon, Jul 15, 2019 at 06:33:00PM +1000, Alexey Kardashevskiy wrote:
>
>
> On 13/07/2019 01:20, Christoph Hellwig wrote:
> > > This skips the 32bit DMA setup check if the bypass is can be selected.
> >
> > That sentence does not parse. I think you need to dop the "can be"
> > based on the
On Mon, Jul 15, 2019 at 4:30 PM Segher Boessenkool
wrote:
>
> On Mon, Jul 15, 2019 at 05:05:34PM +1000, Michael Ellerman wrote:
> > Segher Boessenkool writes:
> > > Yes, that is why I used the environment variable, all binutils work
> > > with that. There was no --target option in GNU ar before
On 01.07.19 12:27, Michal Hocko wrote:
> On Mon 01-07-19 11:36:44, Oscar Salvador wrote:
>> On Mon, Jul 01, 2019 at 10:51:44AM +0200, Michal Hocko wrote:
>>> Yeah, we do not allow to offline multi zone (node) ranges so the current
>>> code seems to be over engineered.
>>>
>>> Anyway, I am
On 01.07.19 10:41, Michal Hocko wrote:
> On Mon 27-05-19 13:11:50, David Hildenbrand wrote:
>> Let's factor out removing of memory block devices, which is only
>> necessary for memory added via add_memory() and friends that created
>> memory block devices. Remove the devices before calling
>>
On 01.07.19 14:51, Michal Hocko wrote:
> On Mon 01-07-19 10:01:41, Michal Hocko wrote:
>> On Mon 27-05-19 13:11:47, David Hildenbrand wrote:
>>> We want to improve error handling while adding memory by allowing
>>> to use arch_remove_memory() and __remove_pages() even if
>>>
On 01.07.19 14:46, Michal Hocko wrote:
> On Mon 01-07-19 09:43:06, Michal Hocko wrote:
>> On Mon 27-05-19 13:11:43, David Hildenbrand wrote:
>>> ZONE_DEVICE is not yet supported, fail if an altmap is passed, so we
>>> don't forget arch_add_memory()/arch_remove_memory() when unlocking
>>> support.
On 01.07.19 14:47, Michal Hocko wrote:
> On Mon 01-07-19 09:45:03, Michal Hocko wrote:
>> On Mon 27-05-19 13:11:44, David Hildenbrand wrote:
>>> Will come in handy when wanting to handle errors after
>>> arch_add_memory().
>>
>> I do not understand this. Why do you add a code for something that is
The eeh_sysfs_remove_device() function is supposed to clear the
EEH_DEV_SYSFS flag since it indicates the EEH sysfs entries have been added
for a pci_dev.
When the sysfs files are removed eeh_remove_device() the eeh_dev and the
pci_dev have already been de-associated. This then causes the
In eeh_notify_resume_show() the pci_dn for the device is looked up once in
the declaration block and then once after checking for a NULL eeh_dev.
Remove the second lookup since it's pointless.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/kernel/eeh_sysfs.c | 1 -
1 file changed, 1
There are several EEH sysfs properties that only exists when the
"ibm,is-open-sriov-pf" property appears in the device tree node of the PCI
device. This used on pseries to indicate to the guest that the hypervisor
allows the guest to configure the SR-IOV capability. Doing this requires
some
The EEH_ATTR_SHOW() helper is used to display fields from struct eeh_dev
not struct pci_dn.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/kernel/eeh_sysfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/eeh_sysfs.c b/arch/powerpc/kernel/eeh_sysfs.c
At the point where we start inserting ranges into the EEH address cache the
binding between pci_dev and eeh_dev has already been set up. Instead of
consulting the pci_dn tree we can retrieve the eeh_dev directly using
pci_dev_to_eeh_dev().
Signed-off-by: Oliver O'Halloran
---
Fixes of no particular importance. I just wanted to cut down the pile of
patches I've got hanging around.
On 13/07/2019 01:28, Christoph Hellwig wrote:
On Fri, Jul 12, 2019 at 07:45:05PM +1000, Alexey Kardashevskiy wrote:
This is an attempt to allow DMA masks between 32..59 which are not large
enough to use either a PHB3 bypass mode or a sketchy bypass. Depending
on the max order, up to 40 is
On 13/07/2019 01:20, Christoph Hellwig wrote:
This skips the 32bit DMA setup check if the bypass is can be selected.
That sentence does not parse. I think you need to dop the "can be"
based on the actual patch.
"the 32bit DMA setup check" is
"if (!(tbl = get_iommu_table_base(dev)))".
I
Right now powerpc provides an implementation to read elf files
with the kexec_file() syscall. Make that available as a public
kexec interface so it can be re-used on other architectures.
Signed-off-by: Sven Schnelle
---
arch/Kconfig | 3 +
arch/powerpc/Kconfig
Changes to v3:
- add support for 32-bit ELF files
Changes to v2:
- use git format-patch -C
Changes to v1:
- split up patch into smaller pieces
- rebase onto powerpc/next
- remove unused variable in kexec_elf_load()
Changes to RFC version:
- remove unused Elf_Rel macro
- remove section
We're not using them, so we can drop the parsing.
Signed-off-by: Sven Schnelle
---
include/linux/kexec.h | 1 -
kernel/kexec_elf.c| 137 --
2 files changed, 138 deletions(-)
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index
Change the order to have a 64/32/16 order, no functional change.
Signed-off-by: Sven Schnelle
---
kernel/kexec_elf.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/kernel/kexec_elf.c b/kernel/kexec_elf.c
index 6e9f52171ede..76e7df64d715 100644
---
It wasn't used anywhere, so lets drop it.
Reviewed-by: Christophe Leroy
Signed-off-by: Sven Schnelle
---
kernel/kexec_elf.c | 4
1 file changed, 4 deletions(-)
diff --git a/kernel/kexec_elf.c b/kernel/kexec_elf.c
index 70d31b8feeae..e346659af324 100644
--- a/kernel/kexec_elf.c
+++
base was never assigned, so we can remove it.
Reviewed-by: Christophe Leroy
Signed-off-by: Sven Schnelle
---
kernel/kexec_elf.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/kernel/kexec_elf.c b/kernel/kexec_elf.c
index e346659af324..9421eebbacf0 100644
---
It's not used anywhere so just drop it.
Signed-off-by: Sven Schnelle
---
kernel/kexec_elf.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/kernel/kexec_elf.c b/kernel/kexec_elf.c
index effe9dc0b055..70d31b8feeae 100644
--- a/kernel/kexec_elf.c
+++ b/kernel/kexec_elf.c
@@ -8,8 +8,6 @@
The powerpc version only supported 64 bit. Add some
code to switch decoding of fields during runtime so
we can kexec a 32 bit kernel from a 64 bit kernel and
vice versa.
Signed-off-by: Sven Schnelle
---
kernel/kexec_elf.c | 57 ++
1 file changed, 42
On Mon, Jul 15, 2019 at 05:05:34PM +1000, Michael Ellerman wrote:
> Segher Boessenkool writes:
> > Yes, that is why I used the environment variable, all binutils work
> > with that. There was no --target option in GNU ar before 2.22.
>
> Yeah, we're not very good at testing with really old
Hi Michael,
On Thu, Jul 11, 2019 at 09:08:51PM +1000, Michael Ellerman wrote:
> Sven Schnelle writes:
> > On Wed, Jul 10, 2019 at 05:09:29PM +0200, Christophe Leroy wrote:
> >> Le 10/07/2019 à 16:29, Sven Schnelle a écrit :
> >> > It had only one definition, so just use the function directly.
>
There is a race between releasing an irq on one cpu and fetching it
from XIVE on another cpu as there does not seem to be any locking between
these, probably because xive_irq_chip::irq_shutdown() is supposed to
remove the irq from all queues in the system which it does not do.
As a result, when
Segher Boessenkool writes:
> On Sun, Jul 14, 2019 at 07:45:15AM +0900, Masahiro Yamada wrote:
>> On Sat, Jul 13, 2019 at 10:17 PM Segher Boessenkool
>> wrote:
>> > On Sat, Jul 13, 2019 at 07:47:44AM -0500, Segher Boessenkool wrote:
>> > > On Sat, Jul 13, 2019 at 12:21:06PM +0900, Masahiro Yamada
On Mon, Jul 15, 2019 at 4:49 PM Michael Ellerman wrote:
>
> Christophe Leroy writes:
> > PPC32 also have flush_dcache_range() so it can also support
> > ARCH_HAS_PMEM_API and ARCH_HAS_UACCESS_FLUSHCACHE without changes.
> >
> > Signed-off-by: Christophe Leroy
> > ---
> > arch/powerpc/Kconfig |
Christophe Leroy writes:
> PPC32 also have flush_dcache_range() so it can also support
> ARCH_HAS_PMEM_API and ARCH_HAS_UACCESS_FLUSHCACHE without changes.
>
> Signed-off-by: Christophe Leroy
> ---
> arch/powerpc/Kconfig | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
Qian Cai writes:
> At the beginning of setup_64.c, it has,
>
> #ifdef DEBUG
> #define DBG(fmt...) udbg_printf(fmt)
> #else
> #define DBG(fmt...)
> #endif
>
> where DBG() could be compiled away, and generate warnings,
>
> arch/powerpc/kernel/setup_64.c: In function
On 7/11/19 10:23 AM, Michael Ellerman wrote:
Hi Maddy,
Madhavan Srinivasan writes:
diff --git a/arch/powerpc/platforms/powernv/opal-imc.c
b/arch/powerpc/platforms/powernv/opal-imc.c
index 186109bdd41b..e04b20625cb9 100644
--- a/arch/powerpc/platforms/powernv/opal-imc.c
+++
62 matches
Mail list logo
