On 6/17/21 11:48 AM, Gerd Hoffmann wrote:
> Hi,
>
>> Do we need to be able to unload modules that we previously loaded? Or is
>> this not a realistic requirement?
>
> Surely doable, but it's work and needs infrastructure we don't have
> right now. We must be able to unregister everything
Hi,
> Do we need to be able to unload modules that we previously loaded? Or is this
> not a realistic requirement?
Surely doable, but it's work and needs infrastructure we don't have
right now. We must be able to unregister everything modules can
register, which is only partly the case
On 6/17/21 7:37 AM, Gerd Hoffmann wrote:
> Hi,
>
However, please correct me if I'm wrong, I understand that an accelerator
as a
module will add an overhead that some user won't be willing to pay. So,
give
them the option to have built-in accelerators seems a good
Hi,
> >> However, please correct me if I'm wrong, I understand that an accelerator
> >> as a
> >> module will add an overhead that some user won't be willing to pay. So,
> >> give
> >> them the option to have built-in accelerators seems a good idea.
> >
> > Modules add some overhead, yes,
On 6/16/21 11:28 AM, Gerd Hoffmann wrote:
>>> Hmm, what would be the use case? Right now qemu has the all-or-nothing
>>> approach for modules, i.e. if modules are enabled everything we can
>>> build as module will be built as module, and I havn't seen any drawbacks
>>> so far. So, why would one
> > Hmm, what would be the use case? Right now qemu has the all-or-nothing
> > approach for modules, i.e. if modules are enabled everything we can
> > build as module will be built as module, and I havn't seen any drawbacks
> > so far. So, why would one compile parts of qemu as module and other
On terça-feira, 15 de junho de 2021 02:09:30 -03 Gerd Hoffmann wrote:
> On Mon, Jun 14, 2021 at 10:19:27PM +, José Ricardo Ziviani wrote:
> > Hello Gerd,
> >
> > On sexta-feira, 11 de junho de 2021 10:03:21 -03 Gerd Hoffmann wrote:
> > > Hi,
> > >
> > > > Are there any pending patches to
On Mon, Jun 14, 2021 at 10:19:27PM +, José Ricardo Ziviani wrote:
> Hello Gerd,
>
> On sexta-feira, 11 de junho de 2021 10:03:21 -03 Gerd Hoffmann wrote:
> > Hi,
> >
> > > Are there any pending patches to handle the remaining tcg dependencies
> > > in qemu? When trying to build tcg
N¬Æ¦º[b¥ªíë,j¢Â ú+«g{Oj»vëß:ëâè4f
íz{S©ì}êÄÊ x*º^vâÖà¨×§µ<©z×±·úej)Ü
ªìz
signature.asc
Description: This is a digitally signed message part.
On 11/06/21 10:29, Gerd Hoffmann wrote:
Are there any pending patches to handle the remaining tcg dependencies
in qemu? When trying to build tcg modular (more than only
tcg-accel-ops*) I get lots of unresolved symbols to tcg bits which are
referenced directly (in cpu.c, gdbstub.c, monitor,
On 6/11/21 3:03 PM, Gerd Hoffmann wrote:
> Hi,
>
>> Are there any pending patches to handle the remaining tcg dependencies
>> in qemu? When trying to build tcg modular (more than only
>> tcg-accel-ops*) I get lots of unresolved symbols to tcg bits which are
>> referenced directly (in cpu.c,
Hi,
> Are there any pending patches to handle the remaining tcg dependencies
> in qemu? When trying to build tcg modular (more than only
> tcg-accel-ops*) I get lots of unresolved symbols to tcg bits which are
> referenced directly (in cpu.c, gdbstub.c, monitor, ...).
>
> The CONFIG_TCG=n
On Fri, Jun 11, 2021 at 09:35:42AM +0200, Paolo Bonzini wrote:
> On 10/06/21 15:12, Claudio Fontana wrote:
> > The difficulty is that accelerator code is going to be split across a
> > large number of directories.
We basically have to define the source sets at the toplevel meson.build
file, then
On 10/06/21 15:12, Claudio Fontana wrote:
The difficulty is that accelerator code is going to be split across a
large number of directories.
It should be possible to use a sourceset per target; just like there is
target_arch, target_softmmu_arch, target_user_arch we can add
On 6/10/21 2:23 PM, Gerd Hoffmann wrote:
> On Thu, Jun 10, 2021 at 12:34:14PM +0200, Claudio Fontana wrote:
>> On 6/10/21 12:15 PM, Gerd Hoffmann wrote:
>>> Based on the "modules: add metadata database" patch series sent
>>> earlier today. Adds support for target-specific modules to the
>>>
Hi,
> Build qtest modular on top of that was easy, patch below.
>
> I'm not convinced though that the approach will work for other
> accelerators too given that they have dependencies to directories
> outside accel/ ...
Oh, it depends on how high you hang the tcg modularization bar.
Building
On Thu, Jun 10, 2021 at 12:34:14PM +0200, Claudio Fontana wrote:
> On 6/10/21 12:15 PM, Gerd Hoffmann wrote:
> > Based on the "modules: add metadata database" patch series sent
> > earlier today. Adds support for target-specific modules to the
> > module code and build infrastructure. Builds one
On 6/10/21 12:15 PM, Gerd Hoffmann wrote:
> Based on the "modules: add metadata database" patch series sent
> earlier today. Adds support for target-specific modules to the
> module code and build infrastructure. Builds one simple module
> (virtio-9p-device) for testing purposes. Well, one
Based on the "modules: add metadata database" patch series sent
earlier today. Adds support for target-specific modules to the
module code and build infrastructure. Builds one simple module
(virtio-9p-device) for testing purposes. Well, one module per
target to be exact ;)
Gerd Hoffmann (4):
19 matches
Mail list logo
