> >> So what im proposing is AXI stream is implemented as a unidirectional
> >> point to point bus. The xilinx ethernet system would consist of two of
> >> these buses one for tx, one for rx.
> >
> > I thought the idea was that with QOM the bus/device model would go away.
> > The DMA controller im
> >>> Of course we then hit the usual problem with QOM that we can only link
> >>> to objects, and it's impossible to expose multiple interfaces of the
> >>> same type.
> >>
> >> I'm pretty sure Anthony claimed this was entirely possible --
> >> presumably that's how Pins are going to work.
> >
>
> > I'm no SPI expert, but a bit of googling suggests that it's
> > a synchronous duplex bus, so you always send a byte of data
> > to the slave and get one back in return (even if for some slaves
> > it might be random garbage).
Waitaminute. So this is just basic synchronous serial?
We already h
> 2012/4/3 Paul Brook :
> >> > I'm no SPI expert, but a bit of googling suggests that it's
> >> > a synchronous duplex bus, so you always send a byte of data
> >> > to the slave and get one back in return (even if for some slaves
> >> >
> Hi Paul,
>
> Regarding using ssi, theres a few things that come to mind:
>
> Theres no sense of it being a multi-slave bus, its just a point to
> point link. SPI devices universally have the notion of the CS pin that
> tristates the device of the bus. Masters connect to a number of slaves
> and
In future I'd prefer if all patches had a description. In this case I'd say
what devices are being added. Hint: it's more than just the I2C controller.
> Signed-off-by: Oskar Andero
Acked-by: Paul Brook
> >> static uint32_t addr_to_wpnum(uint64_t addr) {
> >> return addr>> (HWBLOCK_SHIFT + SECTOR_SHIFT + WPGROUP_SHIFT);
> >> }
> >
> > This implicitly limits max address to 0x << (HWBLOCK_SHIFT +
> > SECTOR_SHIFT + WPGROUP_SHIFT), have you done this on purpose?
>
> You could argue for
> +++ b/hw/versatile_i2c.c
> @@ -0,0 +1,102 @@
> +/*
> + * Versatile I2C controller
I'd go for "ARM Versatile I2C controller".
I wish companies wouldn't pick generic terms as product names :-( That's not
your fault though!
> + *
> + * Copyright (C) 2012 Oskar Andero
AFAICS You've copy/pasted
> /* QEMU Synchronous Serial Interface support. */
>
> -/* In principle SSI is a point-point interface. As such the qemu
> - implementation has a single slave device on a "bus".
> +/* In principle SSI is a point-point interface.
> However it is fairly common for boards to have multiple sl
> On 23 April 2012 23:21, Peter Chubb wrote:
> > Peter> Are these two devices really on the same IRQ?
> >
> > Yes. A single interrupt line comes from the FPGA into the AVIC.
> > Inside the FPGA the interrupts for the UARTs, SD card and NAND flash
> > are connected to that single interrupt line.
> Im happy to spend the 10 mins updating stellaris.c accordingly, but is
> someone sitting on a binary package and brief instructions or some
> such to regression test it? Do you of this machine have some sort of
> kernel image handy?
I've attached a tarball with some test binaries. They're built
coded status
byte is insufficient. CMD58 is specific to SPI mode. It is undefined in
regular SD mode.
Signed-off-by: Paul Brook
---
hw/sd.c | 57 ++---
hw/ssi-sd.c | 11 +--
2 files changed, 47 insertions(+), 21 deletions(-)
diff --
> > +static inline int64_t is_between(int64_t x, int64_t a, int64_t b)
> > +{
> > +if (a < b) {
> > +return x > a && x <= b;
> > +}
> > +return x < a && x >= b;
> > +}
>
> This looks slightly odd -- should the boundary condition for whether
> a value equal to the max/min really
> On Tue, Feb 21, 2012 at 11:04 PM, Paul Brook wrote:
> >> > +static inline int64_t is_between(int64_t x, int64_t a, int64_t b)
> >> > +{
> >> > +if (a < b) {
> >> > +return x > a && x <= b;
> >> > +}
> > Thinking about that, I realised why I don't like the following line:
> >> +s->reg_value = (uint32_t)((x + interval) % interval);
> >
> > This assumes x > -interval, which is not always true.
>
> This would mean you have wrapped twice or more in one time step, which
> I am assuming is a fa
that.
Dynamic iendianness switching requires messing with data accesses,
preferably with TCG cooperation, and is orthogonal to BE8 support.
Signed-off-by: Paul Brook
---
disas.c| 11 +--
linux-user/elfload.c |1 +
linux-user/main.c | 12
linux
> In QEMU with -R
>
> $ qemu-arm -R $(( 0x1000 )) ./brk
> mmap: 0x935000
> current brk: 0x
> -8000 ---p 00:00 0
> 8000-9000 r-xp 08:09 1248935408 /brk
> 9000-0001 ---p 00:00 0
> 0001-00011000 r--p 08:09 12489
> When mmap()'ing memory somewhere where it's not allowed, we should not
> default to the "next free page" which could be right after brk()'ed memory,
> but rather at TARGET_UNMAPPED_BASE, which ensures that brk() can extend its
> space later on.
NACK, As discussed on IRC.
Effectively prevents mm
> If the guest process tells us to map at a specific address, we shouldn't
> increase the "last automatic mapping ended here" variable.
That sounds reasonable, in fact I'd go further. Tests on an x86-linux machine
(both 32-bit and 64-bit userspace) show that if the requested address is not
avai
> On Mon, Jun 20, 2011 at 6:23 PM, Paul Brook wrote:
> >> > Yeah, that's why I said, "hard to do well". It makes it very hard to
> >> > add new socket types.
> >>
> >> PCI, USB, IDE, SCSI, SBus, what else? APICBus? I2C? 8 socket types
> One feature we need for QEMU/KVM on embedded Power Architecture is the
> ability to do passthru assignment of SoC I/O devices and memory. An
> important use case in embedded is creating static partitions--
> taking physical memory and I/O devices (non-PCI) and partitioning
> them between the hos
> But the real challenge is how to expose the device to the guest device
> tree. Especially when it comes to links between dt nodes, interrupt maps,
> etc. We basically have 3 choices there:
>
> * take the host device tree pieces and modify them
> * provide device tree chunks for each device
> > So, from a qemu command line perspective, all you should have to do is
> > pass qemu the device-tree -path- to the device you want to pass-trough
> > (you may support passing a full hierarchy here).
>
> I agree in principle but I think it should be done in a slightly
> different way.
>
> I th
> > irq[0].guest_irq = "10"
> >
> > This should be independent of anything to do with device tree. This
> > would be useful for x86 too to assign platform devices (like the HPET).
>
> That's fine, as long as there's something layered on top of it for the case
> where we do want to reference some
> On Fri, 1 Jul 2011 18:03:01 +0100
>
> Paul Brook wrote:
> > Basically you should start by implementing full emulation of a device
> > with similar characteristics to the one you want to passthrough.
>
> That's not going to happen.
Why is your device so uniqu
> > Why is your device so unique? How does it interact with the guest system
> > and what features does it require that doen't exist in any device that
> > can be emulated?
>
> Perhaps I misunderstood what you meant by "similar characteristics". I see
> no reason to spend a bunch of time implemen
> On Fri, 2011-07-01 at 21:59 +0100, Paul Brook wrote:
> > > On Fri, 1 Jul 2011 18:03:01 +0100
> > >
> > > Paul Brook wrote:
> > > > Basically you should start by implementing full emulation of a device
> > > > with similar characteristics t
> So you're basically saying we should tackle these 3 issues separately:
>
> * actually pass through a device
> * generate interrupt links
> * model the guest device tree dynamically based on whatever the user
> gives us
Yes.
Paul
> jpeg decoder have its limitation, it only accept jpg file with
> width=16*M, height=16*N.
> bmp decoder only accept 24bpp file, with a resolution that a video
> mode could support. Recommended is 640x480(mostly used).
Doing image decoding in the bios seems particularly pointless. Why
> -/* Avoid mode switch when restoring CPSR. */
> -env->uncached_cpsr = val & CPSR_M;
> -cpsr_write(env, val, 0x);
> +
> +env->uncached_cpsr = env->cpsr_vmstate & CPSR_M;
> +cpsr_write(env, env->cpsr_vmstate, 0x);
You've removed the helpful comment explaining w
> >> +env->uncached_cpsr = env->cpsr_vmstate & CPSR_M;
> >> +cpsr_write(env, env->cpsr_vmstate, 0x);
> >
> > [1] Maybe a necessary hack, but still a wart from requiring static table
> > driven vmstate descriptions.
>
> I wonder if we shouldn't make it easier to do what I do for Al
> Just realised i made the patch a bit too fast and added a caracter on top
> of console.c when reviewing code...
>
> here is the correct patch.
Why do we need any device specfic code for this?
Surely the console layer is the only thing that needs to care, and should just
make the appropriate se
t; and a global modification of the comment structure. This patch rebases
> our softfloat code to SoftFloat-2a in order to have a GPLv2 compatible
> license.
Acked-by: Paul Brook
> * ARMv5TE series (FA606TE, FA626TE, FA616TE, FA726TE)
>
> All the single core RISC listed above are included in this patch.
> And there are two Faraday CP15 extensions (AUX and I/D-Scratchpad)
> have been implemented as NOP.
Is a NOP appropriate? Should you at least read the value
> I don't think there's much point adding tons of "XXX" comments
> when a bunch of these aren't actually wrong code. If you want to fix
> this I think a better approach would be more focused patches aimed
> at adding 'break;' or "/* fallthrough */" based on actual human
> examination of the surroun
> > diff --git a/disas/cris.c b/disas/cris.c
> > +/* XXX: questionable fallthrough */
>
> Inherited from binutils; if you want to clean this up, suggest to do it
> there.
Except that upstream binutils is GPLv3, so this code is effectively orphaned.
Paul
> +#ifdef USE_THIS_DEAD_CODE
> +void mdio_detach(struct qemu_mdio *bus, struct qemu_phy *phy, unsigned int
> addr) +{
> +bus->devs[addr & 0x1f] = NULL;
> +}
> +#endif
This is clearly wrong.
It also worries me that there isn't a clean separation between the MDIO bus
and the bitbang interface
ime I implemented the VersatilePB did
not include the IO region. The PCI interrupt routing still seems to be missing
from the docs.
Acked-by: Paul Brook
[Ignoring any issues with the backwards comaptibility hacks]
> > -sd_adtc, sd_none, sd_none, sd_none, sd_none, sd_none, sd_none,
> > +sd_adtc, sd_none, sd_bc, sd_bc, sd_none, sd_none,
>
> sd_bcr? not that it really matters though
Err, probably.
> > +case 58:/* CMD58: READ_OCR */
> > +if (!sd->spi) {
> > +goto bad_cm
Recent testing showed the SPI mode SD card emulation (ssi-sd.c) doesn't
actually work if the guest tries to use features from the SD Physical
Layer Specification v2 (this incluldes SDHC).
This series replaces my previous single patch.
Paul Brook (2):
Fix SPI SD card command responses
hw
Implement CMD58. This command is only valid in SPI mode, and required when we
implement CMD8. Most of the code is already there, we just need to
trigger it.
Signed-off-by: Paul Brook
---
hw/sd.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/hw/sd.c b/hw
d CMD58 to follow)
this gets messy, with both parts requiring command specific knowledge.
We already have magic SPI-mode behavior in sd.c, so may as well just
generate the correct response there.
Signed-off-by: Paul Brook
---
hw/sd.c
> >> If this command could be issued in transfer state maybe in addition to
> >> IDLE_STATE you also need to set other bits (ADDRESS_ERROR,
> >> COM_CRC_ERROR, ILLEGAL_COMMAND, ERASE_SEQ_ERROR) in MSB of R3 response?
> >
> > In theory, yes. I was thinking of a follow-up patch to move the spi
> >
> And drop passing is_spi argument to SDCardClass::init function.
> "spi" property could be set while SD card is in IDLE state. It defaults to
> "false".
Why? This isn't something that should be under user or board control. The SD
card object is an implementation detail. It's something that's
> Move feature register value setup to per-CPU init functions.
> +env->cp15.c0_c1[0] = cpu->id_pfr0;
> +env->cp15.c0_c1[1] = cpu->id_pfr1;
> +env->cp15.c0_c1[2] = cpu->id_dfr0;
> +env->cp15.c0_c1[3] = cpu->id_afr0;
> +env->cp15.c0_c1[4] = cpu->id_mmfr0;
> +env->cp15.c0_c1[5
> > Add myself as co-maintainer alongside Paul Brook for the TCG ARM
> > guest implementation (target-arm) and the ARM dev boards (integratorcp,
> > realview, stellaris, versatilepb).
> >
> > Signed-off-by: Peter Maydell
>
> Acked-by: Anthony Liguori
>
> Fixes two trivial indices errors.
No.
You're doing two much in a single patch. While both happen to be bug in the
save/restore code involving arrays, these are not two instances of the same
bug. The justification for each change is completely different.
Even if each change was obviously cor
evices to Qemu, so I do see a
> > rough outline of how I would implement it.
> >
> > However, last year, Paul Brook commented [1] that he wasn't convinced
> > about the usefulness of emulating an S3 Trio or Virge card, because of
> > performance reasons. He suggested
> The Neon versions of int-float conversions need their own helper routines
> because they must use the "standard FPSCR" rather than the default one.
> Refactor the helper functions to make it easy to add the neon versions.
> While we're touching the code, move the helpers to op_helper.c so that
>
> PCIBus *ppce500_pci_init(qemu_irq pci_irqs[4], target_phys_addr_t
> registers) {
> -PPCE500PCIState *controller;
> +DeviceState *dev;
> +PCIBus *b;
> +PCIHostState *h;
> +PPCE500PCIState *s;
> PCIDevice *d;
> -int index;
> static int ppce500_pci_id;
> +SysBus
> > PCIBus *ppce500_pci_init(qemu_irq pci_irqs[4], target_phys_addr_t
> > registers) {
> > -PPCE500PCIState *controller;
> > +DeviceState *dev;
> > +PCIBus *b;
> > +PCIHostState *h;
> > +PPCE500PCIState *s;
> >
> > PCIDevice *d;
> >
> > -int index;
> >
> > stati
> On Fri, May 6, 2011 at 5:09 PM, Paul Brook wrote:
> >> The Neon versions of int-float conversions need their own helper
> >> routines because they must use the "standard FPSCR" rather than the
> >> default one. Refactor the helper functions to make it e
> @@ -250,7 +254,6 @@ static const VMStateDescription vmstate_ppce500_pci = {
>
> .minimum_version_id = 1,
> .minimum_version_id_old = 1,
> .fields = (VMStateField[]) {
>
> -VMSTATE_PCI_DEVICE_POINTER(pci_dev, PPCE500PCIState),
Doesn't this require incrementing versio
> The e500 PCI controller isn't qdev'ified yet. This leads to severe issues
> when running with -drive.
>
> To be able to use a virtio disk with an e500 VM, let's convert the PCI
> controller over to qdev.
>
> Signed-off-by: Alexander Graf
Reviewed-by: Paul Brook
> TCG uses a fixed global register (AREG0) to which points to currently
> used CPUState, also known as 'env'. Using a fixed register has the
> downsides that the register must be reserved by TCG for generated code
> and by the compiler for compiling a few critical files (op_helper.c
> etc.). The la
> Since virtio devices intentionally access memory directly, we
> are not actually dependant on the iommu patches in order to
> make progress. Merely fixing the PCI interrupt setup was
> enough to get the virtio-pci interface working.
There should be nothing special about virtio-pci. These device
> On 05/10/2011 02:33 PM, Paul Brook wrote:
> > There should be nothing special about virtio-pci. These devices should
> > access memory in exactly the same way as any other PCI device. Bypassing
> > the normal PCI iommu is IMO a serious bug.
>
> I suspect that the
> While we're at it, let us change things a bit further to allow guest
> byte-swap load/store insns to be implemented more efficiently. For
> instance, currently a sparc load_asr (little-endian), as emulated on
> an x86 host, does the byte swap twice.
FWIW this also ends up interacting with the d
> The PL041 driver provides an interface to an ACLink bus.
> The LM4549 driver emulates a DAC connected on the ACLink bus.
> Only audio playback is implemented.
Shouldn't this be shared with the other AC97 devices?
Paul
> On the other hand the current ac97.c implementation is a closely coupled
> combination of a PCI/ACLink bridge (Intel 82801AA) with a generic AC97
> codec. This has prevent me to easily reuse this code.
>
> The milkymist-ac97 implementation is another case. It looks like a basic
> implementation
> Add a .mailmap file so 'git shortlog' can map the unfriendly
> pre-git-conversion author entries to real names.
>+Paul Brook> pbrook
>
This bit looks ok to me.
Paul
ete legacy option and document it as such, or fix it as part of
(1). In the latter case it's probably going to do the wrong thing on boards
that have both virtio-mmio and PCI (there are at least two correct answers).
>[...]
> Correct. Syborg virtio was something Paul Brook did bit is n
> In previous version IRQ was lowered every time if enable bits were
> not set. If platform has splitted IRQ source to pass IRQ to two
> identical GICs simultaneously in first of which IRQ passing is
> enabled but in second is disabled, handling IRQ by second GIC would
> lower IRQ previously raised
> A group of us are starting to work on sandboxing QEMU device emulation
> code. We're just getting started investigating various approaches, and
> want to engage the community to gather input.
>
> Following are the design points that we are currently considering:
>
> * Decompose QEMU into multi
> On Friday, December 09, 2011 04:17:50 PM Paul Brook wrote:
> > > A group of us are starting to work on sandboxing QEMU device emulation
> > > code. We're just getting started investigating various approaches, and
> > > want to engage the community to gather in
> > Last time I checked at least one of the Intel/AMD schemes had been
> > implemented, through I don't know if it's been merged, or had any serious
> > performance tuning. My main intent was to raise this as a potentially
> > viable alternative. Someone who actually cares about the answer can
>
> > > Last time I checked at least one of the Intel/AMD schemes had been
> > > implemented, through I don't know if it's been merged, or had any
> > > serious performance tuning. My main intent was to raise this as a
> > > potentially viable alternative. Someone who actually cares about the
> > >
> > What mismatches does this catch that the existing debug code doesn't?
>
> Cf. patch 4/4:
>
> TCGv tmp = tcg_temp_new_i32();
> tcg_temp_free_i32(tmp);
>
> TCGv_i32 tmp2 = tcg_temp_new();
> tcg_temp_free(tmp2);
Why is this a problem? If TARGET_LONG_BITS==32 then tcg_temp_free and
tcg_temp_f
> This series makes target-i386 compile with DEBUG_TCGV_TL.
What benefit does this provide?
I effectively already asked this in reply to your patch adding
DEBUG_TCGV_TL[1]. One answer is sufficient, this mail is really just to link
the two threads together :-)
Paul
[1] http://lists.nongnu.or
> >> I'm not sure what guest software uses the syborg virtio transport.
> >
> > It is/was a virtual reference platform for SymbianOS. However since then
> > the Symbian Foundation got shot in the back of the head and the rest of
> > Nokia jumped ship to Windows, so I'd be surprised if anyone real
> I can do that, but not this year (on holiday from Friday 16th, without
> any access to Internet whatsoever :-) One think to be decided is in what
> order the halfs should be filled? Low first, then high? High then low?
> Does it matter at all? :-)
My inital though was that you shouldn't be chang
> Am 12.12.2011 00:42, schrieb Paul Brook:
> >> This series makes target-i386 compile with DEBUG_TCGV_TL.
> >
> > What benefit does this provide?
>
> It showcases what changes would need to be done to allow type-safe
> compilation of the first pair of --e
> > Trying to make a 32-bit target "64-bit safe" without actually
> > implementing the 64-bit target is a complete waste of time.
>
> That's where we disagree. I rather do things right from the start than
> leaving the cleanup work to someone else later on.
>
> > You've almost no chance of getting
> The full set of devices names and properties used in this example are
> below:
>
> Type: I440FX
> Is-a: Device
> Implements: PciBus
> Name: i440fx
> Properties:
>piix3: Composition
>slot[1.0]: Backlink
>
> Type: PIIX3
> Isa-a: PciDevice
> Implements: IsaBus
> Name: i44
> >> +tpm_passthrough="no"
> >
> > Same as before, please probe for existence.
>
> We would be probing for /dev/tpm0. Is that really what we want that this
> driver only gets compiled if /dev/tpm0 is (currently) available?
If what you say is true then this code should always be enabled.
Paul
> > When compiling qemu statically with multilib on PPC, we hit the
> > same issue that commit 845f2c2812d9ed24b36c02a3d06ee83aeafe8b49
> > is fixing. Do the same here.
>
> How many of these ld files can we get rid of if we use -Ttext-segment
> instead? Generally all we're really caring about is m
> Am 12.12.2011 16:58, schrieb Paul Brook:
> >> For me the most annoying issue was that tcg_gen_qemu_{ld,st}* needs
> >> TCGv.
> >
> > You mean the value transferred is always TCGv sized, so ld32u requires an
> > additional truncation before doing 32-bit ari
> >>> You've almost no chance of getting
> >>> it right. In some cases the correct answer will be to use 32-bit
> >>> arithmetic, then sign/zero extend the result. In other cases the
> >>> correct answer will be to perform word size arithmetic. Blindly
> >>> picking one just makes the bugs harder
> On 13.12.2011, at 07:19, Paul Brook wrote:
> >>> When compiling qemu statically with multilib on PPC, we hit the
> >>> same issue that commit 845f2c2812d9ed24b36c02a3d06ee83aeafe8b49
> >>> is fixing. Do the same here.
> >>
> >> How
> On 12/12/2011 11:51 PM, Paul Brook wrote:
> >>>> +tpm_passthrough="no"
> >>>
> >>> Same as before, please probe for existence.
> >>
> >> We would be probing for /dev/tpm0. Is that really what we want that this
> >&g
> It's multiple inheritance but interfaces (implements) cannot carry state
> which avoids an inheritance diamond problem.
> > It sounds like some
> > form of multiple inheritance, but it's unclear to me which should be the
> > primary type. For PCI host bridges like the i440fx we currently have t
> The TPM device accessed by the passthrough driver must not be used by
> any other application on the host.
>
> Since the host's firmware (BIOS/UEFI) has already initialized the TPM,
> the VM's firmware (BIOS/UEFI) will not be able to initialize the TPM
> again and may therefore not show a TPM-sp
> > That still leaves both PCIDevice and SysBusDevice state. The i440fx
> > is a fairly simple device, but more complex bridges have additional state
> > that needs to be accessible from both the PCI and SysBus interfaces.
>
> SysBus is so badly abused today I think we would have to reevaluate wh
> > When compiling qemu statically with multilib on PPC, we hit the
> > same issue that commit 845f2c2812d9ed24b36c02a3d06ee83aeafe8b49
> > is fixing. Do the same here.
>
> How many of these ld files can we get rid of if we use -Ttext-segment
> instead? Generally all we'
> >> Composition == "etching to the same piece of silicon". Nothing more,
> >> nothing less.
> >
> > That's a really crappy definition. Most ARM systems are comprised of
> > approximately one piece of silicon. There may be dozens of variants of a
> > particular chip, with the same device models
> >> IIRC mmap'ing files would break with 32-on-64, but I'd have to check up
> >> on the details. I ended up passing MAP_32BIT to all linux-user mmap
> >> calla for 32-on-x86_64, but that doesn't work with -R.
> >
> > Hmm, I thought we'd fixed that. It's the reason h2g_valid exists.
> >
> > Eith
> The proper solution would be to rewrite mmap.c to be smarter (perhaps
> by looking at /proc/self/maps and reserving a lot of space with PROT_NONE
> mappings at startup and then managing it itself), but so far nobody's
> done that
Yes they have. That's what -R does.
We used to try and parse /pro
> >> The proper solution would be to rewrite mmap.c to be smarter (perhaps
> >> by looking at /proc/self/maps and reserving a lot of space with
> >> PROT_NONE mappings at startup and then managing it itself), but so far
> >> nobody's done that
> >
> > Yes they have. That's what -R does.
>
> -R do
> > Do we have a user interface issue here?
>
> I want to separate backwards compatibility from ABI compatibility. We
> should provide nice high level interfaces that are forever backwards
> compatible. But when it comes to hooking up IRQs between devices, that
> interface should just be ABI com
> But there are two distinct classes of user. One class of user really is
> thinking:
>
> "I want a KVM virtual machine, with 3 disks and 2 network cards"
>
> They could give a flying hoot whether the i440fx inherits from pcidevice or
> implements pcibus.
>
> We need to provide an obviously dis
> I also don't want the user to have to always make the decision about how to
> hook up IRQs for every single device because in a lot of circumstances,
> there's no point.
How else are we going to figure out how the IRQ lines are wired up?
> A basic premise for me is that simple things should be
Recent gcc notice that the ASLA configure check uses an uninitialized
variable, causing spurious failures. Adjust the testcase to avoid this.
Signed-off-by: Paul Brook
---
configure |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index c65b5f6
> This patch introduces configuration variables
> CONFIG_SCSI_LSI
> CONFIG_SCSI_MEGASAS
> and renames the existing CONFIG_ESP to CONFIG_SCSI_ESP.
> With this the available SCSI HBAs can be configured for each
> target configuration instead of compiling it in for everyone.
No. These are both PCI de
> The way mmio endianness is currently implemented is horrifying.
Agreed.
> #ifdef TARGET_WORDS_BIGENDIAN
> val = bswap32(val);
> #endif
>
> With the move to get device code only compiled once, this has
> become harder and harder to justify though, since we don't know
> the target endianness
> Makefile.objs |1 +
> default-configs/i386-softmmu.mak |1 +
> default-configs/x86_64-softmmu.mak |1 +
Why are you only enabling this on x86? PCI devices, especially things like
SATA controllers, should be completely target independent.
Paul
> On 25.11.2010, at 13:28, Paul Brook wrote:
> >> Makefile.objs |1 +
> >> default-configs/i386-softmmu.mak |1 +
> >> default-configs/x86_64-softmmu.mak |1 +
> >
> > Why are you only enabling this on x86? PCI devices, e
> > less than half of the targets are big-endian. If it's broken on
> > big-endian there should be a comment somewhere documenting this, so we
> > know to fix it.
>
> Well, it's stated in the cover letter and the same is true for almost every
> PCI device in qemu we have today. So what would you p
> On 25.11.2010, at 11:59, Paul Brook wrote:
> >> This patch introduces configuration variables
> >> CONFIG_SCSI_LSI
> >> CONFIG_SCSI_MEGASAS
> >> and renames the existing CONFIG_ESP to CONFIG_SCSI_ESP.
> >> With this the available SCSI HBAs can
> I rebased this and rechecked it. The *total* libguestfs boot time
> goes from 86 seconds down to 7.7 seconds. The proportion of that
> attributable to loading the appliance is approximately 650 times [sic]
> faster.
Nack.
> +/* Target address and size for DMA operations. This is only used
>
> I must say I'd like to get rid of the chunking transfer in scsi-disk.
> To have it for scsi-disk only is really pointless, as you can
> potentially send exactly the same commands via scsi-generic.
> So for scsi-generic to work properly qemu need to be able to
> allocate the _entire_ data buffer.
101 - 200 of 1782 matches
Mail list logo
