Re: bhyve: can't to passthru bge(4) card
Hi Sergey, On Mon, Jan 20, 2014 at 11:43 AM, Sergey Matveychuk wrote: > Hi. > > I try to passthru bge: > % pciconf -vl > ... > ppt0@pci0:3:0:1:class=0x02 card=0x169d103c chip=0x165714e4 > rev=0x01 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'NetXtreme BCM5719 Gigabit Ethernet PCIe' > class = network > subclass = ethernet > ... > % cat /boot/loader.conf > vmm_load="yes" > pptdevs="3/0/1" > > % bhyve -c ${VM_CPUNUM} -m ${VM_MEMSIZE} -AI -HP -g0 \ > -s 0:0,hostbridge \ > -s 3:0,passthru,3/0/1 \ > -s 2:0,virtio-blk,${VM_DISK} \ > -S 31,uart,${VM_CONSOLE} \ > ${VM_NAME} > I suspect that this is because the function number of the virtual PCI device and the physical PCI device are different. Could you try to use the following instead: -s 2:1,passthru,3/0/1 Alternatively you could try assigning the physical PCI device 3/0/0: -s 3:0,passthru,3/0/0 best Neel > And I got this on boot: > > bge0: mem > 0xc001-0xc001,0xc002-0xc002,0xc003-0xc003 irq 36 at > device 3.0 on pci0 > bge0: APE FW version: NCSI v1.0.60.0 > bge0: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E > bge0: Try again > bge0: Try again > bge0: Try again > bge0: Try again > bge0: attaching PHYs failed > device_attach: bge0 attach returned 6 > > I used this as an instruction: https://wiki.freebsd.org/bhyve/pci_passthru > ___ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to > "freebsd-virtualization-unsubscr...@freebsd.org" ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: KVM Clock
John Baldwin wrote: >There is the __compiler_membar() macro in that you could >use if >this code is x86-specific (and thus knows it only needs a compiler >barrier). Ah. Thanks. This will do. Something like access_once would be perfect, though. I'll post an updated patch that does not duplicate code that is in xen/ soonish. Didn't get around to testing it the last days. Julian -- Out of office. Please excuse my brevity. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: bhyve: reboot stops vm
On Mon, Jan 20, 2014 at 6:31 PM, Sergey Matveychuk wrote: > Hi. > > Is it expected behaviour? > > sem@vm0[17]% sudo reboot > Jan 21 07:27:51 vm0 reboot: rebooted by sem > Jan 21 07:27:51 vm0 syslogd: exiting on signal 15 > Waiting (max 60 seconds) for system process `vnlru' to stop...done > Waiting (max 60 seconds) for system process `bufdaemon' to stop...done > Waiting (max 60 seconds) for system process `syncer' to stop... > Syncing disks, vnodes remaining...2 0 done > All buffers synced. > Uptime: 1m17s > Rebooting... > cpu_reset: Stopping other CPUs > root@bhyve[36]# > Yes it is... -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: bhyve: reboot stops vm
On Tue, 21 Jan 2014 03:31:40 +0400 Sergey Matveychuk wrote: > Hi. > > Is it expected behaviour? > > sem@vm0[17]% sudo reboot > Jan 21 07:27:51 vm0 reboot: rebooted by sem > Jan 21 07:27:51 vm0 syslogd: exiting on signal 15 > Waiting (max 60 seconds) for system process `vnlru' to stop...done > Waiting (max 60 seconds) for system process `bufdaemon' to stop...done > Waiting (max 60 seconds) for system process `syncer' to stop... > Syncing disks, vnodes remaining...2 0 done > All buffers synced. > Uptime: 1m17s > Rebooting... > cpu_reset: Stopping other CPUs > root@bhyve[36]# Yes -- Michael Gmelin ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
bhyve: reboot stops vm
Hi. Is it expected behaviour? sem@vm0[17]% sudo reboot Jan 21 07:27:51 vm0 reboot: rebooted by sem Jan 21 07:27:51 vm0 syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...2 0 done All buffers synced. Uptime: 1m17s Rebooting... cpu_reset: Stopping other CPUs root@bhyve[36]# ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: KVM Clock
On Wednesday 15 January 2014 17:59:10 Julian Stecklina wrote: > On Mi, 2014-01-15 at 17:04 +0100, Roger Pau Monné wrote: > > On 15/01/14 14:45, Julian Stecklina wrote: > > > On Mi, 2014-01-15 at 14:08 +0100, Roger Pau Monné wrote: > > >> On 15/01/14 13:05, Julian Stecklina wrote: > > >>> On 01/14/2014 05:13 PM, Peter Grehan wrote: > > Hi Julian, > > > > > is anyone working on KVM clock support for FreeBSD? If not, I > > > might take a shot at it. > > > > None I know of: go for it :) > > >>> > > >>> Works for me so far: > > >>> https://github.com/blitz/freebsd/commit/cdc5f872b3e48cc0dda031fc7d6bde > > >>> dc65c3148f> >> > > >> Looking > > >> > > >> at the code it seems some common routines could be shared > > >> between the KVM PV clock and the Xen PV clock > > >> (sys/dev/xen/timer/timer.c). The data passed from the hypervisor to > > >> the guest has exactly the same format (see struct vcpu_time_info in > > >> Xen public headers). > > > > > > Yes, I know. Didn't get around to making it pretty yesterday evening. ;) > > > I'll post an updated patch, when I have some time. Any suggestions where > > > to put the two common functions? > > > > > >> At a first sight the KVM clock can benefit from using scale_delta > > >> (which is going to be faster than the C version implemented in > > >> kvmclock_get_timecount), > > > > > > At least somewhat on amd64. 32-bit looks pretty identical. > > > > > >> and xen_fetch_vcpu_tinfo is exactly the same > > >> > > >> as kvmclock_fetch. > > > > > > I think xen_fetch_vcpu_tinfo has a subtle bug: > > > 217 do { > > > 218 dst->version = src->version; > > > 219 rmb(); > > > 220 dst->tsc_timestamp = src->tsc_timestamp; > > > 221 dst->system_time = src->system_time; > > > 222 dst->tsc_to_system_mul = src->tsc_to_system_mul; > > > 223 dst->tsc_shift = src->tsc_shift; > > > 224 rmb(); > > > 225 } while ((src->version & 1) | (dst->version ^ > > > > > > src->version)); > > > > > > In line 225 src->version is potentially read twice. If you consider the > > > following schedule: > > > > > > host starts updating data, sets src->version to 1 > > > guest reads src->version (1) and stores it into dst->version. > > > guest copies inconsistent data > > > guest reads src->version (1) and computes xor with dst->version. > > > host finishes updating data and sets src->version to 2 > > > guest reads src->version (2) and checks whether lower bit is not set. > > > while loop exits with inconsistent data! > > > > > > I think the C standard (at least C11) permits this as it does not > > > specify in which order the two reads in line 225 need to happen. > > > > According to the operator precedence and associativity in C > > (http://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B#Operator_preceden > > ce), if I'm reading it right, the condition in the while line will be > > evaluated as follows (because of the left-to-right associativity of the > > > > | operator): > > 1. (src->version & 1) > > 2. (dst->version ^ src->version) > > 3. result of 1 | result of 2 > > > > So AFAICT the flow that you describe could never happen, because > > (src->version & 1) is always done before (dst->version ^ src->version). > > Operator precedence doesn't matter. Consider it written like this: > > or(and(src->version, 1), xor(dst->version, src->version)) > > C gives you no guarantees whether the and or the xor will be executed > first. There is no sequence point in between. And even with a sequence > point, the C11 memory model gives you no guarantees about how the reads > are ordered. > > This discussion is somewhat theoretical, because > a) the hypervisor will probably update the data structure in the > current vCPU context (making memory consistency issues go away). > b) the compiler will likely not be an asshole. ;) > > Pseudocode for a better fetch could be: > > dst->version = src->version; > rmb(); > ... read data ... > rmb(); > version_post = src->version; > rmb(); <- keeps the compiler from reading src->version multiple times > > and then doing the test with version_post and dst->version. > Unfortunately, rmb() expands into lfence, even if there is no need for > that here. There is the __compiler_membar() macro in that you could use if this code is x86-specific (and thus knows it only needs a compiler barrier). -- John Baldwin ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Fwd: bhyve: can't to passthru bge(4) card
-- Forwarded message -- From: Aryeh Friedman Date: Mon, Jan 20, 2014 at 3:01 PM Subject: Re: bhyve: can't to passthru bge(4) card To: Sergey Matveychuk A question if you make the NIC the bridge device in PetiteCloud (we will have physical NIC support in the next few tertiary versions but for now your stuck with something like the manual version above) does it work any better I suspect you have the networking set up wrong before calling bhyve On Mon, Jan 20, 2014 at 2:43 PM, Sergey Matveychuk wrote: > Hi. > > I try to passthru bge: > % pciconf -vl > ... > ppt0@pci0:3:0:1:class=0x02 card=0x169d103c chip=0x165714e4 > rev=0x01 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'NetXtreme BCM5719 Gigabit Ethernet PCIe' > class = network > subclass = ethernet > ... > % cat /boot/loader.conf > vmm_load="yes" > pptdevs="3/0/1" > > % bhyve -c ${VM_CPUNUM} -m ${VM_MEMSIZE} -AI -HP -g0 \ > -s 0:0,hostbridge \ > -s 3:0,passthru,3/0/1 \ > -s 2:0,virtio-blk,${VM_DISK} \ > -S 31,uart,${VM_CONSOLE} \ > ${VM_NAME} > > And I got this on boot: > > bge0: mem > 0xc001-0xc001,0xc002-0xc002,0xc003-0xc003 irq 36 > at device 3.0 on pci0 > bge0: APE FW version: NCSI v1.0.60.0 > bge0: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E > bge0: Try again > bge0: Try again > bge0: Try again > bge0: Try again > bge0: attaching PHYs failed > device_attach: bge0 attach returned 6 > > I used this as an instruction: https://wiki.freebsd.org/bhyve/pci_passthru > ___ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to "freebsd-virtualization- > unsubscr...@freebsd.org" > -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
bhyve: can't to passthru bge(4) card
Hi. I try to passthru bge: % pciconf -vl ... ppt0@pci0:3:0:1:class=0x02 card=0x169d103c chip=0x165714e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme BCM5719 Gigabit Ethernet PCIe' class = network subclass = ethernet ... % cat /boot/loader.conf vmm_load="yes" pptdevs="3/0/1" % bhyve -c ${VM_CPUNUM} -m ${VM_MEMSIZE} -AI -HP -g0 \ -s 0:0,hostbridge \ -s 3:0,passthru,3/0/1 \ -s 2:0,virtio-blk,${VM_DISK} \ -S 31,uart,${VM_CONSOLE} \ ${VM_NAME} And I got this on boot: bge0: mem 0xc001-0xc001,0xc002-0xc002,0xc003-0xc003 irq 36 at device 3.0 on pci0 bge0: APE FW version: NCSI v1.0.60.0 bge0: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E bge0: Try again bge0: Try again bge0: Try again bge0: Try again bge0: attaching PHYs failed device_attach: bge0 attach returned 6 I used this as an instruction: https://wiki.freebsd.org/bhyve/pci_passthru ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
RE: LOCAL MAP OPTIMIZATION FOR : mail-archive.com (Less Than $99/Month)
Good Morning Sir / Mam Is your business ranking in local maps shown on PAGE 1 of google ? With new google policies they have specifically asked local business owners to optimize their website for local maps rather than JUST organics. Do you know the reason why you are not ranked well on google MAPs or why there is drop in your website rankings? Prime reason for bad rankings for a busniess is lack of local presence and local citations ie getting your business listed on directories like YELP, MANTA & Many more. These websites not just give your business a push but also help you Maintain a good Online Reputation. Why you need to optimize your website for local MAP Listings ? - MAP listings get 10 times more clicks than organic listings - Increased conversions because of real reviews posted on your Google Plus Page - Every year there is 30% increase in searches for local keywords - Increases legitimacy of a Business We will help you get your website ranked well on google for the related keywords in your niche. We specialize in LOCAL SEARCH ENGINE OPTIMIZATION increasing visibility for small businesses by ranking them for geographically-related keywords. Say for eg-: you want to search a plumber in your city, You will be typing in keywords like Plumbers + City Or Plumbers + IN + City. We make sure your website comes in google MAP listings shown on page 1 for each such keyword. Now Google believes in - BE ORIGINAL, HAVE ORIGINAL AND GIVE ORIGINAL which means that google wants to end up that frustrating experience of users who are searching for Service Or Product and seeing the results that are not even close to what they are looking for. Google only wants to give their user original and relevant results. This makes it even more important that we showcase our business in the best possible way and make sure our website in valued high by google. We at TheLOCALIST will make google feel the importance of your business by following their guidelines thus ranking your website higher in serach results. We are presently offering LOCAL OPTIMIZATION to more than 400 websites and they all rank page 1 for all possible keywords !!! Each month your website is submitted to more than 50 citations and social presence is controlled by posting videos and blogs all over the web. Email us back with your website & phone number so we can discuss this further with you. Our Packages start from as low as 99$/month. Thanks For Taking Time To Read Our Email Polly Martin Local SEO Manager ( THE Localist ) Address : 24 ST Suite 32 Downtown Provo Utah --- NOT INTERESTED ? REPLY WITH NOT INTERESTED IN THE SUBJECT LINE ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Current problem reports assigned to freebsd-virtualization@FreeBSD.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o kern/165252 virtualization[vimage] [pf] [panic] kernel panics with VIMAGE and PF o kern/161094 virtualization[vimage] [pf] [panic] kernel panic with pf + VIMAGE wh o kern/160541 virtualization[vimage][pf][patch] panic: userret: Returning on td 0x o kern/160496 virtualization[vimage] [pf] [patch] kernel panic with pf + VIMAGE o kern/148155 virtualization[vimage] [pf] Kernel panic with PF + VIMAGE kernel opt a kern/147950 virtualization[vimage] [carp] VIMAGE + CARP = kernel crash s kern/143808 virtualization[pf] pf does not work inside jail 7 problems total. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"