Hi,
We are working on a project where we need to explore the virtual
machine introspection technique in a nested environment. More
specifically, we want to know if from L0, we can reconstruct the
process list of L2. And to begin with, we just want to explore a
relatively simple case, i.e., only on
On Wed, Jul 03, 2019 at 03:26:25PM +0100, Daniel P. Berrangé wrote:
> On Mon, Jul 01, 2019 at 01:31:00PM -0500, miny...@acm.org wrote:
> > From: Corey Minyard
> >
> > Using the UUID that qemu generates probably isn't the best thing
> > to do, allow it to be passed in via properties, and use QemuU
On Sat, 6 Jul 2019 at 11:28, Mark Cave-Ayland
wrote:
>
> On 06/07/2019 11:16, Peter Maydell wrote:
> > If you just do 'make' rather than 'make install' does it fail the same way?
>
> Interesting. A quick test shows that "make V=1 -j2" works fine, it's just
> "make V=1
> -j2 install" which is fail
Am Sat, 6 Jul 2019 08:54:13 -0700 (PDT)
schrieb no-re...@patchew.org:
> Patchew URL:
> https://patchew.org/QEMU/20190706154308.7280-1-h...@tuxfamily.org/
>
> Hi,
>
> This series seems to have some coding style problems. See output
> below for more information:
[...]
> ERROR: space required after
Hi Sukrit,
On 7/6/19 7:09 AM, Sukrit Bhatnagar wrote:
Changes in v2:
* Modify load_dsr() such that dsr mapping is not performed if dsr value
is non-NULL. Also move free_dsr() out of load_dsr() and call it right
before if needed. These two changes will allow us to call load_dsr()
even w
Patchew URL: https://patchew.org/QEMU/20190706154308.7280-1-h...@tuxfamily.org/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190706154308.7280-1-h...@tuxfamily.org
Type: series
Subject: [Qemu-devel] [PATCH v3 0/4] m68k: Add basi
I don't have much clue about the NeXT hardware, but at least I know now
the source files a little bit, so I volunteer to pick up patches and send
PULL requests for them until someone else with more knowledge steps up
to do this job instead.
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Thoma
The NeXTcube uses a linear framebuffer with 4 greyscale colors and
a fixed resolution of 1120 * 832.
This code has been taken from Bryce Lanham's GSoC 2011 NeXT branch at
https://github.com/blanham/qemu-NeXT/blob/next-cube/hw/next-fb.c
and altered to fit the latest interface of the current QEMU
It is still quite incomplete (no SCSI, no floppy emulation, no network,
etc.), but the firmware already shows up the debug monitor prompt in the
framebuffer display, so at least the very basics are already working.
This code has been taken from Bryce Lanham's GSoC 2011 NeXT branch at
https://git
During Google Summer of Code 2011, Bryce Lanham added the possibility to
emulate the NeXTcube machine in QEMU, e.g. see these URLs for some details:
https://wiki.qemu.org/Google_Summer_of_Code_2011#NeXT_machines_system_emulation
https://lists.gnu.org/archive/html/qemu-devel/2011-08/msg02158.html
It is likely still quite incomplete (e.g. mouse and interrupts are not
implemented yet), but it is good enough for keyboard input at the firmware
monitor.
This code has been taken from Bryce Lanham's GSoC 2011 NeXT branch at
https://github.com/blanham/qemu-NeXT/blob/next-cube/hw/next-kbd.c
and a
Patchew URL: https://patchew.org/QEMU/20190705202500.18853-1-phi...@redhat.com/
Hi,
This series failed build test on s390x host. Please find the details below.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
# Testing script will be invoked under the git checkout with
# HEAD pointing to a commit that ha
This patch adds support for propagating guest PASID-based iotlb flush
to host via vfio container ioctl.
Cc: Kevin Tian
Cc: Jacob Pan
Cc: Peter Xu
Cc: Eric Auger
Cc: Yi Sun
Cc: David Gibson
Signed-off-by: Liu Yi L
---
hw/vfio/pci.c | 23 +++
1 file changed, 23 insertions
Intel VT-d 3.0 supports nested translation in PASID granularity. For guest
SVA support, nested translation is enabled for specific PASID. In such case,
guest owns the GVA->GPA translation which is configured as first level page
table in host side for a specific pasid, and host owns GPA->HPA transla
This patch adds flush_pasid_iotlb() in PCIPASIDOps for passing guest
PASID-based iotlb flush operation to host via vfio interface.
Cc: Kevin Tian
Cc: Jacob Pan
Cc: Peter Xu
Cc: Eric Auger
Cc: Yi Sun
Cc: David Gibson
Signed-off-by: Liu Yi L
---
hw/pci/pci.c | 15 +++
inc
This patch allocates PASID tagged VTDAddressSpace instances per
BDF+PASID. New PASID tagged VTDAddressSpace instances is allocated
when captured guest pasid selective pasid cache invalidation.
For pasid selective pasid cache invalidation from guest under Intel
VT-d caching-mode, it could be one of
This patch flushes pasid cache after a device selective context cache
flush. This is a behavior to ensure safety. Actually, programmer should
issue a pasid cache flush following a device selective context cache
invalidation.
TODO: global and domain selective context cache flush should also be
foll
This patch introduces new fields in VTDAddressSpace for further PASID support
in Intel vIOMMU. In old time, each device has a VTDAddressSpace instance to
stand for its guest IOVA address space when vIOMMU is enabled. However, when
PASID is exposed to guest, device will have multiple address spaces
RID_PASID field was introduced in VT-d 3.0 spec, it is used for DMA
requests w/o PASID in scalable mode VT-d. It is also known as IOVA.
And in VT-d 3.1 spec, there is further definition on it:
"Implementations not supporting RID_PASID capability (ECAP_REG.RPS is
0b), use a PASID value of 0 to perf
PASID-based IOTLB (piotlb) is used during walking Intel VT-d first-level
page table. This patch adds frame of processing for PASID-based IOTLB flush.
Detailed processing is in next patch of this patchset.
Cc: Kevin Tian
Cc: Jacob Pan
Cc: Peter Xu
Cc: Yi Sun
Signed-off-by: Liu Yi L
---
hw/i38
This patch adds virtual command support to Intel vIOMMU per Intel VT-d 3.1
spec. This patch adds two virtual commands: alloc_pasid and free_pasid.
Cc: Kevin Tian
Cc: Jacob Pan
Cc: Peter Xu
Cc: Yi Sun
Signed-off-by: Liu Yi L
Signed-off-by: Yi Sun
---
hw/i386/intel_iommu.c | 139
This patch adds PASID cache flush emulation framework. Per Intel VT-d 3.0
spec, PASID cache invalidation under caching-mode provides a mechanism
software Intel VT-d(vIOMMU) implementations to track guest PASID bind/unbind
operations. This is a key part of vIOMMU support for guest SVA. And this
patc
This patch captures the guest PASID table entry modifications and passdown
the changes to host. Thus guest page table is bound to host IOMMU and is
configured as 1st level page table (GVA->GPA) whose translation result
would further go through host VT-d 2nd level page table(GPA->HPA) under
nested t
This patch imports the vIOMMU related definitions from kernel
uapi/iommu.h. e.g. iommu fault report, pasid allocation, guest
pasid bind and guest iommu cache flush.
Cc: Kevin Tian
Cc: Jacob Pan
Cc: Peter Xu
Cc: Eric Auger
Cc: Yi Sun
Signed-off-by: Liu Yi L
Signed-off-by: Jacob Pan
Signed-of
This patch adds vfio implementation PCIPASIDOps.bind_gpasid/unbind_pasid().
These two functions are used to propagate guest pasid bind and unbind
requests to host via vfio container ioctl.
Cc: Kevin Tian
Cc: Jacob Pan
Cc: Peter Xu
Cc: Eric Auger
Cc: Yi Sun
Cc: David Gibson
Signed-off-by: Liu
This patch adds two callbacks pci_device_bind/unbind_gpasid() to
PCIPASIDOps. These two callbacks are used to propagate guest pasid
bind/unbind to host. The implementations of the callbacks would be
device passthru modules like vfio.
Cc: Kevin Tian
Cc: Jacob Pan
Cc: Peter Xu
Cc: Eric Auger
Cc:
This patch imports the vIOMMU related definitions from kernel
uapi/vfio.h. e.g. pasid allocation, guest pasid bind, guest pasid
table bind and guest iommu cache invalidation.
Cc: Kevin Tian
Cc: Jacob Pan
Cc: Peter Xu
Cc: Eric Auger
Cc: Yi Sun
Signed-off-by: Liu Yi L
Signed-off-by: Jacob Pan
Intel VT-d 3.0 introduces scalable mode, and it has a bunch of
capabilities related to scalable mode translation, thus there
are multiple combinations. While this vIOMMU implementation
wants simplify it for user by providing typical combinations.
User could config it by "sm_model" option. The usage
This patch adds vfio implementation PCIPASIDOps.alloc_pasid/free_pasid().
These two functions are used to propagate guest pasid allocation and
free requests to host via vfio container ioctl.
Cc: Kevin Tian
Cc: Jacob Pan
Cc: Peter Xu
Cc: Eric Auger
Cc: Yi Sun
Cc: David Gibson
Signed-off-by: L
This patch introduces PCIPASIDOps for PASID related operations in
future usage like virt-SVA. Related discussions can be found in
below links.
https://lists.gnu.org/archive/html/qemu-devel/2018-03/msg00078.html
https://lists.gnu.org/archive/html/qemu-devel/2018-03/msg00940.html
So far, to setup v
Shared virtual address (SVA), a.k.a, Shared virtual memory (SVM) on Intel
platforms allow address space sharing between device DMA and applications.
SVA can reduce programming complexity and enhance security.
This series is intended to expose SVA capability to VMs. i.e. shared guest
application add
On 06/07/2019 11:16, Peter Maydell wrote:
> On Sat, 6 Jul 2019 at 10:59, Mark Cave-Ayland
> wrote:
>>
>> Hi all,
>>
>> Today I tried transferring my QEMU development setup from my laptop onto a
>> faster
>> desktop machine (Intel i7-6700) and was surprised to find my normal "full"
>> build
>> s
On Mittwoch, 3. Juli 2019 13:13:26 CEST Christian Schoenebeck wrote:
> To support multiple devices on the 9p share, and avoid
> qid path collisions we take the device id as input
[snip]
> - Fixed v9fs_do_readdir() having exposed info outside
>export root with '..' entry.
[snip]
> diff
On Sat, 6 Jul 2019 at 10:59, Mark Cave-Ayland
wrote:
>
> Hi all,
>
> Today I tried transferring my QEMU development setup from my laptop onto a
> faster
> desktop machine (Intel i7-6700) and was surprised to find my normal "full"
> build
> script failing:
>
> ./configure --target-list='x86_64-so
Hi all,
Today I tried transferring my QEMU development setup from my laptop onto a
faster
desktop machine (Intel i7-6700) and was surprised to find my normal "full" build
script failing:
./configure --target-list='x86_64-softmmu sparc64-softmmu sparc-softmmu
ppc-softmmu
arm-softmmu' --prefix=/h
Patchew URL:
https://patchew.org/QEMU/1562356239-19391-1-git-send-email-pbonz...@redhat.com/
Hi,
This series failed build test on s390x host. Please find the details below.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
# Testing script will be invoked under the git checkout with
# HEAD pointing to a
Patchew URL:
https://patchew.org/QEMU/20190705221504.25166-1-ehabk...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20190705221504.25166-1-ehabk...@redhat.com
Subject: [Qemu-devel] [PULL v6 00/42] Machine
37 matches
Mail list logo
