> > 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-l
> > > 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
> 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 an
> > 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,
> * 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 compat
> > > > > 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
> > > >
> * 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, an
> 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
> > 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
> > 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,
> > ### 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 frobn
> 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 device
> 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
> 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 wher
> 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
> + --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 in
> > 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 un
> > 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
> 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
> 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
> >>> 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 Thursday 04 December 2008, Anthony Liguori wrote:
> Hollis Blanchard wrote:
> > On Thu, 2008-12-04 at 20:33 +, Anthony Liguori wrote:
> >> +static void balloon_page(void *addr, int deflate)
> >> +{
> >> +#if defined(__linux__)
> >> +if (!kvm_enabled() || kvm_has_sync_mmu())
> >> +
On Monday 08 December 2008, Ryan Harper wrote:
> Linux and Windows send a TARGET RESET message to the device when it fails
> to respond as it expects. For example, when it tries to select LUN1, which
> we don't support. This patch is needed to support the Linux sym53c8xx_2
> driver when configure
> Which I figured was because lsi_soft_reset doesn't initialize
> current_dma_len. I added current_dma_len to soft_reset and now we can
> probe with out failing, and existing partitions on the device show up,
> but any further use of the device results in broken behavior.
>...
> Because the drive
On Sunday 14 December 2008, Gleb Natapov wrote:
> There is a need for communication channel between host and various
> agents that are running inside a VM guest. The channel will be used
> for statistic gathering, logging, cut & paste, host screen resolution
> changes notification, guest configurat
> > That's pointless; cirrus for example has 8MB of mmio while a
> > cpu-to-vram blit is in progress, and some random device we'll add
> > tomorrow could easily introduce more. Our APIs shouldn't depend on
> > properties of emulated hardware, at least as much as possible.
>
> One way to think of w
> The generic resolving API should look something like
>
> int (*resolve)(target_phys_addr_t address_in, target_phys_addr_t
> length_in, target_phys_addr_t &address_out, target_phys_addr_t
> &length_out)
I don't think this is sufficient. A paged iommu may split a single range into
multiple disjoi
> > Modern BIOSes have splash screens. I don't see why our BIOS shouldn't
> > have one too.
>
> Crap PC BIOSes have splash screens because they're horribly slow
> and otherwise printing lots of irrelevant scary junk at users. The
> best BIOS 'splash' screen is one which never appears unless there
> BTW, why does qemu not carry all bochs bios source? For reference, but
> also to fully comply with the LGPL (pointing to the original source is
> not sufficient when delivering binaries - like e.g. bios.bin...).
If this is really an issue, then I strongly suggest we fix it by moving the
bios in
> > I'm trying to debug a 32bit (i386) kernel on a 64bit host under kvm, but
> > gdb always refuses it with:
> QEMU and also KVM's x86_64 version are currently broken /wrt debugging
> targets < 64 bits. I've posted a fix a while ago, but there were
> concerns that gdb should better be enhanced (wh
On Saturday 20 December 2008, Jan Kiszka wrote:
> Paul Brook wrote:
> >>> I'm trying to debug a 32bit (i386) kernel on a 64bit host under kvm,
> >>> but gdb always refuses it with:
> >>
> >> QEMU and also KVM's x86_64 version are currently br
> >> From a higher perspective, it is surely not the cleanest approach. But
> >> it still appears to be the only one which helps us working around this
> >> gdb shortcoming.
> >
> > Actually it isn't. You could add an explicit switch.
>
> And what would this buy us? I would have to go from your gdb
> Well, I'm using gdb over qemu and kvm in precisely that hybrid
> scenarios, but also in normal ones. Heavily. And I'm only able to do
> this because of the workaround. But I'm willing to learn about scenarios
> where it causes /regressions/.
I find that hard to believe. Doesn't it break horribly
> Do those archs also have multiple register layouts that are coupled to
> those different instruction sets? Do they switch the instruction sets
> via 'set arch'?
No, but neither does x86. You just need to teach gdb how to debug 32-bit code
on a 64-bit target.
> I think x86 is (historically) spe
> A concern here is the growing size of the virtio-net I/O port space
> config. This series brings it up to 256 bytes with PCI resource
> rounding. The VLAN filter bitmap would increase that by another 512
> bytes, making it 1kB and limiting us to something less than 64 such
> devices per guest.
> >> A concern here is the growing size of the virtio-net I/O port space
> >> config. This series brings it up to 256 bytes with PCI resource
> >
> > This is one reason why IO ports are a reallybad idea. Use memory mapped
> > register spaces like any other sane system and you won't have a problem.
> What I meant is that if we allow the guest to change his mac address, it
> can deliberately
> change it to other hosts/guests mac and thus create networking problems.
> Although guest can always mangle packets, maybe it worth enforcing these
> macs for the guest.
This doesn't seem any different
> >> +static uint8_t bcast[] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
> >
> > 'const'?
>
> It may be good practice but practically speaking, I don't think it will
> generate different code. The only thing that uses bcast is memcmp()
> which should be a builtin. Since bcast doesn't otherwise e
On Friday 06 February 2009, Alex Williamson wrote:
> Now that virtio-net knows what packets the guest wants to see, we
> can start moving the filtering down the stack. This patch adds
> an interface to set the software filter in the tap device. It's
> fairly limited, but we can back it up with ou
> > There should be two interface points between the the vlan and the device:
> > 1) The device can indicate that it only cares about incoming (vlan to
> > device) packets sent to a subset of MAC addresses.
> > 2) The vlan can request that a device discards outgoing (device to vlan)
> > packets tha
> +static void virtio_net_vlan_client_added(void *opaque)
>...
> +static void virtio_net_vlan_client_removed(void *opaque)
Why are these two different?
It looks like what you really want is a callback for "Something changed,
and you need to reset your MAC filter."
Paul
--
To unsubscribe from thi
On Thursday 12 February 2009, Alex Williamson wrote:
> On Thu, 2009-02-12 at 16:26 +0000, Paul Brook wrote:
> > > +static void virtio_net_vlan_client_added(void *opaque)
> > >...
> > > +static void virtio_net_vlan_client_removed(void *opaque)
> >
> > Why
> - A device requests a filter and is told if the request is successful
> - On success the device may skip it's own filtering
> - If another vlan client is added, the following _must_ occur:
> - The "filterer" must clear (remove) the filter
> - The "filteree" must revert to using their own fi
On Friday 13 February 2009, Jamie Lokier wrote:
> Paul Brook wrote:
> > > We could use a changed() function, but it would need to know the
> > > direction of the change, which leads back to the same mechanics. If
> > > there's a better way, please suggest it.
> > A simple "Something changed, please try your filter again" callback
> > automatically covers all these cases.
>
> It doesn't, if tap has no memory of how many clients require a filter.
I'm talking about a callback for devices requesting an inbound filter. Devices
implementing outgoing (device
> The callback you suggest for devices requesting an inbound filter will
> infinite-loop when there's two such devices on the same vlan bus,
> because each time the callback is called, that device will re-issue
> its filter request which triggers the callback on the other similar
> device. Back an
> > > I think it still suffers from the same race condition so today it
> > > wouldn't work. You could fix the bottom half scheduling though so that
> > > you could safely schedule a bottom half from a signal handler (using
> > > roughly the same trick).
> >
> > Fwiw, it's perfectly sensible to ha
> >> svn co svn://svn.savannah.nongnu.org/qemu/branches/stable_0_10_0
> > Will a stable release be called 0.10.0.1 or 0.10.1? (I'd prefer the
> > latter)
>
> I was thinking the later but am open to suggestion.
Definitely the latter. I think the branch is mis-named, it should be
stable_0_10 (with
On Wednesday 28 May 2008, Glauber Costa wrote:
> Hi guys,
>
> here's a new spin of the patches I sent yesterday. It basically merges the
> comments I received, and adapts to the current state of the svn tree.
> Also, as Fabrice said multiple times inlining would be better, I'm taking
> a new approa
> Ultimately, I'd like to push this into qemu since nothing we're doing
> here is arch or kvm specific.
What advantage does inclusion with qemu give?
AFAICS You're going to have to download gigabytes of images anyway, so
wouldn't it make more sense to include the test script with those?
Paul
--
On Tuesday 29 July 2008, andrzej zaborowski wrote:
> 2008/7/29 Chris Lalancette <[EMAIL PROTECTED]>:
> > Attached is a simple patch to make i2c_bus_save() put a 32-bit quantity
> > in the save file, which matches what i2c_bus_load() expects to pull out
> > of the save file later. Without this fix
> I've been playing with CONFIG_NO_HZ and been surprised by the
> results. I was trying to reproduce the wakeup every 10ms that
> Samuel Thibault mentioned, thinking the HPET would improve it.
> But for an idle guest in both cases (with and without HPET), the
> number of wakeups per second was rel
> This patch obviously requires UHCI patch. The combo has been tested with
> various devices. See the UHCI patch description for list of the devices.
> Most of the testing was done with the KVM flavor of QEMU.
Have you tested OHCI hosts?
Paul
--
To unsubscribe from this list: send the line "unsub
> Given that OHCI is much more complex than UHCI (both the code and the spec)
> I decided to give up on OHCI, at least for now. I noticed Codesourcery
> copyright on OHCI. Did you have anything to do with the OHCI implementation?
Yes, I wrote the current OHCI support, based on some initial patches
101 - 154 of 154 matches
Mail list logo
