On 9/23/08, David Miller <[EMAIL PROTECTED]> wrote:
> From: Hollis Blanchard <[EMAIL PROTECTED]>
>
> Date: Mon, 22 Sep 2008 16:27:40 -0500
>
>
> > On Mon, 2008-09-22 at 15:31 -0500, Javier Guerra wrote:
> > > On Mon, Sep 22, 2008 at 3:18 PM, Hollis Blanchard <[EMAIL PROTECTED]>
> wrote:
> > > >
On 9/23/08, David Miller <[EMAIL PROTECTED]> wrote:
> From: "Blue Swirl" <[EMAIL PROTECTED]>
>
> Date: Tue, 23 Sep 2008 18:28:06 +0300
>
>
> > On 9/22/08, David Miller <[EMAIL PROTECTED]> wrote:
>
> > > As he mentioned, the V8 rett inst
On 9/23/08, David Miller <[EMAIL PROTECTED]> wrote:
> From: "Blue Swirl" <[EMAIL PROTECTED]>
>
> Date: Tue, 23 Sep 2008 18:34:12 +0300
>
>
> > On 9/23/08, David Miller <[EMAIL PROTECTED]> wrote:
>
> > > Sun4v systems come with Sun
On 9/24/08, Blue Swirl <[EMAIL PROTECTED]> wrote:
> On 9/23/08, David Miller <[EMAIL PROTECTED]> wrote:
> > From: "Blue Swirl" <[EMAIL PROTECTED]>
> >
> > Date: Tue, 23 Sep 2008 18:28:06 +0300
> >
> >
> > > On 9/22/08,
On 9/24/08, David Miller <[EMAIL PROTECTED]> wrote:
> From: "Blue Swirl" <[EMAIL PROTECTED]>
>
> Date: Wed, 24 Sep 2008 21:06:21 +0300
>
>
> > Now I found the relevant part in the manuals. The extra sun4v bit is
> > not taken into accoun
On 10/29/08, Avi Kivity <[EMAIL PROTECTED]> wrote:
> Hollis Blanchard wrote:
>
> > On Tue, Oct 28, 2008 at 6:36 PM, Anthony Liguori <[EMAIL PROTECTED]>
> wrote:
> >
> >
> > > Something I was thinking about this morning, and I think the first place
> > > where we'll definitely need a hook, is how to
On 10/29/08, Blue Swirl <[EMAIL PROTECTED]> wrote:
> On 10/29/08, Avi Kivity <[EMAIL PROTECTED]> wrote:
> > Hollis Blanchard wrote:
> >
> > > On Tue, Oct 28, 2008 at 6:36 PM, Anthony Liguori <[EMAIL PROTECTED]>
> > wrote:
> > >
> &
On 5/20/09, Avi Kivity wrote:
> Blue Swirl wrote:
>
> > Sparc64 also uses packets ("mondos", not implemented yet) for
> > interrupt vector data, there the packet size is 8 * 64 bits. I think
> > we should aim for a more generic API that covers this case al
On 5/20/09, Michael S. Tsirkin wrote:
> On Wed, May 20, 2009 at 08:44:31PM +0300, Blue Swirl wrote:
> > On 5/20/09, Michael S. Tsirkin wrote:
> > > On Wed, May 20, 2009 at 08:21:01PM +0300, Blue Swirl wrote:
> > > > On 5/20/09, Michael S. Tsirkin wrote:
> &
On 5/20/09, 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.
>
> Signed-off-by: Michael S. T
On 5/20/09, Michael S. Tsirkin wrote:
> On Wed, May 20, 2009 at 08:21:01PM +0300, Blue Swirl wrote:
> > On 5/20/09, Michael S. Tsirkin wrote:
> > > define api for allocating/setting up msi-x irqs, and for updating them
> > > with msi-x vector information, supp
On 5/20/09, Michael S. Tsirkin wrote:
> On Wed, May 20, 2009 at 09:38:58PM +0300, Blue Swirl wrote:
> > On 5/20/09, Michael S. Tsirkin wrote:
> > > On Wed, May 20, 2009 at 08:44:31PM +0300, Blue Swirl wrote:
> > > > On 5/20/09, Michael S. Tsirkin wrote:
>
On 5/20/09, Michael S. Tsirkin wrote:
> On Wed, May 20, 2009 at 11:02:24PM +0300, Michael S. Tsirkin wrote:
> > On Wed, May 20, 2009 at 09:38:58PM +0300, Blue Swirl wrote:
> > > On 5/20/09, Michael S. Tsirkin wrote:
> > > > On Wed, May 20, 2009 at 08:4
On 5/20/09, Michael S. Tsirkin wrote:
> On Wed, May 20, 2009 at 11:26:42PM +0300, Blue Swirl wrote:
> > On 5/20/09, Michael S. Tsirkin wrote:
> > > On Wed, May 20, 2009 at 11:02:24PM +0300, Michael S. Tsirkin wrote:
> > > > On Wed, May 20, 2009 at 09:3
On 3/16/10, Anthony Liguori wrote:
> On 03/16/2010 08:57 AM, Avi Kivity wrote:
>
> > On 03/16/2010 03:51 PM, Anthony Liguori wrote:
> >
> > > On 03/16/2010 08:29 AM, Avi Kivity wrote:
> > >
> > > > On 03/16/2010 03:17 PM, Yoshiaki Tamura wrote:
> > > >
> > > > > Avi Kivity wrote:
> > > > >
> > > >
On 3/30/10, Eduard - Gabriel Munteanu wrote:
> hw/iommu.c concerns the SPARC IOMMU. However we intend to implement the
> AMD IOMMU, which could lead to confusion unless we rename the former.
I was also thinking of renaming the file some time ago. The correct
name would be "sun4m_iommu.c". Sun4c
On 3/30/10, Joerg Roedel wrote:
> On Tue, Mar 30, 2010 at 08:06:36PM +0300, Blue Swirl wrote:
> > On 3/30/10, Eduard - Gabriel Munteanu wrote:
> > > hw/iommu.c concerns the SPARC IOMMU. However we intend to implement the
> > > AMD IOMMU, which could lead to con
On 3/30/10, Eduard - Gabriel Munteanu wrote:
> This currently loads a non-functional IVRS ACPI table and provides a
> skeleton for initializing the AMD IOMMU.
>
> Signed-off-by: Eduard - Gabriel Munteanu
> ---
> Makefile.target |1 +
> hw/amd_iommu.c | 103
> +
Thanks, applied.
On Thu, Jul 29, 2010 at 9:16 PM, Marcelo Tosatti wrote:
> On Thu, Jul 29, 2010 at 01:41:45PM +0300, Gleb Natapov wrote:
>> Use this one instead.
>>
>> On Wed, Jul 28, 2010 at 06:13:22PM +0300, Gleb Natapov wrote:
>> > It is possible that subpage mmio is registered over existing m
On Sat, Aug 28, 2010 at 2:54 PM, Eduard - Gabriel Munteanu
wrote:
> This introduces emulation for the AMD IOMMU, described in "AMD I/O
> Virtualization Technology (IOMMU) Specification".
>
> Signed-off-by: Eduard - Gabriel Munteanu
> ---
> Makefile.target | 2 +-
> hw/amd_iommu.c | 663
> +
On Sat, Aug 28, 2010 at 2:54 PM, Eduard - Gabriel Munteanu
wrote:
> Hi,
>
> I rebased my work on mst's PCI tree and, hopefully, fixed issues raised by
> others. Here's a summary of the changes:
> - made it apply to mst/pci
> - moved some AMD IOMMU stuff in a reset handler
> - dropped range_covers_
On Sat, Aug 28, 2010 at 9:53 PM, Eduard - Gabriel Munteanu
wrote:
> On Sat, Aug 28, 2010 at 03:58:23PM +0000, Blue Swirl wrote:
>> On Sat, Aug 28, 2010 at 2:54 PM, Eduard - Gabriel Munteanu
>> wrote:
>> > This introduces emulation for the AMD IOMMU, described in &quo
On Sun, Aug 29, 2010 at 9:55 AM, Joerg Roedel wrote:
> On Sat, Aug 28, 2010 at 04:00:31PM +0000, Blue Swirl wrote:
>> On Sat, Aug 28, 2010 at 2:54 PM, Eduard - Gabriel Munteanu
>
>> > Please have a look and merge if you like it.
>>
>> The endianess bug still exist
On Thu, Sep 2, 2010 at 9:49 AM, Michael S. Tsirkin wrote:
> On Thu, Sep 02, 2010 at 11:40:58AM +0300, Eduard - Gabriel Munteanu wrote:
>> On Thu, Sep 02, 2010 at 08:28:26AM +0300, Michael S. Tsirkin wrote:
>> > On Sat, Aug 28, 2010 at 05:54:53PM +0300, Eduard - Gabriel Munteanu wrote:
>> > > PCI d
On Tue, Sep 7, 2010 at 2:43 AM, Amos Kong wrote:
> -- Forwarded message --
> From: Amos Kong
> Date: Tue, Sep 7, 2010 at 7:49 AM
> Subject: Guest hangs when I do general operation.
> To: 王箫
>
>
> kvm upstream: 43e413f7db1a4a90671dda0b1d6c1f8cb30673ed KVM: Whitespace
> changes to
On Wed, Oct 13, 2010 at 8:00 AM, Hidetoshi Seto
wrote:
> (Add CC to k...@vger)
>
> (2010/10/12 10:52), Hao, Xudong wrote:
>> Hi,
>> Currently qemu-kvm build fail on RHEL5 with gcc 4.1.2, build can pass on
>> Fedora11 with gcc 4.4.1, can anybody look on RHEL5 system?
>>
>> Gcc: 4.1.2
>> system: RH
your patch on top of this. You
>>> could add a kvm_cpu_model to the machine structure that gets defaulted
>>> too if kvm_enabled(). You could also introduce a new KVM machine type
>>> that gets defaulted to if no explicit machine is specified.
>>>
>>
>
On Sun, Oct 24, 2010 at 3:34 PM, Avi Kivity wrote:
> The current ioport callbacks are not type-safe, in that they accept an
> "opaque"
> pointer as an argument whose type must match the argument to the registration
> function; this is not checked by the compiler.
>
> This patch adds an alternativ
On Mon, Oct 25, 2010 at 10:00 AM, Avi Kivity wrote:
> On 10/24/2010 08:14 PM, Blue Swirl wrote:
>>
>> On Sun, Oct 24, 2010 at 3:34 PM, Avi Kivity wrote:
>> > The current ioport callbacks are not type-safe, in that they accept an
>> > "opaque"
>>
On Tue, Oct 26, 2010 at 8:05 AM, Avi Kivity wrote:
> On 10/25/2010 08:38 PM, Blue Swirl wrote:
>>
>> >
>> > I don't really see why we need registration; cpu_register_io() takes
>> > function pointers, a size, and an opaque, and gives an integer hand
On Tue, Oct 26, 2010 at 5:35 PM, Avi Kivity wrote:
> On 10/26/2010 07:27 PM, Anthony Liguori wrote:
>>>
>>> Sorry, I don't follow your meaning.
>>>
>>> When I said "size is implied" I meant that the IOPort object has a
>>> separate function pointer for sizes 1, 2, and 4, so it ioport_register()
>
On Wed, Oct 27, 2010 at 9:26 AM, Avi Kivity wrote:
> On 10/26/2010 08:33 PM, Blue Swirl wrote:
>>
>> >
>> > Why two types? I think some devices use PIO on a PC and MMIO on other
>> > architectures. Sharing the type would allow sharing code.
>>
&
On Fri, Oct 29, 2010 at 4:39 PM, Alex Williamson
wrote:
> 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.
>
> Signed-off-by: Alex Williamson
> ---
>
> Makefile.target | 1 +
> cpu-com
On Thu, Jan 21, 2010 at 2:39 PM, Andre Przywara wrote:
> john cooper wrote:
>>
>> Chris Wright wrote:
>>>
>>> * Daniel P. Berrange (berra...@redhat.com) wrote:
To be honest all possible naming schemes for '-cpu ' are just as
unfriendly as each other. The only user friendly option is
On Mon, Jun 14, 2010 at 9:44 AM, Nicholas A. Bellinger
wrote:
> From: Nicholas Bellinger
>
> This patch adds initial support for using the Linux BSG interface with
> write/read vectored
> AIO as a QEMU backstore (SCSIDeviceInfo) with hw/scsi-bus.c compatible HBA
> emulation.
Did I miss the doc
On Tue, Jun 15, 2010 at 4:13 PM, Anthony Liguori wrote:
> On 06/15/2010 10:41 AM, Christoph Hellwig wrote:
>>
>> On Tue, Jun 15, 2010 at 08:18:12AM -0700, Chris Wright wrote:
>>
>>>
>>> KVM/qemu patches
>>> - patch rate is high, documentation is low, review is low
>>> - patches need to include bet
On Fri, Jun 18, 2010 at 6:38 PM, Ryan Harper wrote:
> Create a new attribute for virtio-blk devices that will fetch the serial
> number
> of the block device. This attribute can be used by udev to create disk/by-id
> symlinks for devices that don't have a UUID (filesystem) associated with them.
On Sat, Jun 19, 2010 at 10:58 AM, Ulrich Drepper wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/19/2010 01:24 AM, Blue Swirl wrote:
>>> +static inline int serial_sysfs(char *d, char *s, int n)
>>> +{
>>> + char *di = d;
>>
&g
On Wed, Aug 4, 2010 at 10:32 PM, Eduard - Gabriel Munteanu
wrote:
> Hi,
>
> I hope I solved the issues raised by Anthony and Paul.
>
> Please have a look and tell me what you think. However, don't merge it yet (in
> case you like it), I need to test and cleanup some pieces further. There are
> als
On Wed, Aug 4, 2010 at 10:32 PM, Eduard - Gabriel Munteanu
wrote:
> PCI devices should access memory through pci_memory_*() instead of
> cpu_physical_memory_*(). This also provides support for translation and
> access checking in case an IOMMU is emulated.
>
> Memory maps are treated as remote IOT
On Wed, Aug 4, 2010 at 10:32 PM, Eduard - Gabriel Munteanu
wrote:
> This introduces emulation for the AMD IOMMU, described in "AMD I/O
> Virtualization Technology (IOMMU) Specification".
>
> Signed-off-by: Eduard - Gabriel Munteanu
> ---
> Makefile.target | 2 +
> configure | 10 +
>
Thanks, applied.
On Sat, Aug 14, 2010 at 11:47 PM, Cam Macdonell wrote:
> Signed-off-by: Cam Macdonell
> ---
> kvm-stub.c | 5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/kvm-stub.c b/kvm-stub.c
> index 3378bd3..d45f9fa 100644
> --- a/kvm-stub.c
> +++ b/kvm-stub
Thanks, applied.
On Sat, Aug 14, 2010 at 11:47 PM, Cam Macdonell wrote:
> Signed-off-by: Cam Macdonell
> ---
> Makefile.target | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/Makefile.target b/Makefile.target
> index b791492..c8281e9 100644
> --- a/Makefile.target
On Sun, Aug 15, 2010 at 7:27 PM, Eduard - Gabriel Munteanu
wrote:
> This introduces emulation for the AMD IOMMU, described in "AMD I/O
> Virtualization Technology (IOMMU) Specification".
>
> Signed-off-by: Eduard - Gabriel Munteanu
> ---
> Makefile.target | 2 +
> hw/amd_iommu.c | 688
> ++
On 12/5/08, Anthony Liguori <[EMAIL PROTECTED]> wrote:
> glibc implements posix-aio as a thread pool and imposes a number of
> limitations.
>
> 1) it limits one request per-file descriptor. we hack around this by
> dup()'ing
> file descriptors which is hideously ugly
>
> 2) it's impossible to
On 12/12/08, Andrea Arcangeli wrote:
> From: Andrea Arcangeli
>
> One major limitation for KVM today is the lack of a proper way to write
> drivers
> in a way that allows the host OS to use direct DMA to the guest physical
> memory
> to avoid any intermediate copy. The only API provided to d
On 12/12/08, Andrea Arcangeli wrote:
> From: Andrea Arcangeli
>
> Add can_dma and post_dma methods needed before/after direct IO to guest
> physical memory.
>
> Signed-off-by: Andrea Arcangeli
> +/* nonlinear range */
> +if (pd_first != pd)
> +return NULL;
In
On 12/12/08, Anthony Liguori wrote:
> Blue Swirl wrote:
>
> > On 12/12/08, Andrea Arcangeli wrote:
> >
> >
> > > From: Andrea Arcangeli
> > >
> > > Add can_dma and post_dma methods needed before/after direct IO to guest
> > > p
On 12/14/08, 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 configuration etc.
I
On 12/15/08, Anthony Liguori wrote:
> Avi Kivity wrote:
>
> > Anthony Liguori wrote:
> >
> > > I've thought quite a bit about it, and I'm becoming less convinced that
> this sort of API is going to be helpful.
> > >
> > > I was thinking that we need to make one minor change to the map API I
> prop
On 12/16/08, Anthony Liguori wrote:
> Blue Swirl wrote:
>
> > I changed the ESP SCSI and Lance Ethernet on Sparc32 to resolve the IO
> > address to physical memory (see patch). ESP works (no zero copy yet),
> > Lance doesn't. It looks much better. Because the resolv
On 12/16/08, Laurent Vivier wrote:
> This patch adds to qemu the function needed to display a splash image under
> BIOS control through the firmware control device.
>
> It adds a "-splash" option allowing to specify the picture file name (a .PNG)
> to display. You can enable/disable a fade in,
On 12/16/08, Paul Brook wrote:
> > 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 i
On 12/16/08, Avi Kivity wrote:
> Anthony Liguori wrote:
>
> >
> > > There are still some issues I'm not happy yet:
> > > - handling of access violations: resolving should stop before the bad
> > > page, the transfers should be done until that and then post error.
> > > - bounce buffers needed for
On 12/16/08, Anthony Liguori wrote:
> Avi Kivity wrote:
>
> > Blue Swirl wrote:
> >
> > >
> > > > I don't understand. It's not a device that needs bouncing, it's a
> > > > particular transfer. This could be either due to the tra
On 12/16/08, Laurent Vivier wrote:
> This series of patches adds a nice BIOS startup splash screen.
>
> It adds a "-splash" option allowing to specify the picture file name (a
> 640x480 (or less) and true color PNG) to display. You can enable/disable fade
> in,
> fade out and bootmenu. The tim
On 12/16/08, Anthony Liguori wrote:
> Blue Swirl wrote:
>
> > On 12/16/08, Laurent Vivier wrote:
> >
> >
> > > This series of patches adds a nice BIOS startup splash screen.
> > >
> > > It adds a "-splash" option allowing to specif
On 12/18/08, Glauber Costa wrote:
> Since now we have our own memory read/write function, we don't
> depend on all of tcg data structures anymore. So, instead of filling
> them up, bypass it altogether by using kvm_set_phys mem alone.
>
> To do that, we now have to provide our own way to get pa
On 12/19/08, Anthony Liguori wrote:
> Blue Swirl wrote:
>
> > On 12/18/08, Glauber Costa wrote:
> >
> >
> > > Since now we have our own memory read/write function, we don't
> > > depend on all of tcg data structures anymore. So, instead of fillin
On 12/22/08, Glauber Costa wrote:
> >> It really does though. The way physical memory is registered and managed
> >> is TCG specific right now. It has deep hooks for invalidating
> >> TranslationBlock's, and the table structure is designed to be conducive to
> >> the access patterns of TCG.
On 12/27/08, Lennert Buytenhek wrote:
> On Sat, Dec 27, 2008 at 07:52:39PM +, Frederik Himpe wrote:
>
> > Mandriva is now using the -Werror=format-security CFLAG by default. To
> > make kvm 82 compile with this option, I had to apply this patch:
> >
> http://svn.mandriva.com/cgi-bin/viewvc
On 2/3/09, Alex Williamson wrote:
> Make use of the new RX_MODE control virtqueue class by dropping
> packets the guest doesn't want to see.
>
> Signed-off-by: Alex Williamson
> +static uint8_t bcast[] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
'const'?
--
To unsubscribe from this list: sen
On 5/28/08, Glauber Costa <[EMAIL PROTECTED]> wrote:
> We change interrupt functions so they have the same
> signature, getting only an env parameter. When necessary,
> some more attributed were added to the relevant CPUState to
> make it possible.
> -#elif defined(TARGET_SPARC)
> -
On Fri, Dec 28, 2012 at 10:32 AM, Jason Wang wrote:
> This patch implements both userspace and vhost support for multiple queue
> virtio-net (VIRTIO_NET_F_MQ). This is done by introducing an array of
> VirtIONetQueue to VirtIONet.
>
> Signed-off-by: Jason Wang
> ---
> hw/virtio-net.c | 318
> +
On Fri, Dec 28, 2012 at 10:31 AM, Jason Wang wrote:
> This patch adds basic multiqueue support for qemu. The idea is simple, an
> array
> of NetClientStates were introduced in NICState, parse_netdev() were extended
> to
> find and match all NetClientStates belongs to the backend and place their
On Fri, Jan 4, 2013 at 5:12 AM, Jason Wang wrote:
> On 12/29/2012 01:52 AM, Blue Swirl wrote:
>> On Fri, Dec 28, 2012 at 10:32 AM, Jason Wang wrote:
>>> This patch implements both userspace and vhost support for multiple queue
>>> virtio-net (VIRTIO_NET_F_MQ). Thi
On Fri, Jan 4, 2013 at 2:52 PM, Eduardo Habkost wrote:
> This is a cleanup that tries to solve two small issues:
>
> - We don't need a separate kvm_pv_eoi_features variable just to keep a
>constant calculated at compile-time, and this style would require
>adding a separate variable (that'
On Fri, Jan 4, 2013 at 2:52 PM, Eduardo Habkost wrote:
> The kvm_mmu_op feature was removed from the kernel since v3.3 (released
> in March 2012), it was marked for removal since January 2011 and it's
> slower than shadow or hardware assisted paging (see kernel commit
> fb92045843). It doesn't mak
On Fri, Jan 4, 2013 at 3:37 PM, Eduardo Habkost wrote:
> The -cpu check/enforce warnings are printing incorrect information about the
> missing flags. There are no feature flags on CPUID leaves 0 and 0x8000,
> but
> there were references to 0 and 0x8000 in the table at
> kvm_check_feature
On Wed, Jan 9, 2013 at 6:26 AM, Pandarathil, Vijaymohan R
wrote:
> - Create eventfd per vfio device assigned to a guest and register an
> event handler
>
> - This fd is passed to the vfio_pci driver through a new ioctl
>
> - When the device encounters an error, th
201 - 270 of 270 matches
Mail list logo
