> This patch enables USB UHCI global suspend/resume feature. The OS will
> stop the HC once all ports are suspended. If there is activity on the
> port(s), an interrupt signalling remote wakeup will be triggered.
I'm pretty sure this is wrong. Suspend/resume works based on physical
topology, i.e
> On 11/26/10 03:15, Marcelo Tosatti wrote:
> > On Fri, Nov 26, 2010 at 12:38:28AM +0000, Paul Brook wrote:
> >>> This patch enables USB UHCI global suspend/resume feature. The OS will
> >>> stop the HC once all ports are suspended. If there is activity o
> 2) instrumenting i386 is extremely time-consuming (for the developer)
>
> As my work is not tied to a specific target architecture, I was thinking of
> shifting into PPC, as the ISA is pretty regular and that would certainly
> make the process easier by just patching a small set of places in the
> > Likewise requiring separate tracing hooks be added to the existing
> > decoders is extremely unlikely to be a feasible long-term
> > solution.
>
> You mean having to modify each "translate.c"? The worst event to handle
> is instruction fetch on x86.
Instruction fetches are trivial, you just i
> > diff --git a/exec.c b/exec.c
> > index db9ff55..f54a360 100644
> > --- a/exec.c
> > +++ b/exec.c
> >
> > @@ -3370,6 +3474,22 @@ static int cpu_register_io_memory_fixed(int
> > io_index,
> >
> > }
> > io_mem_opaque[io_index] = opaque;
> >
> > +switch (endian) {
> > +case DEVIC
over which devices are built.
Following patch series allows a default config to include other files, and
uses this to consistently enable all PCI devices on all targets.
I have also made VirtIO devices optional.
Paul Brook (3):
Include directives in default configs
PCI config include
VirtIO
Allow default configs to be split into several files.
Signed-off-by: Paul Brook
---
Makefile | 11 ++-
Makefile.objs |3 ++-
make_device_config.sh | 27 +++
3 files changed, 35 insertions(+), 6 deletions(-)
create mode 100644
Split PCI config options into a separate file
Signed-off-by: Paul Brook
---
Makefile.objs | 20 +++-
Makefile.target|4 ++--
default-configs/arm-softmmu.mak|3 +--
default-configs/cris-softmmu.mak |2
Make virtio devices optional. Selecting individual devices is not useful
as the host bindings are all in one file.
Signed-off-by: Paul Brook
---
Makefile.objs | 10 --
Makefile.target |4 ++--
default-configs/s390x-softmmu.mak |1 +
3
> Currently we list PCI devices in every PCI capable architecture
> individually. This is cumbersome when adding new devices and prone to
> failure because one might miss out on one.
>
> So let's instead have a generic PCI configuration file where people can
> throw in their cross-platform compati
er
> grained control over which devices are built.
>
> Following patch series allows a default config to include other files, and
> uses this to consistently enable all PCI devices on all targets.
>
> I have also made VirtIO devices optional.
>
> Paul Brook (3):
>
> > Switching endianness of a CPU generally does not effect the endianness of
> > the CPU/peripheral busses. It makes the CPU byteswap accesses before
> > they are seen by either memory or devices.
> >
> > In theory it might be possible to avoid redundant byteswaps if you're
> > really clever. I
> > diff --git a/default-configs/sparc-softmmu.mak
> > b/default-configs/sparc-softmmu.mak index becf880..7c788b8 100644
> > --- a/default-configs/sparc-softmmu.mak
> > +++ b/default-configs/sparc-softmmu.mak
> > @@ -1,10 +1,10 @@
> > # Default configuration for sparc-softmmu
> >
> > +include pci
> One question I have about Kemari is whether it adds new constraints to
> the QEMU codebase? Fault tolerance seems like a cross-cutting concern
> - everyone writing device emulation or core QEMU code may need to be
> aware of new constraints. For example, "you are not allowed to
> release I/O op
e same
> for targets where I wasn't entirely sure.
... and for good reason. The lance code relies on the (nominally PCI) pcnet
emulation :-( Fixed as below.
Subject: [PATCH] Split out common pcnet code
The core pcnet emulation code is used by both the PCI "pcnet" device
and the SPARC
> On Sat, Nov 27, 2010 at 11:30:52AM +0000, Paul Brook wrote:
> > ---
> >
> > Makefile.objs |3 +-
> > default-configs/pci.mak |1 +
> > default-configs/sparc-softmmu.mak |1 +
> > h
> >> Could you formulate the constraints so developers are aware of them in
> >> the future and can protect the codebase. How about expanding the
> >> Kemari wiki pages?
> >
> > If you like the idea above, I'm happy to make the list also on
> > the wiki page.
>
> Here's a different question: wha
> 2010/11/29 Paul Brook :
> >> >> Could you formulate the constraints so developers are aware of them
> >> >> in the future and can protect the codebase. How about expanding the
> >> >> Kemari wiki pages?
> >> >
> >> > I
> >> To answer Stefan's question, there shouldn't be any requirement
> >> for a device, but must be tested with Kemari. If it doesn't work
> >> correctly, the problems must be fixed before adding to the list.
> >
> > What exactly are the problems? Is this a device bus of a Kemari bug?
> > If it's
> > If devices incorrectly claim support for live migration, then that should
> > also be fixed, either by removing the broken code or by making it work.
>
> I totally agree with you.
>
> > AFAICT your current proposal is just feeding back the results of some
> > fairly specific QA testing. I'd
> >> Sorry, I didn't get what you're trying to tell me. My plan would
> >> be to initially start from a subset of devices, and gradually
> >> grow the number of devices that Kemari works with. While this
> >> process, it'll include what you said above, file a but and/or fix
> >> the code. Am I m
> > Is this a fair summary: any device that supports live migration workw
> > under Kemari?
>
> It might be fair summary but practically we barely have live migration
> working w/o Kemari. In addition, last I checked Kemari needs additional
> hooks and it will be too hard to keep that out of tree
>Hi,
>
> > Not me at the moment, but unless you tunnel it inside another
> > protocol, you'd really want to look at the existing USB-over-IP
> > protocols instead of reinventing the wheel:
> > http://usbip.sourceforge.net/ (some support in Linux already IIRC)
> > (and there are others which I
> On 11/29/2010 10:53 AM, Paul Brook wrote:
> >>> Is this a fair summary: any device that supports live migration workw
> >>> under Kemari?
> >>
> >> It might be fair summary but practically we barely have live migration
> >> working w/o Kemar
> Hi,
>
> On 11/30/2010 12:32 PM, Alon Levy wrote:
> > On Tue, Nov 30, 2010 at 12:26:56PM +0100, Hans de Goede wrote:
>
>
> >> Then there would be multiple ways to add a virtual usb device using
> >> usb-net-redir.c to the virtual machine. One way of adding such a device
> >> could be starting a
> usb_add net:192.168.1.100::[vid]:[pid]
> or:
> usb_add net:192.168.1.100::[busnr]:[addr]
> > ...
> > Instead I suggest just using a freeform string ID. For practical reasons
> > we probably want to restrict this to regular characters, like we do
> > other ids (i.e. [-_A-Za
> > > -qemu_chr_write(vcon->chr, buf, len);
> > > +ret = qemu_chr_write(vcon->chr, buf, len);
> > > +if (ret == -EAGAIN) {
> > > +virtio_serial_throttle_port(port, true);
> > > +}
> > >
> > > }
> >
> > This looks wrong. It will loose data in the case of a partial write
>
> /* Callback function that's called when the guest sends us data */
> static void flush_buf(VirtIOSerialPort *port, const uint8_t *buf, size_t
> len) {
> VirtConsole *vcon = DO_UPCAST(VirtConsole, port, port);
> +int ret;
>
> -qemu_chr_write(vcon->chr, buf, len);
> +ret = qemu_
> On (Wed) Dec 01 2010 [11:59:35], Paul Brook wrote:
> > > > > -qemu_chr_write(vcon->chr, buf, len);
> > > > > +ret = qemu_chr_write(vcon->chr, buf, len);
> > > > > +if (ret == -EAGAIN) {
>
> > > when there's a partial write, it tries to do a write again, which will
> > > fail with -EAGAIN.
> >
> > Doesn't that cause the first partial chunk to be incorrectly transmitted
> > twice? You may only return EAGAIN if no data was transmitted.
>
> Except for the fact that no caller of qemu_c
> Logically, implementation of Vmull.s32 and vmul.u32 is just similar to the
> 8 and 16 bit cases. For example:
> case 4: gen_helper_neon_mull_s32(dest, a, b); break;
> case 5: gen_helper_neon_mull_u32(dest, a, b); break;
> I implemented in this way and tested. It is OK. So I can't understa
> On (Thu) Dec 02 2010 [17:31:36], Paul Brook wrote:
> > > > > when there's a partial write, it tries to do a write again, which
> > > > > will fail with -EAGAIN.
> > > >
> > > > Doesn't that cause the first partial chunk to be i
> > As with the DMA interface added a while ago, I believe it's important to
> > get these APIs right. Quick hacks to support limited use-cases just end
> > up needing a complete rewrite (or even worse multiple concurrent
> > APIs/implementations) once we actually start using them seriously.
>
>
> > > Sure. My proposal is for qemu_chr_write() to succeed all the time. If
> > > the backend can block, and the caller can handle it, it can get a
> > > -EAGAIN (or WSAEWOULDBLOCK) return. When the backend becomes writable,
> > > the chardev can call the ->writes_unblocked() callback for that c
> > > > > But that's entirely in guest memory, so it's limited to the amount
> > > > > of RAM that has been allocated to the guest.
> > > >
> > > > Exactly. The guest can cause ram_size * nr_ports of additional host
> > > > memory to be allocated. Not acceptable.
> > >
> > > OK -- so this is how
> Check if the guest really sent any items in the out_vq before using
> them. Similarly, check if there is a buffer to send data in before
> writing.
Can this actually happen? If so why/how?
Why does it need a special case in this device?
If this is guest triggerable then calling abort() is wron
> On (Fri) Dec 10 2010 [14:02:37], Paul Brook wrote:
> > > -if (!discard) {
> > > +if (discard) {
> > > +goto next;
> > > +}
> > >
> > > +next:
> > > virtqueue_push(vq, &elem, 0
> On (Fri) Dec 10 2010 [13:59:50], Paul Brook wrote:
> > > Check if the guest really sent any items in the out_vq before using
> > > them. Similarly, check if there is a buffer to send data in before
> > > writing.
> >
> > Can this actually happen? If
> -if (!discard) {
> +if (discard) {
> +goto next;
> +}
> +next:
> virtqueue_push(vq, &elem, 0);
Please don't do this.
Paul
Not a qemu bug. madvise and (associated constants via sys/mman.h) are
supplied by glibc. You need to update your C library.
** Changed in: qemu
Status: New => Invalid
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bug
> On Thu, Dec 02, 2010 at 01:12:13PM +0100, Kevin Wolf wrote:
> > > DEFINE_PROP_UINT16("physical_block_size", _state,
> > > \
> > >
> > > _conf.physical_block_size, 512),
> > > \
> > >
> > >
> On Sat, Dec 11, 2010 at 12:50:20PM +0000, Paul Brook wrote:
> > > It's guest visible state, so it must not change due to migrations. For
> > > the current implementation all values for it work anyway - if it's
> > > smaller than the block size w
> This adds a minimum chunk of Anthony's RAM API support so that we
> can identify actual VM RAM versus all the other things that make
> use of qemu_ram_alloc.
Why do we care? How are you defining "actual VM RAM"?
Surely the whole point of qemu_ram_alloc is to allocate a chunk of memory that
can
> I have some questions about PCIe operations sssuming the device has MMIO
> handlers involved (as shown above).
> 1. Will all PCIe config operations
> ALWAYS use the installed config handlers? Or can PCIe config operations
> use the MMIO handlers?
Access to PCI config space is provided by the P
> Hello.
>
> I am working on implementation of deteministic execution replay technology
> for Qemu. It should be similar to VMWare's replay debugging.
>
> To make alarm timer (which invokes host_alarm_handler function)
> determinisic, I changed it's behavior: it sets flag, that execution should
> +int is_ioport_assigned(pio_addr_t addr)
Shouldn't we move this into register_ioport_{read,write}, and have that fail
if the port has already been assigned?
Paul
> Notice that this patch was sent against hpet as one example, if we agree
> that this "way" of disabling devices is ok, we could disable more
> devices/have more flexibility. Notice that in general, we (RHEL/KVM)
> are interested in a small subset of qemu devices.
IMO this patch is a backwards s
> On 05/24/2010 11:32 AM, Paul Brook wrote:
> >> Notice that this patch was sent against hpet as one example, if we agree
> >> that this "way" of disabling devices is ok, we could disable more
> >> devices/have more flexibility. Notice that in general, we (
> for (i = 0; i < 24; i++) {
> sysbus_connect_irq(sysbus_from_qdev(hpet), i, isa_irq[i]);
> }
> +rtc_irq = qemu_allocate_feedback_irqs(hpet_handle_rtc_irq,
> + sysbus_from_qdev(hpet), 1);
> }
This is wrong. Th
> +static SysBusDeviceInfo hpet_device_info = {
> +.qdev.name= "hpet",
> +.qdev.size= sizeof(HPETState),
> +.qdev.no_user = 1,
Why shouldn't the user create HPET devices? I thought you'd removed all the
global state.
Paul
> > This is wrong. The hpet device should expose this as an IO pin.
>
> Will look into this.
>
> BTW, I just realized that the GPIO handling is apparently lacking
> support for attaching an output to multiple inputs. Or am I missing
> something?
Use an explicit mux.
Incidentally I suspect your
> Paul Brook wrote:
> >>> This is wrong. The hpet device should expose this as an IO pin.
> >>
> >> Will look into this.
> >>
> >> BTW, I just realized that the GPIO handling is apparently lacking
> >> support for attaching
> > I realise that. However I'd expect things to break if the guest OS
> > devices to share an IRQ line between the HPET and some other device.
>
> The guest would share IRQ8, not the RTC output. So there would be no
> difference to the current situation.
The difference is that you've removed the
> At the other extreme, would it be possible to make the educated guests
> aware of the virtualization also in clock aspect: virtio-clock?
The guest doesn't even need to be aware of virtualization. It just needs to be
able to accommodate the lack of guaranteed realtime behavior.
The fundamental
> > In some cases we don't even do that, and just reschedule the event some
> > arbitrarily small amount of time later. This assumes the guest to do
> > useful work in that time. In a single threaded environment this is
> > probably true - qemu got enough CPU to inject the first interrupt, so
> > w
> >> Then the amount
> >> of CPU cycles between timer interrupts would increase and hopefully
> >> the guest can keep up. If the guest sleeps, time base could be
> >> accelerated to catch up with wall clock and then set back to 1:1 rate.
> >
> > Can't follow you ATM, sorry. What should be slowed
> Try to pci hotplug a vga card, watch qemu die with hw_error().
> This patch fixes it.
I think this is wrong. There's no reason why VGA adapters shouldn't be
hotplugged. You should fix the underlying problems that prevent hotplugging
(or make them fail gracefully).
Paul
> The problem is that this path is never used as tsr_retry is never > 0
> initially. So if qemu_chr_write() fails, we never try again but drop
qemu_chr_write is a blocking interface. It should only fail if an
unrecoverable error occurs. In that case there's noting useful we can do, and
no reason
> Use a qemu_irq to request CPU exit.
Needing to request a CPU exit at all is just wrong. See previous discussions
about how any use of qemu_bh_schedule_idle is fundamentally broken.
Paul
> The system emulators for each arch are using inconsistent
> naming for the default PCI bus "pci" vs "pci.0". Since it
> is conceivable we'll have multiple PCI buses in the future
> standardize on "pci.0" for all architectures. This ensures
> mgmt apps can rely on a name when assigning PCI devices
> The basic device interface looks like
> ...
> +
> +/* Register a memory region at START_ADDR/SIZE. The REGION structure will
> + be initialized appropriately for DEV using CB as the operation set. */
> +extern void cpu_register_memory_region(MemoryRegion *region,
> +
[Hit send too early on previous mail...]
> The basic device interface looks like
> ...
> +
> +/* Register a memory region at START_ADDR/SIZE. The REGION structure will
> + be initialized appropriately for DEV using CB as the operation set. */
> +extern void cpu_register_memory_region(MemoryRegi
> On Thu, May 27, 2010 at 2:39 PM, Michael S. Tsirkin wrote:
> > On Sun, May 23, 2010 at 08:34:30PM +, Blue Swirl wrote:
> >> Convert also APB to use the registration so that
> >> we can remove mem_base.
> >>
> >> Signed-off-by: Blue Swirl
> >> ---
> >> hw/apb_pci.c | 23 +
> On Fri, May 28, 2010 at 7:34 PM, Paul Brook wrote:
> >> Use a qemu_irq to request CPU exit.
> >
> > Needing to request a CPU exit at all is just wrong. See previous
> > discussions about how any use of qemu_bh_schedule_idle is fundamentally
> > broken.
>
> The problem is that the ID names of default devices in machines are ABI
> sensitive. Management apps need to know what the ID of these default
> devices are. The x86 machines have already used 'pci.0' as their name
> in the previous 0.12 release and libvirt is using this naming. We later
> discov
> Paul Brook writes:
> >> The system emulators for each arch are using inconsistent
> >> naming for the default PCI bus "pci" vs "pci.0". Since it
> >> is conceivable we'll have multiple PCI buses in the future
> >> standardize o
> Re: 68a1c816868b3e35a1da698af412b29e61b1948a
>
> In general, I like the idea (especially since I've proposed it before. ;-)
>
> However:
>
> +if (have_guest_base) {
> +flags |= MAP_FIXED;
> +}
>
> I think this is broken. If the user specifies -G n -R m they're ho
>Hi,
>
> > I disagree. Anything that depends on device creation order is
> > fundamentally broken. If you want to create globally unique
> > user-friendly tags for devices or busses then that is a completely
> > different problem, and should be done via explicit aliases.
>
> For anything cre
> From pthread man:
>
> These functions manipulate the calling thread's stack of
> thread-cancellation clean-up handlers. A clean-up handler is
> a function that is automatically executed when a thread is canceled
> [...] it might, for example, unlock a mutex so that it becomes
> availab
> From: Jan Kiszka
>
> As long as we allow /dev.1 as shortcut for /dev1/bus1, we also have to
> make sure that /dev1/dev2 works for /dev1/bus1/dev2/bus2 - as long as
> there is only one child bus per device.
How about we make this explicit in the syntax by having a different separator
for bus n
> Also require IDs to start with a letter to provide for possible future
> extensions.
I'd go further than that, and require that user specified IDs match
[A-Za-z][A-Za-z0-9_-]*
Paul
> I'm trying to get arm big endian support to work. I patched the 2.6.33
> kernel to pretend that good old versatilepb can have a big endian CPU
> plugged into it (attached), and then I built a kernel with the attached
> .config, and qemu went "boing":
That's about the result I'd expect. The fact
> the "irqchip" option, if you note, is not x86-specific, in any case.
> Any machine has an irqchip. The first idea was to use something like
> "apic=in_kernel|userspace" which would be, that, very x86-centric.
How is this not x86-pc specific? All you're doing is creating two different
machines,
> Paul Brook writes:
> >> Also require IDs to start with a letter to provide for possible future
> >> extensions.
> >
> > I'd go further than that, and require that user specified IDs match
> > [A-Za-z][A-Za-z0-9_-]*
>
> I talked with Dan
> Kill nographic timer. Have a global gui_timer instead. Have the gui
> timer enabled unconditionally. We need a timer running anyway for mmio
> flush, so the whole have-gui-timer-only-when-needed logic is pretty
> pointless. It also simplifies displaylisteners coming and going at
> runtime, we
> With -netdev, there now seems to be little need to support vlans,
> enabling them leads to user confusion and bad performance.
> Disable support for vlans by default, add config option to enable.
No. If you want to remove vlans, then actually do that.
As I've said before if you want a point-poin
> On Mon, Jun 07, 2010 at 05:16:30PM +0100, Paul Brook wrote:
> > > With -netdev, there now seems to be little need to support vlans,
> > > enabling them leads to user confusion and bad performance.
> > > Disable support for vlans by default, add config option to en
> diff --git a/hw/realview.c b/hw/realview.c
> index a36bdbe..8dcef80 100644
> --- a/hw/realview.c
> +++ b/hw/realview.c
> @@ -444,9 +444,9 @@ static QEMUMachine realview_eb_mpcore_machine = {
> .init = realview_eb_mpcore_init,
> .opts_default = (QemuOptValue[]) {
> QOPT_VALUE("d
> max_cpus is complicated because it was used for multiple purposes.
I don't see any such uses.
> > This is a fundamental property/limitation of the hardware. Expect qemu to
> > crash if the value is modified.
>
> In this case, the machine cores should be rejecting totally invalid
> values to pr
> This series introduces a rather radical change in the way we deal with
> machine definitions in QEMU.
I think we should aim to eliminate machine_register_core, and design
appropriately. In particular I'd try and avoid adding options that become
trivially redundant once you can easily change t
> >> Kill nographic timer. Have a global gui_timer instead. Have the gui
> >> timer enabled unconditionally. We need a timer running anyway for mmio
> >> flush, so the whole have-gui-timer-only-when-needed logic is pretty
> >> pointless. It also simplifies displaylisteners coming and going at
>
> > I'm undecided how much parameterisation it's worth trying to support in
> > the device tree. IMO the current code has way too much magic, because
> > creating a new variant involves hacking and rebuilding pc.c.
>
> See patch 22/22. There is really no magic involved, even though the
> compat m
> I see three possible options to handle this.
>
>(1) Write a hub (or morph the current vlan code into this). Then
>you can do something like:
>
> qemu -netdev socket,id=p1 \
> -netdev user,id=p2 \
> -netdev dump,id=p3 \
>
> The problem I was trying to address can be seen with something like:
>
> -drive file=foo.img,if=virtio,file=bar.img
>
> You get no error, and foo.img is what gets used. It's fair to argue
> this is a silly use case but what I'm trying to achieve is to make it
> possible to do:
>
> -drive file
> > Once you eliminate machine_register_core that knowledge has
> >
> > somehow got to come from your device tree description file. Having a
> > single device tree that can morph into significantly different machines
> > seems like unnecessary complexity given this is a user-specified file.
>
> >>>Once you eliminate machine_register_core that knowledge has
> >>>
> >>> somehow got to come from your device tree description file. Having a
> >>> single device tree that can morph into significantly different machines
> >>> seems like unnecessary complexity given this is a user-specifie
> The offset given to a block created via qemu_ram_alloc/map() is arbitrary,
> let the caller specify a name so we can make a positive match.
> @@ -1924,7 +1925,9 @@ static int pci_add_option_rom(PCIDevice *pdev)
> +snprintf(name, sizeof(name), "pci:%02x.%x.rom",
> + PCI_SLOT(pdev-
> On 06/08/2010 09:30 PM, Paul Brook wrote:
> >> The offset given to a block created via qemu_ram_alloc/map() is
> >> arbitrary, let the caller specify a name so we can make a positive
> >> match.
> >>
> >>
> >> @@ -1924,7
> > > Not all ram is associated with a device.
> >
> > Maybe not, but where it is we should be using that information.
> > Absolute minimum we should be using the existing qdev address rather than
> > inventing a new one. Duplicating this logic inside every device seems
> > like a bad idea so I s
> * Alex Williamson (alex.william...@redhat.com) wrote:
> > +// XXX check duplicates
>
> Yes, definitely. You created a notion of a hierarchical namespace,
> can this be formalized any more?
We already have one: The qdev tree.
Paul
> Keep in mind, this has to be a stable string across versions of qemu
> since this is savevm/migration. Are we absolutely confident that the
> full qdev path isn't going to change? I'm more confident that a unique
> device name is going to be static across qemu versions.
The actual representati
> >> Because at some point the base tree will have to be written in C.
> >
> > No. You can start with a completely empty machine.
> > We don't/shouldn't need any machine specific C code.
>
> I think you're missing the argument. I should be possible to create a
> machine entirely from a FDT or vi
> > Not really. This identifier is device and bus independent, which is why
> > I suggested passing the device to qemu_ram_alloc. This can then figure
> > out how to the identify the device. It should probably do this the same
> > way that we identify the saved state for the device. Currently I
> >> AFAICS the current commandline options only result in simple addition of
> >> devices. They might add slightly different devices in slightly different
> >> places, but that's easy to accommodate by having the machine define a
> >> few standard device/bus IDs.
> >>
> >> IMO it's even more lame
> For usb hid devices: No idea how they work and whenever we can put them
> into sleep somehow (with/without guest cooperation).
The issue with USB is that it is (by design) a polled system. The UHCI adapter
has to wakeup every 1ms to read transfer descriptors from guest RAM.
Until recently ther
> On Thu, 2010-06-10 at 10:23 +0200, Gerd Hoffmann wrote:
> > > I may have been a bit misleading here. What we really want to do is use
> > > the same matching algorithm as is used by the rest of the device
> > > state. Currently this is a vmstate name and [arbitrary] numeric id. I
> > > don't reme
> > > to the identify the device. It should probably do this the same way
> > > that we identify the saved state for the device. Currently I think
> > > this is an arbitrary vmstate name/id, but I expect this to change to a
> > > qdev address (e.g. /i440FX-pcihost/pci.0/_addr_04.0").
> >
> > Ok,
> Note that I *only* object to case 2 (derive bus name from parent
> device's ID). Case 3 (derive bus name from bus type) is fine with me.
>
> > Using a single counter for all busses is also wrong. The order of bus
> > creation is a device implementation detail, under no circumstances
> > should
> The trouble I'm running into is that the SaveStateEntry.instance_id is
> effectively private, and there's no easy way to associate a
> SaveStateEntry to a device since it passes an opaque pointer, which
> could be whatever the driver decides it wants. I'm wondering if we
> should pass the Device
When combining multiple values as part of a NEON array load, do explcit
shift/or rather than using gen_bfi. This voids redundant mask
operations.
Signed-off-by: Paul Brook
---
target-arm/translate.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/target-arm
201 - 300 of 1782 matches
Mail list logo
