> +tcg_gen_shli_i32(tmp2, tmp, 16);
> +tcg_gen_or_i32(tmp, tmp, tmp2);
Which if you're paying attention is incorrect. Actual committed patch is
correct - tcg_gen_shli_i32(tmp2, tmp2, 16);
Paul
> +} else if (timer_fsb_route(timer)) {
> +apic_send_msi(timer->fsb >> 32, timer->fsb & 0x);
This should use a regular memory write, like the PCI MSI-X code does.
Paul
> This patch allows to optionally attach a message to an IRQ event. The
> message can contain a payload reference and a callback that the IRQ
> handler may invoke to report the delivery result. The former can be used
> to model message signaling interrupts, the latter to cleanly implement
> IRQ de-
> On Sat, Jun 12, 2010 at 12:21 PM, Paul Brook wrote:
> >> This patch allows to optionally attach a message to an IRQ event. The
> >> message can contain a payload reference and a callback that the IRQ
> >> handler may invoke to report the delivery result. The fo
> I think message passing interrupts
> are only used in bus based systems, like PCI or UPA/JBUS etc. I don't
> know how LAPIC/IOAPIC bus works, it could be similar.
PCI Message Signalled Interrupts use a regular data write, and we model it
exactly that way. Under normal circumstances you program
> > [*] A simple unidirectional dma request line is suitable for qmu_irq. A
> > DMA system that transfers data outside of memory read/write transactions
> > is not. e.g. ISA effectively defines a regular memory bus plus 8
> > bidirectional data streams (aka DMA channels). These are multiplexed
> >
> I think we could solve all problems (well, maybe not world peace, yet)
> by switching to message based system for all of DMA and IRQs.
>
> Each device would have a message input port and way to output messages.
>
> Examples:
>
> Zero copy memory access from device D1 to D2 to host memory (D3)
> TBH I preferred the original system whereby the source can query the state
> of the sink (i.e "are you ignoring this line?"). Note that conceptually
> this should be *querying* state, not responding to an event.
People are still pushing qemu_irq as an message passing interface, so I'm
going to
Move inclusion of stdbool.h to common header files, instead of including
in an ad-hoc manner.
Signed-off-by: Paul Brook
---
block/blkdebug.c |2 --
check-qjson.c|1 -
dyngen-exec.h|1 +
hw/9p.h |2 --
hw/eepro100.c|1 -
hw/hw.h
> On Sun, Jun 13, 2010 at 3:49 PM, Paul Brook wrote:
> >> I think we could solve all problems (well, maybe not world peace, yet)
> >> by switching to message based system for all of DMA and IRQs.
> >>
> >> Each device would have a messag
> >> For the memory access case, in practice the interface could be
> >> sysbus_memory_rw(DeviceState *parent, target_phys_addr_t addr,
> >> target_phys_addr_t size)
> >
> > Why "parent"?
>
> Parent device or bus host bridge device. Alternatively there could be
> a bus handle.
A device has no wa
> > And I think we can move the capability setup into init. But this is not
> > directly related to this patch, would just avoid adding this hunk to
> > hpet_reset.
>
> I actually did that initially and tried to init hpet_cfg there too, but
> then noticed that mmio[0].addr below is not initialized
> > > "/main-system-bus/pci.0,addr=09.0/virtio-blk-pci"
There's a device missing between the main system bus and the pci bus. Should
be something like:
/main-system-bus/piix4-pcihost/pci.0/_09.0
> > Could you explain why you add "identified properties of the immediate
> > parent bus and device
> On Mon, 2010-06-14 at 14:09 +0100, Paul Brook wrote:
> > > > > "/main-system-bus/pci.0,addr=09.0/virtio-blk-pci"
> >
> > There's a device missing between the main system bus and the pci bus.
> > Should be something like:
> >
> > /
> On Mon, 2010-06-14 at 18:49 +0200, Jan Kiszka wrote:
> > Alex Williamson wrote:
> > > On Mon, 2010-06-14 at 18:00 +0200, Jan Kiszka wrote:
> > >> And instead of introducing another hierarchy level with the bus
> > >> address, I would also prefer to add this as prefix or suffix to the
> > >> devic
> > > Ok, I can get it down to something like:
> > >
> > > /i440FX-pcihost/pci.0/virtio-blk-pci,09.0
> > >
> > > The addr on the device is initially a little non-intuitive to me since
> > > it's a property of the bus, but I guess it make sense if we think of
> > > that level as slot, which includ
> >> This suggests we are incorrectly coalescing writes, and we should
> >> actually be
> >> notifying qemu when (at least) he first write occurs. If we aren't
> >> outputting
> >> anything we don't want to be waking up periodically just to flush an
> >> empty
> >> MMIO buffer.
> >
> > That is com
> >> -static void ioapic_reset(void *opaque)
> >> +static void ioapic_reset(DeviceState *d)
> >> {
> >> -IOAPICState *s = opaque;
> >> +IOAPICState *s = container_of(d, IOAPICState, busdev.qdev);
> >
> > DO_UPCAST()? I hate it, but it's what the other devices do...
>
> Both are used:
>
> > >>Could we just have qemu build the hpet tables and pass them through to
> > >>seabios? Perhaps using the qemu_cfg_acpi_additional_tables() method.
> > >
> > >Possible, and I considered that. I personally prefer to pass minimum
> > >information required for seabios to discover underlying HW an
> > In fact what you really want to do is transfer the device tree
> > (including properties), and create the machine from scratch, not load
> > state into a pre-supplied device tree.
>
> Well, I agree, but that's a lot more of an overhaul, and once again
> we're changing the problem.
I think it'
> > Alex proposed to disambiguate by adding "identified properties of the
> > immediate parent bus and device" to the path component. For PCI, these
> > are dev.fn. Likewise for any other bus where devices have unambigous
> > bus address. The driver name carries no information!
>
> From user PO
> >> From user POV, driver names are very handly to address a device
> >> intuitively - except for the case you have tones of devices on the same
> >> bus that are handled by the same driver. For that case we need to
> >> augment the device name with a useful per-bus ID, derived from the bus
> >> a
> Paul Brook wrote:
> >>>> From user POV, driver names are very handly to address a device
> >>>> intuitively - except for the case you have tones of devices on the
> >>>> same bus that are handled by the same driver. For that case we need
> >&
> >> Works for serial, but fails for ISA devices not occupying an address.
> >
> > An ISA device without an IO/MMIO capabilities seems extremely unlikely.
> > What exactly would such a device do?
>
> Inject interrupts via that bus (while exposing registers in some other
> way). The m48t59 seems t
> > Every hotplug-capable bus must have a proper addressing scheme, I think
> > this is a reasonable and achievable requirement. Then we don't need
> > instance numbers for those buses.
>
> What about USB?
USB has useful device addresses (physical ports).
These aren't used by most of the higher-l
> > > Every hotplug-capable bus must have a proper addressing scheme, I think
> > > this is a reasonable and achievable requirement. Then we don't need
> > > instance numbers for those buses.
> >
> > What about USB?
>
> USB has useful device addresses (physical ports).
> These aren't used by most
> On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
> > > > Alex proposed to disambiguate by adding "identified properties of the
> > > > immediate parent bus and device" to the path component. For PCI,
> > > > these are dev.fn. Likewise for an
> > I find this argument contradictory. The migration code already needs to
> > check whether a device is compatible before it allows migration. The
> > driver name is not sufficient to ensure compatibility, so I see no
> > benefit in including it in the device address.
>
> See my comment above,
> * Paul Brook (p...@codesourcery.com) wrote:
> > > > I find this argument contradictory. The migration code already needs
> > > > to check whether a device is compatible before it allows migration.
> > > > The driver name is not sufficient to ensure compat
> > > > > See my comment above, I'm not seeing a sufficient argument about
> > > > > why driver name matching is a false sense of security.
> > > >
> > > > I still say it should be the migration code that checks that both
> > > > vmstate structures are for the same type of device. i.e. if
> > > >
> * Else, use TYPE.NUM, where TYPE is derived from the bus type, and NUM
> is the bus number, as above.
>
> ### Paul proposes to either drop TYPE.NUM (and require drivers to
> provide bus names), or make NUM count separately for each bus type.
I revised this proposal: Drop the .NUM part, an
> Markus Armbruster wrote:
> > A number of changes to qdev paths have been proposed in various threads.
> > It's becoming harder to keep track of them, so let me sum them up in one
> > place. Please correct me if I misrepresent your ideas.
> >
> > I'm going to describe the current state of things
Teach strace code about linux specific mprotect flags.
Signed-off-by: Paul Brook
---
linux-user/strace.c |3 +++
linux-user/syscall_defs.h |6 ++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/linux-user/strace.c b/linux-user/strace.c
index d77053b..bf9a0d9
Report exit status to GDB when a semihosted application exits.
Signed-off-by: Paul Brook
---
arm-semi.c |1 +
gdbstub.c | 34 --
gdbstub.h |2 +-
m68k-semi.c |1 +
4 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/arm-semi.c b
When loading a shared library that requires an executable stack,
glibc uses the mprotext PROT_GROWSDOWN flag to achieve this.
We don't support PROT_GROWSDOWN.
Add a special case to handle changing the stack permissions in this way.
Signed-off-by: Paul Brook
---
linux-user/elfload.c |
> > I think this would be better served by adding explicit aliases/IDs for
> > those use-cases. i.e. define the global ID "pci.0" to be an alias for
> >
> > /i440FX-pcihost/pci
>
> Makes sense. We could attach this ID to the BusState (corresponding to
> DeviceState:id) and manually set it during
> > Bus names are chosen by the system as follows:
> >
> > * If the driver of the parent device model provides a name, use that.
> >
> > * Else, if the parent device has id ID, use ID.NUM, where NUM is the bus
> >
> > number, counting from zero in creation order.
> >
> > * Else, use TYPE.NUM,
> > ### Paul proposes to require all buses to define bus addresses. Make
> > one up if necessary.
>
> That seems arbitrary and prone to breakage. How do we handle a subtle
> change in device instantiation order and still allow migration? If by
> code change or command line ordering my frobn
> $ qemu-system-arm -semihosting -cpu cortex-a9 -nographic -kernel
> ./input.exe
-nographic implies -monitor stdio -serial stdio. Don't do that if you want to
access stdio via semihosting.
Paul
> So I've been looking for a way to obtain things like a PCIDevice from a
> more generic structure (say from hw/qdev.h),
If you're having to figure out what kind of a device you have then I think
you're already doing something else wrong. I'd expect the bits of code that
needs to identify device
> Thanks for your reply. This isn't about a specific IOMMU. Let me
> describe the situation better:
>
> 1. I'm implementing the AMD IOMMU, which is a PCI IOMMU (not in the CPU).
> 2. Devices need address translation and checking through this IOMMU.
> 3. But in the future there might be other IOMMU
> The user basically can specify two things:
>
> - a transport protocol. Normally this is just the filesystem
>interface, but it can also be nbd, http or for really sick people
>vvfat. This is a setting which can't be guessed, btw - it needs
>to be explicitly set in some way, with f
> diff --git a/exec-all.h b/exec-all.h
> index a775582..ebe88ad 100644
> --- a/exec-all.h
> +++ b/exec-all.h
> @@ -353,4 +353,8 @@ extern int singlestep;
> /* cpu-exec.c */
> extern volatile sig_atomic_t exit_request;
>
> +#ifdef NEED_GLOBAL_ENV
> +register CPUState *env asm(AREG0);
> +#endif
W
> On 06/28/2010 10:29 PM, Paul Brook wrote:
> >> diff --git a/exec-all.h b/exec-all.h
> >> index a775582..ebe88ad 100644
> >> --- a/exec-all.h
> >> +++ b/exec-all.h
> >> @@ -353,4 +353,8 @@ extern int singlestep;
> >>
> >>
> On 06/29/2010 03:51 PM, Paolo Bonzini wrote:
> > On 06/29/2010 01:30 PM, Paul Brook wrote:
> >> I don't understand what this is supposed to achieve. The inclusion
> >> of exec.h is what defines whether this global variable is
> >> available. Just as impo
> >> BTW, this may be useful for one thing: being able to include exec.h
> >> without bringing in the global variable.
> >
> > I'd argue that's not a desirable feature. I'd much rather have exec.h be
> > the controlling factor than have all files include the same set of
> > headers and have semant
> Since it solves existing problem and is rejected without any rational
> explanation and without proposing alternative solution (in form of code)
> it should be committed.
No. This is not sufficient justification for applying a patch. We should not
be accepting patches just because they exist.
> I really see no tangible objection to Jan's patches. They don't impact
> any other code. They don't inhibit flexibility in the infrastructure.
> You might consider it to be a "hack" but so what. QEMU is filled with
> hacks. It would be useless without them because there would be very
> little
> Here is the patch again. There may be more work to be done on top of this,
> but this patch staying out of tree hasn't noticeably accelerated that work
> in the past year and change. Could it please be merged?
As mentioned previously, "V5" should be split into its component parts.
Paul
> Blue Swirl wrote:
> > On Sat, Jul 3, 2010 at 7:39 AM, Jan Kiszka wrote:
> >> Paul Brook wrote:
> >>>> I really see no tangible objection to Jan's patches. They don't
> >>>> impact any other code. They don't inhibit flexibility in
> Memory accesses must go through the IOMMU layer.
No. Devices should not know or care whether an IOMMU is present.
You should be adding a DeviceState argument to cpu_physical_memory_{rw,map}.
This should then handle IOMMU translation transparently.
You also need to accomodate the the case wher
> On Wed, Jul 14, 2010 at 02:53:03PM +0100, Paul Brook wrote:
> > > Memory accesses must go through the IOMMU layer.
> >
> > No. Devices should not know or care whether an IOMMU is present.
>
> There are real devices that care very much about an IOMMU. Basically all
> + --enable-amd-iommu-emul) amd_iommu="yes"
> +#ifdef CONFIG_AMD_IOMMU
> +amd_iommu_init(pci_bus);
> +#endif
This should not be a configure option.
Paul
> > The right approach IMHO is to convert devices to use bus-specific
> > functions to access memory. The bus specific functions should have
> > a device argument as the first parameter.
>
> As for ATS, the internal api to handle the device's dma reqeust needs
> a notion of a translated vs. an un
> > Depending how the we decide to handle IOMMU invalidation, it may also be
> > necessary to augment the memory_map API to allow the system to request a
> > mapping be revoked. However this issue is not specific to the IOMMU
> > implementation. Such bugs are already present on any system that all
> On Wed, Jul 14, 2010 at 09:13:44PM +0100, Paul Brook wrote:
> > A device performs a memory access on its local bus. It has no knowledge
> > of how that access is routed to its destination. The device should not
> > be aware of any IOMMUs, in the same way that it do
> On Wed, Jul 14, 2010 at 02:53:03PM +0100, Paul Brook wrote:
> > > Memory accesses must go through the IOMMU layer.
> >
> > No. Devices should not know or care whether an IOMMU is present.
>
> They don't really care. iommu_get() et al. are convenience funct
> >>> Depending how the we decide to handle IOMMU invalidation, it may also
> >>> be necessary to augment the memory_map API to allow the system to
> >>> request a mapping be revoked. However this issue is not specific to
> >>> the IOMMU implementation. Such bugs are already present on any system
> The qemu-kvm could boot from SCSI disk image by utilizing seabios, this
> patch ported codes
> from qemu-kvm to let upstream qemu to support booting from SCSI disk image.
No. This has nothing to do with SCSI.
What it does is add a really cheap and nasty block storage device that aliases
one of
> > This has been discussed several times before. The proper solution is to
> > teach the bios how to boot off SCSI devices. IIRC support for virtio
> > devices already exists, implementing support for the SCSI controller
> > shouldn't be that much harder.
>
> Couldn't we just have an option rom f
> > Couldn't we just have an option rom for the SCSI controller? The same way
> > the VGABIOS is a rewrite of a VGA BIOS for the Cirrus Logic...
>
> Of course we could, but it should not be extboot, but proper scsi driver.
> gpxe has src/drivers/block/scsi.c so may be it already supports qemu scsi
> I suggest these steps:
>
> 1. Debug output to stdout is no longer accepted for new / modified code.
>
> 2. New or modified debug messages should go to stderr.
I don't see this as a real improvement. Arguably these aren't errors, so
stdout is where they should be going.
If we're going to do
> Bottom halves are run at the very end of the event loop which means that
> they're guaranteed to be the last thing run. idle bottom halves can be
> rescheduled without causing an infinite loop and do not affect the
> select timeout (which normal bottom halves do).
Idle bottom halves (i.e. qemu_
> vnet_hdr is IMHO a really bad example to copy from.
>
> vnet_hdr leaks into the migration state via n->has_vnet_hdr. What this
> means is that if you want to migrate from -net tap -net nic,model=virtio
> to -net user -net nic,model=virtio, it will fail.
>
> This is a hard problem to solve in q
> On Wed, Feb 24, 2010 at 03:14:25AM +0000, Paul Brook wrote:
> > > vnet_hdr is IMHO a really bad example to copy from.
> > >
> > > vnet_hdr leaks into the migration state via n->has_vnet_hdr. What this
> > > means is that if you want to migrate from -n
> > If we do have a software
> > fallback then the feature bit is just for backwards compatibility, and
> > should be enabled unconditionally (on current machine types).
>
> Software fallback might turn out to be slower than disabling the feature
> in the guest. For example, and extra pass over pac
> Before doing the switch, I need to figure out what to do with the
> current texi documentation. I think it makes sense to move
> qemu-doc.texi to a wiki page and remove it from the source repository.
> The other option would be to link to it as an external page and keep it
> within revision cont
> +++ b/hw/rtl8139.c
> @@ -41,6 +41,10 @@
> * segmentation offloading
> * Removed slirp.h dependency
> * Added rx/tx buffer reset when enabling
> rx/tx operation + *
> + * 2010-Feb-04 Fredian
> > Idle bottom halves (i.e. qemu_bh_schedule_idle) are just bugs waiting to
> > happen, and should never be used for anything.
>
> Idle bottom halves make considerable more sense than the normal bottom
> halves.
>
> The fact that rescheduling a bottom half within a bottom half results in
> an in
> Very simply, without idle bottom halves, there's no way to implement
> polling with the main loop. If we dropped idle bottom halves, we would
> have to add explicit polling back to the main loop.
>
> How would you implement polling?
AFAICS any sort of polling is by definition time based so use
> Since b567b38 (target-arm: remove T0 and T1, 2009-10-16) the only global
> register that is actually used is AREG0, so the complexity of
> hostregs_helper.h is unwarranted.
>
> Let's just say that env should be the only global register. AREG1 and
> AREG2 in principle could still be used to work
> On 02/26/2010 12:30 PM, Paul Brook wrote:
> >> Since b567b38 (target-arm: remove T0 and T1, 2009-10-16) the only global
> >> register that is actually used is AREG0, so the complexity of
> >> hostregs_helper.h is unwarranted.
> >>
> >> Let's
>diff --git a/qemu-lock.h b/qemu-lock.h
This code isn't used in any interesting ways, it should be removed..
Paul
> > I think it would be much cleaner to make the madvise() calls from
> > exec.c, now you are duplicating some of the functionality there. The
> > calls could be controlled by a global variable (set only in pc.c) so
> > non-PC architectures would not be disturbed.
>
> One thing we could do (that I
>+/*
>+ * ftruncate is not supported by hugetlbfs in older
>+ * hosts, so don't bother checking for errors.
>+ * If anything goes wrong with it under other filesystems,
>+ * mmap will fail.
>+ */
>+if (ftruncate(fd, memory))
>+ perror("ftruncate");
Code does not m
> Use led status notification support in vnc.
>
> The qemu vnc server keeps track of the capslock and numlock states based
> on the key presses it receives from the vnc client. But this fails in
> case the guests idea of the capslock and numlock state changes for other
> reasons. One case is gue
> On 02/25/10 11:23, Markus Armbruster wrote:
> > You're supposed to use scsi-generic for that. Which rejects anything
> > but /dev/sg*.
>
> Well, it isn't *that* easy. The SG_IO ioctl used by scsi-generic works
> on tons of devices in linux, not only /dev/sg*. I've seen patches
> floading arou
> > I'm pretty sure a guest can cause those to change and I'm not 100%
> > sure, but I think it's a potential source of exploits if you assume a
> > mapping. In the very least, a guest can trick vhost into writing to ram
> > that it wouldn't normally write to.
>
> This seems harmless. guest can
> > There certainly
> > exist machines that can change physical RAM mapping.
>
> I am talking about mapping between phy RAM offset and qemu virt address.
> When can it change without RAM in question going away?
RAM offset or guest physical address? The two are very different.
Some machines have
> > invalid/unsupported opcode: 00 - 00 - 00 () 4800fa44 1
>
> I have fixed that in HEAD by stopping the translation just after a trap,
> as the instructions might never be executed.
>
> It is not a full fix, as the OS can actually use any instruction that
> always generate a trap (even a
> /* All direct uses of g2h and h2g need to go away for usermode softmmu.
> */ #define g2h(x) ((void *)((unsigned long)(x) + GUEST_BASE))
> +
> +#if HOST_LONG_BITS == TARGET_VIRT_ADDR_SPACE_BITS
Shouldn't this be <= ?
1ul << T_V_A_S_B is undefined for 64-bit guests on 32-bit hosts.
> +#defin
> So guest can cause vhost to write to a wrong place in RAM, but it can
> just pass a wrong address directly.
That's not the point. Obviously any DMA capable device can be used to
compromise a system. However if a device writes to address B after being told
to write to address A, then you have
> I'm sympathetic to your arguments though. As qemu is today, the above
> is definitely the right thing to do. But ram is always ram and ram
> always has a fixed (albeit non-linear) mapping within a guest.
I think this assumption is unsafe. There are machines where RAM mappings can
change. It's
> Which brings us to the problem of exec.c and the address spaces therein.
> First, there was the fact that TARGET_PHYS_ADDR_SPACE_BITS was constrained
> to be no larger than 32 (with a partial hack for Alpha to extend this to
> 42 bits). Second, that this physical address space value was applied
> Since virtio devices can live on two busses (sysbus with Syborg or PCI),
> we need to introduce a set of virtio specific functions.
>...
> Inside the VirtIODevice, there would be corresponding function pointers,
> and depending on whether it was a PCI device or a Syborg device, it would
> call
> On 02/26/2010 07:32 PM, Paul Brook wrote:
> >> > You could still use them for local register variables, but I can
> >> > prepare a patch to remove them (unless you do that yourself).
> >
> > I'm not sure what you mean by a "local register varia
> ARMv7 has a simplified access permissions model that is enabled
> by setting the AFE bit of the SCTLR. This patch adds checking
> for permission values for when this mode is selected.
This is already implemented.
Paul
> > I think this assumption is unsafe. There are machines where RAM mappings
> > can change. It's not uncommon for a chip select (i.e. physical memory
> > address region) to be switchable to several different sources, one of
> > which may be RAM. I'm pretty sure this functionality is present (but
> >> With a new api, cpu_physical_memory_map() changes semantics. It only
> >> returns pointers for static ram mappings. Everything else is bounced
> >> which guarantees that an address can't change during DMA.
> >
> > Doesn't this mean that only the initial RAM is directly DMA-able?
> >
> > Whil
> I want to port QEMU on the ARM11 platform. I think, many developers try to
> this work.
Should already work.
Paul
> >> The key difference is that these regions are created and destroyed
> >> rarely and in such a way that the destruction is visible to the guest.
> >
> > So you're making ram unmap an asynchronous process, and requiring that
> > the address space not be reused until that umap has completed?
>
>
> The new function I'm proposing has the following semantics:
>
> - it always returns a persistent mapping
> - it never bounces
> - it will only fail if the mapping isn't ram
So you're assuming that virtio rings are in ram that is not hot-pluggable or
remapable, and the whole region is contiguou
> > That sounds like it's likely to come back and bite you. The guest has no
> > idea which areas of ram happen to be contiguous on the host.
>
> Practically speaking, with target-i386 anything that is contiguous in
> guest physical memory is contiguous in the host address space provided
> it's ra
> TCG internal helpers only access to the values passed in arguments, and
> do not modify the CPU internal state. Thus they can be declared as
> const and pure.
I think this needs an explanatory comment. It's not immediately obvious that
tcg_gen_helperN and tcg_gen_helper{32,64} have significantl
> Support an inter-vm shared memory device that maps a shared-memory object
> as a PCI device in the guest. This patch also supports interrupts between
> guest by communicating over a unix domain socket. This patch applies to
> the qemu-kvm repository.
No. All new devices should be fully qdev b
> On Fri, Mar 05, 2010 at 11:15:45AM +0000, Paul Brook wrote:
> > > TCG internal helpers only access to the values passed in arguments, and
> > > do not modify the CPU internal state. Thus they can be declared as
> > > const and pure.
> >
> > I think t
> On 03/08/2010 12:53 AM, Paul Brook wrote:
> >> Support an inter-vm shared memory device that maps a shared-memory
> >> object as a PCI device in the guest. This patch also supports
> >> interrupts between guest by communicating over a unix domain socket.
> >
> However, coherence could be made host-type-independent by the host
> mapping and unampping pages, so that each page is only mapped into one
> guest (or guest CPU) at a time. Just like some clustering filesystems
> do to maintain coherence.
You're assuming that a TLB flush implies a write barrie
> Signed-off-by: Paul Bolle
> ---
> usb-linux.c |3 ---
> 1 files changed, 0 insertions(+), 3 deletions(-)
>
> diff --git a/usb-linux.c b/usb-linux.c
> index a9c15c6..23155dd 100644
> --- a/usb-linux.c
> +++ b/usb-linux.c
> @@ -846,9 +846,6 @@ static int usb_linux_update_endp_table(USBHostDe
> Is there any reason (other than being coding style) in using qemu_free()
> instead of free()? As per qem-malloc.c qemu_free() is nothing but free().
The whole point of qemu_{malloc,free} is to isolate code from the system
implementation of malloc/free. It's entirely possible that future versio
301 - 400 of 1782 matches
Mail list logo
