.
>
> Juergen Gross <jgr...@suse.com> writes:
>
>> Mails to chr...@sous-sol.org are not deliverable since several months.
>> Drop him as PARAVIRT_OPS maintainer.
>>
>> Signed-off-by: Juergen Gross <jgr...@suse.com>
Acked-by: Chris Wright <chr...@redhat.c
Acked-by: Chris Wright <chr...@redhat.com>
;)
thanks,
-chris
On Oct 26, 2017 7:41 PM, "Rusty Russell" <ru...@rustcorp.com.au> wrote:
> Chris CC'd: He wasn't that hard to find.
>
> (linkedin says he's CTO of RedHat now. I feel like an underachiever!)
>
&g
Hi all,
This list is run as a moderated list to minimize spam (gets a decent
amount despite filtering). I've tended to this for years, and I'd
like to add some folks from community to help so that posts are
quickly approved. Please let me know if you'd like to help.
thanks,
-chris
Following on the heels of a successful KVM Forum and oVirt Workshop,
FOSDEM will be hosting a Virtualization DevRoom in February. If you've
been to FOSDEM before, you know this is about developers and code, not
products.
Presentation proposals are due by December 16th 2012.
The full details are
* Chris Wright (chr...@redhat.com) wrote:
We were also able to video the speakers, and will send a note when the
videos are available.
(and thanks again to Andrew Cathrow for making this happen)
I don't think a note went out yet. The videos are available as well.
thanks,
-chris
KVM Forum 2010 was quite a success, many thanks to all who participated!
For those who couldn't attend, the presentations are available online now:
(thanks to Andrew Cathrow for pushing them all up)
http://www.linux-kvm.org/page/KVM_Forum_2010#Presentations
We were also able to video the
* Pankaj Thakkar (pthak...@vmware.com) wrote:
We intend to upgrade the upstreamed vmxnet3 driver to implement NPA so that
Linux users can exploit the benefits provided by passthrough devices in a
seamless manner while retaining the benefits of virtualization. The document
below tries to answer
This looks like an error case, but it's just a special case to shutdown
the backend. Clarify with a comment.
Signed-off-by: Chris Wright chr...@redhat.com
---
drivers/vhost/net.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
Trivial change, just for readability. The filp is not installed on
failure, so the current code is not incorrect (also vhost_dev_init
currently has no failure case). This just treats setting f-private_data
as something with global scope (sure, true only after fd_install).
Signed-off-by: Chris
such devices.
Signed-off-by: Alok N Kataria akata...@vmware.com
Looks in good shape to me.
Reviewed-by: Chris Wright chr...@sous-sol.org
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org
* Shreyas Bhatewara (sbhatew...@vmware.com) wrote:
Some of the features of vmxnet3 are :
PCIe 2.0 compliant PCI device: Vendor ID 0x15ad, Device ID 0x07b0
INTx, MSI, MSI-X (25 vectors) interrupts
16 Rx queues, 8 Tx queues
Driver doesn't appear to actually support more
* Alok Kataria (akata...@vmware.com) wrote:
On Mon, 2009-09-28 at 19:25 -0700, H. Peter Anvin wrote:
On 09/28/2009 05:45 PM, Alok Kataria wrote:
+ bool VMI Guest support [will be deprecated soon]
+ default n
This is incorrect use of the word deprecated... it's *already*
-by: Chris Wright chr...@sous-sol.org
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
* Bhavesh Davda (bhav...@vmware.com) wrote:
Hi Chris,
Thanks a bunch for your really thorough review! I'll answer some of your
questions here. Shreyas can respond to your comments about some of the coding
style/comments/etc. in a separate mail.
The style is less important at this stage,
* Bhavesh Davda (bhav...@vmware.com) wrote:
Thanks a bunch for your really thorough review! I'll answer some of
your questions here. Shreyas can respond to your comments about some of
the coding style/comments/etc. in a separate mail.
The style is less important at this stage, but
* Stephen Hemminger (shemmin...@vyatta.com) wrote:
On Mon, 21 Sep 2009 16:37:22 +0930
Rusty Russell ru...@rustcorp.com.au wrote:
Actually this framework can apply to traditional network adapters which
have
just one tx/rx queue pair. And applications using the same user/kernel
. These functions
have been around since the beginning, so are backwards compatible with
all older kernel versions.
Cc: xen-de...@lists.xensource.com
Cc: virtualizat...@lists.osdl.org
Cc: Chris Wright chr...@sous-sol.org
Cc: Jeremy Fitzhardinge jer...@xensource.com
Signed-off-by: Greg Kroah-Hartman
the beginning, so are backwards compatible with
all older kernel versions.
Cc: xen-de...@lists.xensource.com
Cc: virtualizat...@lists.osdl.org
Cc: Chris Wright chr...@sous-sol.org
Cc: Jeremy Fitzhardinge jer...@xensource.com
Signed-off-by: Greg Kroah-Hartman gre...@suse.de
Acked-by: Chris Wright chr
* Greg KH (g...@kroah.com) wrote:
On Thu, Apr 30, 2009 at 03:35:35PM -0700, Chris Wright wrote:
* Greg Kroah-Hartman (gre...@suse.de) wrote:
In the near future, the driver core is going to not allow direct access
to the driver_data pointer in struct device. Instead, the functions
* Ingo Molnar (mi...@elte.hu) wrote:
* Chris Wright chr...@sous-sol.org wrote:
* Arkadiusz Miskiewicz (a.miskiew...@gmail.com) wrote:
On Friday 03 of April 2009, Chris Wright wrote:
* Arkadiusz Miskiewicz (a.miskiew...@gmail.com) wrote:
What about
* Arkadiusz Miskiewicz (a.miskiew...@gmail.com) wrote:
What about 9ea09af3bd3090e8349ca2899ca2011bd94cda85 ?
stop_machine: introduce stop_machine_create/destroy.
That is later fixed in a0e280e0f33f6c859a235fb69a875ed8f3420388.
Can you please verify if 2.6.29 works for you? Your bisects are
* Arkadiusz Miskiewicz (a.miskiew...@gmail.com) wrote:
and this as bad commit:
7f7ace0cda64c99599c23785f8979a072e118058 is first bad commit
Does it make any difference if you roll fwd a couple commits to:
802bf931f2688ad125b73db597ce63cc842fb27a
That fixes a possible problem with the
* Rafael J. Wysocki (r...@sisk.pl) wrote:
This may be caused by the recent PM changes. Can you please test if commit
8efb8c76fcdccf5050c0ea059dac392789baaff2 is fine?
I just tested on my t400, it's not[1]. See same symptoms as Arkadiusz.
Seems as if it responds to initial apci event, I see
* Rafael J. Wysocki (r...@sisk.pl) wrote:
On Wednesday 01 April 2009, Chris Wright wrote:
* Rafael J. Wysocki (r...@sisk.pl) wrote:
This may be caused by the recent PM changes. Can you please test if
commit
8efb8c76fcdccf5050c0ea059dac392789baaff2 is fine?
I just tested on my
* Rafael J. Wysocki (r...@sisk.pl) wrote:
Sorry for the misunderstanding, I thought the breakage might be introduced
between 15f7176eb1cccec0a332541285ee752b935c1c85 and
0a0c5168df270a50e3518e4f12bddb31f8f5f38f, so I thought it would be a good
idea to verify if
in a 64MB guest causes reproducible
pagetable corruption.
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
Cc: jer...@xensource.com
Cc: virtualizat...@lists.osdl.org
Cc: sta...@kernel.org
Signed-off-by: Chris Wright chr...@sous-sol.org
---
arch/x86/lguest/boot.c | 10 +-
1 file
* Rusty Russell ([EMAIL PROTECTED]) wrote:
+ /* No real sector limit. */
+ blk_queue_max_sectors(vblk-disk-queue, -1U);
+
Is that actually legitimate? I think it'd still work out, but seems
odd, e.g. all the spots that do:
q-max_hw_sectors 9
will just toss the upper bits...
* Greg KH ([EMAIL PROTECTED]) wrote:
+static int
+igb_virtual(struct pci_dev *pdev, int nr_virtfn)
+{
+ unsigned char my_mac_addr[6] = {0x00, 0xDE, 0xAD, 0xBE, 0xEF, 0xFF};
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ struct igb_adapter *adapter =
we really know what the One True Usage model is for VF
devices. Chris Wright has some ideas, I have some ideas and Yu Zhao has
some ideas. I bet there's other people who have other ideas too.
I'd love to hear those ideas.
First there's the question of how to represent the VF on the host
* Anthony Liguori ([EMAIL PROTECTED]) wrote:
We've already gone down the road of trying to make standard paravirtual
interfaces (via virtio). No one was sufficiently interested in
collaborating. I don't see why other paravirtualizations are going to
be much different.
The point is to
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
Hmm, I know paravirt-ops had an issue with mcount in the RT tree. I can't
remember the exact issues, but it did have something to do with the way
parameters were passed in.
Chris, do you remember what the issues were?
Yes, paravirt ops have a
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
On Thu, 3 Jan 2008, Chris Wright wrote:
Yes, paravirt ops have a well-specified calling convention (register
based). There was a cleanup that Andi did that caused the problem
because it removed all the fastcall annotations since -mregparm=3
* James Courtier-Dutton ([EMAIL PROTECTED]) wrote:
If one could directly expose a device to the guest, this feature could
be extremely useful for me.
Is it possible? How would it manage to handle the DMA bus mastering?
Yes it's possible (Xen supports pci pass through). Without an IOMMU
(like
* James Courtier-Dutton ([EMAIL PROTECTED]) wrote:
Ok, so I need to get a new CPU like the Intel Core Duo that has VT
features? I have an old Pentium 4 at the moment, without any VT features.
Depends on your goals. You can certainly give a paravirt Xen guest[1]
physical hardware without any VT
* Glauber de Oliveira Costa ([EMAIL PROTECTED]) wrote:
As alternatives what we have now, we can either keep the paravirt_ops as
it is now for the native case, just hooking the vsmp functions in place
of the normal one, (there are just three ops anyway), refill the
paravirt_ops entirely in
* Glauber de Oliveira Costa ([EMAIL PROTECTED]) wrote:
Only caveat, is that it has to be done before smp gets in the game, and
with interrupts disabled. (which makes the function in vsmp.c not eligible).
My current option is to force VSMP to use PARAVIRT, as said before, and
then fill
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
Add file pattern to MAINTAINER entry
Signed-off-by: Joe Perches [EMAIL PROTECTED]
diff --git a/MAINTAINERS b/MAINTAINERS
index e4e1cc3..8395aba 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5153,6 +5153,11 @@ M: [EMAIL PROTECTED]
L:
* Randy Dunlap ([EMAIL PROTECTED]) wrote:
On Mon, 13 Aug 2007 11:55:36 -0700 Chris Wright wrote:
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
+F: arch/i386/xen/
+F: drivers/*/xen-*front.c
+F: drivers/xen/
+F: include/asm-i386/xen/
+F: include/xen
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
I'm implementing a more efficient version of the Xen iret paravirt_op,
so that it can use the real iret instruction where possible. I really
need to get access to per-cpu variables, so I can set the event mask
state in the vcpu_info structure,
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
Yep, this patch gets rid of my spinning thread. I can't find this patch
or any discussion on marc.info; is there a better netdev list archive?
See the linkwatch bustage in git-net thread on netdev
If you are interested in trying the new paravirt_ops kernels, I've
created some packages and uploaded them to:
http://et.redhat.com/~chrisw/paravirt_ops/
There you'll find a yum repo (see yum.README for details) and an
INSTALL file for getting started. With this package you can use a
single
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
Eric W. Biederman wrote:
Then why you had to allocate enough pages to cause a failure has me stumped.
Perhaps there is some other bug?
Perhaps, but nothing comes to mind. I'll see what happens when I boot
this kernel on real hardware
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
Seems to work OK for native and Xen. I had to play a bit with the
paravirt-sched-clock patch to deal with the VMI changes. Zach, can you
check that it still works?
Here's what's working for me on UP. The boot cpu on UP is never getting
the
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
Yes, but unfortunately that is a nop:
/*
* Avoid unnecessary state transitions, as it confuses
* Geode / Cyrix based boxen.
*/
case CLOCK_EVT_MODE_SHUTDOWN:
if (evt-mode ==
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
Jeremy Fitzhardinge wrote:
Why not submit a patch to do what you need here? (The Geode comment is
a bit worrying though.)
Why should VMI add workaround into PIT code?
I'm not sure it's a workaround, seems more like a subtle diff (perhaps
it's
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
Seems to work OK for native and Xen. I had to play a bit with the
paravirt-sched-clock patch to deal with the VMI changes. Zach, can you
check that it still works?
Cool, thanks for the rebase. Here's some small fixes.
Minor issue with
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
Jeremy Fitzhardinge wrote:
Seems to work OK for native and Xen. I had to play a bit with the
paravirt-sched-clock patch to deal with the VMI changes. Zach, can you
check that it still works?
I'm on it.
Not sure about cycles_2_ns...
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
diff -r c02ab981c99c arch/i386/kernel/vmiclock.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/arch/i386/kernel/vmiclock.c Mon Apr 09 15:47:17 2007 -0700
@@ -0,0 +1,318 @@
+/*
+ * VMI paravirtual timer support routines.
+ *
+ * Copyright
* Eric W. Biederman ([EMAIL PROTECTED]) wrote:
Is it truly critical to inline any of these instructions?
I don't have any current measurements. But we'd been aiming
at getting irq_{en,dis}able to a simple memory write to pda.
But simplicity, maintenance, etc. win over trimming a couple
cycles,
49 matches
Mail list logo