> Where does the translator need access to this original code? I was
> just thinking about this problem today, wondering how much overhead
> there is with this SMC page protection thing.
When an MMU fault occurs qemu re-translates the TB with additional annotations
to determine which guest instr
> +#if defined(__linux__) && defined(__x86_64__)
> +#define MAX_TRANSPARENT_HUGEPAGE_SIZE (2*1024*1024)
> + if (size >= MAX_TRANSPARENT_HUGEPAGE_SIZE)
I'd prefer something like:
#if defined(__linux__) && defined(__x86_64__)
/* [...Allow the host to use huge pages easily...]. */
#define PRE
> Ideally this would evolve into supporting IPMI, which would allow
> managing VMs exactly like physical servers without concern, appart
> launching the actual process first.
> cf.
> http://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface
> http://openipmi.sourceforge.net/
>
> Anyon
> +#if !defined(CONFIG_USER_ONLY)
> if (arm_feature(env, ARM_FEATURE_XSCALE)
> && ((env->cp15.c15_cpar ^ 0x3fff) & (1 << cpnum)))
> return 1;
> +#endif
This is almost certainly the wrong way to fix this.
Paul
> +static uint32_t get_elf_hwcap(void)
> +{
> +return thread_env->features;
> +}
No. These values are not the same.
Paul
> Thanks for the review.
>
> On Sun, Mar 14, 2010 at 09:59:44PM +0000, Paul Brook wrote:
> > > The patch also convert all machines that have an addend, simplify the
> > > PowerPC kernel loading
> >
> > The new PPC code looks like it may break images > 16
> The patch also convert all machines that have an addend, simplify the
> PowerPC kernel loading
The new PPC code looks like it may break images > 16M in size.
> and fix the MIPS kernel loading using this new
> feature.
I'm fairly sure the MIPS routines are not board specific, so it'd be nice i
> On Sat, 13 Mar 2010, Paul Brook wrote:
> > > a) elfload.c:859
> > >
> > >#define TARGET_ELF_PAGESTART(_v) ((_v) & ~(unsigned
> > > long)(TARGET_ELF_EXEC_PAGESIZE-1))
> > >
> > >This means that for 64bit guest on a 32bit host t
> Richard Henderson schrieb:
> > Define L1_MAP_ADDR_SPACE_BITS to be either the virtual address size
> > (in user mode) or physical address size (in system mode), and use
> > that to size l1_map. This rewrites page_find_alloc, page_flush_tb,
> > and walk_memory_regions.
> >
> > Use TARGET_PHYS_ADD
> Commit 30724e758a21ba9f807efafe268626bd479db9de breaks
> malta (and other) mips 32 bit emulation.
>
> Fixing the physical address size for 32 bit machines
> makes it work again.
>-#define TARGET_PHYS_ADDR_SPACE_BITS 36
>+#define TARGET_PHYS_ADDR_SPACE_BITS 32
This is almost certainly the wrong
> a) elfload.c:859
>
>#define TARGET_ELF_PAGESTART(_v) ((_v) & ~(unsigned
> long)(TARGET_ELF_EXEC_PAGESIZE-1))
>
>This means that for 64bit guest on a 32bit host the _v's value is
>silently reduced to 32bit, the cast should be abi_ulong.
>
> b) mmap.c:428
>
>real_start = start
> /src/qemu/exec.c: In function `page_set_flags':
> /src/qemu/exec.c:2336: warning: comparison is always true due to
> limited range of data type
Should be fixed by b480d9b74dfd1efd29026b7dc6438364a633ee99
Paul
> Richard Henderson (6):
> Move TARGET_PHYS_ADDR_SPACE_BITS to target-*/cpu.h.
> Use TARGET_VIRT_ADDR_SPACE_BITS in h2g_valid.
> linux-user: Use h2g_valid in qemu_vmalloc.
> linux-user: Fix mmap_find_vma returning invalid addresses.
> Implement multi-level page tables.
> Fix last page e
>My point is that there is no need to show the smaller page sizes to
>userland, only the max one is relevant and this isn't going to change
>and I'm uncomfortable to add plural stuff to a patch that doesn't
>contemplate mixes page sizes and for the time being multiple hpage size
>isn't even on the
> > No particular preference. Or you could have .../page_sizes list all
> > available sizes, and have qemu take the first one (or last depending on
> > sort order).
>
> That would also work. Considering that the current transparent
> hugepage support won't support any more than 1 page, I think it'
> > So shouldn't [the name of] the value the kernel provides for recommended
> > alignment be equally implementation agnostic?
>
> Is sys/kernel/mm/transparent_hugepage directory implementation
> agnostic in the first place?
It's about as agnostic as MADV_HUGEPAGE :-)
> If we want to fully take
> On Fri, Mar 12, 2010 at 04:04:03PM +0000, Paul Brook wrote:
> > > > > $ cat /sys/kernel/mm/transparent_hugepage/hpage_pmd_size
> > > > > 2097152
>
> > Hmm, ok. I'm guessing linux doesn't support anything other than "huge"
> > a
> > allocates it on a 2M boundary. I suspect you actually want (base % 2M) ==
> > 1M. Aligning on a 1M boundary will only DTRT half the time.
>
> The 1m-end is an hypothetical worry that come to mind as I was
> discussing the issue with you. Basically my point is that if the pc.c
> code will chang
> > > $ cat /sys/kernel/mm/transparent_hugepage/hpage_pmd_size
> > > 2097152
> >
> > Is "pmd" x86 specific?
>
> It's linux specific, this is common code, nothing x86 specific. In
> fact on x86 it's not called pmd but Page Directory. I've actually no
> idea what pmd stands for but it's definitely n
> On Thu, Mar 11, 2010 at 05:55:10PM +0000, Paul Brook wrote:
> > sysconf(_SC_HUGEPAGESIZE); would seem to be the obvious answer.
>
> There's not just one hugepage size
We only have one madvise flag...
> and that thing doesn't exist yet
> plus it'd re
> +When wrapping standard library functions, use the prefix qemu_ to alert
> +readers that they are seeing a wrapped version; otherwise avoid this
> prefix. +
I'm tempted to say "When wrapping or providing functionality that could easily
be confused with standard library functions [...]".
I'm n
> On Thu, Mar 11, 2010 at 04:28:04PM +0000, Paul Brook wrote:
> > > > + /*
> > > > +* Align on HPAGE_SIZE so "(gfn ^ pfn)&
> > > > +* (HPAGE_SIZE-1) == 0" to allow KVM to take advantage
> Paul Brook wrote:
> >> 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 th
> > + /*
> > +* Align on HPAGE_SIZE so "(gfn ^ pfn)&
> > +* (HPAGE_SIZE-1) == 0" to allow KVM to take advantage
> > +* of hugepages with NPT/EPT.
> > +*/
> > + new_block->host = qemu_memalign(1<< TARGET_HPAGE_BITS, size);
This sh
> On 03/11/2010 06:57 AM, Paul Brook wrote:
> >> +struct QEMUNotifier
> >> +{
> >> +void (*notify)(QEMUNotifier *notifier);
> >> +};
> >
> > I suggest combining this with QEMUBH.
>
> I take it your not opposed to converting QEMUBH
> On 03/11/2010 01:57 PM, Paul Brook wrote:
> > +struct QEMUNotifier
> >
> > > +{
> > > +void (*notify)(QEMUNotifier *notifier);
> > > +};
> >
> > I suggest combining this with QEMUBH.
>
> I didn't understand this suggestion
> +struct QEMUNotifier
> +{
> +void (*notify)(QEMUNotifier *notifier);
> +};
>
I suggest combining this with QEMUBH.
Paul
> On 03/10/2010 07:41 PM, Paul Brook wrote:
> >>> You're much better off using a bulk-data transfer API that relaxes
> >>> coherency requirements. IOW, shared memory doesn't make sense for TCG
> >>
> >> Rather, tcg doesn't make
> > You're much better off using a bulk-data transfer API that relaxes
> > coherency requirements. IOW, shared memory doesn't make sense for TCG
>
> Rather, tcg doesn't make sense for shared memory smp. But we knew that
> already.
In think TCG SMP is a hard, but soluble problem, especially when
> >> As of March 2009[1] Intel guarantees that memory reads occur in order
> >> (they may only be reordered relative to writes). It appears AMD do not
> >> provide this guarantee, which could be an interesting problem for
> >> heterogeneous migration..
> >
> > Interesting, but what ordering would c
> > In a cross environment that becomes extremely hairy. For example the x86
> > architecture effectively has an implicit write barrier before every
> > store, and an implicit read barrier before every load.
>
> Btw, x86 doesn't have any implicit barriers due to ordinary loads.
> Only stores and
> On 02/26/2010 10:17 AM, Gerd Hoffmann wrote:
> > Adds infrastructure for keyboard led status tracking to qemu.
> >
> > Signed-off-by: Gerd Hoffmann
>
> Applied. Thanks.
What about guests that use the capslock LED for something useful, instead of
capslock?
Paul
> > Can't this be achieved by just disabling the feature bits? IOW,
> >
> > ctrl_vq=0,ctrl_vlan=0?
>
> Michael still wants the guest to populate the MAC filter table so that
> we can use it to announce MACs on the bridge, especially after a
> migration.
We don't do that to start with. We only s
> 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
> 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
> 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
> 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.
> >
> 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
> 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
> 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
> > 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
> 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
> >> 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?
>
>
> I want to port QEMU on the ARM11 platform. I think, many developers try to
> this work.
Should already work.
Paul
> >> 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 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
> 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
> 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
> 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
> 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
> 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
> 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
> /* 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
> > 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
> > 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
> > 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
> 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
> 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
>+/*
>+ * 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
> > 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
>diff --git a/qemu-lock.h b/qemu-lock.h
This code isn't used in any interesting ways, it should be removed..
Paul
> 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
> 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
> 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
> > 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
> +++ 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
> 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
> > 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
> 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
> 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
> 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_
> 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
> I thought we will get rid of vpb_pci_config_addr, and fill in
> fields in PCIConfigAddress directly. If we don't, and still
> recode into PC format, this is not making code any prettier
> so I don't really see what this buys us.
I agree. This patch seems to be introducing churn for no benefit.
On Tuesday 12 January 2010, Isaku Yamahata wrote:
> To use pci host framework, use PCIHostState instead of PCIBus in
> PCIVPBState.
No.
pci_host.[ch] provides very specific functionality, it is not a generic PCI
host device. Specifically it provides indirect access to PCI config space via
a me
> > > > Given we need both, why not actually defined an API that gives you
> > > > this?
> > >
> > > Because, I do not want to define APIs, I want to reuse an existing one.
> >
> > Except that, say you said later in your email, no API exists for doing
> > atomic accesses, so you need different code
On Wednesday 23 December 2009, Michael S. Tsirkin wrote:
> On Wed, Dec 23, 2009 at 12:25:46PM +0000, Paul Brook wrote:
> > > > > So possibly this means that we
> > > > > could optimize the barrier away, but I don't think this amounts to
> > > > >
> > > So possibly this means that we
> > > could optimize the barrier away, but I don't think this amounts to a
> > > serious issue, I guess portability/readability is more important.
> >
> > The more important issue is that regular devices which to not require
> > coherency or ordering can omit th
> > I mean have a single function that does both the atomic load/store and
> > the memory barrier. Instead of:
> >
> > stw_phys(addr, val)
> > barrier();
> >
> > We do:
> >
> > stw_phys_barrier(addr, val).
>
> Well, I think it's a good idea to use Linux APIs instead of
> inventing our own. A
> The problem is that the whole define is just plain wrong which tells me
> that the code is using the bswap functions incorrectly. This really
> needs to be fixed by someone who knows the dbdma device. I don't see how
> calling incorrect calls even more incorrect makes any difference.
The real pr
> > Given this is supposed to be portable code, I wonder if we should have
> > atomic ordered memory accessors instead.
> >
> > Paul
>
> Could you clarify please?
>
> The infiniband bits I used as base are very portable,
> I know they build on a ton of platforms. I just stripped
> a couple of inf
On Tuesday 22 December 2009, Anthony Liguori wrote:
> On 12/22/2009 05:26 AM, Michael S. Tsirkin wrote:
> > On Tue, Dec 08, 2009 at 06:18:18PM +0200, Michael S. Tsirkin wrote:
> >> The following fixes a class of long-standing bugs in qemu:
> >> when kvm is enabled, guest might access device structu
> > Ram allocations should be associated with a device. The VMState stuff
> > this should make this fairly straightforward.
>
> Right, but for the sake of simplicity, you don't want to treat that ram
> any differently than main ram wrt live migration. That's why I proposed
> adding a context id f
> > We should just qemu_ram_alloc() that memory regardless of whether we
> > every map it into the guest. Since roms can be large, we want to send
> > their contents over during the live part of migration. If we use
> > qemu_ram_alloc(), we get that for free.
>
> Currently live migration uses ra
> http://thread.gmane.org/gmane.comp.emulators.qemu/44869
>
> I'm not sure why Paul never pushed it but I think he was able to create
> the syborg board purely from a device tree.
The patches referenced above include purely device-tree based Syborg and
Stellaris boards.
It works fairly nicely f
> --- a/posix-aio-compat.c
> +++ b/posix-aio-compat.c
> @@ -502,7 +502,8 @@ static void aio_signal_handler(int signum)
> if (posix_aio_state) {
> char byte = 0;
>
> - write(posix_aio_state->wfd, &byte, sizeof(byte));
> + if (write(posix_aio_state->wfd, &byte, sizeof(byte)) != sizeo
On Saturday 19 December 2009, Richard Henderson wrote:
> Changes from round 3:
>
> * Drop movcond for now.
> * Only use movzbl and not xor in setcond.
I'm still catching up on mail backlog from this thread, but I'm concerned that
we're exposing setcond to the target translation code if we're p
> -uint32_t VF; /* V is the bit 31. All other bits are undefined */
> +uint32_t VF; /* V is the bit 28. */
No. The original comment is correct.
Paul
On Saturday 12 December 2009, Dave Airlie wrote:
> So I've been musing on the addition of some sort of 3D passthrough for
> qemu (as I'm sure have lots of ppl)
IIUC a typical graphics system consists of several operations:
1) Allocate space for data objects[2] on server[1].
2) Upload data from cl
> According to comment in exec-all.h:
> /* Deterministic execution requires that IO only be performed on the last
>instruction of a TB so that interrupts take effect immediately. */
>
> Sparc generator must then violate this assumption. Is the assumption
> valid also when not using icount and
On Thursday 10 December 2009, Michael S. Tsirkin wrote:
> The recent e1000 bug made the important of using
> symbolic macros for pci config access clear for me.
> So I started going over drivers and converting
> to symbolic constants instead of hard-coded ones.
> I did a large part until I run out
> > Using -icount should give you precise interrupt delivery.
>
> That's what I thought, but as I reported a few days ago, I couldn't
> find a good value for icount when using OBP.
> I tried a few values but keep getting "qemu: fatal: Raised interrupt
> while not in I/O function".
That's almost c
> type *qemu_new(type, n_types);
> type *qemu_new0(type, n_types);
>
> type *qemu_renew(type, mem, n_types);
> type *qemu_renew0(type, mem, n_types);
It always annoys me having to specify element count for things that aren't
arrays.
I suggestion a single object allocation function, and an array
On Monday 07 December 2009, Artyom Tarasenko wrote:
> Can it be that qemu (-system-sparc in my case, but I guess it's more
> or less similar on all platforms) reacts to irqs slower than a real
> hardware due to tcg optimizations?
Interrupts generally only trigger at branch instructions, or similar
On Monday 30 November 2009, Alexander Graf wrote:
> Currently we have this stupid role of disallowing:
>
> if (r)
> break;
This has been discussed to death several times, in several different paces,
and with no clear resolution or consensus, so I'm going to make an executive
decision:
> > Our cpu keeps multiple seperate address spaces open at the same time
> > (similar to x86 with a bunch of cr0s), defined by address space control
> > elements in various control registers. Linux uses primary, secondary and
> > home space to address user space and kernel space. The third one is u
On Tuesday 01 December 2009, Glauber Costa wrote:
> On Tue, Dec 01, 2009 at 12:57:27PM +0000, Paul Brook wrote:
> > > You might want to have a 'static uint8_t zero_length_malloc[0]' and
> > > return that instead of the magic cookie '1'. Makes the code more
> You might want to have a 'static uint8_t zero_length_malloc[0]' and
> return that instead of the magic cookie '1'. Makes the code more
> readable IMHO and you'll also have symbol in gdb when debugging qemu.
Having multiple malloc return the same pointer sounds like a really bad idea.
Paul
>> It's really not that much of a fast path. Unless you're doing something
>> particularly obscure then even under heavy load you're unlikely to exceed
>> a few kHz.
>
>I think with kvm, heavy disk stressing benchmark can get higher.
I'd still expect this to be the least of your problems.
If not
> No, this would slow us down because these are per-pin.
> We need a sum of interrupts so that config space
> can be updated by a single command.
> Interrupts are a fastpath, extra loops there should be avoided.
It's really not that much of a fast path. Unless you're doing something
particularly
> So maybe add "use -device ? to get list of all devices"
> to help text?
>
> [...@tuck qemu]$ ~/qemu-git/bin/qemu-system-x86_64 -device ?
> /home/mst/qemu-git/bin/qemu-system-x86_64: invalid option -- '-device'
You need to stop your shell eating the ?
Paul
501 - 600 of 1782 matches
Mail list logo
