similar to: [PATCH v4 0/7] jailhouse: Enhance secondary Jailhouse guest support /wrt PCI

Basic x86 support [1] for running Linux as secondary Jailhouse [2] guest is currently pending in the tip tree. This builds on top and enhances the PCI support for x86 and also ARM guests (ARM[64] does not require platform patches and works already). Key elements of this series are: - detection of Jailhouse via device tree hypervisor node - function-level PCI scan if Jailhouse is detected -

Basic x86 support [1] for running Linux as secondary Jailhouse [2] guest is currently pending in the tip tree. This builds on top and enhances the PCI support for x86 and also ARM guests (ARM[64] does not require platform patches and works already). Key elements of this series are: - detection of Jailhouse via device tree hypervisor node - function-level PCI scan if Jailhouse is detected -

Basic x86 support [1] for running Linux as secondary Jailhouse [2] guest is currently pending in the tip tree. This builds on top and enhances the PCI support for x86 and also ARM guests (ARM[64] does not require platform patches and works already). Key elements of this series are: - detection of Jailhouse via device tree hypervisor node - function-level PCI scan if Jailhouse is detected -

Basic x86 support [1] for running Linux as secondary Jailhouse [2] guest is currently pending in the tip tree. This builds on top and enhances the PCI support for x86 and also ARM guests (ARM[64] does not require platform patches and works already). Key elements of this series are: - detection of Jailhouse via device tree hypervisor node - function-level PCI scan if Jailhouse is detected -

Basic x86 support [1] for running Linux as secondary Jailhouse [2] guest is currently pending in the tip tree. This builds on top and enhances the PCI support for x86 and also ARM guests (ARM[64] does not require platform patches and works already). Key elements of this series are: - detection of Jailhouse via device tree hypervisor node - function-level PCI scan if Jailhouse is detected -

Basic x86 support [1] for running Linux as secondary Jailhouse [2] guest is currently pending in the tip tree. This builds on top and enhances the PCI support for x86 and also ARM guests (ARM[64] does not require platform patches and works already). Key elements of this series are: - detection of Jailhouse via device tree hypervisor node - function-level PCI scan if Jailhouse is detected -

On Thu, Mar 1, 2018 at 7:40 AM, Jan Kiszka <jan.kiszka at siemens.com> wrote: > Use the PCI mmconfig base address exported by jailhouse in boot > parameters in order to access the memory mapped PCI configuration space. > --- a/arch/x86/kernel/jailhouse.c > +++ b/arch/x86/kernel/jailhouse.c > @@ -124,6 +124,13 @@ static int __init jailhouse_pci_arch_init(void) >

From: Otavio Pontes <otavio.pontes at intel.com> Use the PCI mmconfig base address exported by jailhouse in boot parameters in order to access the memory mapped PCI configuration space. Signed-off-by: Otavio Pontes <otavio.pontes at intel.com> [Jan: rebased, fixed !CONFIG_PCI_MMCONFIG, used pcibios_last_bus] Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com> ---

From: Otavio Pontes <otavio.pontes at intel.com> Use the PCI mmconfig base address exported by jailhouse in boot parameters in order to access the memory mapped PCI configuration space. Signed-off-by: Otavio Pontes <otavio.pontes at intel.com> [Jan: rebased, fixed !CONFIG_PCI_MMCONFIG] Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com> --- arch/x86/include/asm/pci_x86.h | 2

From: Otavio Pontes <otavio.pontes at intel.com> Use the PCI mmconfig base address exported by jailhouse in boot parameters in order to access the memory mapped PCI configuration space. Signed-off-by: Otavio Pontes <otavio.pontes at intel.com> [Jan: rebased, fixed !CONFIG_PCI_MMCONFIG] Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com> --- arch/x86/include/asm/pci_x86.h | 2

From: Otavio Pontes <otavio.pontes at intel.com> Use the PCI mmconfig base address exported by jailhouse in boot parameters in order to access the memory mapped PCI configuration space. Signed-off-by: Otavio Pontes <otavio.pontes at intel.com> [Jan: rebased, fixed !CONFIG_PCI_MMCONFIG] Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com> --- arch/x86/include/asm/pci_x86.h | 2

On Mon, Jan 22, 2018 at 8:12 AM, Jan Kiszka <jan.kiszka at siemens.com> wrote: > #include <linux/export.h> > #include <linux/pci.h> > #include <asm/pci_x86.h> > +#include <asm/jailhouse_para.h> Keep it in order? > #include <linux/acpi.h> > #include <linux/irqdomain.h> > #include <linux/pm_runtime.h> > +#include

On Mon, Jan 22, 2018 at 8:12 AM, Jan Kiszka <jan.kiszka at siemens.com> wrote: > #include <linux/export.h> > #include <linux/pci.h> > #include <asm/pci_x86.h> > +#include <asm/jailhouse_para.h> Keep it in order? > #include <linux/acpi.h> > #include <linux/irqdomain.h> > #include <linux/pm_runtime.h> > +#include

On Wed, 28 Feb 2018, Jan Kiszka wrote: > From: Jan Kiszka <jan.kiszka at siemens.com> > > Per PCIe r4.0, sec 7.5.1.1.9, multi-function devices are required to > have a function 0. Therefore, Linux scans for devices at function 0 > (devfn 0/8/16/...) and only scans for other functions if function 0 > has its Multi-Function Device bit set or ARI or SR-IOV indicate >

On 2014-06-13 10:45, Paolo Bonzini wrote: > Il 13/06/2014 08:23, Jan Kiszka ha scritto: >>>> That would preserve zero-copy capabilities (as long as you can work >>>> against the shared mem directly, e.g. doing DMA from a physical NIC or >>>> storage device into it) and keep the hypervisor out of the loop. >> > >> > This seems ill thought

On 2014-06-13 10:45, Paolo Bonzini wrote: > Il 13/06/2014 08:23, Jan Kiszka ha scritto: >>>> That would preserve zero-copy capabilities (as long as you can work >>>> against the shared mem directly, e.g. doing DMA from a physical NIC or >>>> storage device into it) and keep the hypervisor out of the loop. >> > >> > This seems ill thought

On 2014-06-13 02:47, Rusty Russell wrote: > Jan Kiszka <jan.kiszka at siemens.com> writes: >> On 2014-06-12 04:27, Rusty Russell wrote: >>> Henning Schild <henning.schild at siemens.com> writes: >>> It was also never implemented, and remains a thought experiment. >>> However, implementing it in lguest should be fairly easy. >> >> The

On 2014-06-13 02:47, Rusty Russell wrote: > Jan Kiszka <jan.kiszka at siemens.com> writes: >> On 2014-06-12 04:27, Rusty Russell wrote: >>> Henning Schild <henning.schild at siemens.com> writes: >>> It was also never implemented, and remains a thought experiment. >>> However, implementing it in lguest should be fairly easy. >> >> The

On 2015-09-01 10:01, Michael S. Tsirkin wrote: > On Tue, Sep 01, 2015 at 09:35:21AM +0200, Jan Kiszka wrote: >> Leaving all the implementation and interface details aside, this >> discussion is first of all about two fundamentally different approaches: >> static shared memory windows vs. dynamically remapped shared windows (a >> third one would be copying in the

On 2015-09-01 10:01, Michael S. Tsirkin wrote: > On Tue, Sep 01, 2015 at 09:35:21AM +0200, Jan Kiszka wrote: >> Leaving all the implementation and interface details aside, this >> discussion is first of all about two fundamentally different approaches: >> static shared memory windows vs. dynamically remapped shared windows (a >> third one would be copying in the