All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefano Stabellini <sstabellini@kernel.org>
To: Huang Rui <ray.huang@amd.com>
Cc: "Gerd Hoffmann" <kraxel@redhat.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Anthony PERARD" <anthony.perard@citrix.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	"Jan Beulich" <jbeulich@suse.com>,
	"Antonio Caggiano" <antonio.caggiano@collabora.com>,
	"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
	"Robert Beckett" <bob.beckett@collabora.com>,
	qemu-devel@nongnu.org, xen-devel@lists.xenproject.org,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Stewart Hildebrand" <Stewart.Hildebrand@amd.com>,
	"Xenia Ragiadakou" <burzalodowa@gmail.com>,
	"Honglei Huang" <honglei1.huang@amd.com>,
	"Julia Zhang" <julia.zhang@amd.com>,
	"Chen Jiqian" <Jiqian.Chen@amd.com>
Subject: Re: [RFC QEMU PATCH 13/18] hw/i386/xen/xen-hvm: Introduce xen_ram_block_check function
Date: Fri, 17 Mar 2023 17:38:10 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.22.394.2303171735020.3359@ubuntu-linux-20-04-desktop> (raw)
In-Reply-To: <20230312092244.451465-14-ray.huang@amd.com>

On Sun, 12 Mar 2023, Huang Rui wrote:
> Introduce xen_ram_block_check function to check whether current ramblock
> is xen ram memory.
> 
> Signed-off-by: Huang Rui <ray.huang@amd.com>
> ---
>  hw/i386/xen/xen-hvm.c | 15 +++++++++++++++
>  include/hw/xen/xen.h  |  1 +
>  2 files changed, 16 insertions(+)
> 
> diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
> index e4293d6d66..a4f12aefce 100644
> --- a/hw/i386/xen/xen-hvm.c
> +++ b/hw/i386/xen/xen-hvm.c
> @@ -32,6 +32,7 @@
>  #include "sysemu/xen.h"
>  #include "sysemu/xen-mapcache.h"
>  #include "trace.h"
> +#include "include/exec/ramblock.h"
>  
>  #include <xen/hvm/ioreq.h>
>  #include <xen/hvm/e820.h>
> @@ -1564,6 +1565,20 @@ void xen_register_framebuffer(MemoryRegion *mr)
>      framebuffer = mr;
>  }
>  
> +bool xen_ram_block_check(RAMBlock *rb)
> +{
> +	bool ret;
> +
> +	if (!rb)
> +		return false;
> +
> +	ret = (rb == ram_memory.ram_block);
> +	if (ret)
> +		rb->offset = 0;

I take that this is needed because there is a ramblock that is
ram_memory but with offset != 0?  So it would fail the block->offset ==
0 check in qemu_ram_ptr_length (which is meant to capture all accesses
to ram_memory, but failing at it)?

If so, would it be possible to just do this instead:


diff --git a/softmmu/physmem.c b/softmmu/physmem.c
index fb412a56e1..3e2640dabd 100644
--- a/softmmu/physmem.c
+++ b/softmmu/physmem.c
@@ -2149,7 +2149,7 @@ static void *qemu_ram_ptr_length(RAMBlock *ram_block, ram_addr_t addr,
          * because we don't want to map the entire memory in QEMU.
          * In that case just map the requested area.
          */
-        if (block->offset == 0) {
+        if (block->offset == 0 || block == ram_memory.ram_block) {
             return xen_map_cache(addr, *size, lock, lock);
         }
 


> +	return ret;
> +}
> +
>  void xen_shutdown_fatal_error(const char *fmt, ...)
>  {
>      va_list ap;
> diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
> index afdf9c436a..99a383eb17 100644
> --- a/include/hw/xen/xen.h
> +++ b/include/hw/xen/xen.h
> @@ -31,5 +31,6 @@ qemu_irq *xen_interrupt_controller_init(void);
>  void xenstore_store_pv_console_info(int i, Chardev *chr);
>  
>  void xen_register_framebuffer(struct MemoryRegion *mr);
> +bool xen_ram_block_check(RAMBlock *rb);
>  
>  #endif /* QEMU_HW_XEN_H */
> -- 
> 2.25.1
> 


  reply	other threads:[~2023-03-18  0:38 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-12  9:22 [RFC QEMU PATCH 00/18] Add VirtIO GPU and Passthrough GPU support on Xen Huang Rui
2023-03-12  9:22 ` [RFC QEMU PATCH 01/18] virtio: Add shared memory capability Huang Rui
2023-03-13  9:01   ` Philippe Mathieu-Daudé
2023-03-12  9:22 ` [RFC QEMU PATCH 02/18] virtio-gpu: hostmem Huang Rui
2023-03-12  9:22 ` [RFC QEMU PATCH 03/18] virtio-gpu: Handle resource blob commands Huang Rui
2023-03-12  9:22 ` [RFC QEMU PATCH 04/18] virtio-gpu: CONTEXT_INIT feature Huang Rui
2023-03-13  9:06   ` Philippe Mathieu-Daudé
2023-03-12  9:22 ` [RFC QEMU PATCH 05/18] virtio-gpu: Unrealize Huang Rui
2023-03-12  9:22 ` [RFC QEMU PATCH 06/18] virtio-gpu: Resource UUID Huang Rui
2023-03-12  9:22 ` [RFC QEMU PATCH 07/18] virtio-gpu: Support Venus capset Huang Rui
2023-03-12  9:22 ` [RFC QEMU PATCH 08/18] virtio-gpu: Initialize Venus Huang Rui
2023-03-12 17:51   ` Dmitry Osipenko
2023-03-13  2:22     ` Dmitry Osipenko
2023-03-13 15:57       ` Huang Rui
2023-03-13 15:55     ` Huang Rui
2023-03-15 23:14       ` Dmitry Osipenko
2023-03-24 13:22         ` Huang Rui
2023-04-03 21:03           ` Dmitry Osipenko
2023-03-12  9:22 ` [RFC QEMU PATCH 09/18] meson: Enable virglrenderer unstable APIs Huang Rui
2023-03-12  9:22 ` [RFC QEMU PATCH 10/18] virtio-gpu: Handle set scanout blob command Huang Rui
2023-03-12  9:22 ` [RFC QEMU PATCH 11/18] virtio-gpu: make blob scanout use dmabuf fd Huang Rui
2023-03-12  9:22 ` [RFC QEMU PATCH 12/18] softmmu: Fix the size to map cache with xen for host virtual address Huang Rui
2023-03-18  0:31   ` Stefano Stabellini
2023-03-12  9:22 ` [RFC QEMU PATCH 13/18] hw/i386/xen/xen-hvm: Introduce xen_ram_block_check function Huang Rui
2023-03-18  0:38   ` Stefano Stabellini [this message]
2023-03-12  9:22 ` [RFC QEMU PATCH 14/18] softmmu: Add ram block check to map the xen ram memory Huang Rui
2023-03-12  9:22 ` [RFC QEMU PATCH 15/18] softmmu: Enable qemu ram allocation with fd for Xen Huang Rui
2023-03-12  9:22 ` [RFC QEMU PATCH 16/18] virtio-gpu: fix hw-display-virtio-gpu.so undefined symbol virtio_gpu_virgl_resource_unmap Huang Rui
2023-03-12  9:22 ` [RFC QEMU PATCH 17/18] virtio-gpu: Add video hardware accelerate support for virgl Huang Rui
2023-03-12  9:22 ` [RFC QEMU PATCH 18/18] xen: translate irq of host pci device to gsi Huang Rui

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.22.394.2303171735020.3359@ubuntu-linux-20-04-desktop \
    --to=sstabellini@kernel.org \
    --cc=Jiqian.Chen@amd.com \
    --cc=Stewart.Hildebrand@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=anthony.perard@citrix.com \
    --cc=antonio.caggiano@collabora.com \
    --cc=bob.beckett@collabora.com \
    --cc=burzalodowa@gmail.com \
    --cc=christian.koenig@amd.com \
    --cc=dgilbert@redhat.com \
    --cc=honglei1.huang@amd.com \
    --cc=jbeulich@suse.com \
    --cc=julia.zhang@amd.com \
    --cc=kraxel@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=ray.huang@amd.com \
    --cc=roger.pau@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.