> 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
> > 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
> > > 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
> > >
> > 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
>
> 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
> 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
> 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
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
> 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
> 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
> >> +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
> -/* 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
> 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
> > 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
>
> 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
> 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
> 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
> > 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, 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
> > 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
> > 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
> 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
> 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
> 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
> > 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
> ought to be enough for anybody.
Off the top of my head: AClink (audio), i2s (audio), SSI/SSP (synchonous
serial), Firewire,
> > For changes to
> > the TCG side we want to consider how we can provide useful aliasing
> > information, rather than a naive replacement of TCG_AREG0 with a
> > variable.
>
> What aliasing information?
Aliasing of cpu state accesses between tcg_global_mem_new_* variables,
qemu_ld/st ops, and
> > I just spoke with Paul on IRC about this. In summary:
> > * for a helper to cause an exception then it has (a) to make sure CPU
> >
> > state (pc, condflags) is sync'd before the call to the helper and (b)
> > the helper has to be in a file with access to global env, because it
> > needs to ca
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> @@ -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
> 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
> > 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
> 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
> 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
>
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
> Hello.
>
> I am working on implementation of deteministic execution replay technology
> for Qemu. It should be similar to VMWare's replay debugging.
>
> To make alarm timer (which invokes host_alarm_handler function)
> determinisic, I changed it's behavior: it sets flag, that execution should
> I have some questions about PCIe operations sssuming the device has MMIO
> handlers involved (as shown above).
> 1. Will all PCIe config operations
> ALWAYS use the installed config handlers? Or can PCIe config operations
> use the MMIO handlers?
Access to PCI config space is provided by the P
> This adds a minimum chunk of Anthony's RAM API support so that we
> can identify actual VM RAM versus all the other things that make
> use of qemu_ram_alloc.
Why do we care? How are you defining "actual VM RAM"?
Surely the whole point of qemu_ram_alloc is to allocate a chunk of memory that
can
> On Sat, Dec 11, 2010 at 12:50:20PM +0000, Paul Brook wrote:
> > > It's guest visible state, so it must not change due to migrations. For
> > > the current implementation all values for it work anyway - if it's
> > > smaller than the block size w
> On Thu, Dec 02, 2010 at 01:12:13PM +0100, Kevin Wolf wrote:
> > > DEFINE_PROP_UINT16("physical_block_size", _state,
> > > \
> > >
> > > _conf.physical_block_size, 512),
> > > \
> > >
> > >
Not a qemu bug. madvise and (associated constants via sys/mman.h) are
supplied by glibc. You need to update your C library.
** Changed in: qemu
Status: New => Invalid
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bug
> -if (!discard) {
> +if (discard) {
> +goto next;
> +}
> +next:
> virtqueue_push(vq, &elem, 0);
Please don't do this.
Paul
> On (Fri) Dec 10 2010 [13:59:50], Paul Brook wrote:
> > > Check if the guest really sent any items in the out_vq before using
> > > them. Similarly, check if there is a buffer to send data in before
> > > writing.
> >
> > Can this actually happen? If
> On (Fri) Dec 10 2010 [14:02:37], Paul Brook wrote:
> > > -if (!discard) {
> > > +if (discard) {
> > > +goto next;
> > > +}
> > >
> > > +next:
> > > virtqueue_push(vq, &elem, 0
> Check if the guest really sent any items in the out_vq before using
> them. Similarly, check if there is a buffer to send data in before
> writing.
Can this actually happen? If so why/how?
Why does it need a special case in this device?
If this is guest triggerable then calling abort() is wron
> > > > > But that's entirely in guest memory, so it's limited to the amount
> > > > > of RAM that has been allocated to the guest.
> > > >
> > > > Exactly. The guest can cause ram_size * nr_ports of additional host
> > > > memory to be allocated. Not acceptable.
> > >
> > > OK -- so this is how
> > > Sure. My proposal is for qemu_chr_write() to succeed all the time. If
> > > the backend can block, and the caller can handle it, it can get a
> > > -EAGAIN (or WSAEWOULDBLOCK) return. When the backend becomes writable,
> > > the chardev can call the ->writes_unblocked() callback for that c
> > As with the DMA interface added a while ago, I believe it's important to
> > get these APIs right. Quick hacks to support limited use-cases just end
> > up needing a complete rewrite (or even worse multiple concurrent
> > APIs/implementations) once we actually start using them seriously.
>
>
> On (Thu) Dec 02 2010 [17:31:36], Paul Brook wrote:
> > > > > when there's a partial write, it tries to do a write again, which
> > > > > will fail with -EAGAIN.
> > > >
> > > > Doesn't that cause the first partial chunk to be i
> Logically, implementation of Vmull.s32 and vmul.u32 is just similar to the
> 8 and 16 bit cases. For example:
> case 4: gen_helper_neon_mull_s32(dest, a, b); break;
> case 5: gen_helper_neon_mull_u32(dest, a, b); break;
> I implemented in this way and tested. It is OK. So I can't understa
> > > when there's a partial write, it tries to do a write again, which will
> > > fail with -EAGAIN.
> >
> > Doesn't that cause the first partial chunk to be incorrectly transmitted
> > twice? You may only return EAGAIN if no data was transmitted.
>
> Except for the fact that no caller of qemu_c
> On (Wed) Dec 01 2010 [11:59:35], Paul Brook wrote:
> > > > > -qemu_chr_write(vcon->chr, buf, len);
> > > > > +ret = qemu_chr_write(vcon->chr, buf, len);
> > > > > +if (ret == -EAGAIN) {
>
> /* Callback function that's called when the guest sends us data */
> static void flush_buf(VirtIOSerialPort *port, const uint8_t *buf, size_t
> len) {
> VirtConsole *vcon = DO_UPCAST(VirtConsole, port, port);
> +int ret;
>
> -qemu_chr_write(vcon->chr, buf, len);
> +ret = qemu_
> > > -qemu_chr_write(vcon->chr, buf, len);
> > > +ret = qemu_chr_write(vcon->chr, buf, len);
> > > +if (ret == -EAGAIN) {
> > > +virtio_serial_throttle_port(port, true);
> > > +}
> > >
> > > }
> >
> > This looks wrong. It will loose data in the case of a partial write
>
> usb_add net:192.168.1.100::[vid]:[pid]
> or:
> usb_add net:192.168.1.100::[busnr]:[addr]
> > ...
> > Instead I suggest just using a freeform string ID. For practical reasons
> > we probably want to restrict this to regular characters, like we do
> > other ids (i.e. [-_A-Za
> Hi,
>
> On 11/30/2010 12:32 PM, Alon Levy wrote:
> > On Tue, Nov 30, 2010 at 12:26:56PM +0100, Hans de Goede wrote:
>
>
> >> Then there would be multiple ways to add a virtual usb device using
> >> usb-net-redir.c to the virtual machine. One way of adding such a device
> >> could be starting a
> On 11/29/2010 10:53 AM, Paul Brook wrote:
> >>> Is this a fair summary: any device that supports live migration workw
> >>> under Kemari?
> >>
> >> It might be fair summary but practically we barely have live migration
> >> working w/o Kemar
>Hi,
>
> > Not me at the moment, but unless you tunnel it inside another
> > protocol, you'd really want to look at the existing USB-over-IP
> > protocols instead of reinventing the wheel:
> > http://usbip.sourceforge.net/ (some support in Linux already IIRC)
> > (and there are others which I
> > Is this a fair summary: any device that supports live migration workw
> > under Kemari?
>
> It might be fair summary but practically we barely have live migration
> working w/o Kemari. In addition, last I checked Kemari needs additional
> hooks and it will be too hard to keep that out of tree
> >> Sorry, I didn't get what you're trying to tell me. My plan would
> >> be to initially start from a subset of devices, and gradually
> >> grow the number of devices that Kemari works with. While this
> >> process, it'll include what you said above, file a but and/or fix
> >> the code. Am I m
> > If devices incorrectly claim support for live migration, then that should
> > also be fixed, either by removing the broken code or by making it work.
>
> I totally agree with you.
>
> > AFAICT your current proposal is just feeding back the results of some
> > fairly specific QA testing. I'd
> >> To answer Stefan's question, there shouldn't be any requirement
> >> for a device, but must be tested with Kemari. If it doesn't work
> >> correctly, the problems must be fixed before adding to the list.
> >
> > What exactly are the problems? Is this a device bus of a Kemari bug?
> > If it's
> 2010/11/29 Paul Brook :
> >> >> Could you formulate the constraints so developers are aware of them
> >> >> in the future and can protect the codebase. How about expanding the
> >> >> Kemari wiki pages?
> >> >
> >> > I
> >> Could you formulate the constraints so developers are aware of them in
> >> the future and can protect the codebase. How about expanding the
> >> Kemari wiki pages?
> >
> > If you like the idea above, I'm happy to make the list also on
> > the wiki page.
>
> Here's a different question: wha
> On Sat, Nov 27, 2010 at 11:30:52AM +0000, Paul Brook wrote:
> > ---
> >
> > Makefile.objs |3 +-
> > default-configs/pci.mak |1 +
> > default-configs/sparc-softmmu.mak |1 +
> > h
e same
> for targets where I wasn't entirely sure.
... and for good reason. The lance code relies on the (nominally PCI) pcnet
emulation :-( Fixed as below.
Subject: [PATCH] Split out common pcnet code
The core pcnet emulation code is used by both the PCI "pcnet" device
and the SPARC
> One question I have about Kemari is whether it adds new constraints to
> the QEMU codebase? Fault tolerance seems like a cross-cutting concern
> - everyone writing device emulation or core QEMU code may need to be
> aware of new constraints. For example, "you are not allowed to
> release I/O op
> > diff --git a/default-configs/sparc-softmmu.mak
> > b/default-configs/sparc-softmmu.mak index becf880..7c788b8 100644
> > --- a/default-configs/sparc-softmmu.mak
> > +++ b/default-configs/sparc-softmmu.mak
> > @@ -1,10 +1,10 @@
> > # Default configuration for sparc-softmmu
> >
> > +include pci
> > Switching endianness of a CPU generally does not effect the endianness of
> > the CPU/peripheral busses. It makes the CPU byteswap accesses before
> > they are seen by either memory or devices.
> >
> > In theory it might be possible to avoid redundant byteswaps if you're
> > really clever. I
er
> grained control over which devices are built.
>
> Following patch series allows a default config to include other files, and
> uses this to consistently enable all PCI devices on all targets.
>
> I have also made VirtIO devices optional.
>
> Paul Brook (3):
>
> Currently we list PCI devices in every PCI capable architecture
> individually. This is cumbersome when adding new devices and prone to
> failure because one might miss out on one.
>
> So let's instead have a generic PCI configuration file where people can
> throw in their cross-platform compati
Make virtio devices optional. Selecting individual devices is not useful
as the host bindings are all in one file.
Signed-off-by: Paul Brook
---
Makefile.objs | 10 --
Makefile.target |4 ++--
default-configs/s390x-softmmu.mak |1 +
3
Split PCI config options into a separate file
Signed-off-by: Paul Brook
---
Makefile.objs | 20 +++-
Makefile.target|4 ++--
default-configs/arm-softmmu.mak|3 +--
default-configs/cris-softmmu.mak |2
Allow default configs to be split into several files.
Signed-off-by: Paul Brook
---
Makefile | 11 ++-
Makefile.objs |3 ++-
make_device_config.sh | 27 +++
3 files changed, 35 insertions(+), 6 deletions(-)
create mode 100644
over which devices are built.
Following patch series allows a default config to include other files, and
uses this to consistently enable all PCI devices on all targets.
I have also made VirtIO devices optional.
Paul Brook (3):
Include directives in default configs
PCI config include
VirtIO
> > diff --git a/exec.c b/exec.c
> > index db9ff55..f54a360 100644
> > --- a/exec.c
> > +++ b/exec.c
> >
> > @@ -3370,6 +3474,22 @@ static int cpu_register_io_memory_fixed(int
> > io_index,
> >
> > }
> > io_mem_opaque[io_index] = opaque;
> >
> > +switch (endian) {
> > +case DEVIC
> > Likewise requiring separate tracing hooks be added to the existing
> > decoders is extremely unlikely to be a feasible long-term
> > solution.
>
> You mean having to modify each "translate.c"? The worst event to handle
> is instruction fetch on x86.
Instruction fetches are trivial, you just i
> 2) instrumenting i386 is extremely time-consuming (for the developer)
>
> As my work is not tied to a specific target architecture, I was thinking of
> shifting into PPC, as the ISA is pretty regular and that would certainly
> make the process easier by just patching a small set of places in the
> On 11/26/10 03:15, Marcelo Tosatti wrote:
> > On Fri, Nov 26, 2010 at 12:38:28AM +0000, Paul Brook wrote:
> >>> This patch enables USB UHCI global suspend/resume feature. The OS will
> >>> stop the HC once all ports are suspended. If there is activity o
> This patch enables USB UHCI global suspend/resume feature. The OS will
> stop the HC once all ports are suspended. If there is activity on the
> port(s), an interrupt signalling remote wakeup will be triggered.
I'm pretty sure this is wrong. Suspend/resume works based on physical
topology, i.e
> 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.
> 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
>
> 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
> > 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 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
> 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
> 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
> 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
> > 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
> > 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
> 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
> >>> 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
> 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
> 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
> > 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
201 - 300 of 1782 matches
Mail list logo
