> > 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
> 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
> > 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
> >> 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
> > 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
> 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
> +struct QEMUNotifier
> +{
> +void (*notify)(QEMUNotifier *notifier);
> +};
>
I suggest combining this with QEMUBH.
Paul
> 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
> 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
> > + /*
> > +* 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
> 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
> 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
> +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 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
> > > $ 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
> > 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
> 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
> > 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
> > 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'
>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
> 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
> /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
> 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
> 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
> 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
> 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
> 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
> 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
> +static uint32_t get_elf_hwcap(void)
> +{
> +return thread_env->features;
> +}
No. These values are not the same.
Paul
> +#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
> 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(__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
> 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
the guest invalidates this region then flush the
whole TLB.
Signed-off-by: Paul Brook
---
cpu-defs.h |2 +
exec-all.h | 14 ++
exec.c | 55
hw/alpha_palcode.c |7
> Oh, well, yes, I remember. qemu is more strict on ISA irq sharing now.
> A bit too strict.
>
> /me goes dig out a old patch which never made it upstream for some
> reason I forgot. Attached.
This is wrong. Two devices should never be manipulating the same qemu_irq
object. If you want mult
> + if (size >= PREFERRED_RAM_ALIGN)
> + new_block->host = qemu_memalign(PREFERRED_RAM_ALIGN, size);
>
Is this deliberately bigger-than rather than multiple-of?
Having the size not be a multiple of alignment seems somewhat strange, it's
always going to be wrong at one end...
> On Wed, Mar 17, 2010 at 03:05:57PM +0000, Paul Brook wrote:
> > > + if (size >= PREFERRED_RAM_ALIGN)
> > > + new_block->host = qemu_memalign(PREFERRED_RAM_ALIGN,
> > > size);
> >
> > Is this deliberately bigger-than rathe
> > > Size not multiple I think is legitimate, the below-4G chunk isn't
> > > required to end 2M aligned, all it matters is that the above-4G then
> > > starts aligned. In short one thing to add in the future as parameter
> > > to qemu_ram_alloc is the physical address that the host virtual
> > > a
> On 03/16/2010 10:10 PM, Blue Swirl wrote:
> >> Yes, and is what tlb_protect_code() does and it's called from
> >> tb_alloc_page() which is what's code when a TB is created.
> >
> > Just a tangential note: a long time ago, I tried to disable self
> > modifying code detection for Sparc. On most R
> On Wed, Mar 17, 2010 at 03:52:15PM +0000, Paul Brook wrote:
> > > > > Size not multiple I think is legitimate, the below-4G chunk isn't
> > > > > required to end 2M aligned, all it matters is that the above-4G
> > > > > then start
> On 03/17/2010 11:14 AM, Paul Bolle wrote:
> > On Wed, 2010-03-17 at 10:59 -0500, Anthony Liguori wrote:
> >> On 03/08/2010 06:58 AM, Paul Bolle wrote:
> >>> Signed-off-by: Paul Bolle
> >>
> >> Applied. Thanks.
> >
> > Paul Broo
> > If something should never happen (as in this case) then an abort/assert
> > is completely appropriate. Once things get that screwed up there's no
> > right answer, and the best thing we can do is terminate immediately to
> > try and avoid further damage.
>
> This case was:
>
> switch (foo & 0
> A VirtIOBlock device cannot be a VirtIODevice while being a
> VirtIOPCIProxy (proxy is a poor name, btw).
>
> It really ought to be:
>
> DeviceState -> VirtIODevice -> VirtIOBlock
>
> and:
>
> PCIDevice -> VirtIOPCI : implements VirtIOBus
>
> The interface between the VirtIODevice and VirtIO
> > John attempted this and it was reverted because the implementation
> > exhausted the PCI config space.
>
> I don't understand that. Existig hardware devices dump much more of
> their data such as vendor and model type information into the config
> space, how can using a field that real hardwar
> > It's a classic OOP problem.
> >
> > VirtIOBlock is-a VirtIODevice, VirtIODevice is-a DeviceState
> >
> > VirtIOPCI is-a PCIDevice, PCIDevice is-a Device State.
> >
> > But VirtIODevice is-a VirtIOPCI device isn't always true so it can't be
> > an is-a relationship. Initially, this was true and
> But look at the lguest virtio implement. We would definitely model a
> VirtIOBus if we implemented something like that in qemu. VirtIO really
> is designed to be a bus.
When you say "bus" you actually mean point-point connection, right[1]?
I don't see anything in virtio that allows arbitration
> On 03/22/2010 11:16 AM, Paul Brook wrote:
> >> But look at the lguest virtio implement. We would definitely model a
> >> VirtIOBus if we implemented something like that in qemu. VirtIO really
> >> is designed to be a bus.
> >
> > When you say &quo
>Solutions:
>- VirtIOPCIBus and hang devices from there (anthony). Why? because
> this is a simulated pci bus, we can implement the features that we
> need (not full pci) in the three showed architectures. We will have
> VirtIOPCIBLock everywhere, and its VirtIOPCIBus implmentation will
> h
> > Right. The only real challenge is dealing with legacy save/restore and
> > command line syntax. For save/restore, we can possibly have a dummy
> > device that can split the VirtioPCI device state from the virtio device
> > states and do the right thing.
> >
> > I'm not sure what we should do
> > I think there is a serious divergence of approach there, instanciating
> > API stating 'we are gonna deprecate them sooner or later' tell the
> > application developper 'my time is more important than yours' and not
> > really something I like to carry to the API users.
> > The main goal of lib
> I am involved in a project that we use Qemu user mode for i386
> (./i386-linux-user/qemu-i386). I want to modify the source code
> in such a way to make qemu execute a buffer of bytes (given from the comman
> line for example) rather than loading
> an ELF file and executing. I started looking at
> I can't quite see what such a libqemu would buy us compared to straight
> QMP.
>
> Talking QMP should be easy, provided you got a suitable JSON library.
I agree. My undesranding is this was one of the large motivations behind using
JSON: It's a common protocol that already has convenient bindi
> On 03/23/2010 09:24 PM, Anthony Liguori wrote:
> > We also provide an API for guest creation (the qemu command line).
>
> As an aside, I'd like to see all command line options have qmp
> equivalents (most of them can be implemented with a 'set' command that
> writes qdev values). This allows a
> > IMO the no_user flag is a bug, and should not exist.
>
> Sorry, what's that?
Usually an indication that a device has been incorrectly or inproperly
converted to the qdev interface.
Paul
> If the technical documentation at
> http://www.usenix.org/publications/library/proceedings/usenix05/tech/freeni
> x/full_papers/bellard/bellard_html/index.html is still valid (I think it
> is), Qemu has two modes of handling access to guest memory - system
> emulation, in which an entire guest
> On 03/24/2010 12:19 PM, Richard Henderson wrote:
> > On 03/24/2010 02:47 AM, Paolo Bonzini wrote:
> >> 1) make CPUState define only common fields. Include CPUState at the
> >> beginning of each per-target CPUXYZState.
> >
> > Irritatingly, the common fields contain quite big TLBs. And the
> > off
> Paul Brook writes:
> >> > IMO the no_user flag is a bug, and should not exist.
> >>
> >> Sorry, what's that?
> >
> > Usually an indication that a device has been incorrectly or inproperly
> > converted to the qdev interface.
>
> Ca
> 1) make CPUState define only common fields. Include CPUState at the
> beginning of each per-target CPUXYZState.
> >>>
> >>> Irritatingly, the common fields contain quite big TLBs. And the
> >>> offsets from the start of env affect the compactness of the code
> >>> generated from TCG. We
> But now there is a bigger problem, how to pass the property to the
> device. It's not fair to require the user to remember to set it.
It should not be a property of the device. All devices have a native
endianness (for PCI this is little-endian), and the intermediate
busses/interconnects shoul
> Actually, Anthony suggested at some point to just use 64 bits for
> TARGET_PHYS_ADDR_BITS and remove the need for hw32/64.
>
> I think that people emulationg 32bits on 32bits would suffer, but have
> no clue how much. Anthony, what was the idea?
Sacrificing runtime performance to avoid rebuild
> On 03/24/2010 05:33 PM, Paul Brook wrote:
> >> But now there is a bigger problem, how to pass the property to the
> >> device. It's not fair to require the user to remember to set it.
> >
> > It should not be a property of the device. All devices have a
> I'd prefer a generic address type since this makes it easier to
> share code: for example virtio devices can use different busses,
This is exactly why virtio devices should not be accessing memory. They should
be doing everything via a virtqueue, which can interface with the host
bindings appr
> /* Force QEMU to process pending events */
> -void qemu_notify_event(void);
> +void qemu_notify_event(QEMUIOWorker *worker);
> static void handle_input(VirtIODevice *vdev, VirtQueue *vq)
> {
> +qemu_notify_event(main_io_worker);
> }
This feels completely wrong.
Devices shouldn't know o
> On Thu, Mar 25, 2010 at 09:06:00PM +0000, Paul Brook wrote:
> > > /* Force QEMU to process pending events */
> > > -void qemu_notify_event(void);
> > > +void qemu_notify_event(QEMUIOWorker *worker);
> > >
> > > static voi
> This set of patches is quite raw, intended mostly just for discussion
> at this point. We'd like to identify the unobjectionable patches and
> "ready for upstream with minor fixes" patches first, so we can send
> them for a pull request. After which we can start diving more deeply
> into restruct
>This patch adds support for the pselect syscall in linux-user emulation
>and also adds several support functions required to translate the
>timespec structs between the target and the host.
IIUC the whole point of the pselect is that it should be atomic. By emulating
this in a non-atomic fasion
> New char device emulating an Elo serial touchpad.
>
> TODO: The output of the touchpad should be in the range of the
> resolution. But I don't know a clean way to get the screen resolution.
> Any help will be very wellcomed
Are you sure? I don't see how real hardware would be able to do that.
> Hi Roland,
>
> On 30.03.2010, at 01:52, Roland Elek wrote:
> > Dear Qemu developers,
> >
> > I am a university student from Hungary interested in contributing to Qemu
> > through Google Summer of Code. I am interested in emulation, and two
> > projects from the ideas page in particular. One of t
> I will contact jai soon about the S3 Trio. I'll also skim through the
> documentation so that I can set reasonable goals in my timeline.
TBH I'm less convinced about the utility of emulating an S3 graphics card.
You'd want to make sure you know what you're expecting from it.
While it may have
> Oh this is happening with x86_64-bsd-user on the same arch so I'd say
> (abi_ulong)-1 would be the same as ~0ul (and still cause the assert.)
No. These two are different when sizeof(abi_ulong) < sizeof(long).
Paul
> I'm wondering take part on GSoC with QEMU, I really liked the "IOMMU
> emulation project". However I only know basically how an IOMMU works,
> but that is not a big a deal, I can learn about it and implement.
> Besides read the code and learn how a IOMMU works what else more do I
> need to do? Al
> But this makes kvm_enabled() check dynamic and code that was
> eliminated by compiler for !CONFIG_KVM will now be generated.
>
> Wouldn't adding CONFIG_KVM to config-host.h also solve the problem?
CONFIG_KVM is (and should be) a per-target decision.
Paul
>This patch adds support for virtio-rng. Data is read from a chardev
> and can be either raw entropy or received via the EGD protocol.
I still don't get why you need this at all. It seems like virtio-serial would
already provides everything you need.
> +qemu_gettimeofday(&now);
> Wenhao Xu wrote:
> > Hi, Juan,
> >I am fresh to both QEMU and KVM. But so far, I notice that QEMU
> > uses "KVM_SET_USER_MEMORY_REGION" to set memory region that KVM can
> > use and uses cpu_register_physical_memory_offset to register the same
> > memory to QEMU emulator, which means QEMU an
> > One example is the openpic page size pointed out downthread.
> >
> > What about something like this (doesn't change all the places affected
> > by your series, compile-tested only)?
>
> In general (with vmport and maybe virtio as the only exceptions), the
> devices have no business knowing
>>> 1) state machines with a thread pool to make blocking functions
>>> asynchronous (what we have today)
>>>
>>> 2) co-operative threading
>>>
>>> 3) pre-emptive threading
> > On a philosophical note, threads may be easier to model complex
> > hardware that includes a processor, for example our s
>CPU #0CPU #1
>
>x <- load-locked(A)
>y <- load(B)
> x+1 -> store(A)
> y+1 -> store(B)
> x -> store(A)
>f(x,y) -> store-cond(A)
>
> Unless I made a mistake, the above cannot store f(x,y+1)
>> >This patch adds support for virtio-rng. Data is read from a
>> > chardev and can be either raw entropy or received via the EGD protocol.
>>
>> I still don't get why you need this at all. It seems like
>> virtio-serial would already provides everything you need.
>
>I guess when virtio-rn
> On 04/01/2010 04:14 PM, Paul Brook wrote:
> >>> On a philosophical note, threads may be easier to model complex
> >>> hardware that includes a processor, for example our scsi card (and how
> >>> about using tcg as a jit to boost it :)
> >>
>
> Paul Brook wrote:
> >>>>This patch adds support for virtio-rng. Data is read from a
> >>>> chardev and can be either raw entropy or received via the EGD
> >>>> protocol.
> >>>
> >>> I still don't get why y
> This is my first contribution to QEMU: I've written a virtual piece of
> hardware (e.g. ports) that the mouse pointer can be used as an absolute
> pointing device even with non USB devices, e.g. with DOS and doesn't need
> any high memory usage USB driver. This is necessary for e.g. VNC remote
>
> > Looks like the tablet is set to 100 Hz polling rate. We may be able
> > to get away with 30 Hz or even less (ep_bInterval, in ms, in
> > hw/usb-wacom.c).
>
> Changing the USB tablet polling interval from 10ms to 100ms in both
> hw/usb-wacom.c and hw/usb-hid.c made no difference except the an i
Commit f1698408 "Compile usb-ohci only once" introduces a "be" property to the
pci-ohci device. The PCI bus is always little-endian, so this is completely
bogus. A hypothetical big-endian device would actually introduce another
byteswap.
As discussed previously, if you really want to avoid comp
> > The USB HID devices implement the SET_IDLE command, so the polling
> > interval will have no real effect on performance.
>
> On a Linux guest (F12), I see 125 USB interrupts per second with no
> mouse movement, so something is broken (on the guest or host).
Turns out to be a a bug in the UHCI
> On 4/4/10, Paul Brook wrote:
> > Commit f1698408 "Compile usb-ohci only once" introduces a "be" property
> > to the pci-ohci device. The PCI bus is always little-endian, so this is
> > completely bogus. A hypothetical big-endian device would actually
> > My guess is that the overhead you're seeing is entirely from the USB host
> > adapter having to wake up and check the transport descriptor lists. This
> > will only result in the guest being woken if a device actually responds
> > (as mentioned above it should not).
>
> A quick profile on the
addr_t.
Signed-off-by: Paul Brook
---
configure |3 ---
cpu-defs.h | 17 +++--
exec.c |2 +-
softmmu_template.h | 28
targphys.h |5 +
tcg/mips/tcg-target.c |4 ++--
tcg/p
> There might be cases where a few bytes would have been sent out to char
> devices and some not. Currently the return values from qemu_chr_write()
> to char devs are only -1, indicating an error, or the complete length
> of the string passed.
>
> Make 'len' a pointer instead, and indicate how muc
> On (Mon) Apr 05 2010 [17:33:38], Paul Brook wrote:
> > > There might be cases where a few bytes would have been sent out to char
> > > devices and some not. Currently the return values from qemu_chr_write()
> > > to char devs are only -1, indicating an error, or th
> To emulate hardware without an EEPROM,
> EEPROM_SIZE may be set to 0.
If might, but it isn't.
This patch introduces a condition that will never be false. Please don't do
that. I consider code that is never used to be actively harmful. Any feature
that requires the user hack the source may as
> Hello,
>
> This patchset introduces flow control to virtio-console and
> chardev-based virtio serial ports. This series is based on the
> previous series I sent on Mar 31st (00/17: v4: virtio-serial fixes,
> new abi for port discovery)
>
> The qemu chardevs can now return -EAGAIN when a non-blo
>1. DMAR tables must be loaded by command line ( -acpitable
> sig=DMAR,data=hw/DMAR.dat )
Why?
> +void cpu_physical_memory_rw_io(target_phys_addr_t addr, uint8_t *buf,
> + int len, int is_write, uint16_t devfn,
> + int* err);
This appear
> Use a set of #define to define the allowed ARM instructions, depending
> on the __ARM_ARCH_*__ GCC defines.
>
> Signed-off-by: Aurelien Jarno
> ---
> tcg/arm/tcg-target.c | 27 ---
> 1 files changed, 24 insertions(+), 3 deletions(-)
>
> diff --git a/tcg/arm/tcg-targe
> +static inline void tcg_out_bswap32(TCGContext *s, int cond, int rd, int rn)
> +#else
> +/* This code only uses one temporary register. There is probably
> + a faster way to do that with more temporary registers. */
You can do better even without a temporary:
eor r8, rn, rn, ror #
> On Thu, Apr 08, 2010 at 03:38:52PM +0200, Stefan Weil wrote:
> > Register fp is a bad choice for compilations without
> > optimisation, because the compiler makes heavy use
> > of this register (so the resulting code crashes).
>
> I don't fully understand why the compiler makes use of this regis
> {
> - fprintf_ftype fprintf = info->fprintf_func;
>void * stream = info->stream;
I'm pretty sure this is not the correct fix.
"Fix a warning" is not sufficient justification for any change. We need to
understand what was wrong with the old code, and why the new code is
> If a small 'seed' dtb file is loaded into qemu and then heavily modified
> (say for runtime population of all the device nodes), then 2x the dtb
> size turns out not to be very much.
>
> This patch changes the device tree loading code to add a fixed 8k of
> additional space to the dtb buffer.
I
> Hi everyone,
>
> This is an experimental set of patches for populating the flattened
> device tree (fdt) data from the actual set of qdevs in the platform.
> I'm not expecting this to get merged anytime soon, but I wanted to get
> it out there to solicit comments. My target for this is testing
> On Fri, Apr 9, 2010 at 6:07 AM, Paul Brook wrote:
> >> Hi everyone,
> >>
> >> This is an experimental set of patches for populating the flattened
> >> device tree (fdt) data from the actual set of qdevs in the platform.
> >> I'm not expecting
> The Problem:
>
> CONFIG_USER_ONLY kinda sorta tries to manage the distinction between
> qemu memory and guest memory. This can be seen in the PAGE_RESERVED
> frobbing and qemu_malloc etc. However, it doesn't handle random malloc
> calls eg from libc itself or other libraries in use.
>
> Possibl
401 - 500 of 1782 matches
Mail list logo
