On Wed, Mar 03, 2010 at 08:15:15AM -0600, Anthony Liguori wrote:
> On 03/02/2010 04:41 PM, Paul Brook wrote:
> >>The new function I'm proposing has the following semantics:
> >>
> >>- it always returns a persistent mapping
> >>- it never bounces
> >>- it will only fail if the mapping isn't ram
> >S
> > That sounds like it's likely to come back and bite you. The guest has no
> > idea which areas of ram happen to be contiguous on the host.
>
> Practically speaking, with target-i386 anything that is contiguous in
> guest physical memory is contiguous in the host address space provided
> it's ra
On 03/02/2010 04:41 PM, Paul Brook wrote:
The new function I'm proposing has the following semantics:
- it always returns a persistent mapping
- it never bounces
- it will only fail if the mapping isn't ram
So you're assuming that virtio rings are in ram that is not hot-pluggable
As lon
> The new function I'm proposing has the following semantics:
>
> - it always returns a persistent mapping
> - it never bounces
> - it will only fail if the mapping isn't ram
So you're assuming that virtio rings are in ram that is not hot-pluggable or
remapable, and the whole region is contiguou
On 03/02/2010 12:00 PM, Marcelo Tosatti wrote:
- it always returns a transient mapping
- it may (transparently) bounce
- it may fail to bounce, caller must deal
The new function I'm proposing has the following semantics:
What exactly are the purposes of the new function?
We need an
On Tue, Mar 02, 2010 at 10:56:48AM -0600, Anthony Liguori wrote:
> On 03/02/2010 10:12 AM, Marcelo Tosatti wrote:
> >On Sun, Feb 28, 2010 at 02:57:56PM -0600, Anthony Liguori wrote:
> >>On 02/28/2010 11:19 AM, Michael S. Tsirkin wrote:
> Both have security implications so I think it's importan
On Tue, Mar 02, 2010 at 10:56:48AM -0600, Anthony Liguori wrote:
> On 03/02/2010 10:12 AM, Marcelo Tosatti wrote:
>> On Sun, Feb 28, 2010 at 02:57:56PM -0600, Anthony Liguori wrote:
>>
>>> On 02/28/2010 11:19 AM, Michael S. Tsirkin wrote:
>>>
> Both have security implications so I th
On 03/02/2010 10:12 AM, Marcelo Tosatti wrote:
On Sun, Feb 28, 2010 at 02:57:56PM -0600, Anthony Liguori wrote:
On 02/28/2010 11:19 AM, Michael S. Tsirkin wrote:
Both have security implications so I think it's important that they
be addressed. Otherwise, I'm pretty happy with how t
On Tue, Mar 02, 2010 at 10:12:05AM -0600, Anthony Liguori wrote:
> On 03/02/2010 09:53 AM, Paul Brook wrote:
> The key difference is that these regions are created and destroyed
> rarely and in such a way that the destruction is visible to the guest.
> >>>So you're making ram unmap an async
On Sun, Feb 28, 2010 at 02:57:56PM -0600, Anthony Liguori wrote:
> On 02/28/2010 11:19 AM, Michael S. Tsirkin wrote:
> >>Both have security implications so I think it's important that they
> >>be addressed. Otherwise, I'm pretty happy with how things are.
> >Care suggesting some solutions?
>
>
On 03/02/2010 09:53 AM, Paul Brook wrote:
The key difference is that these regions are created and destroyed
rarely and in such a way that the destruction is visible to the guest.
So you're making ram unmap an asynchronous process, and requiring that
the address space not be reused unt
On Tue, Mar 02, 2010 at 03:53:30PM +, Paul Brook wrote:
> > >> The key difference is that these regions are created and destroyed
> > >> rarely and in such a way that the destruction is visible to the guest.
> > >
> > > So you're making ram unmap an asynchronous process, and requiring that
> >
> >> The key difference is that these regions are created and destroyed
> >> rarely and in such a way that the destruction is visible to the guest.
> >
> > So you're making ram unmap an asynchronous process, and requiring that
> > the address space not be reused until that umap has completed?
>
>
On 03/02/2010 08:55 AM, Paul Brook wrote:
With a new api, cpu_physical_memory_map() changes semantics. It only
returns pointers for static ram mappings. Everything else is bounced
which guarantees that an address can't change during DMA.
Doesn't this mean that only the initial RAM is
> >> With a new api, cpu_physical_memory_map() changes semantics. It only
> >> returns pointers for static ram mappings. Everything else is bounced
> >> which guarantees that an address can't change during DMA.
> >
> > Doesn't this mean that only the initial RAM is directly DMA-able?
> >
> > Whil
On 03/02/2010 08:33 AM, Paul Brook wrote:
I think this assumption is unsafe. There are machines where RAM mappings
can change. It's not uncommon for a chip select (i.e. physical memory
address region) to be switchable to several different sources, one of
which may be RAM. I'm pretty sure this fu
> > I think this assumption is unsafe. There are machines where RAM mappings
> > can change. It's not uncommon for a chip select (i.e. physical memory
> > address region) to be switchable to several different sources, one of
> > which may be RAM. I'm pretty sure this functionality is present (but
On 02/28/2010 04:39 PM, Paul Brook wrote:
I'm sympathetic to your arguments though. As qemu is today, the above
is definitely the right thing to do. But ram is always ram and ram
always has a fixed (albeit non-linear) mapping within a guest.
I think this assumption is unsafe. There are m
On Mon, Mar 01, 2010 at 03:54:00PM -0600, Anthony Liguori wrote:
> On 03/01/2010 01:27 PM, Michael S. Tsirkin wrote:
>> On Sun, Feb 28, 2010 at 10:39:21PM +, Paul Brook wrote:
>>
I'm sympathetic to your arguments though. As qemu is today, the above
is definitely the right thing t
On 03/01/2010 01:27 PM, Michael S. Tsirkin wrote:
On Sun, Feb 28, 2010 at 10:39:21PM +, Paul Brook wrote:
I'm sympathetic to your arguments though. As qemu is today, the above
is definitely the right thing to do. But ram is always ram and ram
always has a fixed (albeit non-linear) mapp
On Sun, Feb 28, 2010 at 10:39:21PM +, Paul Brook wrote:
> > I'm sympathetic to your arguments though. As qemu is today, the above
> > is definitely the right thing to do. But ram is always ram and ram
> > always has a fixed (albeit non-linear) mapping within a guest.
>
> I think this assumpt
> I'm sympathetic to your arguments though. As qemu is today, the above
> is definitely the right thing to do. But ram is always ram and ram
> always has a fixed (albeit non-linear) mapping within a guest.
I think this assumption is unsafe. There are machines where RAM mappings can
change. It's
On 02/28/2010 03:01 PM, Michael S. Tsirkin wrote:
On Sun, Feb 28, 2010 at 02:57:56PM -0600, Anthony Liguori wrote:
On 02/28/2010 11:19 AM, Michael S. Tsirkin wrote:
Both have security implications so I think it's important that they
be addressed. Otherwise, I'm pretty happy with ho
On Sun, Feb 28, 2010 at 02:57:56PM -0600, Anthony Liguori wrote:
> On 02/28/2010 11:19 AM, Michael S. Tsirkin wrote:
>>> Both have security implications so I think it's important that they
>>> be addressed. Otherwise, I'm pretty happy with how things are.
>>>
>> Care suggesting some soluti
On 02/28/2010 11:19 AM, Michael S. Tsirkin wrote:
Both have security implications so I think it's important that they
be addressed. Otherwise, I'm pretty happy with how things are.
Care suggesting some solutions?
The obvious thing to do would be to use the memory notifier in vhost
On Sun, Feb 28, 2010 at 10:08:26AM -0600, Anthony Liguori wrote:
> On 02/27/2010 01:44 PM, Michael S. Tsirkin wrote:
>>> and it doesn't
>>> support all of the features of userspace virtio. Since it's in upstream
>>> Linux without supporting all of the virtio-net features, it's something
>>> we're
On 02/27/2010 01:44 PM, Michael S. Tsirkin wrote:
and it doesn't
support all of the features of userspace virtio. Since it's in upstream
Linux without supporting all of the virtio-net features, it's something
we're going to have to deal with for a long time.
Speaking of vlan filtering etc
On Fri, Feb 26, 2010 at 09:23:01AM -0600, Anthony Liguori wrote:
> On 02/26/2010 08:51 AM, Michael S. Tsirkin wrote:
>> On Thu, Feb 25, 2010 at 01:47:27PM -0600, Anthony Liguori wrote:
>>
>>> On 02/25/2010 12:28 PM, Michael S. Tsirkin wrote:
>>>
This adds vhost binary option to tap,
On 02/26/2010 08:51 AM, Michael S. Tsirkin wrote:
On Thu, Feb 25, 2010 at 01:47:27PM -0600, Anthony Liguori wrote:
On 02/25/2010 12:28 PM, Michael S. Tsirkin wrote:
This adds vhost binary option to tap, to enable vhost net accelerator.
Default is off for now, we'll be able to make def
On Thu, Feb 25, 2010 at 01:47:27PM -0600, Anthony Liguori wrote:
> On 02/25/2010 12:28 PM, Michael S. Tsirkin wrote:
>> This adds vhost binary option to tap, to enable vhost net accelerator.
>> Default is off for now, we'll be able to make default on long term
>> when we know it's stable.
>>
>> vho
On 02/25/2010 12:28 PM, Michael S. Tsirkin wrote:
This adds vhost binary option to tap, to enable vhost net accelerator.
Default is off for now, we'll be able to make default on long term
when we know it's stable.
vhostfd option can be used by management, to pass in the fd. Assigning
vhostfd imp
31 matches
Mail list logo
