On 14.02.25 12:16, Gerd Hoffmann wrote:
On Fri, Feb 14, 2025 at 10:51:17AM +0100, Alexander Graf wrote:
I also like to have dedicated register spaces per component. So even if you
choose to make it a hard split, I think we're better off with 4k at
0xfef1 for control and 64k at 0xfef2
On Fri, Feb 14, 2025 at 10:51:17AM +0100, Alexander Graf wrote:
> I also like to have dedicated register spaces per component. So even if you
> choose to make it a hard split, I think we're better off with 4k at
> 0xfef1 for control and 64k at 0xfef2 for the buffer for example.
Well, if w
On 14.02.25 08:55, Gerd Hoffmann wrote:
Hi,
How do your patches pick the transfer mode? Is that dictated by the
host? Or is the guest free to choose? In case of the latter: How does
the guest decide what to do?
In our version, the guest gets to pick. It defaults to the DMA interface
u
Hi,
> > How do your patches pick the transfer mode? Is that dictated by the
> > host? Or is the guest free to choose? In case of the latter: How does
> > the guest decide what to do?
>
> In our version, the guest gets to pick. It defaults to the DMA interface
> unless it detects that it's r
On 13.02.25 15:54, Gerd Hoffmann wrote:
On Thu, Feb 13, 2025 at 11:14:03AM +0100, Alexander Graf wrote:
I don't think so. The firmware driver knows this actually is normal ram
and can setup mappings and memory attributes accordingly. The situation
is a bit different from vga memory bars whic
On Thu, Feb 13, 2025 at 11:14:03AM +0100, Alexander Graf wrote:
>
> > I don't think so. The firmware driver knows this actually is normal ram
> > and can setup mappings and memory attributes accordingly. The situation
> > is a bit different from vga memory bars which are handled by pci bus
> > m
On 13.02.25 10:28, Ard Biesheuvel wrote:
On Wed, 12 Feb 2025 at 22:26, Alexander Graf wrote:
On 12.02.25 16:18, Gerd Hoffmann wrote:
Hi,
Yes. Knowing both physical and virtual address works only for memory
you allocated yourself before ExitBootServices. So you can't pass on
pointers f
On 13.02.25 10:52, Gerd Hoffmann wrote:
Hi,
That will bring back all issues with cached vs non-cached memory accesses,
no? So edk2 will always access that memory as device memory which means it
bypasses the cache, while QEMU will access it through the cache. So that
buffer would need to ac
Hi,
> That will bring back all issues with cached vs non-cached memory accesses,
> no? So edk2 will always access that memory as device memory which means it
> bypasses the cache, while QEMU will access it through the cache. So that
> buffer would need to actually be MMIO memory I suppose?
I d
On Wed, 12 Feb 2025 at 22:26, Alexander Graf wrote:
>
>
> On 12.02.25 16:18, Gerd Hoffmann wrote:
> >Hi,
> >
> >>> Yes. Knowing both physical and virtual address works only for memory
> >>> you allocated yourself before ExitBootServices. So you can't pass on
> >>> pointers from the OS, you h
On 12.02.25 16:18, Gerd Hoffmann wrote:
Hi,
Yes. Knowing both physical and virtual address works only for memory
you allocated yourself before ExitBootServices. So you can't pass on
pointers from the OS, you have to copy the data to a buffer where you
know the physical address instead.
Hi,
> > Yes. Knowing both physical and virtual address works only for memory
> > you allocated yourself before ExitBootServices. So you can't pass on
> > pointers from the OS, you have to copy the data to a buffer where you
> > know the physical address instead. Yes, some overhead. Should st
On 12.02.25 13:28, Gerd Hoffmann wrote:
On Wed, Feb 12, 2025 at 12:30:20PM +0100, Alexander Graf wrote:
On 12.02.25 11:24, Gerd Hoffmann wrote:
Why do you use confidential computing in the first place if you trust
the host with your EFI variables? I'd rather see something simliar
running und
On Wed, Feb 12, 2025 at 12:30:20PM +0100, Alexander Graf wrote:
>
> On 12.02.25 11:24, Gerd Hoffmann wrote:
> >
> > Why do you use confidential computing in the first place if you trust
> > the host with your EFI variables? I'd rather see something simliar
> > running under guest control, in svs
On 12.02.25 11:24, Gerd Hoffmann wrote:
Hi,
+/* read header */
+dma_memory_read(&address_space_memory, dma,
+uv->buffer, sizeof(*mhdr),
+MEMTXATTRS_UNSPECIFIED);
Depending on DMA sounds appealing at first, but can fall apart in corner
cases.
Hi,
> > +/* read header */
> > +dma_memory_read(&address_space_memory, dma,
> > +uv->buffer, sizeof(*mhdr),
> > +MEMTXATTRS_UNSPECIFIED);
>
> Depending on DMA sounds appealing at first, but can fall apart in corner
> cases. I know of 2 cases where
On 11.02.25 10:23, Gerd Hoffmann wrote:
This is the core code for guest <-> host communication. This accepts
request messages from the guest, dispatches them to the service called,
and sends back the response message.
Signed-off-by: Gerd Hoffmann
---
hw/uefi/var-service-core.c | 237 ++
This is the core code for guest <-> host communication. This accepts
request messages from the guest, dispatches them to the service called,
and sends back the response message.
Signed-off-by: Gerd Hoffmann
---
hw/uefi/var-service-core.c | 237 +
1 file chang
18 matches
Mail list logo
