@@ -682,10 +733,18 @@ void virtio_init_pci(VirtIOPCIProxy *proxy,
VirtIODevice *vdev) if (size (size-1))
size = 1 qemu_fls(size);
+proxy-bar0_mask = size - 1;
You'll get better performance if you use page-sized mappings. You're already
creating a mapping bigger than the
In a nutshell, I don't know what a SHPC is (nor OSHP), so I'm looking
for an additional Ack.
No problem, I'll get an Ack :)
Meanwhile - here's a summary, as far as I understand it.
Originally PCI SIG only defined the electrical
and mechanical requirements from hotplug, no standard
Now an OS can have a standard driver and use it
to activate hotplug functionality. This is OS hotplug (OSHP).
So presumably this will work on targets that don't have ACPI?
Assuming a competent guest OS of course. Have you tested this?
This being the qemu side of things? I run
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 be
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: what requirements
2010/11/29 Paul Brook p...@codesourcery.com:
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
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 the former
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 rather not
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 missing what
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 until
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 Kemari. In addition, last I checked Kemari needs additional
hooks
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
On 11/26/10 03:15, Marcelo Tosatti wrote:
On Fri, Nov 26, 2010 at 12:38:28AM +, 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 on the
port(s), an interrupt signalling remote wakeup
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.
The right approach IMHO is to convert devices to use bus-specific
functions to access memory. The bus specific functions should have
a device argument as the first parameter.
As for ATS, the internal api to handle the device's dma reqeust needs
a notion of a translated vs. an
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 allows
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 doesn't know whether it
happens
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 functions
which can and do return NULL when there's
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 allows
Memory accesses must go through the IOMMU layer.
No. Devices should not know or care whether an IOMMU is present.
You should be adding a DeviceState argument to cpu_physical_memory_{rw,map}.
This should then handle IOMMU translation transparently.
You also need to accomodate the the case
On Wed, Jul 14, 2010 at 02:53:03PM +0100, Paul Brook wrote:
Memory accesses must go through the IOMMU layer.
No. Devices should not know or care whether an IOMMU is present.
There are real devices that care very much about an IOMMU. Basically all
devices supporting ATS care about
+ --enable-amd-iommu-emul) amd_iommu=yes
+#ifdef CONFIG_AMD_IOMMU
+amd_iommu_init(pci_bus);
+#endif
This should not be a configure option.
Paul
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at
So I've been looking for a way to obtain things like a PCIDevice from a
more generic structure (say from hw/qdev.h),
If you're having to figure out what kind of a device you have then I think
you're already doing something else wrong. I'd expect the bits of code that
needs to identify devices
Thanks for your reply. This isn't about a specific IOMMU. Let me
describe the situation better:
1. I'm implementing the AMD IOMMU, which is a PCI IOMMU (not in the CPU).
2. Devices need address translation and checking through this IOMMU.
3. But in the future there might be other IOMMU
### Paul proposes to require all buses to define bus addresses. Make
one up if necessary.
That seems arbitrary and prone to breakage. How do we handle a subtle
change in device instantiation order and still allow migration? If by
code change or command line ordering my frobnitz
* Else, use TYPE.NUM, where TYPE is derived from the bus type, and NUM
is the bus number, as above.
### Paul proposes to either drop TYPE.NUM (and require drivers to
provide bus names), or make NUM count separately for each bus type.
I revised this proposal: Drop the .NUM part, and
Markus Armbruster wrote:
A number of changes to qdev paths have been proposed in various threads.
It's becoming harder to keep track of them, so let me sum them up in one
place. Please correct me if I misrepresent your ideas.
I'm going to describe the current state of things, and the
I think this would be better served by adding explicit aliases/IDs for
those use-cases. i.e. define the global ID pci.0 to be an alias for
/i440FX-pcihost/pci
Makes sense. We could attach this ID to the BusState (corresponding to
DeviceState:id) and manually set it during machine
Bus names are chosen by the system as follows:
* If the driver of the parent device model provides a name, use that.
* Else, if the parent device has id ID, use ID.NUM, where NUM is the bus
number, counting from zero in creation order.
* Else, use TYPE.NUM, where TYPE is
In fact what you really want to do is transfer the device tree
(including properties), and create the machine from scratch, not load
state into a pre-supplied device tree.
Well, I agree, but that's a lot more of an overhaul, and once again
we're changing the problem.
I think it's you
Alex proposed to disambiguate by adding identified properties of the
immediate parent bus and device to the path component. For PCI, these
are dev.fn. Likewise for any other bus where devices have unambigous
bus address. The driver name carries no information!
From user POV, driver
From user POV, driver names are very handly to address a device
intuitively - except for the case you have tones of devices on the same
bus that are handled by the same driver. For that case we need to
augment the device name with a useful per-bus ID, derived from the bus
address where
Paul Brook wrote:
From user POV, driver names are very handly to address a device
intuitively - except for the case you have tones of devices on the
same bus that are handled by the same driver. For that case we need
to augment the device name with a useful per-bus ID, derived from
Works for serial, but fails for ISA devices not occupying an address.
An ISA device without an IO/MMIO capabilities seems extremely unlikely.
What exactly would such a device do?
Inject interrupts via that bus (while exposing registers in some other
way). The m48t59 seems to fall in
Every hotplug-capable bus must have a proper addressing scheme, I think
this is a reasonable and achievable requirement. Then we don't need
instance numbers for those buses.
What about USB?
USB has useful device addresses (physical ports).
These aren't used by most of the higher-level
Every hotplug-capable bus must have a proper addressing scheme, I think
this is a reasonable and achievable requirement. Then we don't need
instance numbers for those buses.
What about USB?
USB has useful device addresses (physical ports).
These aren't used by most of the
On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
Alex proposed to disambiguate by adding identified properties of the
immediate parent bus and device to the path component. For PCI,
these are dev.fn. Likewise for any other bus where devices have
unambigous bus address
I find this argument contradictory. The migration code already needs to
check whether a device is compatible before it allows migration. The
driver name is not sufficient to ensure compatibility, so I see no
benefit in including it in the device address.
See my comment above, I'm not
* Paul Brook (p...@codesourcery.com) wrote:
I find this argument contradictory. The migration code already needs
to check whether a device is compatible before it allows migration.
The driver name is not sufficient to ensure compatibility, so I see
no benefit in including
See my comment above, I'm not seeing a sufficient argument about
why driver name matching is a false sense of security.
I still say it should be the migration code that checks that both
vmstate structures are for the same type of device. i.e. if
necessary the device name
/main-system-bus/pci.0,addr=09.0/virtio-blk-pci
There's a device missing between the main system bus and the pci bus. Should
be something like:
/main-system-bus/piix4-pcihost/pci.0/_09.0
Could you explain why you add identified properties of the immediate
parent bus and device? They
On Mon, 2010-06-14 at 14:09 +0100, Paul Brook wrote:
/main-system-bus/pci.0,addr=09.0/virtio-blk-pci
There's a device missing between the main system bus and the pci bus.
Should be something like:
/main-system-bus/piix4-pcihost/pci.0/_09.0
Ok, I can easily come up
On Mon, 2010-06-14 at 18:49 +0200, Jan Kiszka wrote:
Alex Williamson wrote:
On Mon, 2010-06-14 at 18:00 +0200, Jan Kiszka wrote:
And instead of introducing another hierarchy level with the bus
address, I would also prefer to add this as prefix or suffix to the
device name, e.g.
Ok, I can get it down to something like:
/i440FX-pcihost/pci.0/virtio-blk-pci,09.0
The addr on the device is initially a little non-intuitive to me since
it's a property of the bus, but I guess it make sense if we think of
that level as slot, which includes an address and
The trouble I'm running into is that the SaveStateEntry.instance_id is
effectively private, and there's no easy way to associate a
SaveStateEntry to a device since it passes an opaque pointer, which
could be whatever the driver decides it wants. I'm wondering if we
should pass the
On Thu, 2010-06-10 at 10:23 +0200, Gerd Hoffmann wrote:
I may have been a bit misleading here. What we really want to do is use
the same matching algorithm as is used by the rest of the device
state. Currently this is a vmstate name and [arbitrary] numeric id. I
don't remember whether
to the identify the device. It should probably do this the same way
that we identify the saved state for the device. Currently I think
this is an arbitrary vmstate name/id, but I expect this to change to a
qdev address (e.g. /i440FX-pcihost/pci.0/_addr_04.0).
Ok, that seems
Not all ram is associated with a device.
Maybe not, but where it is we should be using that information.
Absolute minimum we should be using the existing qdev address rather than
inventing a new one. Duplicating this logic inside every device seems
like a bad idea so I suggest
* Alex Williamson (alex.william...@redhat.com) wrote:
+// XXX check duplicates
Yes, definitely. You created a notion of a hierarchical namespace,
can this be formalized any more?
We already have one: The qdev tree.
Paul
--
To unsubscribe from this list: send the line unsubscribe kvm
Keep in mind, this has to be a stable string across versions of qemu
since this is savevm/migration. Are we absolutely confident that the
full qdev path isn't going to change? I'm more confident that a unique
device name is going to be static across qemu versions.
The actual representation
Not really. This identifier is device and bus independent, which is why
I suggested passing the device to qemu_ram_alloc. This can then figure
out how to the identify the device. It should probably do this the same
way that we identify the saved state for the device. Currently I think
The offset given to a block created via qemu_ram_alloc/map() is arbitrary,
let the caller specify a name so we can make a positive match.
@@ -1924,7 +1925,9 @@ static int pci_add_option_rom(PCIDevice *pdev)
+snprintf(name, sizeof(name), pci:%02x.%x.rom,
+
On 06/08/2010 09:30 PM, Paul Brook wrote:
The offset given to a block created via qemu_ram_alloc/map() is
arbitrary, let the caller specify a name so we can make a positive
match.
@@ -1924,7 +1925,9 @@ static int pci_add_option_rom(PCIDevice *pdev)
+snprintf(name, sizeof(name
Does this mean that virtio-blk supports all three combinations?
1. FLUSH that isn't a barrier
2. FLUSH that is also a barrier
3. Barrier that is not a flush
1 is good for fsync-like operations;
2 is good for journalling-like ordered operations.
3 sounds like it doesn't mean a
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 increase
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
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 host side
Wenhao Xu xuwenhao2...@gmail.com 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
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 multiple
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 RISC
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
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 sense for shared memory smp. But we knew that
already.
In think TCG SMP
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 cause problems
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
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 atomics
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.
This patch applies to the qemu-kvm repository
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 barrier,
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
+/*
+ * 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 match
I immediately reproduced the problem locally. It turns out that
kvm reflects packets coming from one guest NIC on another guest
NIC, and since both are connected to the same bridge we're getting
endless packet storm. To a level when kvm process becomes 100%
busy and does not respond to
But I certainly do _not_ want to update the SCSI disk
emulation, as this is really quite tied to the SCSI parallel
interface used by the old lsi53c895a.c.
This is completely untrue. scsi-disk.c contains no transport-specific code. It
is deliberately designed to be independent of both the
However, as I've mentioned repeatedly, the reason I won't merge
virtio-serial is that it duplicates functionality with virtio-console.
If the two are converged, I'm happy to merge it. I'm not opposed to
having more functionality.
I strongly agree.
Paul
--
To unsubscribe from this list: send
So I propose this as a universal quoting scheme:
\char where char is not ASCII alphanumeric.
No thank you. This sounds dangerously like the windows command shell quoting
rules. At first clance they appear to just work, however when you actually
try to figure out what's going on it gets
On Wednesday 15 July 2009, Anthony Liguori wrote:
Blue Swirl wrote:
I bet this won't compile on win32.
Instead of this (IMHO doomed) escape approach, maybe the filename
parameter could be specified as the next argument, for example:
-hda format=qcow2,blah,blah,filename_is_next_arg -hda
Instead of using '-drive if=none' we could use some other syntax where
the filename can be passed as separate argument. Can switches have two
arguments? If so, maybe this:
-hostdrive $file $options
This only works for a single mandatory argument that needs to contain awkward
Right, that part I'm okay with. But the vCont based gdb model presumes
a unified address space which while usually true for kernel address
spaces, isn't universally true and certainly not true when PC is in
userspace. That's what I understood to be the major objection to vCont.
The thread
As pointed out before, it doesn't break anything but adds a workaround
for scenarios which are _now_ broken (16/32 bit target code exported as
64 bit is widely useless for gdb today). Sorry, but you never explained
to me how user are _currently_ supposed to debug under that conditions,
namely
currently SMP guests happen to see n vCPUs as n different sockets.
Some guests (Windows comes to mind) have license restrictions and refuse
to run on multi-socket machines.
So lets introduce a cores= parameter to the -cpu option to let the user
specify the number of _cores_ the guest should
On Saturday 04 July 2009, Andre Przywara wrote:
Paul Brook wrote:
currently SMP guests happen to see n vCPUs as n different sockets.
Some guests (Windows comes to mind) have license restrictions and refuse
to run on multi-socket machines.
So lets introduce a cores= parameter to the -cpu
I agree it's pointless, but it is a Microsoft requirement for passing
their SVVP tests. Enabling it by default makes life a little easier for
users who wish to validate their hypervisor and has no drawbacks.
I wasn't arguing against setting it by default (for QEMU CPU types), just
against
Here are two patches. One implements a virtio-serial device in qemu
and the other is the driver for a guest kernel.
So I'll ask again. Why is this separate from virtio-console?
Paul
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to
On Tuesday 23 June 2009, Amit Shah wrote:
On (Tue) Jun 23 2009 [13:55:52], Paul Brook wrote:
Here are two patches. One implements a virtio-serial device in qemu
and the other is the driver for a guest kernel.
So I'll ask again. Why is this separate from virtio-console?
I'm basically
On Tuesday 23 June 2009, Christian Bornträger wrote:
Am Dienstag 23 Juni 2009 14:55:52 schrieb Paul Brook:
Here are two patches. One implements a virtio-serial device in qemu
and the other is the driver for a guest kernel.
So I'll ask again. Why is this separate from virtio-console?
I
On Thursday 18 June 2009, Michael S. Tsirkin wrote:
Make it possible to resize PCI regions. This will be used by virtio
with MSI-X, where the region size depends on whether MSI-X is enabled,
and can change across load/save.
I thought we'd agreed we shouldn't be doing this.
i.e. if the user
Note that platform must set a flag to declare MSI supported.
For PC this will be set by APIC.
This sounds wrong. The device shouldn't know or care whether the system
has a MSI capable interrupt controller. That's for the guest OS to figure
out.
You are right of course. In theory
If we really need to avoid MSI-X capable devices then that should be done
explicity per-device. i.e. you have a different virtio-net device that
does not use MSI-X.
Paul
Why should it be done per-device?
Because otherwise you end up with the horrible hacks that you're currently
That's seems just plain wrong to me.
Loading a VM shouldn't not
do anything that can't happen during normal operation.
At least wrt pci, we are very far from this state: load just overwrites
all registers, readonly or not, which can never happen during normal
operation.
IMO that code is
On Wednesday 10 June 2009, Michael S. Tsirkin wrote:
On Wed, Jun 10, 2009 at 04:15:04PM +0100, Paul Brook wrote:
That's seems just plain wrong to me.
Loading a VM shouldn't not
do anything that can't happen during normal operation.
At least wrt pci, we are very far from
If you can't create an identical machine from scratch then I don't
consider snapshot/migration to be a useful feature. i.e. as soon as you
shutdown and restart the guest it is liable to break anyway.
Why is liable to break?
A VM booted on an old version of qemu and migrated to a new
On Wednesday 10 June 2009, Michael S. Tsirkin wrote:
On Wed, Jun 10, 2009 at 05:46:03PM +0100, Paul Brook wrote:
If you can't create an identical machine from scratch then I don't
consider snapshot/migration to be a useful feature. i.e. as soon as
you shutdown and restart the guest
If we can't start a new qemu with the same hardware configuration then we
should not be allowing migration or loading of snapshots.
OK, so I'll add an option in virtio-net to disable msi-x, and such
an option will be added in any device with msi-x support.
Will that address your concern?
On Tuesday 09 June 2009, Han, Weidong wrote:
Paul Brook wrote:
On Monday 08 June 2009, Weidong Han wrote:
When hot remove an assigned device, segmentation fault was triggered
by qemu_free(pci_dev-qdev) in pci_unregister_device().
pci_register_device() doesn't initialize or set pci_dev
On Monday 25 May 2009, Michael S. Tsirkin wrote:
Add functions implementing MSI-X support. First user will be virtio-pci.
Note that platform must set a flag to declare MSI supported.
For PC this will be set by APIC.
This sounds wrong. The device shouldn't know or care whether the system has a
On Monday 08 June 2009, Weidong Han wrote:
When hot remove an assigned device, segmentation fault was triggered
by qemu_free(pci_dev-qdev) in pci_unregister_device().
pci_register_device() doesn't initialize or set pci_dev-qdev. For an
assigned device, qdev variable isn't touched at all. So
-/* FIXME: load/save binding. */
-//pci_device_save(vdev-pci_dev, f);
-//msix_save(vdev-pci_dev, f);
qdev regressed save/restore? What else is broken right now from the
qdev commit?
I'm beginning to think committing in the state it was in was a mistake.
Paul, can you put
On Wednesday 20 May 2009, Michael S. Tsirkin wrote:
define api for allocating/setting up msi-x irqs, and for updating them
with msi-x vector information, supply implementation in ioapic. Please
comment on this API: I intend to port my msi-x patch to work on top of
it.
I though the point of
The PCI bus doesn't need any special support (I think) but something on
the other end needs to interpret those writes.
Sure. But there's definitely nothing PCI specific about it. I assumed this
would all be contained within the APIC.
In any case we need some internal API for this, and
The PCI bus doesn't need any special support (I think) but something on
the other end needs to interpret those writes.
Sure. But there's definitely nothing PCI specific about it. I assumed
this would all be contained within the APIC.
MSIs are defined by PCI and their configuration is
On Thursday 21 May 2009, Avi Kivity wrote:
Paul Brook wrote:
In any case we need some internal API for this, and qemu_irq looks
like a good choice.
What do you expect to be using this API?
virtio, emulated devices capable of supporting MSI (e1000?), device
assignment (not yet
A tight coupling between PCI devices and the APIC is just going to cause
us problems later one. I'm going to come back to the fact that these are
memory writes so once we get IOMMU support they will presumably be
subject to remapping by that, just like any other memory access.
I'm not
1 - 100 of 140 matches
Mail list logo
