On 30.04.20 13:11, Srivatsa Vaddagiri wrote:
* Will Deacon [2020-04-30 11:41:50]:
On Thu, Apr 30, 2020 at 04:04:46PM +0530, Srivatsa Vaddagiri wrote:
If CONFIG_VIRTIO_MMIO_OPS is defined, then I expect this to be unconditionally
set to 'magic_qcom_ops' that uses hypervisor-supported
On 29.04.20 12:45, Michael S. Tsirkin wrote:
On Wed, Apr 29, 2020 at 12:26:43PM +0200, Jan Kiszka wrote:
On 29.04.20 12:20, Michael S. Tsirkin wrote:
On Wed, Apr 29, 2020 at 03:39:53PM +0530, Srivatsa Vaddagiri wrote:
That would still not work I think where swiotlb is used for pass-thr
On 29.04.20 12:20, Michael S. Tsirkin wrote:
On Wed, Apr 29, 2020 at 03:39:53PM +0530, Srivatsa Vaddagiri wrote:
That would still not work I think where swiotlb is used for pass-thr devices
(when private memory is fine) as well as virtio devices (when shared memory is
required).
So that is a
On 28.02.20 17:47, Alex Bennée wrote:
Jan Kiszka writes:
On 28.02.20 11:30, Jan Kiszka wrote:
On 28.02.20 11:16, Alex Bennée wrote:
Hi,
I believe there has been some development work for supporting VIRTIO on
Xen although it seems to have stalled according to:
https
On 28.02.20 11:30, Jan Kiszka wrote:
On 28.02.20 11:16, Alex Bennée wrote:
Hi,
I'm currently trying to get my head around virtio and was wondering how
widespread adoption of virtio is amongst the various hypervisors and
emulators out there.
Obviously I'm familiar with QEMU both via KVM
On 28.02.20 11:16, Alex Bennée wrote:
Hi,
I'm currently trying to get my head around virtio and was wondering how
widespread adoption of virtio is amongst the various hypervisors and
emulators out there.
Obviously I'm familiar with QEMU both via KVM and even when just doing
plain emulation
On 13.10.19 14:20, Michael S. Tsirkin wrote:
> On Sun, Oct 13, 2019 at 02:01:03PM +0200, Jan Kiszka wrote:
>> On 13.10.19 13:52, Michael S. Tsirkin wrote:
>>> On Sun, Oct 13, 2019 at 11:03:30AM +0200, Jan Kiszka wrote:
>>>> From: Jan Kiszka
>>>>
>>
On 13.10.19 13:52, Michael S. Tsirkin wrote:
> On Sun, Oct 13, 2019 at 11:03:30AM +0200, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> Various changes in the recent kernel versions broke the build due to
>> missing function and header stubs.
>>
>> Signed-of
From: Jan Kiszka
Various changes in the recent kernel versions broke the build due to
missing function and header stubs.
Signed-off-by: Jan Kiszka
---
tools/virtio/crypto/hash.h | 0
tools/virtio/linux/dma-mapping.h | 2 ++
tools/virtio/linux/kernel.h | 2 ++
3 files changed, 4
CONFIG, used pcibios_last_bus]
Signed-off-by: Jan Kiszka <jan.kis...@siemens.com>
Reviewed-by: Andy Shevchenko <andy.shevche...@gmail.com>
---
arch/x86/include/asm/pci_x86.h | 2 ++
arch/x86/kernel/jailhouse.c| 8
arch/x86/pci/mmconfig-shared.c | 4 ++--
3 files changed, 12 in
From: Jan Kiszka <jan.kis...@siemens.com>
Since e279b6c1d329 ("x86: start unification of arch/x86/Kconfig.*"), we
have two PCI_MMCONFIG entries, one from the original i386 and another
from x86_64. This consolidates both entries into a single one.
Signed-off-by: Jan Kiszka <jan
com>
CC: Otavio Pontes <otavio.pon...@intel.com>
CC: Rob Herring <robh...@kernel.org>
Jan Kiszka (6):
jailhouse: Provide detection for non-x86 systems
PCI: Scan all functions when running over Jailhouse
x86: Align x86_64 PCI_MMCONFIG with 32-bit variant
x86: Consolidate PCI_MM
From: Jan Kiszka <jan.kis...@siemens.com>
Jailhouse does not use ACPI, but it does support MMCONFIG. Make sure the
latter can be built without having to enable ACPI as well. Primarily, we
need to make the AMD mmconf-fam10h_64 depend upon MMCONFIG and ACPI,
instead of just the former.
Save
From: Jan Kiszka <jan.kis...@siemens.com>
Allow to enable PCI_MMCONFIG when only SFI is present and make this
option default on. This will help consolidating both into one Kconfig
statement.
Signed-off-by: Jan Kiszka <jan.kis...@siemens.com>
---
arch/x86/Kconfig | 3 ++-
1 fil
From: Jan Kiszka <jan.kis...@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
From: Jan Kiszka <jan.kis...@siemens.com>
Implement jailhouse_paravirt() via device tree probing on architectures
!= x86. Will be used by the PCI core.
CC: Rob Herring <robh...@kernel.org>
CC: Mark Rutland <mark.rutl...@arm.com>
CC: Juergen Gross <jgr...@suse.com>
S
From: Jan Kiszka <jan.kis...@siemens.com>
Signed-off-by: Jan Kiszka <jan.kis...@siemens.com>
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4623caf8d72d..6dc0b8f3ae0e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7523,6 +
From: Jan Kiszka <jan.kis...@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
t;
CC: Rob Herring <robh...@kernel.org>
Jan Kiszka (6):
jailhouse: Provide detection for non-x86 systems
PCI: Scan all functions when running over Jailhouse
x86: Align x86_64 PCI_MMCONFIG with 32-bit variant
x86: Consolidate PCI_MMCONFIG configs
x86/jailhouse: Allow to use PCI_MMCON
CONFIG, used pcibios_last_bus]
Signed-off-by: Jan Kiszka <jan.kis...@siemens.com>
---
arch/x86/include/asm/pci_x86.h | 2 ++
arch/x86/kernel/jailhouse.c| 8
arch/x86/pci/mmconfig-shared.c | 4 ++--
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/pc
From: Jan Kiszka <jan.kis...@siemens.com>
Allow to enable PCI_MMCONFIG when only SFI is present and make this
option default on. This will help consolidating both into one Kconfig
statement.
Signed-off-by: Jan Kiszka <jan.kis...@siemens.com>
---
arch/x86/Kconfig | 3 ++-
1 fil
From: Jan Kiszka <jan.kis...@siemens.com>
Jailhouse does not use ACPI, but it does support MMCONFIG. Make sure the
latter can be built without having to enable ACPI as well. Primarily, we
need to make the AMD mmconf-fam10h_64 depend upon MMCONFIG and ACPI,
instead of just the former.
Save
From: Jan Kiszka <jan.kis...@siemens.com>
Since e279b6c1d329 ("x86: start unification of arch/x86/Kconfig.*"), we
have two PCI_MMCONFIG entries, one from the original i386 and another
from x86_64. This consolidates both entries into a single one.
Signed-off-by: Jan Kiszka <jan
From: Jan Kiszka <jan.kis...@siemens.com>
Implement jailhouse_paravirt() via device tree probing on architectures
!= x86. Will be used by the PCI core.
CC: Rob Herring <robh...@kernel.org>
CC: Mark Rutland <mark.rutl...@arm.com>
CC: Juergen Gross <jgr...@suse.com>
S
From: Jan Kiszka <jan.kis...@siemens.com>
Signed-off-by: Jan Kiszka <jan.kis...@siemens.com>
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4623caf8d72d..6dc0b8f3ae0e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7523,6 +
On 2018-03-01 11:31, Andy Shevchenko wrote:
> On Thu, Mar 1, 2018 at 7:40 AM, Jan Kiszka <jan.kis...@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.
>
From: Jan Kiszka <jan.kis...@siemens.com>
Jailhouse does not use ACPI, but it does support MMCONFIG. Make sure the
latter can be built without having to enable ACPI as well. Primarily, we
need to make the AMD mmconf-fam10h_64 depend upon MMCONFIG and ACPI,
instead of just the former.
Save
<b.spran...@linutronix.de>
CC: Mark Rutland <mark.rutl...@arm.com>
CC: Otavio Pontes <otavio.pon...@intel.com>
CC: Rob Herring <robh...@kernel.org>
Jan Kiszka (5):
jailhouse: Provide detection for non-x86 systems
PCI: Scan all functions when running over Jailhouse
x86:
From: Jan Kiszka <jan.kis...@siemens.com>
Since e279b6c1d329 ("x86: start unification of arch/x86/Kconfig.*"), we
have two PCI_MMCONFIG entries, one from the original i386 and another
from x86_64. This consolidates both entries into a single one.
The logic for x86_32, w
From: Jan Kiszka <jan.kis...@siemens.com>
Implement jailhouse_paravirt() via device tree probing on architectures
!= x86. Will be used by the PCI core.
CC: Rob Herring <robh...@kernel.org>
CC: Mark Rutland <mark.rutl...@arm.com>
Signed-off-by: Jan Kiszka <j
]
Signed-off-by: Jan Kiszka <jan.kis...@siemens.com>
---
arch/x86/include/asm/pci_x86.h | 2 ++
arch/x86/kernel/jailhouse.c| 7 +++
arch/x86/pci/mmconfig-shared.c | 4 ++--
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/a
From: Jan Kiszka <jan.kis...@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
From: Jan Kiszka <jan.kis...@siemens.com>
Signed-off-by: Jan Kiszka <jan.kis...@siemens.com>
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 93a12af4f180..4b889f282c77 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7521,6 +
On 2018-02-28 09:44, Thomas Gleixner wrote:
> On Wed, 28 Feb 2018, Jan Kiszka wrote:
>
>> From: Jan Kiszka <jan.kis...@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 de
From: Jan Kiszka <jan.kis...@siemens.com>
Implement jailhouse_paravirt() via device tree probing on architectures
!= x86. Will be used by the PCI core.
CC: Rob Herring <robh...@kernel.org>
CC: Mark Rutland <mark.rutl...@arm.com>
Signed-off-by: Jan Kiszka <j
lt;robh...@kernel.org>
Jan Kiszka (5):
jailhouse: Provide detection for non-x86 systems
PCI: Scan all functions when running over Jailhouse
x86: Consolidate PCI_MMCONFIG configs
x86/jailhouse: Allow to use PCI_MMCONFIG without ACPI
MAINTAINERS: Add entry for Jailhouse
Otavio Pontes (1):
]
Signed-off-by: Jan Kiszka <jan.kis...@siemens.com>
---
arch/x86/include/asm/pci_x86.h | 2 ++
arch/x86/kernel/jailhouse.c| 7 +++
arch/x86/pci/mmconfig-shared.c | 4 ++--
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/a
From: Jan Kiszka <jan.kis...@siemens.com>
Not sure if those two worked by design or just by chance so far. In any
case, it's at least cleaner and clearer to express this in a single
config statement.
Signed-off-by: Jan Kiszka <jan.kis...@siemens.com>
---
arch/x86/Kconfig | 9 +++--
From: Jan Kiszka <jan.kis...@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
From: Jan Kiszka <jan.kis...@siemens.com>
Jailhouse does not use ACPI, but it does support MMCONFIG. Make sure the
latter can be built without having to enable ACPI as well. Primarily, we
need to make the AMD mmconf-fam10h_64 depend upon MMCONFIG and ACPI,
instead of just the former.
Save
From: Jan Kiszka <jan.kis...@siemens.com>
Signed-off-by: Jan Kiszka <jan.kis...@siemens.com>
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 93a12af4f180..4b889f282c77 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7521,6 +
On 2018-02-22 21:57, Bjorn Helgaas wrote:
> On Mon, Jan 22, 2018 at 07:12:46AM +0100, Jan Kiszka wrote:
>> From: Jan Kiszka <jan.kis...@siemens.com>
>>
>> PCI and PCIBIOS probing only scans devices at function number 0/8/16/...
>> Subdevices (e.g. multiq
On 2018-02-23 14:23, Andy Shevchenko wrote:
> On Mon, Jan 22, 2018 at 8:12 AM, Jan Kiszka <jan.kis...@siemens.com> wrote:
>
>> #include
>> #include
>> #include
>> +#include
>
> Keep it in order?
>
Done.
>
>> #include
>> #
On 2018-01-28 18:26, Andy Shevchenko wrote:
> On Mon, Jan 22, 2018 at 8:12 AM, Jan Kiszka <jan.kis...@siemens.com> wrote:
>> From: Jan Kiszka <jan.kis...@siemens.com>
>>
>> Not sure if those two worked by design or just by chance so far. In any
>> case, it's
From: Jan Kiszka <jan.kis...@siemens.com>
Signed-off-by: Jan Kiszka <jan.kis...@siemens.com>
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 426ba037d943..dd51a2012b36 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7468,6 +
] http://jailhouse-project.org
CC: Benedikt Spranger <b.spran...@linutronix.de>
CC: Mark Rutland <mark.rutl...@arm.com>
CC: Otavio Pontes <otavio.pon...@intel.com>
CC: Rob Herring <robh...@kernel.org>
Jan Kiszka (5):
jailhouse: Provide detection for non-x86 systems
pci:
From: Jan Kiszka <jan.kis...@siemens.com>
Jailhouse does not use ACPI, but it does support MMCONFIG. Make sure the
latter can be built without having to enable ACPI as well. Primarily, we
need to make the AMD mmconf-fam10h_64 depend upon MMCONFIG and ACPI,
instead of just the former.
Save
From: Jan Kiszka <jan.kis...@siemens.com>
Not sure if those two worked by design or just by chance so far. In any
case, it's at least cleaner and clearer to express this in a single
config statement.
Signed-off-by: Jan Kiszka <jan.kis...@siemens.com>
---
arch/x86/Kconfig | 9 +++--
]
Signed-off-by: Jan Kiszka <jan.kis...@siemens.com>
---
arch/x86/include/asm/pci_x86.h | 2 ++
arch/x86/kernel/jailhouse.c| 7 +++
arch/x86/pci/mmconfig-shared.c | 4 ++--
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/a
From: Jan Kiszka <jan.kis...@siemens.com>
Implement jailhouse_paravirt() via device tree probing on architectures
!= x86. Will be used by the PCI core.
CC: Rob Herring <robh...@kernel.org>
CC: Mark Rutland <mark.rutl...@arm.com>
Signed-off-by: Jan Kiszka <j
From: Jan Kiszka <jan.kis...@siemens.com>
PCI and PCIBIOS probing only scans devices at function number 0/8/16/...
Subdevices (e.g. multiqueue) have function numbers which are not a
multiple of 8.
The simple hypervisor Jailhouse passes subdevices directly w/o providing
a virtual PCI to
On 2015-11-10 03:18, Andy Lutomirski wrote:
> On Mon, Nov 9, 2015 at 6:04 PM, Benjamin Herrenschmidt
>> I thus go back to my original statement, it's a LOT easier to handle if
>> the device itself is self describing, indicating whether it is set to
>> bypass a host iommu or not. For L1->L2, well,
On 2015-09-18 23:11, Paolo Bonzini wrote:
> On 18/09/2015 18:29, Claudio Fontana wrote:
>>
>> this is a first RFC for virtio-peer 0.1, which is still very much a work in
>> progress:
>>
>> https://github.com/hw-claudio/virtio-peer/wiki
>>
>> It is also available as PDF there, but the text is
On 2015-09-21 14:13, Michael S. Tsirkin wrote:
> On Fri, Sep 18, 2015 at 06:29:27PM +0200, Claudio Fontana wrote:
>> Hello,
>>
>> this is a first RFC for virtio-peer 0.1, which is still very much a work in
>> progress:
>>
>> https://github.com/hw-claudio/virtio-peer/wiki
>>
>> It is also
On 2015-09-03 10:08, Michael S. Tsirkin wrote:
> On Tue, Sep 01, 2015 at 06:28:28PM +0200, Jan Kiszka wrote:
>> On 2015-09-01 18:02, Michael S. Tsirkin wrote:
>>> On Tue, Sep 01, 2015 at 05:34:37PM +0200, Jan Kiszka wrote:
>>>> On 2015-09-01 16:34, Michael S. Tsirk
On 2015-09-03 10:37, Michael S. Tsirkin wrote:
> On Thu, Sep 03, 2015 at 10:21:28AM +0200, Jan Kiszka wrote:
>> On 2015-09-03 10:08, Michael S. Tsirkin wrote:
>>>
>>> IOW if you wish, you actually can create a shared memory device,
>>> make it accessible to the
On 2015-08-31 16:11, Michael S. Tsirkin wrote:
> Hello!
> During the KVM forum, we discussed supporting virtio on top
> of ivshmem.
No, not on top of ivshmem. On top of shared memory. Our model is
different from the simplistic ivshmem.
> I have considered it, and came up with an alternative
>
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 sha
On 2015-09-01 18:02, Michael S. Tsirkin wrote:
> On Tue, Sep 01, 2015 at 05:34:37PM +0200, Jan Kiszka wrote:
>> On 2015-09-01 16:34, Michael S. Tsirkin wrote:
>>> On Tue, Sep 01, 2015 at 04:09:44PM +0200, Jan Kiszka wrote:
>>>> On 2015-09-01 11:24, Michael S. Tsirk
On 2015-09-01 11:24, Michael S. Tsirkin wrote:
> On Tue, Sep 01, 2015 at 11:11:52AM +0200, Jan Kiszka wrote:
>> 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 implementati
On 2015-09-01 16:34, Michael S. Tsirkin wrote:
> On Tue, Sep 01, 2015 at 04:09:44PM +0200, Jan Kiszka wrote:
>> On 2015-09-01 11:24, Michael S. Tsirkin wrote:
>>> On Tue, Sep 01, 2015 at 11:11:52AM +0200, Jan Kiszka wrote:
>>>> On 2015-09-01 10:01, Michael S. Tsirk
On 2015-07-29 01:21, Benjamin Herrenschmidt wrote:
On Tue, 2015-07-28 at 15:43 -0700, Andy Lutomirski wrote:
New QEMU
always advertises this feature flag. If iommu=on, QEMU's virtio
devices refuse to work unless the driver acknowledges the flag.
This should be configurable.
On 2015-07-29 10:17, Paolo Bonzini wrote:
On 29/07/2015 02:47, Andy Lutomirski wrote:
If new kernels ignore the IOMMU for devices that don't set the flag
and there are physical devices that already exist and don't set the
flag, then those devices won't work reliably on most modern
On 2015-07-28 15:06, Michael S. Tsirkin wrote:
On Tue, Jul 28, 2015 at 02:46:20PM +0200, Paolo Bonzini wrote:
On 28/07/2015 12:12, Benjamin Herrenschmidt wrote:
That is an experimental feature (it's x-iommu), so it can change.
The plan was:
- for PPC, virtio never honors IOMMU
- for
On 2015-07-28 19:15, Paolo Bonzini wrote:
On 28/07/2015 18:42, Jan Kiszka wrote:
On the other hand interrupt remapping is absolutely necessary for
production use, hence my point that x86 does not promise API stability.
Well, we currently implement the features that the Q35 used to expose
On 2015-07-28 18:36, Paolo Bonzini wrote:
On 28/07/2015 15:11, Jan Kiszka wrote:
This doesn't matter much, since the only guests that implement an IOMMU
in QEMU are (afaik) PPC and x86, and x86 does not yet promise any kind
of stability.
Hmm I think Jan (cc) said it was already used out
On 2015-07-28 19:10, Andy Lutomirski wrote:
On Tue, Jul 28, 2015 at 9:44 AM, Jan Kiszka jan.kis...@siemens.com wrote:
The ability to have virtio on systems with IOMMU in place makes testing
much more efficient for us. Ideally, we would have it in non-identity
mapping scenarios as well, e.g
On 2015-07-28 18:11, Andy Lutomirski wrote:
On Jul 28, 2015 6:11 AM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2015-07-28 15:06, Michael S. Tsirkin wrote:
On Tue, Jul 28, 2015 at 02:46:20PM +0200, Paolo Bonzini wrote:
On 28/07/2015 12:12, Benjamin Herrenschmidt wrote
On 2015-07-28 20:22, Andy Lutomirski wrote:
On Tue, Jul 28, 2015 at 10:17 AM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2015-07-28 19:10, Andy Lutomirski wrote:
The trouble is that this is really a property of the bus and not of
the device. If you build a virtio device that physically plugs
On 2015-07-28 21:24, Andy Lutomirski wrote:
On Tue, Jul 28, 2015 at 12:06 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2015-07-28 20:22, Andy Lutomirski wrote:
On Tue, Jul 28, 2015 at 10:17 AM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2015-07-28 19:10, Andy Lutomirski wrote:
The trouble
Am 2015-04-27 um 14:35 schrieb Jan Kiszka:
Am 2015-04-27 um 12:17 schrieb Stefan Hajnoczi:
On Sun, Apr 26, 2015 at 2:24 PM, Luke Gorrie l...@snabb.co wrote:
On 24 April 2015 at 15:22, Stefan Hajnoczi stefa...@gmail.com wrote:
The motivation for making VM-to-VM fast is that while software
Am 2015-04-27 um 12:17 schrieb Stefan Hajnoczi:
On Sun, Apr 26, 2015 at 2:24 PM, Luke Gorrie l...@snabb.co wrote:
On 24 April 2015 at 15:22, Stefan Hajnoczi stefa...@gmail.com wrote:
The motivation for making VM-to-VM fast is that while software
switches on the host are efficient today
Am 2015-04-27 um 15:01 schrieb Stefan Hajnoczi:
On Mon, Apr 27, 2015 at 1:55 PM, Jan Kiszka jan.kis...@siemens.com wrote:
Am 2015-04-27 um 14:35 schrieb Jan Kiszka:
Am 2015-04-27 um 12:17 schrieb Stefan Hajnoczi:
On Sun, Apr 26, 2015 at 2:24 PM, Luke Gorrie l...@snabb.co wrote:
On 24 April
Am 2015-04-27 um 16:36 schrieb Luke Gorrie:
On 27 April 2015 at 16:30, Jan Kiszka jan.kis...@siemens.com wrote:
Today, we have posted interrupts to avoid the vm-exit on the target CPU,
but there is nothing yet (to my best knowledge) to avoid the exit on the
sender side (unless we ignore
On 2014-10-22 22:34, Benjamin Herrenschmidt wrote:
On Wed, 2014-10-22 at 16:17 +0200, Jan Kiszka wrote:
I thought about this again, and I'm not sure anymore if we can use
ACPI
to black-list the incompatible virtio devices. Reason: hotplug. To
my
understanding, the ACPI DRHD tables won't
On 2014-10-22 10:44, Michael S. Tsirkin wrote:
On Wed, Oct 08, 2014 at 11:04:28AM +0200, Cornelia Huck wrote:
On Tue, 07 Oct 2014 18:24:22 -0700
Andy Lutomirski l...@amacapital.net wrote:
On 10/07/2014 07:39 AM, Cornelia Huck wrote:
This patchset aims to get us some way to implement virtio-1
On 2014-06-17 07:24, Paolo Bonzini wrote:
Il 15/06/2014 08:20, Jan Kiszka ha scritto:
I think implementing Xen hypercalls in jailhouse for grant table and
event channels would actually make a lot of sense. The Xen
implementation is 2.5kLOC and I think it should be possible to compact
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
On 2014-06-13 02:47, Rusty Russell wrote:
Jan Kiszka jan.kis...@siemens.com writes:
On 2014-06-12 04:27, Rusty Russell wrote:
Henning Schild henning.sch...@siemens.com writes:
It was also never implemented, and remains a thought experiment.
However, implementing it in lguest should be fairly
On 2014-06-12 04:27, Rusty Russell wrote:
Henning Schild henning.sch...@siemens.com writes:
Hi,
i am working on the jailhouse[1] project and am currently looking at
inter-VM communication. We want to connect guests directly with virtual
consoles based on shared memory. The code complexity in
On 2013-02-28 16:24, Michael S. Tsirkin wrote:
Another problem with PIO is support for physical virtio devices,
and nested virt: KVM currently programs all PIO accesses
to cause vm exit, so using this device in a VM will be slow.
Not answering your question, but support for programming direct
On 2012-08-13 10:35, Nicholas A. Bellinger wrote:
From: Nicholas Bellinger n...@linux-iscsi.org
This is required to get past the following assert with:
commit 1523ed9e1d46b0b54540049d491475ccac7e6421
Author: Jan Kiszka jan.kis...@siemens.com
Date: Thu May 17 10:32:39 2012 -0300
On 2012-08-13 20:03, Michael S. Tsirkin wrote:
On Mon, Aug 13, 2012 at 02:06:10PM +0200, Jan Kiszka wrote:
On 2012-08-13 10:35, Nicholas A. Bellinger wrote:
From: Nicholas Bellinger n...@linux-iscsi.org
This is required to get past the following assert with:
commit
On 2012-05-02 12:09, Raghavendra K T wrote:
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
KVM_HC_KICK_CPU hypercall added to wakeup halted vcpu in paravirtual spinlock
enabled guest.
KVM_FEATURE_PV_UNHALT enables guest to check whether pv spinlock can be
enabled
in guest.
On 2011-11-02 21:11, Michael S. Tsirkin wrote:
MSIX spec requires that device can be operated with
all vectors masked, by polling pending bits.
Add APIs to recall an msix notification, and make polling
mode possible in virtio-pci by clearing the
pending bits and setting ISR appropriately on
On 2011-02-04 14:35, Ravi Kumar Kulkarni wrote:
Hi all,
I'm Initializing the Local and IO APIC for a propeitary operating
system running in Virtualized Environment .
Im facing some problem with qemu-kvm but the code runs fine with qemu.
Does it also run fine with qemu-kvm and
86 matches
Mail list logo
