From: Jakub Jelen
The libssh does not handle non-blocking mode in SFTP correctly. The
driver code already changes the mode to blocking for the SFTP
initialization, but for some reason changes to non-blocking mode.
This used to work accidentally until libssh in 0.11 branch merged
the patch to avoi
From: Jakub Jelen
The libssh does not handle non-blocking mode in SFTP correctly. The
driver code already changes the mode to blocking for the SFTP
initialization, but for some reason changes to non-blocking mode.
This used to work accidentally until libssh in 0.11 branch merged
the patch to avoi
On Wed, Nov 13, 2024 at 03:02:59PM +0300, Michael Tokarev wrote:
> Heh. I was creating a qemu bug report on gitlab when this email arrived :)
>
> 13.11.2024 14:49, Richard W.M. Jones wrote:
> >From: Jakub Jelen
> >
> >The libssh does not handle non-blocking mode in SFTP correctly. The
> >driver c
Heh. I was creating a qemu bug report on gitlab when this email arrived :)
13.11.2024 14:49, Richard W.M. Jones wrote:
From: Jakub Jelen
The libssh does not handle non-blocking mode in SFTP correctly. The
driver code already changes the mode to blocking for the SFTP
initialization, but for som
This patch set introduces a new ARM and macOS HVF specific machine type
called "vmapple", as well as a family of display devices based on the
ParavirtualizedGraphics.framework in macOS. One of the display adapter
variants, apple-gfx-mmio, is required for the new machine type, while
apple-gfx-pci ca
MacOS provides a framework (library) that allows any vmm to implement a
paravirtualized 3d graphics passthrough to the host metal stack called
ParavirtualizedGraphics.Framework (PVG). The library abstracts away
almost every aspect of the paravirtualized device model and only provides
and receives c
From: Alexander Graf
In addition to the ISA and PCI variants of pvpanic, let's add an MMIO
platform device that we can use in embedded arm environments.
Signed-off-by: Alexander Graf
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Signed-off-by: Phil Dennis-Jordan
Revie
From: Alexander Graf
Apple has its own virtio-blk PCI device ID where it deviates from the
official virtio-pci spec slightly: It puts a new "apple type"
field at a static offset in config space and introduces a new barrier
command.
This patch first creates a mechanism for virtio-blk downstream c
This change wires up the PCI variant of the paravirtualised
graphics device, mainly useful for x86-64 macOS guests, implemented
by macOS's ParavirtualizedGraphics.framework. It builds on code
shared with the vmapple/mmio variant of the PVG device.
Signed-off-by: Phil Dennis-Jordan
---
v4:
* Th
From: Alexander Graf
We will introduce a number of devices that are specific to the vmapple
target machine. To keep them all tidily together, let's put them into
a single target directory.
Signed-off-by: Alexander Graf
Signed-off-by: Phil Dennis-Jordan
Reviewed-by: Akihiko Odaki
---
MAINTAIN
From: Alexander Graf
VMApple contains an "aes" engine device that it uses to encrypt and
decrypt its nvram. It has trivial hard coded keys it uses for that
purpose.
Add device emulation for this device model.
Signed-off-by: Alexander Graf
Signed-off-by: Phil Dennis-Jordan
---
v3:
* Rebased
From: Alexander Graf
The VMApple machine exposes AUX and ROOT block devices (as well as USB OTG
emulation) via virtio-pci as well as a special, simple backdoor platform
device.
This patch implements this backdoor platform device to the best of my
understanding. I left out any USB OTG parts; they
macOS's Cocoa event handling must be done on the initial (main) thread
of the process. Furthermore, if library or application code uses
libdispatch, the main dispatch queue must be handling events on the main
thread as well.
So far, this has affected Qemu in both the Cocoa and SDL UIs, although
in
From: Alexander Graf
Instead of device tree or other more standardized means, VMApple passes
platform configuration to the first stage boot loader in a binary encoded
format that resides at a dedicated RAM region in physical address space.
This patch models this configuration space as a qdev dev
From: Alexander Graf
Some boards such as vmapple don't do real legacy PCI IRQ swizzling.
Instead, they just keep allocating more board IRQ lines for each new
legacy IRQ. Let's support that mode by giving instantiators a new
"nr_irqs" property they can use to support more than 4 legacy IRQ lines.
From: Alexander Graf
MacOS unconditionally disables interrupts of the physical timer on boot
and then continues to use the virtual one. We don't really want to support
a full physical timer emulation, so let's just ignore those writes.
Signed-off-by: Alexander Graf
Signed-off-by: Phil Dennis-Jo
I'm happy to take responsibility for the macOS PV graphics code. As
HVF patches don't seem to get much attention at the moment, I'm also
adding myself as designated reviewer for HVF and x86 HVF to try and
improve that.
I anticipate that the resulting workload should be covered by the
funding I'm r
From: Alexander Graf
Apple defines a new "vmapple" machine type as part of its proprietary
macOS Virtualization.Framework vmm. This machine type is similar to the
virt one, but with subtle differences in base devices, a few special
vmapple device additions and a vastly different boot chain.
This
This change adds a property 'display_modes' on the graphics device
which permits specifying a list of display modes. (screen resolution
and refresh rate)
The property is an array of a custom type to make the syntax slightly
less awkward to use, for example:
-device '{"driver":"apple-gfx-pci", "di
The virtio_blk_free_request() function has been a 1-liner forwarding
to g_free() for a while now. We may as well call g_free on the request
pointer directly.
Signed-off-by: Phil Dennis-Jordan
Reviewed-by: Akihiko Odaki
---
hw/block/virtio-blk.c | 43 +++---
On Mon, 11 Nov 2024 at 05:21, Akihiko Odaki
wrote:
> On 2024/11/11 0:01, Phil Dennis-Jordan wrote:
> > On Sun, 10 Nov 2024 at 08:15, Akihiko Odaki
> wrote:
> >>
> >> On 2024/11/08 23:47, Phil Dennis-Jordan wrote:
> >>> From: Alexander Graf
> >>>
> >>> Instead of device tree or other more standa
On 11/13/24 15:23, Phil Dennis-Jordan wrote:
macOS's Cocoa event handling must be done on the initial (main) thread
of the process. Furthermore, if library or application code uses
libdispatch, the main dispatch queue must be handling events on the main
thread as well.
So far, this has affected
On Mon, 11 Nov 2024 at 05:50, Akihiko Odaki
wrote:
> On 2024/11/11 6:55, Phil Dennis-Jordan wrote:
> > MacOS provides a framework (library) that allows any vmm to implement a
> > paravirtualized 3d graphics passthrough to the host metal stack called
> > ParavirtualizedGraphics.Framework (PVG). Th
On Wed, 13 Nov 2024, Phil Dennis-Jordan wrote:
macOS's Cocoa event handling must be done on the initial (main) thread
of the process. Furthermore, if library or application code uses
libdispatch, the main dispatch queue must be handling events on the main
thread as well.
So far, this has affecte
On Wed, Nov 13, 2024 at 7:16 PM BALATON Zoltan wrote:
> > int main(int argc, char **argv)
> > {
> > +QemuThread main_loop_thread;
> > +
> > qemu_init(argc, argv);
> > -return qemu_main();
> > +if (qemu_main) {
> > +qemu_thread_create(&main_loop_thread, "qemu_main",
> > +
On Wed, 13 Nov 2024 at 19:36, Paolo Bonzini wrote:
> On Wed, Nov 13, 2024 at 7:16 PM BALATON Zoltan wrote:
> > > int main(int argc, char **argv)
> > > {
> > > +QemuThread main_loop_thread;
> > > +
> > > qemu_init(argc, argv);
> > > -return qemu_main();
> > > +if (qemu_main) {
> >
Hi Cedric,
> Subject: RE: [PATCH v2 00/18] Fix write incorrect data into flash in user mode
>
> Hi Cedric,
>
> > Subject: Re: [PATCH v2 00/18] Fix write incorrect data into flash in
> > user mode
> >
> > Hello Jamin,
> >
> > On 10/22/24 11:40, Jamin Lin wrote:
> > > change from v1:
> > > 1. Fi
Hi Cedric, Andrew
> Subject: [PATCH v2 0/3] Introduce a new Write Protected pin inverted property
>
> change from v1:
> 1. Support RTC for AST2700.
> 2. Support SDHCI write protected pin inverted for AST2500 and AST2600.
> 3. Introduce Capabilities Register 2 for SD slot 0 and 1.
> 4. Support cre
Hello Jamin,
On 11/14/24 06:32, Jamin Lin wrote:
Hi Cedric, Andrew
Subject: [PATCH v2 0/3] Introduce a new Write Protected pin inverted property
change from v1:
1. Support RTC for AST2700.
2. Support SDHCI write protected pin inverted for AST2500 and AST2600.
3. Introduce Capabilities Registe
On 11/4/24 04:21, Jamin Lin wrote:
The Write Protect pin of SDHCI model is default active low to match the SDHCI
spec. So, write enable the bit 19 should be 1 and write protected the bit 19
should be 0 at the Present State Register (0x24). However, some boards are
design Write Protected pin activ
Hello Jamin,
On 11/14/24 06:30, Jamin Lin wrote:
Hi Cedric,
Subject: RE: [PATCH v2 00/18] Fix write incorrect data into flash in user mode
Hi Cedric,
Subject: Re: [PATCH v2 00/18] Fix write incorrect data into flash in
user mode
Hello Jamin,
On 10/22/24 11:40, Jamin Lin wrote:
change fro
31 matches
Mail list logo
